This is an archive of the discontinued LLVM Phabricator instance.

[LLD] [COFF] Try to report source locations for duplicate symbols
ClosedPublic

Authored by mstorsjo on Oct 15 2019, 2:39 AM.

Details

Summary

This fixes the second part of PR42407.

The message is designed to match what the ELF linker prints, and the message for undefined references.

One part of the message is the name of the symbol where the duplicate occured, which is redundant, as that's printed as the original root issue anyway (but the ELF linker does it similarly).

For files with dwarf debug info, it manually loads and iterates .debug_info to find the declared location of variables, to allow reporting them. (This matches the corresponding code in the ELF linker. This code perhaps even could be shared somewhere in lld/Common?)

For functions, it uses the existing getFileLineDwarf which uses LLVMSymbolizer for translating addresses to file lines.

In object files with codeview debug info, only the source location of duplicate functions is printed. (And even there, only for the first input file. The getFileLineCodeView function requires the object file to be fully loaded and initialized to properly resolve source locations, but duplicate symbols are reported at a stage when the second object file isn't fully loaded yet.)

Diff Detail

Event Timeline

mstorsjo created this revision.Oct 15 2019, 2:39 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 15 2019, 2:39 AM
Herald added a subscriber: aprantl. · View Herald Transcript
ruiu added inline comments.Oct 15 2019, 2:50 AM
lld/COFF/InputFiles.cpp
792

Please add a comment saying that this is using DWARF debug info instead of PDB, which is not very common.

794–795

You can let clang-cl to generate DWARF and use lld-link to link the object files, so this doesn't have to be mingw-specific?

818

I'd add a comment saying this function initializes dwarf, lineTables and variableLoc members..

lld/COFF/SymbolTable.cpp
563

Can you add a comment with an example output?

mstorsjo marked 3 inline comments as done.Oct 15 2019, 3:05 AM
mstorsjo added inline comments.
lld/COFF/InputFiles.cpp
794–795

Technically yes, I guess that could be possible, although I don't think there's any setup where that is commonly done. (Or maybe the windows-itanium setup actually?)

We have a similar check for the mingw flag in getFileLine (before calling getFileLineDwarf) though.

Generally I get the feeling that users of lld in msvc style environments want to run as little of these odd mingw cases as possible, but I don't mind removing the checks; running the code in other cases should be harmless.

818

Sure, can do.

lld/COFF/SymbolTable.cpp
563

Sure, will do.

ruiu added inline comments.Oct 15 2019, 3:21 AM
lld/COFF/InputFiles.cpp
794–795

I believe some UEFI developers are using clang-cl and lld-link with DWARF debug format. And we publicly say that users can use DWARF on Windows using clang-cl and lld-link, so I think we need to consider this as a supported use pattern.

mstorsjo marked an inline comment as done.Oct 15 2019, 3:29 AM
mstorsjo added inline comments.
lld/COFF/InputFiles.cpp
794–795

Okay then; I'll remove the check here. Feel free to remove it from getFileLine in SymbolTable.cpp as well then.

mstorsjo updated this revision to Diff 224991.Oct 15 2019, 3:31 AM
mstorsjo marked 5 inline comments as done.

Added comments as requested, removed checks for the mingw flag before looking for dwarf debug info.

ruiu added a reviewer: thakis.Oct 15 2019, 3:59 AM

This patch looks good to me, but I'd like to get a second opinion from other devs because this could be a big change in UX. Nico, you recently worked on error messages. What do you think of this change?

lld/COFF/SymbolTable.cpp
523–580

I wouldn't use function overloading if it can be avoided easily. I'd name this getSourceLocationBitcode and the other getSourceLocationObj.

mstorsjo marked an inline comment as done.Oct 15 2019, 4:10 AM
mstorsjo added inline comments.
lld/COFF/SymbolTable.cpp
523–580

Ok, will change. There's some predecent of overloading in these functions from before, from D62434 fwiw.

mstorsjo updated this revision to Diff 224998.Oct 15 2019, 4:12 AM

Removed reliance on function overloading in the newly added code.

mstorsjo updated this revision to Diff 225095.Oct 15 2019, 12:06 PM

Removed the redundant symbol name from the error message.

ruiu added a comment.Oct 16 2019, 8:40 PM

Nico, are you happy with this change?

Nico, are you happy with this change?

The output looks fine from what's in the test expectations. To know how it feels in practice I think it's best to land this and use it for a bit.

Code-wise, it's quite a bit of code for dwarf debug info which isn't really used all that much, but meh. I kind of feel like it might possibly make sense to move all the CoffMingw bits into a separate lld/ directory instead of having it in lld/COFF since it's lots of special purpose code. But that's not my call :)

