<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Jan 6, 2018, at 6:55 PM, Rui Ueyama <<a href="mailto:ruiu@google.com" class="">ruiu@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote">On Sat, Jan 6, 2018 at 8:56 AM, Saleem Abdulrasool<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:compnerd@compnerd.org" target="_blank" class="">compnerd@compnerd.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""></div><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 class=""><br class=""><div class="gmail_quote"><span class=""><div dir="auto" class="">On Fri, Jan 5, 2018 at 2:30 AM Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank" class="">ruiu@google.com</a>> wrote:<br class=""></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 class="">Thank you for starting the discussion thread.<div class=""><br class=""></div><div class="">In general I'm in favor of the proposal. Defining a generic way to convey some information from the compiler to the linker is useful, and it looks like it is just a historical reason that the ELF lacks the feature at the moment.</div><div class=""><br class=""></div><div class="">This is a scenario in which the feature is useful: when you include math.h, a compiler (which is driven by some pragma) could added `-lm` to the note section so that a linker automatically links libm.</div><div class=""><br class=""></div><div class="">I think I'm also in favor of the format, which is essentially runs of null-terminated strings (*1) that are basically opaque to compilers.</div></div></blockquote><div dir="auto" class=""><br class=""></div></span><div dir="auto" class="">Yes. However, I think I want to clarify that we want this to be completely opaque to the backend. The front end could possibly have some enhancements to make this better. But, that will be a separate change, and that discussion should take place then. We shouldn’t paint ourselves into a corner. Basically, I think that there is some legitimate concerns here, but they would not be handled at this layer, but above.</div><span class=""><div dir="auto" class=""><br class=""></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 class=""><div class=""></div><div class="">However, you should define as a spec what options are allowed and what their semantics are. We should not accept arbitrary linker options because semantics of some linker options cannot be clearly defined when they appear as embedded options. Just saying "this feature allows you to embed linker options to object files" is too weak as a specification. You need to clearly define a list of options that will be supported by linkers with their clear semantics.</div></div></blockquote><div dir="auto" class=""><br class=""></div></span><div dir="auto" class="">Personally, I would like to see the ability to add support for additional options without having to modify the compiler. That said, I think that there are options which can be scary (e.g. -nopie). I think that the linker should make the decision of what it supports and error out on others. This allows for us to enhance the support over time without a huge overhead. As a starting point, I think that -l and -L are two that would be interesting. I can see -u being useful as well, but the point is that we can slowly grow the support after consideration by delaying the validation of the options.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I think no one including me opposed the idea of designing the feature so that new options can be added without having to modify the compiler. That's fine to me.</div></div></div></div></div></blockquote><div><br class=""></div><div>Excellent. I think that the TLV approach requires that to a certain extent (the enumeration would be hardcoded).</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">What I said is that you still have to specify a list of options that are allowed in the "linker options" section in your *specification*. Your specification is incomplete and underspecified if it doesn't explicitly list linker options with their semantics. If you don't do that, people would start using arbitrary linker options whose semantics are vague/that are dangerous/that are simply wrong (e.g. unclosed `-whole-archive` option)<span style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: small; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; background-color: rgb(255, 255, 255); float: none; display: inline;" class=""><span class=""> </span>after you would implement the feature. We really shouldn't let that mess happen.</span></div></div></div></div></div></blockquote><div><br class=""></div><div>I think we all agree that blindly allowing the linker to honor the options would be scary. I agree that we should whitelist the options, and am of the opinion that we should force validation on the linker side (use of any option which the linker doesn't support in this form can be fatal). Starting small is the best way, with `-l` and `-L` as a starting point. I want to retain the ability to add additional options which may not be available in all linkers. However, whitelisting obviously requires working with the linker as would adding such options, so that could be handled at that time.</div><div><br class=""></div><div>Furthermore, note that the LLVM side of the implementation does not provide a way to add anything from the user - that is a change to clang, and is something that I intend to be a follow up change. As I mentioned in a previous email, I have my own preferences for how to handle those, but, I think that when we start adding support to the frontend for it is the right time to discuss the syntax of how to support that. If we go with the approach of tokenizing the options and doing a C-string per option, I think it leaves sufficient flexibility to permit the frontend proper control to emit the necessary argument and not have the linker parse the options having to worry about quoting and space handling which I believe to be a good compromise on all sides.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Concretely, which options do you want to use? I could imagine everyone wants to use `-l`. `-L` is arguable because I do not see an obvious reason to add a search path from the compiler. You mentioned `-u`. Is there any other flag that you have in your mind?</div></div></div></div></div></blockquote><div><br class=""></div><div>I’m thinking about future enhancements. MachO does actually provide something like `-L` -`l` in a single go via `-framework`. But, no such option exists for ELF since it doesn’t have the concept of framework bundles (but the layout itself is interesting), and I just want to try to keep the door open for such features.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></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 class=""><div class="gmail_quote"><span class=""><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 class=""><div class=""></div><div class="">(*1) One of the big annoyances that I noticed when I was implementing the same feature for COFF is that the COFF's .drctve section that contains linker options have to be tokenized in the same way as the Windows command line does. So it needs to interpret double quotes and backslashes correctly especially when handling space-containing pathnames. This is a design failure that a COFF file contains just a single string instead of runs of strings that have already been tokenized.</div></div></blockquote><div dir="auto" class=""><br class=""></div></span><div dir="auto" class="">I think that there is room for refinement on this. The best part is that the refinement for that is delayed! It would be best done in the front end IMO, and we can actually further discuss and design the feature there. I don’t think that we need to be completely blind to the issues we have seen, but we shouldn’t over constrain either.</div><span class=""><div dir="auto" class=""><br class=""></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 class=""><div class=""></div></div><div class="gmail_extra"><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 4, 2018 at 9:02 AM, Saleem Abdulrasool via llvm-dev<span class="Apple-converted-space"> </span><span class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""></div></div><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 class=""><div class="">Hello all,</div><div class=""><br class=""></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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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_6273432371879462522m_-4841803101413298002HOEnZb"><font color="#888888" class=""><br clear="all" class=""><div class=""><br class=""></div>--<span class="Apple-converted-space"> </span><br class=""><div class="m_6273432371879462522m_-4841803101413298002m_5683958721005498049gmail_signature" data-smartmail="gmail_signature">Saleem Abdulrasool<br class="">compnerd (at) compnerd (dot) org</div></font></span></div></div></div><br class=""></blockquote></div></div><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;">______________________________<wbr class="">_________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class=""><br class=""></blockquote></div></div></blockquote></span></div></div><div class="HOEnZb"><div class="h5"><div dir="ltr" class="">--<span class="Apple-converted-space"> </span><br class=""></div><div class="m_6273432371879462522gmail_signature" data-smartmail="gmail_signature">Saleem Abdulrasool<br class="">compnerd (at) compnerd (dot) org</div></div></div></blockquote></div></div></div></div></blockquote></div><br class=""></body></html>