I am currently working on a language plugin for lldb.
I would like to be able to put a breakpoint on demangled function names, but even after demangling function names through my custom DWARF parser, lldb won’t autocomplete on demangled names nor break on them.
I though about modifiying the IndexPrivate method in Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp, but it does not seem to be the cleanest thing to do.
Where would be the most appropriate place in the lldb source to incorporate demangled function names so breakpoints on them become possible? My own DWARF parser? DWARFCompileUnit?
Elias Boutaleb
Currently the DWARF provides two things for a mangled function in the accelerator tables:
1 - the function basename
2 - the full mangled name
So for a C++ function like:
The accelerator tables would contain "c", and "_ZN1a1b3fooEifc" that would point the the DWARF for this function. Now the user doesn't always type in the complete function name. They might type:
(lldb) b b::c
What we do in this case is chop the name up into "look for 'c'" and then "make sure any matches contain 'b::c'". So this is what currently happens. It is one place where we don't defer to the language plug-ins and allow each language plugin to chop up the string the user typed, so currently if your language doesn't use "::" as the separate for things that are in namespaces/modules/classes, then it might be doing the wrong thing. The Swift enabled LLDB on swift.org has some additional things where we chop up names a little differently since swift uses "." to separate things that are in namespaces/modules/classes (like "a.b.foo(Int, Float, Char)" and the mangling is different as well. For swift we would handle:
(lldb) b b.c
as "look for 'c'" and then "make sure any matches contain 'b.c'".
Can you give some examples of your mangle named and how it would look when demangled? It might help me guide my response a little better.
Since I am working on debugger support for OCaml, I am dealing with symbols of the following form:
camlFoo__bar_1010
The function name is prefixed with the “caml” followed by the local module name. OCaml is using a dot instead of a double colon to access function within a module, and is replaced here by a double underscore.
Then you got the variable/function name, and a unique identifier suffixed to the symbol.
I am not handling multiple modules within a single compilation unit for now.
I guess the basename for that symbol would be bar, and the fully qualified name Foo.bar.
I am handling the demangling myself in my Language plugin. I finally managed to do the change I wanted (spanning over DWARFCompileUnit inside IndexPrivate and Core/Mangled), provided that the current language CU DIE is OCaml:
if (!is_method && cu_language == eLanguageTypeOCaml) {
func_fullnames.Insert (ConstString(demangled.c_str()), DIERef(cu_offset, die.GetOffset()));
continue;
}
There is no autocomplete for bar into Foo.bar though.
I have a concern over discarding the fully mangled name though.