Carlo Kok via llvm-dev
2019-Dec-18 05:52 UTC
[llvm-dev] lld/coff section name .debug_str is longer than 8 characters
Since updating today I get: section name .debug_str is longer than 8 characters and will use a non-standard string table This is LLD + Coff/DWARF; Is this now unsupported, am I doing something wrong or something else?Alternatively, what can I do to hide it?
Martin Storsjö via llvm-dev
2019-Dec-18 07:11 UTC
[llvm-dev] lld/coff section name .debug_str is longer than 8 characters
On Wed, 18 Dec 2019, Carlo Kok via llvm-dev wrote:> Since updating today I get: section name .debug_str is longer than 8 > characters and will use a non-standard string table > > This is LLD + Coff/DWARF; Is this now unsupported, am I doing something > wrong or something else? Alternatively, what can I do to hide it?The warning itself is harmless and doesn't indicate any other behaviour change. It was prompted when MSVC's dumpbin.exe suddenly started erroring out on such object files since MSVC 2019 16.2, but that does seem to be a bug that is going to be fixed (see https://developercommunity.visualstudio.com/content/problem/777863/dumpbin-regression-in-since-toolset-1422.html). As the dumpbin errors only was a regression and not an intentional change (and the bug is marked as "fix pending"), maybe the warning should be reverted? In the meantime, to silence it, you could add the -lldmingw flag, as the warnings isn't printed in MinGW environments (where DWARF debug info is expected and the default). That will opt in to a few other MinGW compatibility behaviours though, but they shouldn't really be fatal (unless you explicitly want to make DLLs with no exported symbols at all). // Martin
Carlo Kok via llvm-dev
2019-Dec-18 07:31 UTC
[llvm-dev] lld/coff section name .debug_str is longer than 8 characters
On Wed, Dec 18, 2019, at 08:11, Martin Storsjö wrote:> On Wed, 18 Dec 2019, Carlo Kok via llvm-dev wrote: > > > Since updating today I get: section name .debug_str is longer than 8 > > characters and will use a non-standard string table > > > > This is LLD + Coff/DWARF; Is this now unsupported, am I doing something > > wrong or something else? Alternatively, what can I do to hide it? > > The warning itself is harmless and doesn't indicate any other behaviour > change. It was prompted when MSVC's dumpbin.exe suddenly started > erroring > out on such object files since MSVC 2019 16.2, but that does seem to be > a > bug that is going to be fixed (see > https://developercommunity.visualstudio.com/content/problem/777863/dumpbin-regression-in-since-toolset-1422.html). > > As the dumpbin errors only was a regression and not an intentional change > (and the bug is marked as "fix pending"), maybe the warning should be > reverted? > > In the meantime, to silence it, you could add the -lldmingw flag, as the > warnings isn't printed in MinGW environments (where DWARF debug info is > expected and the default). That will opt in to a few other MinGW > compatibility behaviours though, but they shouldn't really be fatal > (unless you explicitly want to make DLLs with no exported symbols at all). >Thanks. Reading the LLD source, it looks like it does quite a few things. Wouldn't /debug:dwarf be a better option for this?
Reid Kleckner via llvm-dev
2019-Dec-18 19:26 UTC
[llvm-dev] lld/coff section name .debug_str is longer than 8 characters
The intention of the new warning was to warn when accidentally linking DWARF into a PE image, so it seems working as intended. Typically link.exe strips all codeview, so most users do not run objcopy/strip as a post-link step, so users were accidentally shipping DWARF to users. If you wanted the DWARF in your output, pass /debug:dwarf. It should silence the warning. Let me know if it doesn't. There's also a direct way to disable just this warning with no other change in behavior, /ignore:longsections. On Tue, Dec 17, 2019 at 9:53 PM Carlo Kok via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Since updating today I get: section name .debug_str is longer than 8 > characters and will use a non-standard string table > > This is LLD + Coff/DWARF; Is this now unsupported, am I doing something > wrong or something else?Alternatively, what can I do to hide it? > _______________________________________________ > 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/20191218/9813ed0b/attachment.html>
Carlo Kok via llvm-dev
2019-Dec-18 19:59 UTC
[llvm-dev] lld/coff section name .debug_str is longer than 8 characters
Haven't tested latest. But in my last build from a few months ago and all before that I had lld working fine in this regard, emitting both pdb and dwarf (pdb externally and dwarf in the executable). AFAIK this is still working when I pass /debug. The only new thing was the warning On Wed, Dec 18, 2019, at 20:26, Reid Kleckner wrote:> The intention of the new warning was to warn when accidentally linking DWARF into a PE image, so it seems working as intended. Typically link.exe strips all codeview, so most users do not run objcopy/strip as a post-link step, so users were accidentally shipping DWARF to users. > > If you wanted the DWARF in your output, pass /debug:dwarf. It should silence the warning. Let me know if it doesn't. > > There's also a direct way to disable just this warning with no other change in behavior, /ignore:longsections. > > On Tue, Dec 17, 2019 at 9:53 PM Carlo Kok via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Since updating today I get: section name .debug_str is longer than 8 characters and will use a non-standard string table >> >> This is LLD + Coff/DWARF; Is this now unsupported, am I doing something wrong or something else?Alternatively, what can I do to hide it? >> _______________________________________________ >> 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/20191218/64462944/attachment.html>