[lldb-dev] Adding D language demangling support

[Timothee Cour via lldb-dev]

On Wed, Sep 21, 2016 at 3:10 PM, Greg Clayton <gclayton at 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 <thelastmammoth at 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 at 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 at 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 at lists.llvm.org
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160921/1f516e30/attachment.html>