<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Thu, Mar 14, 2019 at 5:28 PM Peter Collingbourne via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Thu, Mar 14, 2019 at 9:59 AM Rui Ueyama via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Thu, Mar 14, 2019 at 9:28 AM Reid Kleckner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div><div>I guess I agree it would be best to remove the objfile linker option support and replace it with just auto-linking. We already have a mechanism for adding new features to object files: .note sections. Linkers already know to ignore ones that they don't understand. If, in the future, we want to add a new feature that could be handled by embedding linker flags, we can instead implement it with a new .note section that other linkers and old versions of LLD will know to ignore.</div><div dir="ltr"><br></div><div dir="ltr">On top of that, the generic ABI group has previously rejected proposals to embed linker options in object files (<a href="https://groups.google.com/forum/#!topic/generic-abi/iS_-m-X5ZwQ" target="_blank">https://groups.google.com/forum/#!topic/generic-abi/iS_-m-X5ZwQ</a>).</div><div dir="ltr"><br></div><div>Given how ELF has done things in the past, maybe the section name should be ".note.autolink". We could also be like GCC and namespace our extensions as ".note.LLVM.autolink", but maybe that's a step too far.</div></div></blockquote><div><br></div><div>A .note section consists of a series of type-length-value records. My understanding is that the static linker aggregates them to a single location and put it into PT_NOTE segment, and the records can still be read by the loader even after the section table is stripped from an executable. For the proposed purpose, the note section header would not be useful or meaningful, so a plain section that just contains an ASCII string would be simpler.</div></div></div></blockquote><div><br></div><div>I agree that this should not be a note section because the section is meaningless in a final linked executable.</div><div><br></div><div>Note that the proposal is limited to adding -l flags only. I would not expect this particular section to be expanded in the future to cover other use cases; rather, we would likely invent more section types.</div><div><br></div></div><div dir="ltr" class="gmail-m_392535780988395662gmail_signature"><div dir="ltr"><div>Peter</div></div></div></div></div></div></div></blockquote><div><br></div><div>Exactly. To be clear I am not opposing a mechanism to embed linker command line options in input files, maybe someone does have a valid usecase for this. I am basing my arguments in the RFC on the idea that the syntax does matter, in the sense that #pragma comment(lib, "foo") seems to imply a relatively "general" method of specifying a library to link, as opposed to some imagined syntax like #pragma linker-commandline-option("--library", "foo") which is specific to the command line options of a particular linker. Also, given that it seems that autolinking is the only usecase currently, the proposed .autolink section is a simpler (e.g. binary tools can dump the section without needing special rules), and more efficient (bytes needed to convey the information) format than something like .linker-options.</div></div></div></div></div>