<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 8 January 2018 at 08:14, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Mon, Jan 8, 2018 at 3:55 AM, Sean Silva via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Jan 7, 2018 5:02 PM, "Cary Coutant via llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br type="attribution"><blockquote class="m_1533157073070864642m_-5063535380580781243quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_1533157073070864642m_-5063535380580781243quoted-text">> I think we all agree that blindly allowing the linker to honor the options<br>
> would be scary.  I agree that we should whitelist the options, and am 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.  I<br>
> want to retain the ability to add additional options which may not be<br>
> available in all linkers.  However, whitelisting obviously requires working<br>
> with the linker as would adding such options, so that could be handled at<br>
> that time.<br>
<br>
</div>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.</blockquote></div></div></div><div dir="auto"><br></div></span><div dir="auto">That's a very simple and elegant solution.</div></div></blockquote><div><br></div></span><div>I really like that approach too. Command line options and "embedded options" are different, so making them actually look different makes sense.</div></div></div></div></blockquote><div><br></div><div>+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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto">-- Sean Silva</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_1533157073070864642m_-5063535380580781243quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span> The new language should be tailored for<br>
process-to-process communication, rather than user-to-shell<br>
communication.<br>
<div class="m_1533157073070864642m_-5063535380580781243quoted-text"><br>
> I’m thinking about future enhancements.  MachO does actually provide<br>
> something like `-L` -`l` in a single go via `-framework`.  But, no such<br>
> option exists for ELF since it doesn’t have the concept of framework bundles<br>
> (but the layout itself is interesting), and I just want to try to keep the<br>
> door open for such features.<br>
<br>
</div>This is why I also included "path" in my suggestion. I imagine<br>
something very much like -framework, where include files and library<br>
search paths are handled together.<br>
<br>
-cary<br>
</span><span><div class="m_1533157073070864642m_-5063535380580781243elided-text">______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></span></blockquote></div><br></div></div></div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>