This is an archive of the discontinued LLVM Phabricator instance.

Warn when an output section name is longer than 8 characters
ClosedPublic

Authored by rnk on Oct 29 2019, 4:08 PM.

Details

Summary

Microsoft's dumpbin tool cannot handle such PE files. LLVM tools and GNU
tools can, and use this to encode long section names like ".debug_info",
which is commonly used for DWARF. Don't do this in mingw mode, since
these are commonly used.

PR43754

Event Timeline

rnk created this revision.Oct 29 2019, 4:08 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 29 2019, 4:08 PM
Herald added a subscriber: aprantl. · View Herald Transcript
ruiu accepted this revision.Oct 29 2019, 6:52 PM

LGTM

This revision is now accepted and ready to land.Oct 29 2019, 6:52 PM
MaskRay added inline comments.
lld/COFF/Driver.cpp
1198

Delete {}

Microsoft's dumpbin tool cannot handle such PE files.

This had me quite surprised, as I'm sure it was able to handle them just fine.

By testing a few different versions of such tools I had lying around, I see that this worked just fine up to MSVC 2019 16.1, but in 16.2 it changed to error out with "LINK : fatal error LNK1328: missing string table". I'm a bit unsure about whether this really is intended behaviour, or just a bug.

This change in itself seems fine though.

As a heads up for slightly related matters, I'm considering implementing more options for controlling when and how the long section names are emitted (requested at https://github.com/mstorsjo/llvm-mingw/issues/56). GNU ld has options --enable-long-section-names and --disable-long-section-names (where I think disabled was the default in some ancient past, but enable is the default these days, and Rust build tooling includes the --enable-long-section-names flag, which lld/MinGW doesn't recognize yet). Haven't yet entirely decided on whether we should make those options override our current default logic (include long name if debug is enabled, except for runtime mapped sections like .eh_frame where libunwind needs to be able to locate the section name), or just make them override the defaults for non-runtime-mapped sections (like .debug_* and the rust metadata section).

This revision was automatically updated to reflect the committed changes.

Microsoft's dumpbin tool cannot handle such PE files.

This had me quite surprised, as I'm sure it was able to handle them just fine.

By testing a few different versions of such tools I had lying around, I see that this worked just fine up to MSVC 2019 16.1, but in 16.2 it changed to error out with "LINK : fatal error LNK1328: missing string table". I'm a bit unsure about whether this really is intended behaviour, or just a bug.

FYI, I found a existing bug report for this exact issue, https://developercommunity.visualstudio.com/content/problem/777863/dumpbin-regression-in-since-toolset-1422.html, which is marked as fixed, pending release. So apparently the dumpbin misbehaviour is just a regression.