[llvm-dev] RFC: ELF Autolinking

[bd1976 llvm via llvm-dev]

On Thu, Mar 14, 2019 at 4:34 PM Rui Ueyama <ruiu at google.com> wrote:

> On Thu, Mar 14, 2019 at 6:08 AM bd1976 llvm via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> The linker will process the .autolink strings in the following way:
>>
>> 1. Inputs from the .autolink sections of a relocatable object file are
>> added when the linker decides to include that file (which could itself be
>> in a library) in the link. Autolinked inputs behave as if they were
>> appended to the command line as a group after all other options. As a
>> consequence the set of autolinked libraries are searched last to resolve
>> symbols.
>> 2. It is an error if a file cannot be found for a given string.
>> 3. Any command line options in effect at the end of the command line
>> parsing apply to autolinked inputs, e.g. --whole-archive.
>>
>
> I thought that the scope of this mechanism is essentially to add `-lfoo`
> automatically to the command line if you include a header that requires
> `libfoo`. From that perspective, the item 3 seems odd. Why do you need that?
>

I replied to Peter already on this; but, what I'm basically saying is that
if you had a command line like...

bob.o --whole-archive -lbar

... and bob.o was built with #pragma comment(lib, "foo"), then this
effectively is transformed into...

bob.o --whole-archive -lbar -lfoo

...and the --whole-archive applies to the -lfoo. The alternative that you
use some defaults when handling the autolinked libraries.


> 4. Duplicate autolinked inputs are ignored.
>>
>
> I'd say duplicate autolinked inputs are processed normally, but because of
> the same reason why  the second parameter in `-lfoo -lfoo` is basically
> no-op, duplicated autolinked inputs are naturally ignored.
>

Again, replied to Peter - .o files and I also want to leave the door open
for GNU to be able to implement this.


>
> 5. The linker tries to add a library or relocatable object file from each
>> of the strings in a .autolink section by; first, handling the string as if
>> it was specified on the commandline; second, by looking for the string in
>> each of the library search paths in turn; third, by looking for a
>> lib<string>.a or lib<string>.so (depending on the current mode of the
>> linker) in each of the library search paths.
>>
>
> Again, this seems like a little beyond the scope of what I expect (and it
> looks like you want to allow an .o file using this scheme).
>

Again, replied to Peter. I think that .o files should be included,
--library allows this.


> 6. A new command line option --no-llvm-autolink will tell LLD to ignore
>> the .autolink sections.
>>
>> Rationale for the above points:
>>
>> 1. Adding the autolinked inputs last makes the process simple to
>> understand from a developers perspective. All linkers are able to implement
>> this scheme.
>> 2. Error-ing for libraries that are not found seems like better behavior
>> than failing the link during symbol resolution.
>> 3. It seems useful for the user to be able to apply command line options
>> which will affect all of the autolinked input files. There is a potential
>> problem of surprise for developers, who might not realize that these
>> options would apply to the "invisible" autolinked input files; however,
>> despite the potential for surprise, this is easy for developers to reason
>> about and gives developers the control that they may require.
>> 4. Unlike on the command line it is probably easy to include the same
>> input file twice via pragmas and might be a pain to fix; think of
>> Third-party libraries supplied as binaries.
>> 5. This algorithm takes into account all of the different ways that ELF
>> linkers find input files. The different search methods are tried by the
>> linker in most obvious to least obvious order.
>> 6. I considered adding finer grained control over which .autolink inputs
>> were ignored (e.g. MSVC has /nodefaultlib:<library>); however, I concluded
>> that this is not necessary: if finer control is required developers can
>> recreate the same effect autolinking would have had using command line
>> options.
>>
>> Thoughts?
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190314/2838b75d/attachment.html>