[lldb-dev] Inquiry about breakpoints on demangled function names

[E BOUTALEB via lldb-dev]

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.


> Subject: Re: [lldb-dev] Inquiry about breakpoints on demangled function names
> From: gclayton at apple.com
> Date: Mon, 2 May 2016 11:38:29 -0700
> CC: lldb-dev at lists.llvm.org
> To: e.boutaleb at hotmail.fr
> 
> 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:
> 
> a::b::c(int, float, char)
> 
> 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.
> 
> 
> > On May 2, 2016, at 2:49 AM, E BOUTALEB via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> > 
> > 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
> > 
> > 
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160503/b774ca94/attachment.html>