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?
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
