This is an archive of the discontinued LLVM Phabricator instance.

[WIP] [lldb] change name demangling to be consistent between windows and linx
ClosedPublic

Authored by lassefolger on Oct 13 2021, 7:39 AM.

Details

Summary

When printing names in lldb on windows these names contain the full type information while on linux only the name is contained.

This change introduces a flag in the Microsoft demangler to control if the type information should be included.
With the flag enabled demangled name contains only the qualified name, e.g:
without flag -> with flag
int (*array2d)[10] -> array2d
int (*abc::array2d)[10] -> abc::array2d
const int *x -> x

For globals there is a second inconsistency which is not yet addressed by this change. On linux globals (in global namespace) are prefixed with :: while on windows they are not.

Diff Detail

Event Timeline

lassefolger created this revision.Oct 13 2021, 7:39 AM
lassefolger requested review of this revision.Oct 13 2021, 7:39 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptOct 13 2021, 7:39 AM
teemperor requested changes to this revision.Oct 13 2021, 7:54 AM
teemperor added reviewers: mstorsjo, rnk.

This looks in general good to me. You probably want to add a test for this (llvm/test/Demangle/ms-options.test seems like the right place). I added some folks to review the Demangler changes.

The LLDB itself LGTM, but it seems like this patch is also clang-formatting some lines that are unrelated to this patch, so please just clang-format those files as a preparatory NFC commit (If you don't have commit access then @werat or me can also just do that quickly for you). FWIW, there is a git clang-format script that limits clang-format changes to just the lines you touched.

This revision now requires changes to proceed.Oct 13 2021, 7:54 AM
mstorsjo added a subscriber: thakis.

The demangler change looks fine to me (but a test would indeed be necessary), but I think @thakis is the one who's been most involved with the MS demangler.

werat added a comment.Oct 15 2021, 6:53 AM

Thanks for improving this! Can you please add a few examples in the commit description like "before -> after", so it's more obvious what is changing here.

add tests for the change and adjust description to include examples

I don't have an opinion on this change and I don't mind the demangler change, but isn't the type information helpful? The mangled itanium name doesn't include type information which is why it's not printed, but the mangled ms name does include it.

But as I said, I don't have an opinion either way.

I don't have an opinion on this change and I don't mind the demangler change, but isn't the type information helpful? The mangled itanium name doesn't include type information which is why it's not printed, but the mangled ms name does include it.

But as I said, I don't have an opinion either way.

I think the motivation for this patch is just that LLDB uses the demangler to determine variable names and with the current MS demangler, the variable names returned by LLDB are for example int (*array2d)[10] on Windows instead of array2d (on platforms that use the itanium demangler). And that's clearly not what any user expects when they ask for the name of a variable behind a symbol. Note that type information in LLDB is a separate part of the information, so having the type information in the name gives the user no additional information.

rebased after NFC

lassefolger edited the summary of this revision. (Show Details)Oct 18 2021, 9:48 AM
lassefolger edited the summary of this revision. (Show Details)Oct 18 2021, 9:51 AM
rnk accepted this revision.Oct 18 2021, 12:26 PM

lgtm

This flag seems reasonable. Microsoft's UnDecorateName API has quite a few of these kinds of things:
https://docs.microsoft.com/en-us/windows/win32/api/dbghelp/nf-dbghelp-undecoratesymbolname

I don't think it makes sense to implement them all, but clearly, people have use cases for this kind of stuff. I think "name only" might be a useful addition at some point.

teemperor accepted this revision.Oct 19 2021, 1:39 AM
This revision is now accepted and ready to land.Oct 19 2021, 1:39 AM
werat accepted this revision.Oct 19 2021, 3:04 AM