[llvm-dev] lld/coff section name .debug_str is longer than 8 characters

[Carlo Kok via llvm-dev]

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...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

[Martin Storsjö via llvm-dev]

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]

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?

[Martin Storsjö via llvm-dev]

Yeah, it does a few things, but unless your code actually contains
anything that needs it, most of it shouldn't really have any effect. (You
will have the visible effect of adding a couple synthesized symbols and 8
bytes of data in .rdata though.)

But it's indeed not the right permanent solution.

Silencing the warning with /debug:dwarf in addition to /lldmingw sounds
sensible to me, if we really want to keep the warning despite MSVC fixing
the dumpbin issue.

// Martin

[Reid Kleckner via llvm-dev]

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.

[Carlo Kok via llvm-dev]

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