<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jan 8, 2018 at 3:22 AM, Peter Smith <span dir="ltr"><<a href="mailto:peter.smith@linaro.org" target="_blank">peter.smith@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 8 January 2018 at 09:32, James Henderson via llvm-dev<br>
<div><div class="h5"><<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> On 8 January 2018 at 08:14, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
>><br>
>> On Mon, Jan 8, 2018 at 3:55 AM, Sean Silva via llvm-dev<br>
>> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>>><br>
>>><br>
>>><br>
>>> On Jan 7, 2018 5:02 PM, "Cary Coutant via llvm-dev"<br>
>>> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>>><br>
>>> > I think we all agree that blindly allowing the linker to honor the<br>
>>> > options<br>
>>> > would be scary.  I agree that we should whitelist the options, and am<br>
>>> > of the<br>
>>> > opinion that we should force validation on the linker side (use of any<br>
>>> > option which the linker doesn't support in this form can be fatal).<br>
>>> > Starting small is the best way, with `-l` and `-L` as a starting point.<br>
>>> > I<br>
>>> > want to retain the ability to add additional options which may not be<br>
>>> > available in all linkers.  However, whitelisting obviously requires<br>
>>> > working<br>
>>> > with the linker as would adding such options, so that could be handled<br>
>>> > at<br>
>>> > that time.<br>
>>><br>
>>> This is actually why I'd prefer a new "language" over just<br>
>>> whitelisting options. With "lib", "file", and "path", as I suggested,<br>
>>> there's no question whether an option like "-no-pie" is supported, and<br>
>>> no temptation to even try.<br>
>>><br>
>>><br>
>>> That's a very simple and elegant solution.<br>
>><br>
>><br>
>> I really like that approach too. Command line options and "embedded<br>
>> options" are different, so making them actually look different makes sense.<br>
><br>
><br>
> +1 from me. This is very similar to what we have in the Playstation linker<br>
> (which uses integers instead of strings to denote the type of directive). As<br>
> Paul mentioned earlier, we support "lib" and "export" directives, both of<br>
> which would fit nicely into this format.<br>
><br>
>><br>
<br>
</div></div>I'm wondering how much of the likely extensions are already covered by<br>
linker script commands<br>
(<a href="https://sourceware.org/binutils/docs/ld/File-Commands.html#File-Commands" rel="noreferrer" target="_blank">https://sourceware.org/<wbr>binutils/docs/ld/File-<wbr>Commands.html#File-Commands</a>).<br>
Would it be worth investigating embedding fragments of linker script<br>
[*] in the same way as the .directive sections that could be<br>
concatenated or overridden by any user provided linker script? This<br>
would have some advantages:<br>
- there is already a specification and implementation of the commands<br>
and experience of their use and limitations.<br>
- it will be easier to resolve conflicts with existing linker script<br>
commands that might conflict.<br>
- if new commands are needed they can be added to linker scripts.<br></blockquote><div><br></div><div>If we allow users embed linker scripts to object files, all ELF linkers will have to start supporting the linker script even for linking trivial programs. I don't think that's a good situation. IMO linker script is too powerful and too GNU-ish that we want to use it only for some limited purposes (e.g. embedded programming.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[*] The encoding in the object file need not match, as long as the<br>
permitted set of options can map 1:1 to a linker script command.<br>
<br>
My experience with Arm Build Attributes, which are used to reason<br>
about compatibility of relocatable objects and not communication of<br>
options; is that users expect to be able to move binary only objects<br>
between projects, and information embedded in object files that isn't<br>
easily accessible to them that causes a link to fail is extremely<br>
unpopular. I'm definitely of the opinion that we should be cautious<br>
with what we allow to be put in.<br>
<span class="HOEnZb"><font color="#888888"><br>
Peter<br>
</font></span></blockquote></div><br></div></div>