<div dir="auto"><div dir="auto">We should do this. ELF is the odd duck out that lacks this capability.</div><div dir="auto"><br></div><div dir="auto">I agree with Rafael we should have a whitelist of flags that we support, but I'd rather leave the syntax as more or less just a response file. That's basically what's implemented for COFF.</div><div dir="auto"><br></div>Sent from phone</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 3, 2018, 4:13 PM Rafael Avila de Espindola via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Saleem Abdulrasool via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>> writes:<br>
<br>
> Hello all,<br>
><br>
> There was some interest from a number of a few people about adding support<br>
> for embedded linker options to ELF.  This would be an extension that<br>
> requires linker support to actually work, but has significant prior art<br>
> with PE/COFF as well as MachO both having support for this.<br>
><br>
> The desire here is to actually add support to LLVM to pass along the<br>
> necessary information into the object file.  In order to keep this focused<br>
> on that, this thread is specifically for the *backend*, we are not<br>
> discussing how to get the information to the backend here at all, but<br>
> assuming that the information is present in the same LLVM IR encoding<br>
> (llvm.linker-options module metadata string).<br>
><br>
> In order to have compatibility with existing linkers, I am suggesting the<br>
> use of an ELF note.  These are implicitly dropped by the linker so we can<br>
> be certain that the options will not end up in the final binary even if the<br>
> extension is not supported.<br>
<br>
So far LGTM.<br>
<br>
> The payload would be a 4-byte version<br>
> identifier (to allow future enhancements) and a null-terminated string of<br>
> options.<br>
><br>
> This allows for the backend to be entirely oblivious to the data as the<br>
> other backends and allows for extensions in the future without having to<br>
> teach the backend anything about the new functionality (again, something<br>
> which both of the other file formats support).<br>
<br>
That is the part I have issues with.<br>
<br>
A linker has a lot of command line options, we should not make them part<br>
of the object format. What happens if a file has a -strip-all,<br>
--gc-sections or -pie?<br>
<br>
I think the supported features should be explicitly documented and be<br>
encoded a option-number,argument pair.<br>
<br>
The format should also be discussed at least with the gnu linker<br>
maintainers and ideally on <a href="mailto:generic-abi@googlegroups.com" target="_blank" rel="noreferrer">generic-abi@googlegroups.com</a>.<br>
<br>
Cheers,<br>
Rafael<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>