<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 1, 2020 at 5:35 PM Fāng-ruì Sòng via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2020-09-01, Petr Hosek wrote:<br>
>I see the GNU ld behavior as a limitation, not as a feature, as Peter Smith<br>
>also pointed out in <a href="https://reviews.llvm.org/D86762" rel="noreferrer" target="_blank">https://reviews.llvm.org/D86762</a>. While it can be argued<br>
>that there are certain cases where it can help detect layering<br>
>violations as you mentioned in your change, I'm not sure how valuable that<br>
>is in practice. Every case I've encountered so far either in Chrome or in<br>
>Fuchsia was a valid use case, most commonly interceptors. The solution<br>
>has always been the same, wrap all libraries in --start-group/--stop-group<br>
>and it's what most projects do by default to avoid dealing with these<br>
>issues, see for example [Chromium](<br>
><a href="https://source.chromium.org/chromium/chromium/src/+/master:build/toolchain/gcc_toolchain.gni;l=409" rel="noreferrer" target="_blank">https://source.chromium.org/chromium/chromium/src/+/master:build/toolchain/gcc_toolchain.gni;l=409</a>).<br>
>In our case, compatibility with linkers on other platforms is more<br>
>important than compatibility with GNU ld, so I'd prefer to keep the current<br>
>behavior. Projects that care about compatibility with GNU ld can use<br>
>--warn-backrefs.<br>
<br>
I totally understand that some users may not want to deal with GNU ld<br>
compatibility:) I'll then question about Chromium's addition of -z defs:<br>
<a href="https://crrev.com/843583006" rel="noreferrer" target="_blank">https://crrev.com/843583006</a> :)<br>
<br>
-z defs is like a layering checking tool for shared objects while<br>
--warn-backrefs is for archives. For performance, ABI concerns and ease<br>
of deployment, many projects tend to build their own components as<br>
archives instead of shared objects. In this sense --warn-backrefs will<br>
probably be more useful than -z defs.<br>
<br>
(<br>
TIL lorder and tsort were created to define an order of archives in<br>
early versions of Unix. <a href="https://www.gnu.org/software/coreutils/manual/html_node/tsort-background.html" rel="noreferrer" target="_blank">https://www.gnu.org/software/coreutils/manual/html_node/tsort-background.html</a><br>
It seems that the article missed the point that proper library layering is still useful<br>
)<br></blockquote><div><br></div><div>I'm not a fan of this idea of reframing GNU ld behavior as a "layering checking tool". It is an incomplete layering checking tool because it does not detect the scenario where, for example, you have the intended dependency graph:</div><div><br></div><div>A -> B</div><div>A -> C</div><div>B -> D</div><div>C -> D</div><div><br></div><div>(resulting in -la -lb -lc -ld) and you have an unexpected dependency B -> C. There is already a way to detect layering problems, that detects practical layering problems and not just theoretical ones, which is to link programs that use subsets of the libraries. For example, linking a program that depends only on B would result in detecting the invalid B -> C dependency. It's also worth noting that even that would only detect the layering problem if the program depends on the part of B that depends on C.</div><div><br></div><div>A better way to go about achieving layering checking would IMHO be to implement a separate tool (not part of the linker) that is capable of a complete layering check. Such a tool would only depend on symbol table features common to all object formats, so it could probably be implemented generically.</div><div><br></div><div>Peter</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
>On Mon, Aug 31, 2020 at 1:44 PM Fāng-ruì Sòng <<a href="mailto:maskray@google.com" target="_blank">maskray@google.com</a>> wrote:<br>
><br>
>> On Mon, Aug 31, 2020 at 1:29 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
>> ><br>
>> ><br>
>> ><br>
>> > On Mon, Aug 31, 2020 at 1:24 PM Fāng-ruì Sòng <<a href="mailto:maskray@google.com" target="_blank">maskray@google.com</a>><br>
>> wrote:<br>
>> >><br>
>> >> On Fri, Aug 28, 2020 at 11:16 AM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>><br>
>> wrote:<br>
>> >> ><br>
>> >> > Would you like to conduct the conversation here, or on the review<br>
>> thread? (I lean towards having them here, but don't mind if folks feel like<br>
>> it keeps the noise down & want to more post a notice saying "hey, here's<br>
>> this thing, if you're interested, go discuss it over there" - more an<br>
>> optional opt-in rather than requiring people to opt-out via muting the<br>
>> thread, etc)<br>
>> >><br>
>> >> Yes, we can conduct the "should we enable --warn-backrefs by default"<br>
>> >> conversation here. Since the semantics --warn-backrefs of are a bit<br>
>> >> complex, we need a documentation. <a href="https://reviews.llvm.org/D86762" rel="noreferrer" target="_blank">https://reviews.llvm.org/D86762</a> is<br>
>> >> put up to get wording suggestions. Explicitly adding the people to the<br>
>> >> CC list...<br>
>> >><br>
>> >> FWIW for many code bases, --warn-backrefs should produce no warnings<br>
>> >> (error if --fatal-warnings). For some code bases, GNU ld may error<br>
>> >> "undefined reference". --warn-backrefs can catch such problems.<br>
>> ><br>
>> ><br>
>> > One of the questions raised on the thread there was about different<br>
>> linker semantics. I assume the "--warn-backrefs by default" we're<br>
>> discussing is only related to the ld.lld frontend? Not the Windows linker<br>
>> lld behavior (or ld64 (old or new) lld behavior)?<br>
>><br>
>> Yes, the ELF port (lld/ELF). No other port has implemented<br>
>> --warn-backrefs. The intion of --warn-backrefs is to capture behavior<br>
>> differences with GNU ld's ELF ports. If traditional ELF linkers don't<br>
>> behave like that, I can replace "traditional ELF linkers" in<br>
>> <a href="https://reviews.llvm.org/D86762" rel="noreferrer" target="_blank">https://reviews.llvm.org/D86762</a> with "GNU linkers".<br>
>><br>
>> >><br>
>> >><br>
>> >><br>
>> >> > On Thu, Aug 27, 2020 at 10:15 PM Fangrui Song via llvm-dev <<br>
>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> >> >><br>
>> >> >> Hi all, LLD's --warn-backrefs is a tool to identify potential<br>
>> >> >> incompatible archive selection semantics with traditional Unix<br>
>> linkers.<br>
>> >> >> I have improved it (via D77522,D77630 and D77512) to a state where a<br>
>> >> >> --warn-backrefs diagnostic almost assuredly means that the link will<br>
>> >> >> fail with GNU ld, or the symbol will get different resolution in GNU<br>
>> ld and LLD.<br>
>> >> >><br>
>> >> >> My conclusion is that --warn-backrefs is a very useful layering<br>
>> check tool.<br>
>> >> >> I just wrote a documentation about the advantage (of GNU ld's archive<br>
>> >> >> selection semantics..... But we can do better with --warn-backrefs!<br>
>> >> >> GNU ld just reports "undefined reference" with no actionable feedback<br>
>> >> >> about the offending archive)<br>
>> >> >><br>
>> >> >> <a href="https://reviews.llvm.org/D86762" rel="noreferrer" target="_blank">https://reviews.llvm.org/D86762</a><br>
>> >> >><br>
>> >> >> I am wondering whether in the next release we can make<br>
>> --warn-backrefs<br>
>> >> >> the default. I have added many known users to the review.<br>
>> >> >> (There is no need for --no-warn-backrefs because<br>
>> --warn-backrefs-exclude='*' does the same job)<br>
>> >> >> _______________________________________________<br>
>> >> >> LLVM Developers mailing list<br>
>> >> >> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>> >> >> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>><br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div></div>