<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Since I am working on debugger support for OCaml, I am dealing with symbols of the following form:<br><br>camlFoo__bar_1010<br><br>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.<br>Then you got the variable/function name, and a unique identifier suffixed to the symbol.<br><br>I am not handling multiple modules within a single compilation unit for now.<br><br>I guess the basename for that symbol would be bar, and the fully qualified name Foo.bar.<br>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:<br><br>if (!is_method && cu_language == eLanguageTypeOCaml) {<br>func_fullnames.Insert (ConstString(demangled.c_str()), DIERef(cu_offset, die.GetOffset()));<br>continue;<br>}<br><br>There is no autocomplete for bar into Foo.bar though.<br><br>I have a concern over discarding the fully mangled name though.<br><br><br><div>> Subject: Re: [lldb-dev] Inquiry about breakpoints on demangled function names<br>> From: gclayton@apple.com<br>> Date: Mon, 2 May 2016 11:38:29 -0700<br>> CC: lldb-dev@lists.llvm.org<br>> To: e.boutaleb@hotmail.fr<br>> <br>> Currently the DWARF provides two things for a mangled function in the accelerator tables:<br>> <br>> 1 - the function basename<br>> 2 - the full mangled name<br>> <br>> So for a C++ function like:<br>> <br>> a::b::c(int, float, char)<br>> <br>> 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:<br>> <br>> (lldb) b b::c<br>> <br>> 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:<br>> <br>> (lldb) b b.c<br>> <br>> as "look for 'c'" and then "make sure any matches contain 'b.c'".<br>> <br>> 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.<br>> <br>> <br>> > On May 2, 2016, at 2:49 AM, E BOUTALEB via lldb-dev <lldb-dev@lists.llvm.org> wrote:<br>> > <br>> > I am currently working on a language plugin for lldb.<br>> > 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.<br>> > <br>> > 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.<br>> > <br>> > 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?<br>> > <br>> > Elias Boutaleb<br>> > <br>> > <br>> > _______________________________________________<br>> > lldb-dev mailing list<br>> > lldb-dev@lists.llvm.org<br>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev<br>> <br></div> </div></body>
</html>