<div dir="ltr">On Wed, Jan 3, 2018 at 8:08 PM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@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"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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></div></blockquote><div><br></div></span><div>Do we have agreement about this assumption? I think one main point of disagreement is how open-ended we want things, and llvm.linker.options implies, at least at first glance, a very open-ended approach. Can you describe how open-ended llvm.linker.options is, in fact/in practice? I.e. what subset of linker options do the COFF/MachO targets actually support?</div><span class=""><div><br></div></span></div></div></div></blockquote><div><br></div><div>This is something which is already well established.  I'm not proposing to change that.  llvm.linker.options is something which is a string passed by the frontend.  There is nothing that is interpreted by either side.  This is not new metadata that I am introducing, it is the existing infrastructure.  Now, if you like, a newer more restrictive mechanism could be introduced, but that would be beyond the scope of this change IMO.  Both of those do not have any restrictions AFAIK; and any control of what they permit is from the *frontend* side.</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="ltr"><div><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></div></blockquote><div><br></div></span><div>One thing that is on my mind is that the fact that llvm.linker.options is metadata means it can be dropped. So, playing devil's advocate here, it is correct for ELF targets to just ignore it (as they currently do AFAIK). if your intended use case does not actually behave correctly with the llvm.linker.options dropped, then that suggests that something is fishy.</div></div></div></div></blockquote><div><br></div><div>Yeah, the metadata can be dropped.  If the metadata is dropped, then nothing gets embedded into the object file.  The changes being discussed would be embedding additional metadata into the object file.  A separate change would be needed to actually process that in the linker as well as one to the frontend to actually emit the metadata.</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"><div>I guess the fact that llvm.linker.options is currently used for COFF/MachO suggests that it is not dropped in practice in the situations that matter, but it does provide some evidence that we may want to move away from llvm.linker.options. For example, we could let frontends parse legacy open-ended linker pragmas and emit a new IR format with constrained semantics.</div></div></div></div></blockquote><div><br></div><div>Right, this is inline with what I was suggesting as a second mechanism for this that could be designed.  But, again, that is beyond the scope of the changes that I am proposing.</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"><div>(also, do you know if the COFF/MachO representation for the linker options  in the .o file can/cannot be dropped? AFAIK, SHT_NOTE can be ignored)</div></div></div></div></blockquote><div><br></div><div>Well, the content is only in the object files.  The final linked binary does not contain it (which is why Im abusing the SHT_NOTE).  Do you mean does the linker ignore it?  Well, if the linker doesn't support the feature, it would.  In PE/COFF, it is encoded as a special section (.drectve).  In fact, GNU ld doesn't have as complete of an implementation as lld/link and does ignore a bunch of options.  MachO has a special load command (LC_LINKOPT) that encodes this.  But, in both cases, it requires the linker to interpret it, and if it does not, then the same behavior would be observed.</div><div><br></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"><div><br></div><div>I just find it very fishy to consider linker options as advisory. Presumably if a user is passing them, then they are required for correctness.</div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span></div></div></div></blockquote><div><br></div><div>Sure, but that failure would generally be pretty obvious: linking would fail.</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="HOEnZb"><font color="#888888"><div></div><div>-- Sean Silva</div></font></span><span class=""><div><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><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.<span class="m_4814007136789945777HOEnZb"><font color="#888888"><br clear="all"><div><br></div>-- <br><div class="m_4814007136789945777m_1380590450394042649gmail_signature" data-smartmail="gmail_signature">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div>
</font></span></div></div></div>
</blockquote></span></div><br></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div>
</div></div>