[lldb] Support mangled type names in memory read

[kastiglione]

Changes memory read to accept mangled type names with the --type/-t flag. This is useful for Swift where a typename can sometimes be more readily available, or expressible, using a mangled name.

Example of printing a Swift String using its address, and the mangled name for its type ($sSSD):

(lldb) memory read -t $sSSD 0x24680
(String) 0x24680 = "some string"

[llvmbot]

@llvm/pr-subscribers-lldb

Author: Dave Lee (kastiglione)

Changes

---

Full diff: https://github.com/llvm/llvm-project/pull/160601.diff

1 Files Affected:

• (modified) lldb/source/Commands/CommandObjectMemory.cpp (+7)

diff --git a/lldb/source/Commands/CommandObjectMemory.cpp b/lldb/source/Commands/CommandObjectMemory.cpp
index 5786e757ef7ea..22539276468d5 100644
--- a/lldb/source/Commands/CommandObjectMemory.cpp
+++ b/lldb/source/Commands/CommandObjectMemory.cpp
@@ -463,6 +463,13 @@ class CommandObjectMemoryRead : public CommandObjectParsed {
       TypeResults results;
       target->GetImages().FindTypes(search_first.get(), query, results);
       TypeSP type_sp = results.GetFirstType();
+      if (!type_sp) {
+        // Retry, searching for typename as a mangled name.
+        query.SetSearchByMangledName(true);
+        TypeResults results;
+        target->GetImages().FindTypes(search_first.get(), query, results);
+        type_sp = results.GetFirstType();
+      }
 
       if (!type_sp && lookup_type_name.GetCString()) {
         LanguageType language_for_type =

[jimingham]

If you add SetSearchByMangledName to the search query, does that do "search types by name AND by mangled name" or does it mean "Just search by mangled name".

If the former, is there any reason not to do the search for names and mangled names from the start? Is that much more expensive?

Otherwise in this case you're going to search over type names twice, which seems unfortunate.

[kastiglione]

@jimingham

does that do "search types by name AND by mangled name" or does it mean "Just search by mangled name".

setting the flag means "Just search by mangled name"

I had the same line of questions (in my head) as you.

I spoke with @augusto2112 (who introduced this flag) and he says its fine to change the flag to mean "search types by name AND by mangled name".

I'll go ahead and do that.

[jimingham]

LGTM but you might want to wait on Adrian or one of the other DWARF parsing experts.

I don't imagine there's any way you can test this except on the swift fork?

[kastiglione]

I made a few attempts at adding tests here, but with no success I'm settling for tests downstream.

[DavidSpickett]

I see "mangling" and think C++, can it be tested via that?

At least add an example in the PR description so we have an idea what this enables.

[jimingham]

I see "mangling" and think C++, can it be tested via that?

At least add an example in the PR description so we have an idea what this enables.

This is for type lookup, not symbol name lookup. C++ seldom mangles type names. I had thought it never did, but apparently that's not 100% true. But I don't know in what circumstances it does do that. Someone (maybe Pavel) did tell me when this happened but the explanation made my brain shut down.

[kastiglione]

I have tried a few approaches to make C++ work as a test for this change, but could not get it to work. The most appropriate test I could think of was using the mangled name for a type's typeinfo, but that did not work.

[kastiglione]

At least add an example in the PR description so we have an idea what this enables.

done

[DavidSpickett]

I have tried a few approaches to make C++ work as a test for this change, but could not get it to work.

Fair enough, the Swift example is enough to know who to complain to in future :)