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