[llvm-dev] RFC: ELF Autolinking

[bd1976 llvm via llvm-dev]

On Thu, Mar 14, 2019 at 5:30 PM Peter Collingbourne <peter at pcc.me.uk> wrote:

>
>> I would like to propose that we focus on autolinking exclusively and that
>> we divorce the implementation from the idea of "linker options" which, by
>> nature, would tie source code to the vagaries of particular linkers. I
>> don't see much value in supporting other linker operations so I suggest
>> that the binary representation be a mergable string section (SHF_MERGE,
>> SHF_STRINGS), called .autolink, with custom type SHT_LLVM_AUTOLINK
>> (0x6fff4c04), and SHF_EXCLUDE set (to avoid the contents appearing in the
>> output).
>>
>
> Should we set SHF_EXCLUDE on the section? I think it may be better not to
> set it. The semantics of the bit are that the section will be excluded from
> the final output file, but there's no requirement that other sections are
> not excluded. For example SHT_REL(A) sections are interpreted by the linker
> and excluded from the output, but they do not have SHF_EXCLUDE set. The
> SHT_LLVM_AUTOLINK section could be treated similarly in compatible linkers.
> SHF_EXCLUDE is appropriate for sections that can be freely dropped without
> changing the semantics, such as the address significance table, but the
> autolink section is different because dropping it changes the semantics. By
> not setting the bit, we would cause incompatible linkers to leave the
> autolink section in the output file, which would allow downstream tools to
> be written that would detect (and possibly diagnose) such files.
>
> Peter
>

Great point Peter, accepted. I'm rather afraid to say that I just copied
the SHF_EXCLUDE from the existing .linker-options without thinking it
through. When I prototyped this up SHF_EXCLUDE doesn't actually buy you
much because you still need to special case SHT_LLVM_AUTOLINK for -r links
to undo the effect of SHF_EXCLUDE. Probably ELF needs some sort of EXCLUDED
but not for -r links flag.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190314/028b09b9/attachment.html>