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
