[llvm-dev] Linker Option support for ELF

[Rafael Avila de Espindola via llvm-dev]

Saleem Abdulrasool via llvm-dev <llvm-dev at lists.llvm.org> writes:

>> On Jan 9, 2018, at 2:32 AM, James Henderson <jh7370.2008 at my.bristol.ac.uk> wrote:
>> 
>> By my understanding, the proposal is that the user input looks something like:
>> 
>> #pragma linker_directive("lib", "m")
>> 
>> which is passed essentially as is to the linker, i.e. the directive payload is a pair of strings, the first being "lib", the second "m". It is then up to the linker to decide if it supports "lib" directives, and translate that into the corresponding command, or do something else if it doesn't support it, e.g. emit an error or ignore it. Neither the backend nor the frontend need to do any conversion, and it makes it much clearer that these aren't like any other command-line option (due to the limited set that can be passed through, and the possible differences in behaviour, such as order on the command-line).
>> 
>> As an aside, this approach would aid portability to linkers that aren't command-line compatible with one another. If, for example, the switch is "-lib" on linker A, and "-l" on linker B, the user doesn't have to have different source code for each different linker their object is to be consumed by, nor does the compiler have to know about the different possible linkers.
>
> Okay, that seems reasonable enough.  I think I still like the simplicity of having it just be like a response file, but, this approach isn’t too bad for adding custom extensions to.  I do like that it gives greater portability to different linkers.
>
> The one last bit that still remains unanswered is the encoding.  Do we go forward with the abuse of the ELF notes or do is there enough confidence that adding a new section type shouldn’t break compatibility with older linkers?

Given how ELF works I would expect an unknown section to simply end up
in the output, but we can use SHF_EXCLUDE to avoid that.

So +1 for a new section type.

Cheers,
Rafael