Nico, are you happy with this change?

The output looks fine from what's in the test expectations. To know how it feels in practice I think it's best to land this and use it for a bit.

FWIW, I tried mirroring what the corresponding message in the ELF linker looks like, but with less redundancy in the message. (When reporting an undefined reference, locating what symbol the undefined reference is in is a good help even if you don't get a source line - but when reporting a duplicate definition, "finding" the symbol name of each of the conflicting definitions is pointless.)

Code-wise, it's quite a bit of code for dwarf debug info which isn't really used all that much, but meh. I kind of feel like it might possibly make sense to move all the CoffMingw bits into a separate lld/ directory instead of having it in lld/COFF since it's lots of special purpose code. But that's not my call :)

I think some parts of the verbose dwarf code here could be refactored into lld/Common and share it with the ELF linker, but I'd prefer doing that as a separate step after landing this if that's tolerable (as some refactorings easily end up dragging on longer than initially expected). For other mingw related bits, we do have COFF/MinGW.cpp for logic that is easily decoupled from the rest of the COFF logic.

ruiu accepted this revision.Oct 17 2019, 7:10 PM

LGTM

Code-wise, it's quite a bit of code for dwarf debug info which isn't really used all that much, but meh. I kind of feel like it might possibly make sense to move all the CoffMingw bits into a separate lld/ directory instead of having it in lld/COFF since it's lots of special purpose code. But that's not my call :)

I think some parts of the verbose dwarf code here could be refactored into lld/Common and share it with the ELF linker, but I'd prefer doing that as a separate step after landing this if that's tolerable (as some refactorings easily end up dragging on longer than initially expected). For other mingw related bits, we do have COFF/MinGW.cpp for logic that is easily decoupled from the rest of the COFF logic.

I agree that we probably should move this code to lld/Common. I'm not too worried about adding code for mingw to the COFF directory, as long as they are separated clearly. One thing I would do is to add "MinGW only" comment for each function that is used only for mingw. Martin, if you are OK, add the comment to the new functions added in this patch before committing?

This revision is now accepted and ready to land.Oct 17 2019, 7:10 PM

LGTM

I agree that we probably should move this code to lld/Common. I'm not too worried about adding code for mingw to the COFF directory, as long as they are separated clearly. One thing I would do is to add "MinGW only" comment for each function that is used only for mingw. Martin, if you are OK, add the comment to the new functions added in this patch before committing?

Well, some of the new functions are used for codeview as well. And for the verbose dwarf code, originally I had made it MinGW-only with an if (!config->mingw) return;, but you said there might be non-MinGW usecases with dwarf info (UEFI), so I removed the check, so the dwarf code no longer is MinGW-only. Do you want a "primarily used by MinGW" comment instead?

ruiu added a comment.Oct 18 2019, 12:29 AM

Ah, that's true. How about something like "Used if DWARF debug info is used (which is not common)"?

Ah, that's true. How about something like "Used if DWARF debug info is used (which is not common)"?

Maybe ".. which is not common except in MinGW environments" (since it's the default there)?

This revision was automatically updated to reflect the committed changes.