[llvm-dev] Linker Option support for ELF

Sean Silva via llvm-dev llvm-dev at lists.llvm.org
Sun Jan 7 19:55:02 PST 2018

On Jan 7, 2018 5:02 PM, "Cary Coutant via llvm-dev" <llvm-dev at lists.llvm.org>

> I think we all agree that blindly allowing the linker to honor the options
> would be scary.  I agree that we should whitelist the options, and am of
> opinion that we should force validation on the linker side (use of any
> option which the linker doesn't support in this form can be fatal).
> Starting small is the best way, with `-l` and `-L` as a starting point.  I
> want to retain the ability to add additional options which may not be
> available in all linkers.  However, whitelisting obviously requires
> with the linker as would adding such options, so that could be handled at
> that time.

This is actually why I'd prefer a new "language" over just
whitelisting options. With "lib", "file", and "path", as I suggested,
there's no question whether an option like "-no-pie" is supported, and
no temptation to even try.

That's a very simple and elegant solution.

-- Sean Silva

The new language should be tailored for
process-to-process communication, rather than user-to-shell

> I’m thinking about future enhancements.  MachO does actually provide
> something like `-L` -`l` in a single go via `-framework`.  But, no such
> option exists for ELF since it doesn’t have the concept of framework
> (but the layout itself is interesting), and I just want to try to keep the
> door open for such features.

This is why I also included "path" in my suggestion. I imagine
something very much like -framework, where include files and library
search paths are handled together.

LLVM Developers mailing list
llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180107/b1f289a5/attachment.html>

More information about the llvm-dev mailing list