I made it work: https://github.com/llvm-mirror/lldb/pull/3 (note: also requires the D plugin on D side which I can submit to another repo separately, and which is small)
not sure if lldb accepts github PR's but that's the simplest I could do On Sun, Feb 25, 2018 at 3:53 PM, Timothee Cour <timothee.co...@gmail.com> wrote: > update: > > * D now correctly prefixes its symbols with an extra underscore on OSX > (cf https://dlang.org/changelog/2.079.0.html#fix8207) and gdb > correctly demangles D symbols > * in https://github.com/dlang/druntime/pull/2083 I had a PR to support > demangling C++ symbols along with D symbols for D programs via runtime > loading (dlopen) of libc++ ; could we use a similar technique for lldb > by allowing user to dlopen a shared library that would customize > demangling? > > > > > > On Mon, Sep 26, 2016 at 8:50 AM, Greg Clayton <gclay...@apple.com> wrote: >> Just did, and it looks good. >> >>> On Sep 26, 2016, at 3:49 AM, Johan Engelen <jbc.enge...@gmail.com> wrote: >>> >>> Timothee, do you intend to work on this? >>> What can I do to help? >>> >>> In the meanwhile, I'd appreciate it if someone could take a look at >>> https://reviews.llvm.org/D24794 (currently, debugging D code is very much >>> broken without that change). >>> >>> -Johan >>> >>> >>> On Thu, Sep 22, 2016 at 7:21 PM, Greg Clayton via lldb-dev >>> <lldb-dev@lists.llvm.org> wrote: >>> I like the JSON approach. We might need to include the mangled name for the >>> function or specify where arguments go if we aren't going to expect a >>> canned function to be in each dylib. That is a bit harder, but something we >>> should think about. >>> >>> If we look at __cxa_demangle: >>> >>> >>> char* abi::__cxa_demangle(const char *mangled_name, char *output_buffer, >>> size_t *length, int *status); >>> >>> I am not sure how we would logically specify this in the JSON... Where to >>> put the name to demangle, how to call it etc... >>> >>> > On Sep 22, 2016, at 9:56 AM, Timothee Cour <timothee.co...@gmail.com> >>> > wrote: >>> > >>> > >>> > >>> > On Wed, Sep 21, 2016 at 4:13 PM, Greg Clayton via lldb-dev >>> > <lldb-dev@lists.llvm.org> wrote: >>> > You could have a setting that allows you to specify prefix as the key >>> > with a dylib path as a value. Would you expect a function with certain >>> > name or would you need to specify the function name (probably mangled) as >>> > well? Let me know what you are thinking? >>> > >>> > >>> > whatever works it doesn't really matter so long there's something to get >>> > started, I was going for something simple to start with but if you want >>> > this level of flexibility how about using a json config file: >>> > >>> > export LLDB_DEMANGLE_CONFIG_FILE="~/.lldbl.demangle.conf" >>> > >>> > cat ~/.lldbl.demangle.conf >>> > >>> > {"demangle": >>> > ["D": {"prefix" : "_D", "shared_libary_file" : >>> > "/path/libdemangled.dylib", "mangled_name", "_demangle_custom_D"}], >>> > ["nim": /* same for nim language */ ], >>> > } >>> > >>> > Greg >>> > >>> > > On Sep 21, 2016, at 3:50 PM, Timothee Cour <timothee.co...@gmail.com> >>> > > wrote: >>> > > >>> > > >>> > > >>> > > On Wed, Sep 21, 2016 at 3:35 PM, Greg Clayton via lldb-dev >>> > > <lldb-dev@lists.llvm.org> wrote: >>> > > Sounds like you could then make a setting that is a dictionary where >>> > > you say what the prefix is (like maybe "_D") and the value is the path >>> > > to the tool to use? This would be easy to implement. Demangling does >>> > > tend to be one of the most expensive parts of symbol file and debug >>> > > info parsing, so if you do this, you will want to make sure the shell >>> > > tool can be spawned and kept running maybe? >>> > > >>> > > Greg >>> > > >>> > > >>> > > where in the lldb code would be such entry point? >>> > > >>> > > instead of a binary it can just be a library dynamically loaded via >>> > > dlopen (as i wrote, though I should've called it LLDB_DEMANGLER_LIB >>> > > instead of LLDB_DEMANGLER_EXE), and the dynamically loaded symbol be >>> > > cached to make sure it's dlopen'd at most once per process. >>> > > >>> > > Then it's easy enough for us to write a demangleCustom that is fast on >>> > > the D side of things. It can also work with a binary instead of a dllib >>> > > but would be a bit slower (could have a client server model, but that's >>> > > more complex than the simple dllib solution i was proposing). >>> > > >>> > > yes, we could use a prefix for that as well. >>> > > >>> > > >>> > > > On Sep 21, 2016, at 3:30 PM, Timothee Cour <timothee.co...@gmail.com> >>> > > > wrote: >>> > > > >>> > > > >>> > > > >>> > > > On Wed, Sep 21, 2016 at 3:10 PM, Greg Clayton <gclay...@apple.com> >>> > > > wrote: >>> > > > There is no external demangling plug-in infrastructure at the moment, >>> > > > but you could add functionality that would allow it. No one is going >>> > > > to have D installed by default. Where do you expect your demangler >>> > > > dylib to live? >>> > > > Would you just add code that tries to locate the dylib in N places on >>> > > > the current system and try to dlopen it? Avoiding duplication and >>> > > > just not having the functionality at all unless something else is >>> > > > might not make it that useful. Is D stable? Is the mangling changing >>> > > > at all? Will you require a demangler to be vended with each new >>> > > > version of the tool? Are all previous demanglings still valid in >>> > > > newer versions? Can you figure out the version of the D from a >>> > > > compiled executable so that you might be able to locate one of 5 >>> > > > different installs of D and select the right one? Let me know what >>> > > > you use case is. >>> > > > >>> > > > Greg >>> > > > >>> > > > >>> > > > one simple flexible backward compatible option would be to have a >>> > > > generic environment variable: >>> > > > >>> > > > ``` >>> > > > export LLDB_DEMANGLER_EXE="/usr/bin/ddemangle" >>> > > > lldb myprog >>> > > > ``` >>> > > > >>> > > > inside lldb (D-like pseudo code): >>> > > > >>> > > > ``` >>> > > > bool demangle(string symbol, string* output){ >>> > > > auto path=env["LLDB_DEMANGLER_EXE"]; >>> > > > if(!path.empty) { >>> > > > auto demangleCustom=cast(proper_type) dlopen(path); >>> > > > if(demangleCustom(symbol, output)) return true; >>> > > > // fallsback to default code if custom code didn't handle symbol >>> > > > } >>> > > > return run_default_lldb_demangle(symbol, output); >>> > > > } >>> > > > ``` >>> > > > >>> > > > user defined demangler (eg D's demangler) >>> > > > ``` >>> > > > // return true if can demangle symbol (ie it's a D symbol in our case) >>> > > > bool demangleCustom(string symbol, string* output); >>> > > > >>> > > > ``` >>> > > > >>> > > > >> Is the mangling changing at all? >>> > > > >>> > > > yes, there's some ongoing work on making the mangling scheme produce >>> > > > much shorter symbols. The logic is complex, and it'd be a lot of work >>> > > > to reproduce this. >>> > > > >>> > > > Bottomline: this scheme is very flexible, and it'd be no less useful >>> > > > than current situation, where lldb just returns the symbol unchanged >>> > > > if it can't demangle. >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > > On Sep 21, 2016, at 3:00 PM, Timothee Cour >>> > > > > <thelastmamm...@gmail.com> wrote: >>> > > > > >>> > > > > Is there a way to provide a hook (eg, via an extern(C) function, or >>> > > > > using a dynamically loaded shared library) to do this, so as to >>> > > > > simply reuse D's https://dlang.org/phobos/std_demangle.html and >>> > > > > make sure it's always in sync with D's demangling instead of >>> > > > > duplicating code >>> > > > > >>> > > > > On Wed, Sep 21, 2016 at 10:24 AM, Greg Clayton via lldb-dev >>> > > > > <lldb-dev@lists.llvm.org> wrote: >>> > > > > It might be nice to add demangling support to llvm and then use it >>> > > > > by modifying "Mangled::GetDemangledName()" in Mangled.cpp. This is >>> > > > > where all demangling happens. Hopefully you have a great prefix >>> > > > > that won't conflict with other languages "_Z" for C++, "_T" for >>> > > > > swift. But the code in Mangled::GetDemangledName() will look at the >>> > > > > prefix and attempt to demangle the name based on what prefix it >>> > > > > starts with. >>> > > > > >>> > > > > >>> > > > > > On Sep 21, 2016, at 5:52 AM, Johan Engelen via lldb-dev >>> > > > > > <lldb-dev@lists.llvm.org> wrote: >>> > > > > > >>> > > > > > Hi all, >>> > > > > > I recently looked into adding demangling support for D in LLDB, >>> > > > > > but got lost in the code. >>> > > > > > (right now, basic D support is there with: >>> > > > > > https://reviews.llvm.org/D24794) >>> > > > > > >>> > > > > > I'd like some pointers to where demangling is done for the other >>> > > > > > languages, and to where I should add D support for it. >>> > > > > > >>> > > > > > Thanks a lot, >>> > > > > > Johan >>> > > > > > >>> > > > > > _______________________________________________ >>> > > > > > 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 >>> > > >>> > >>> > _______________________________________________ >>> > 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
