[lldb-dev] Inquiry about breakpoints on demangled function names
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
Re: [lldb-dev] Inquiry about breakpoints on demangled function names
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
> > 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
[lldb-dev] Add support for OCaml native debugging
I would like to submit two patches for code review. They introduce concrete support for OCaml native debugging, granted that you have access to the native compiler with DWARF emission support (see https://github.com/ocaml/ocaml/pull/574) This adds about 2000 lines of code. The type system isn't particularly complex here, every value is considered as an unsigned integer, and interpretation of the value is left to an external debugging layer made in OCaml. The language plugin handles function name demangling for breakpoints too. No tests for now. Is it fine to commit binaries with the patchs? Elias Boutaleb ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Add support for OCaml native debugging
I understand your concern. I guess it could be possible to create a conditional test exercised on a particular condition (like the presence of the native compiler), and skipped otherwise. Is it possible for new files to trigger regressions? Most of the changes concern the language plugins, AST context and DWARF parser. Elias From: ztur...@google.com Date: Thu, 7 Jul 2016 16:05:06 + Subject: Re: [lldb-dev] Add support for OCaml native debugging To: tbergham...@google.com; e.bouta...@hotmail.fr; lldb-dev@lists.llvm.org I don't like the idea of not having tests. Promising tests and actually delivering on them are two entirely different things. And without them, we just end up with broken code and nobody to maintain it On Thu, Jul 7, 2016 at 6:23 AM Tamas Berghammer via lldb-dev wrote: What type of binaries do you want to commit in? Generally we don't like putting binaries to the repository because they are not human readable so it is hard to review/diff them and they will only run on a single platform and a single architecture while we support a lot of different configuration. Tamas On Wed, Jul 6, 2016 at 3:26 PM E BOUTALEB via lldb-dev wrote: I would like to submit two patches for code review. They introduce concrete support for OCaml native debugging, granted that you have access to the native compiler with DWARF emission support (see https://github.com/ocaml/ocaml/pull/574) This adds about 2000 lines of code. The type system isn't particularly complex here, every value is considered as an unsigned integer, and interpretation of the value is left to an external debugging layer made in OCaml. The language plugin handles function name demangling for breakpoints too. No tests for now. Is it fine to commit binaries with the patchs? 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 ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Add support for OCaml native debugging
To be frank, I do not like that either. I could add the test the DWARF emission feature hit OCaml packages. Anyway, here are the patches. I would be fine with just the code review if the absence of tests is a bother. I ran check-lldb before and after applying the patches, and AFAIK I didn't introduce any regressions. Elias From: tbergham...@google.com Date: Thu, 7 Jul 2016 13:23:41 + Subject: Re: [lldb-dev] Add support for OCaml native debugging To: e.bouta...@hotmail.fr; lldb-dev@lists.llvm.org What type of binaries do you want to commit in? Generally we don't like putting binaries to the repository because they are not human readable so it is hard to review/diff them and they will only run on a single platform and a single architecture while we support a lot of different configuration. Tamas On Wed, Jul 6, 2016 at 3:26 PM E BOUTALEB via lldb-dev wrote: I would like to submit two patches for code review. They introduce concrete support for OCaml native debugging, granted that you have access to the native compiler with DWARF emission support (see https://github.com/ocaml/ocaml/pull/574) This adds about 2000 lines of code. The type system isn't particularly complex here, every value is considered as an unsigned integer, and interpretation of the value is left to an external debugging layer made in OCaml. The language plugin handles function name demangling for breakpoints too. No tests for now. Is it fine to commit binaries with the patchs? Elias Boutaleb ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 0002-Demangling-OCaml-function-symbols.patch Description: Binary data 0001-Add-support-for-OCaml-native-debugging.patch Description: Binary data ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
