This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [build, c++, lto] Support COMDAT group with Sun as (PR target/40483)


Jason Merrill <jason@redhat.com> writes:

> On 05/18/2010 04:06 PM, Rainer Orth wrote:
>> * For the next issue, first some background: unlike GNU as, which can
>>    declare COMDAT group sections in one go like this
>>
>> 	.section .text.foo,"axG",@progbits,foo,comdat
>>
>>    and defines the signature symbol itself as needed, Sun as needs
>>    separate declarations of the group and section as well as a definition
>>    of the group signature symbol
>
> The group signature needs to be a symbol name, not just any name?  Odd.

Right: see

	http://www.sco.com/developers/gabi/latest/ch4.sheader.html

Section Groups:

[...]
The name of a symbol from one of the containing object's symbol tables
provides a signature for the section group. The section header of the
SHT_GROUP section specifies the identifying symbol entry, as described
above: the sh_link member contains the section header index of the
symbol table section that contains the entry.

>> ** The C++ frontend generates an artificial identifier as group
>>     signature in cp/optimize.c (cdtor_comdat_group), which isn't ever
>>     defined (and doesn't demangle at all).  To solve that problem, I've
>>     decided to set a flag on that identifier which config/sol2.c
>>     (solaris_elf_asm_comdat_section) can use to decide if it needs to
>>     define the symbol.  I've chosen IDENTIFIER_CTOR_OR_DTOR_P since it
>>     seemed to make most sense and the obvious DECL_ARTIFICIAL cannot be
>>     set on an IDENTIFIER_NODE.  The complication is that I cannot simply
>>     include cp/cp-tree.h in sol2.c since all non-C++ compilers fail to
>>     link.  So I've cheated and use the underlying TREE_LANG_FLAG_3
>>     instead.  This is clearly a hack, but worked for me.
>
> Yeah, we clearly can't use TREE_LANG_FLAG in general.  There are still
> plenty of unused language-independent flags on IDENTIFIER_NODE, though it
> seems undesirable to use one for a corner case like this.

That's my thought as well.

> How about having sparc.c remember the names of comdat groups and then at
> EOF emit dummy definitions for any that don't have TREE_SYMBOL_REFERENCED
> set?

Might be an option as well.  I've not tried that yet.  At least it
avoids having to modify both the C++ and LTO front ends for what is
essentially a target problem.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]