[LLVMdev] lld Atoms from STT_SECTION type symbols.

Evandro Menezes emenezes at codeaurora.org
Tue Oct 2 09:45:58 PDT 2012


Sid,

It's a real problem when section GC is active.  It's not very common, 
but, typically, global constructors and destructors are the primary 
instances that may be incorrectly discarded.

The statement KEEP in GNU linker scripts specifies which sections should 
be kept in the final output even if GC judges that it could be discarded.

Perhaps, at this moment, it would suffice to provide an option to 
specify which sections must be kept.  Additionally, perhaps the ELF 
reader or writer could always keep the .init{.*,_array}, 
.fini{.*,_array} and preinit_array sections.

-- 
Evandro Menezes          Austin, TX          emenezes at codeaurora.org
Qualcomm Innovation Center, Inc is a member of the Code Aurora Forum


On 10/01/12 21:06, Sid Manning wrote:
>
> I committed a patch to update the ReaderELF.cpp that, in light of some
> recent changes in the writer, may need another update.  WriterELF is
> looking for atoms of type, typeFirstInSection (STT_SECTION) but the
> reader isn't classifying those yet.
>
> I know there has been some discussion about discarding symbols of type
> STT_SECTION but I don't think that is safe.  This section would never
> make it into the final executable:
>
>> .section .monkey, "a", @progbits
>>
>> .long 0xdeadbeef
>> .long 0xdeadbeef
>> .long 0xdeadbeef
>> .long 0xdeadbeef
>
> The above could be optionally garbage collected out but by default I
> think it should remain in the final output.  That is what gnu-ld would
> do unless -gc-section specified.
>
> At the moment this has a side-effect of extraneous zero-size entries in
> the section header.  As a rule it seems like section header 0 is the
> only section of zero size.
>
>



More information about the llvm-dev mailing list