Fāng-ruì Sòng via llvm-dev
2020-Aug-31 20:44 UTC
[llvm-dev] LLD: Can we make --warn-backrefs the default?
On Mon, Aug 31, 2020 at 1:29 PM David Blaikie <dblaikie at gmail.com> wrote:> > > > On Mon, Aug 31, 2020 at 1:24 PM Fāng-ruì Sòng <maskray at google.com> wrote: >> >> On Fri, Aug 28, 2020 at 11:16 AM David Blaikie <dblaikie at gmail.com> wrote: >> > >> > Would you like to conduct the conversation here, or on the review thread? (I lean towards having them here, but don't mind if folks feel like it keeps the noise down & want to more post a notice saying "hey, here's this thing, if you're interested, go discuss it over there" - more an optional opt-in rather than requiring people to opt-out via muting the thread, etc) >> >> Yes, we can conduct the "should we enable --warn-backrefs by default" >> conversation here. Since the semantics --warn-backrefs of are a bit >> complex, we need a documentation. https://reviews.llvm.org/D86762 is >> put up to get wording suggestions. Explicitly adding the people to the >> CC list... >> >> FWIW for many code bases, --warn-backrefs should produce no warnings >> (error if --fatal-warnings). For some code bases, GNU ld may error >> "undefined reference". --warn-backrefs can catch such problems. > > > One of the questions raised on the thread there was about different linker semantics. I assume the "--warn-backrefs by default" we're discussing is only related to the ld.lld frontend? Not the Windows linker lld behavior (or ld64 (old or new) lld behavior)?Yes, the ELF port (lld/ELF). No other port has implemented --warn-backrefs. The intion of --warn-backrefs is to capture behavior differences with GNU ld's ELF ports. If traditional ELF linkers don't behave like that, I can replace "traditional ELF linkers" in https://reviews.llvm.org/D86762 with "GNU linkers".>> >> >> >> > On Thu, Aug 27, 2020 at 10:15 PM Fangrui Song via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> >> >> Hi all, LLD's --warn-backrefs is a tool to identify potential >> >> incompatible archive selection semantics with traditional Unix linkers. >> >> I have improved it (via D77522,D77630 and D77512) to a state where a >> >> --warn-backrefs diagnostic almost assuredly means that the link will >> >> fail with GNU ld, or the symbol will get different resolution in GNU ld and LLD. >> >> >> >> My conclusion is that --warn-backrefs is a very useful layering check tool. >> >> I just wrote a documentation about the advantage (of GNU ld's archive >> >> selection semantics..... But we can do better with --warn-backrefs! >> >> GNU ld just reports "undefined reference" with no actionable feedback >> >> about the offending archive) >> >> >> >> https://reviews.llvm.org/D86762 >> >> >> >> I am wondering whether in the next release we can make --warn-backrefs >> >> the default. I have added many known users to the review. >> >> (There is no need for --no-warn-backrefs because --warn-backrefs-exclude='*' does the same job) >> >> _______________________________________________ >> >> LLVM Developers mailing list >> >> llvm-dev at lists.llvm.org >> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Petr Hosek via llvm-dev
2020-Sep-01 08:18 UTC
[llvm-dev] LLD: Can we make --warn-backrefs the default?
I see the GNU ld behavior as a limitation, not as a feature, as Peter Smith also pointed out in https://reviews.llvm.org/D86762. While it can be argued that there are certain cases where it can help detect layering violations as you mentioned in your change, I'm not sure how valuable that is in practice. Every case I've encountered so far either in Chrome or in Fuchsia was a valid use case, most commonly interceptors. The solution has always been the same, wrap all libraries in --start-group/--stop-group and it's what most projects do by default to avoid dealing with these issues, see for example [Chromium]( https://source.chromium.org/chromium/chromium/src/+/master:build/toolchain/gcc_toolchain.gni;l=409). In our case, compatibility with linkers on other platforms is more important than compatibility with GNU ld, so I'd prefer to keep the current behavior. Projects that care about compatibility with GNU ld can use --warn-backrefs. On Mon, Aug 31, 2020 at 1:44 PM Fāng-ruì Sòng <maskray at google.com> wrote:> On Mon, Aug 31, 2020 at 1:29 PM David Blaikie <dblaikie at gmail.com> wrote: > > > > > > > > On Mon, Aug 31, 2020 at 1:24 PM Fāng-ruì Sòng <maskray at google.com> > wrote: > >> > >> On Fri, Aug 28, 2020 at 11:16 AM David Blaikie <dblaikie at gmail.com> > wrote: > >> > > >> > Would you like to conduct the conversation here, or on the review > thread? (I lean towards having them here, but don't mind if folks feel like > it keeps the noise down & want to more post a notice saying "hey, here's > this thing, if you're interested, go discuss it over there" - more an > optional opt-in rather than requiring people to opt-out via muting the > thread, etc) > >> > >> Yes, we can conduct the "should we enable --warn-backrefs by default" > >> conversation here. Since the semantics --warn-backrefs of are a bit > >> complex, we need a documentation. https://reviews.llvm.org/D86762 is > >> put up to get wording suggestions. Explicitly adding the people to the > >> CC list... > >> > >> FWIW for many code bases, --warn-backrefs should produce no warnings > >> (error if --fatal-warnings). For some code bases, GNU ld may error > >> "undefined reference". --warn-backrefs can catch such problems. > > > > > > One of the questions raised on the thread there was about different > linker semantics. I assume the "--warn-backrefs by default" we're > discussing is only related to the ld.lld frontend? Not the Windows linker > lld behavior (or ld64 (old or new) lld behavior)? > > Yes, the ELF port (lld/ELF). No other port has implemented > --warn-backrefs. The intion of --warn-backrefs is to capture behavior > differences with GNU ld's ELF ports. If traditional ELF linkers don't > behave like that, I can replace "traditional ELF linkers" in > https://reviews.llvm.org/D86762 with "GNU linkers". > > >> > >> > >> > >> > On Thu, Aug 27, 2020 at 10:15 PM Fangrui Song via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> > >> >> Hi all, LLD's --warn-backrefs is a tool to identify potential > >> >> incompatible archive selection semantics with traditional Unix > linkers. > >> >> I have improved it (via D77522,D77630 and D77512) to a state where a > >> >> --warn-backrefs diagnostic almost assuredly means that the link will > >> >> fail with GNU ld, or the symbol will get different resolution in GNU > ld and LLD. > >> >> > >> >> My conclusion is that --warn-backrefs is a very useful layering > check tool. > >> >> I just wrote a documentation about the advantage (of GNU ld's archive > >> >> selection semantics..... But we can do better with --warn-backrefs! > >> >> GNU ld just reports "undefined reference" with no actionable feedback > >> >> about the offending archive) > >> >> > >> >> https://reviews.llvm.org/D86762 > >> >> > >> >> I am wondering whether in the next release we can make > --warn-backrefs > >> >> the default. I have added many known users to the review. > >> >> (There is no need for --no-warn-backrefs because > --warn-backrefs-exclude='*' does the same job) > >> >> _______________________________________________ > >> >> LLVM Developers mailing list > >> >> llvm-dev at lists.llvm.org > >> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200901/68372f96/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3850 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200901/68372f96/attachment.bin>
Fāng-ruì Sòng via llvm-dev
2020-Sep-02 00:34 UTC
[llvm-dev] LLD: Can we make --warn-backrefs the default?
On 2020-09-01, Petr Hosek wrote:>I see the GNU ld behavior as a limitation, not as a feature, as Peter Smith >also pointed out in https://reviews.llvm.org/D86762. While it can be argued >that there are certain cases where it can help detect layering >violations as you mentioned in your change, I'm not sure how valuable that >is in practice. Every case I've encountered so far either in Chrome or in >Fuchsia was a valid use case, most commonly interceptors. The solution >has always been the same, wrap all libraries in --start-group/--stop-group >and it's what most projects do by default to avoid dealing with these >issues, see for example [Chromium]( >https://source.chromium.org/chromium/chromium/src/+/master:build/toolchain/gcc_toolchain.gni;l=409). >In our case, compatibility with linkers on other platforms is more >important than compatibility with GNU ld, so I'd prefer to keep the current >behavior. Projects that care about compatibility with GNU ld can use >--warn-backrefs.I totally understand that some users may not want to deal with GNU ld compatibility:) I'll then question about Chromium's addition of -z defs: https://crrev.com/843583006 :) -z defs is like a layering checking tool for shared objects while --warn-backrefs is for archives. For performance, ABI concerns and ease of deployment, many projects tend to build their own components as archives instead of shared objects. In this sense --warn-backrefs will probably be more useful than -z defs. ( TIL lorder and tsort were created to define an order of archives in early versions of Unix. https://www.gnu.org/software/coreutils/manual/html_node/tsort-background.html It seems that the article missed the point that proper library layering is still useful )>On Mon, Aug 31, 2020 at 1:44 PM Fāng-ruì Sòng <maskray at google.com> wrote: > >> On Mon, Aug 31, 2020 at 1:29 PM David Blaikie <dblaikie at gmail.com> wrote: >> > >> > >> > >> > On Mon, Aug 31, 2020 at 1:24 PM Fāng-ruì Sòng <maskray at google.com> >> wrote: >> >> >> >> On Fri, Aug 28, 2020 at 11:16 AM David Blaikie <dblaikie at gmail.com> >> wrote: >> >> > >> >> > Would you like to conduct the conversation here, or on the review >> thread? (I lean towards having them here, but don't mind if folks feel like >> it keeps the noise down & want to more post a notice saying "hey, here's >> this thing, if you're interested, go discuss it over there" - more an >> optional opt-in rather than requiring people to opt-out via muting the >> thread, etc) >> >> >> >> Yes, we can conduct the "should we enable --warn-backrefs by default" >> >> conversation here. Since the semantics --warn-backrefs of are a bit >> >> complex, we need a documentation. https://reviews.llvm.org/D86762 is >> >> put up to get wording suggestions. Explicitly adding the people to the >> >> CC list... >> >> >> >> FWIW for many code bases, --warn-backrefs should produce no warnings >> >> (error if --fatal-warnings). For some code bases, GNU ld may error >> >> "undefined reference". --warn-backrefs can catch such problems. >> > >> > >> > One of the questions raised on the thread there was about different >> linker semantics. I assume the "--warn-backrefs by default" we're >> discussing is only related to the ld.lld frontend? Not the Windows linker >> lld behavior (or ld64 (old or new) lld behavior)? >> >> Yes, the ELF port (lld/ELF). No other port has implemented >> --warn-backrefs. The intion of --warn-backrefs is to capture behavior >> differences with GNU ld's ELF ports. If traditional ELF linkers don't >> behave like that, I can replace "traditional ELF linkers" in >> https://reviews.llvm.org/D86762 with "GNU linkers". >> >> >> >> >> >> >> >> >> > On Thu, Aug 27, 2020 at 10:15 PM Fangrui Song via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >> >> >> >> >> Hi all, LLD's --warn-backrefs is a tool to identify potential >> >> >> incompatible archive selection semantics with traditional Unix >> linkers. >> >> >> I have improved it (via D77522,D77630 and D77512) to a state where a >> >> >> --warn-backrefs diagnostic almost assuredly means that the link will >> >> >> fail with GNU ld, or the symbol will get different resolution in GNU >> ld and LLD. >> >> >> >> >> >> My conclusion is that --warn-backrefs is a very useful layering >> check tool. >> >> >> I just wrote a documentation about the advantage (of GNU ld's archive >> >> >> selection semantics..... But we can do better with --warn-backrefs! >> >> >> GNU ld just reports "undefined reference" with no actionable feedback >> >> >> about the offending archive) >> >> >> >> >> >> https://reviews.llvm.org/D86762 >> >> >> >> >> >> I am wondering whether in the next release we can make >> --warn-backrefs >> >> >> the default. I have added many known users to the review. >> >> >> (There is no need for --no-warn-backrefs because >> --warn-backrefs-exclude='*' does the same job) >> >> >> _______________________________________________ >> >> >> LLVM Developers mailing list >> >> >> llvm-dev at lists.llvm.org >> >> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>