[llvm-dev] Linker Option support for ELF

[Rui Ueyama via llvm-dev]

On Wed, Jan 10, 2018 at 9:04 AM, Rafael Avila de Espindola via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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.
>

+1

I feel .note sections (in particular .note.gnu namespace) are used too
casually. Once this proposal is accepted and implemented, we'll live with
that until ELF dies, so defining a new section type and then name the
section ".linker-options" or something without ".note." prefix and the note
section header seems better.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180110/a6d8ef9d/attachment.html>