llvm dev - Jan 2018 - Linker Option support for ELF

On Jan 7, 2018 5:02 PM, "Cary Coutant via llvm-dev" <llvm-dev at
lists.llvm.org>
wrote:
> 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
the
> 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
working
> 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
communication.
> 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
bundles
> (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.

-cary
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
http://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/20180107/b1f289a5/attachment.html>

On Mon, Jan 8, 2018 at 3:55 AM, Sean Silva via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> On Jan 7, 2018 5:02 PM, "Cary Coutant via llvm-dev" <
> llvm-dev at lists.llvm.org> wrote:
>
> > 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
> the
> > 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
> working
> > 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.
>
I really like that approach too. Command line options and "embedded
options" are different, so making them actually look different makes sense.

> -- Sean Silva
>
>
> The new language should be tailored for
> process-to-process communication, rather than user-to-shell
> communication.
>
> > 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
> bundles
> > (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.
>
> -cary
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://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/20180108/dc60c259/attachment.html>

On 8 January 2018 at 08:14, Rui Ueyama <ruiu at google.com> wrote:
> On Mon, Jan 8, 2018 at 3:55 AM, Sean Silva via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>>
>>
>> On Jan 7, 2018 5:02 PM, "Cary Coutant via llvm-dev" <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> > 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 the
>> > 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
>> working
>> > 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.
>>
>
> I really like that approach too. Command line options and "embedded
> options" are different, so making them actually look different makes
sense.
>
+1 from me. This is very similar to what we have in the Playstation linker
(which uses integers instead of strings to denote the type of directive).
As Paul mentioned earlier, we support "lib" and "export"
directives, both
of which would fit nicely into this format.

>
>
>> -- Sean Silva
>>
>>
>> The new language should be tailored for
>> process-to-process communication, rather than user-to-shell
>> communication.
>>
>> > 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
>> bundles
>> > (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.
>>
>> -cary
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://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/20180108/f24a3a11/attachment-0001.html>