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

Reply via email to