<div dir="ltr">On Wed, Jan 3, 2018 at 4:02 PM, Saleem Abdulrasool <span dir="ltr"><<a href="mailto:compnerd@compnerd.org" target="_blank">compnerd@compnerd.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hello all,</div><div><br></div>There was some interest from a number of a few people about adding support for embedded linker options to ELF.  This would be an extension that requires linker support to actually work, but has significant prior art with PE/COFF as well as MachO both having support for this.<div><br></div><div>The desire here is to actually add support to LLVM to pass along the necessary information into the object file.  In order to keep this focused on that, this thread is specifically for the *backend*, we are not discussing how to get the information to the backend here at all, but assuming that the information is present in the same LLVM IR encoding (llvm.linker-options module metadata string).<div><br></div><div>In order to have compatibility with existing linkers, I am suggesting the use of an ELF note.  These are implicitly dropped by the linker so we can be certain that the options will not end up in the final binary even if the extension is not supported.  The payload would be a 4-byte version identifier (to allow future enhancements) and a null-terminated string of options.</div><div><br></div><div>This allows for the backend to be entirely oblivious to the data as the other backends and allows for extensions in the future without having to teach the backend anything about the new functionality (again, something which both of the other file formats support).</div><div><br></div><div>As an example of how this can be useful, it would help with Swift support on Linux where currently the linker options are pushed into a custom section, and a secondary program is used to extract the options from this section prior to the linker being invoked.  This adds a lot of complexity to the driver as well as additional tools being invoked in the build chain slowing down the build.<br></div></div></div></blockquote><div><br></div><div>I realized that I had missed the link to the change that I had put up due to the original conversation.  It is available at <a href="https://reviews.llvm.org/D40849">https://reviews.llvm.org/D40849</a> for those who are interested.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><span class="gmail-HOEnZb"><font color="#888888">-- <br><div class="gmail-m_7515128193821533238gmail_signature">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div>
</font></span></div></div></div>
</blockquote></div><br>-- <br><div class="gmail_signature">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div>
</div></div>