[llvm-dev] Linker Option support for ELF

[Saleem Abdulrasool via llvm-dev]

On Wed, Jan 3, 2018 at 5:04 PM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:

> Saleem Abdulrasool <compnerd at compnerd.org> writes:
>
> > So you are suggesting that the backend take the opaque blob, peer through
> > it, map it to something else and then encode that?
>
> The llvm backend? No, it should probably be done by whatever produced
> the IR. If viewing this a part of the file format, having the FE create
> a metadata asking for (add_lib_enum_value, "foo.a") is not too different
> than than asking for a particular visibility or dll import.
>

Okay, so, that is a different conversation..  Im discussing purely the
encoding from LLVM IR -> object file.  The frontend changes would still
need to be made, and those can be discussed at that point.  Im suggesting
that we treat the current behavior similar to the PE/COFF and MachO
mechanism: it is effectively a response file.


>
> > This means that every
> > single new flag (also consider vendor extensions and non-GNU linkers)
> would
> > need their own mapping and would need additional support for every single
> > variant of an option.  This makes adding support for a flag extremely
> > expensive IMO.
>
> Is some sense that is the idea: forcing each feature to be documented
> and discussed. What feature other than "add that lib" do you have in mind?
>

What about trying to do something like the "-framework" option (thinking
along the various things that swift has to deal with, which don't exist
yet) or the embedded AST modules (for swift debugging) or additional search
paths.


> Cheers,
> Rafael
>

-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180103/ea713e8e/attachment-0001.html>