This is an archive of the discontinued LLVM Phabricator instance.

lld-link: print demangled symbol names for "undefined symbol" diagnostics
ClosedPublic

Authored by thakis on Sep 14 2018, 10:31 AM.

Details

Summary

For this, add a few toString() calls when printing the "undefined symbol" diagnostics; toString() already does demangling on Windows hosts.

Also make lld::demangleMSVC() (called by toString(Symbol*)) call LLVM's microsoftDemangle() instead of UnDecorateSymbolName() so that it works on non-Windows hosts – this makes both updating tests easier and provides a better user experience for people doing cross-links.

Update microsoftDemangle() to work more like itaniumDemangle() after which appears to be modeled, so that lld::demangleItanium() and lld::demangleMSVC() can look alike:

  • Use same method of initializing the output stream and its buffer
  • Allow a nullptr Status pointer
  • Don't print the mangled name on demangling error
  • Write to N (if it is non-nullptr)

This doesn't yet do the right thing for symbols starting with __imp_, but that can be improved in a follow-up.

Diff Detail

Repository
rL LLVM

Event Timeline

thakis created this revision.Sep 14 2018, 10:31 AM
ruiu added inline comments.Sep 14 2018, 10:48 AM
libcxxabi/src/demangle/Utility.h
173 ↗(On Diff #165529)

Looks like there are two patterns how to use this function -- one way is to pass nullptr, nullptr as first two arguments, and the other is to pass an actual buffer. Can you separate that as two functions?

It looks like the latter use case is used only once, so you might be able to inline it.

lld/COFF/SymbolTable.cpp
69 ↗(On Diff #165529)

Update comment.

84–86 ↗(On Diff #165529)

You can just return Candidate.

libcxxabi/src/demangle/Utility.h
173 ↗(On Diff #165529)

There are actually many uses in the LLVM version, see llvm/lib/Demangle/ItaniumDemangle.cpp. Personally, I like it as a single function that encapsulates the buffer initialization for __cxa_demangle. I agree its a bit awkward, but thats just the API that it's trying to implement.

ruiu added inline comments.Sep 14 2018, 11:07 AM
libcxxabi/src/demangle/Utility.h
173 ↗(On Diff #165529)

Oh okay, never mind. If this function is being used in many places, it isn't worth to fix all caller places anyway.

179 ↗(On Diff #165529)

Perhaps off-topic, but I'd perhaps call std::terminate() instead of returning true for memory exhaustion error, as we can't really handle such error situation in most cases.

thakis updated this revision to Diff 165555.Sep 14 2018, 11:39 AM
thakis marked an inline comment as done.

ruiu comments

Thanks!

libcxxabi/src/demangle/Utility.h
179 ↗(On Diff #165529)

This code is identical in lib/Demangle and in libcxxabi. In libcxxabi this is used to implement __cxa_demangle
which commands that an error code is returned on allocation failure: https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-4.3/a01696.html

I agree that regular client software can't do anything useful on oom, but this is dictated by an external api contract.

lld/COFF/SymbolTable.cpp
84–86 ↗(On Diff #165529)

Err, yes :-D Done.

zturner added inline comments.Sep 14 2018, 12:54 PM
llvm/lib/Demangle/MicrosoftDemangle.cpp
1020–1022 ↗(On Diff #165555)

Is this returning true if it fails? Gross. Can we make it return false if it fails?

thakis added inline comments.Sep 14 2018, 12:59 PM
llvm/lib/Demangle/MicrosoftDemangle.cpp
1020–1022 ↗(On Diff #165555)

Returning true on error is reasonably common in the codebase: http://llvm-cs.pcc.me.uk/?q=true+on+error (e.g. https://reviews.llvm.org/D45898#inline-454138) I too wish it wasn't so.

(I'm also calling an existing function here, so I'd prefer to not change all the existing callers.)

llvm/lib/Demangle/MicrosoftDemangle.cpp
1020–1022 ↗(On Diff #165555)

I think LLVM style is true on error, aka unix style. I've seen a lot of both though. I don't see any mention in the coding style guide, but I think this would be a really good thing to have there. Maybe we should start a bikeshed on llvm-dev.

ruiu accepted this revision.Sep 14 2018, 1:05 PM

LGTM

We can discuss whether we should return true or false for success, but this change itself doesn't change the semantics of existing code, and it seems like a pure improvement, so LGTM.

This revision is now accepted and ready to land.Sep 14 2018, 1:05 PM
zturner added inline comments.Sep 14 2018, 1:07 PM
llvm/lib/Demangle/MicrosoftDemangle.cpp
1020–1022 ↗(On Diff #165555)

FWIW I think we should fix all of these, and in the past we've fixed instances of it on the grounds that it's bad form. The case of DiagnoseUseOfDecl is slightly more defensible because the presence of Diagnose sort of hints that it the function returns true, something is wrong. (I'd still change it or rename the function though). That said, it's true you are calling an existing function, but previously that function was only called 6 times, now it is called 11 times. I would prefer not to propagate this confusing usage pattern because it makes the code demonstrably worse imo.

Thanks! Submitting...

llvm/lib/Demangle/MicrosoftDemangle.cpp
1020–1022 ↗(On Diff #165555)

I'll land this as-is since I'm just moving an existing function around, and then I'll send another patch for inverting the meaning of the return value and we'll see if we can convince Erik over there. I see where "unix style" comes from, but that's imho more convincing for functions returning int :-)

This revision was automatically updated to reflect the committed changes.

Also https://reviews.llvm.org/rL342331 and https://reviews.llvm.org/rLLD342332

Do I have to do something special to make phab auto-display multiple revisions per review? I put "Differential Revison: <this review" in all three commit descriptions.

Ah, looks like all changes are mentioned at the top, just not as comments further down.