[llvm-dev] RFC: ELF Autolinking

[bd1976 llvm via llvm-dev]

On Thu, Mar 14, 2019 at 5:28 PM Peter Collingbourne via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Thu, Mar 14, 2019 at 9:59 AM Rui Ueyama via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> On Thu, Mar 14, 2019 at 9:28 AM Reid Kleckner via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hi,
>>>
>>> I guess I agree it would be best to remove the objfile linker option
>>> support and replace it with just auto-linking. We already have a mechanism
>>> for adding new features to object files: .note sections. Linkers already
>>> know to ignore ones that they don't understand. If, in the future, we want
>>> to add a new feature that could be handled by embedding linker flags, we
>>> can instead implement it with a new .note section that other linkers and
>>> old versions of LLD will know to ignore.
>>>
>>> On top of that, the generic ABI group has previously rejected proposals
>>> to embed linker options in object files (
>>> https://groups.google.com/forum/#!topic/generic-abi/iS_-m-X5ZwQ).
>>>
>>> Given how ELF has done things in the past, maybe the section name should
>>> be ".note.autolink". We could also be like GCC and namespace our extensions
>>> as ".note.LLVM.autolink", but maybe that's a step too far.
>>>
>>
>> A .note section consists of a series of type-length-value records. My
>> understanding is that the static linker aggregates them to a single
>> location and put it into PT_NOTE segment, and the records can still be read
>> by the loader even after the section table is stripped from an executable.
>> For the proposed purpose, the note section header would not be useful or
>> meaningful, so a plain section that just contains an ASCII string would be
>> simpler.
>>
>
> I agree that this should not be a note section because the section is
> meaningless in a final linked executable.
>
> Note that the proposal is limited to adding -l flags only. I would not
> expect this particular section to be expanded in the future to cover other
> use cases; rather, we would likely invent more section types.
>
> Peter
>

Exactly. To be clear I am not opposing a mechanism to embed linker command
line options in input files, maybe someone does have a valid usecase for
this. I am basing my arguments in the RFC on the idea that the syntax does
matter, in the sense that #pragma comment(lib, "foo") seems to imply a
relatively "general" method of specifying a library to link, as opposed to
some imagined syntax like #pragma linker-commandline-option("--library",
"foo") which is specific to the command line options of a particular
linker. Also, given that it seems that autolinking is the only usecase
currently, the proposed .autolink section is a simpler (e.g. binary tools
can dump the section without needing special rules), and more efficient
(bytes needed to convey the information) format than something like
.linker-options.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190314/632c0b8a/attachment.html>