<div dir="ltr">On Wed, Jan 3, 2018 at 4:13 PM, Rafael Avila de Espindola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Saleem Abdulrasool via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">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>
</span>So far LGTM.<br>
<span class=""><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>
</span>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></blockquote><div><br></div><div>So you are suggesting that the backend take the opaque blob, peer through it, map it to something else and then encode that?  This means that every single new flag (also consider vendor extensions and non-GNU linkers) would need their own mapping and would need additional support for every single variant of an option.  This makes adding support for a flag extremely expensive IMO.  Filtering options or only supporting a subset of them in a particular linker is still viable in the approach I have proposed.  Emitting a warning on an unsupported flag and dropping it would be a way to handle this without adding the complexity in the backend and frontend and so tightly coupling all the  various pieces of the toolchain.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The format should also be discussed at least with the gnu linker<br>
maintainers and ideally on <a href="mailto:generic-abi@googlegroups.com">generic-abi@googlegroups.com</a>.<br></blockquote><div><br></div><div>Sure, sending that along to them is perfectly reasonable. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cheers,<br>
Rafael</blockquote></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div>
</div></div>