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: gclay...@apple.com
> Date: Mon, 2 May 2016 11:38:29 -0700
> CC: lldb-dev@lists.llvm.org
> To: e.bouta...@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@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@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
