Re: [lldb-dev] Adding D language demangling support

2018-03-09 Thread Timothee Cour via lldb-dev
moved to: https://reviews.llvm.org/D44321

On Mon, Feb 26, 2018 at 10:06 PM, Davide Italiano  wrote:
> On Mon, Feb 26, 2018 at 8:45 PM, Timothee Cour via lldb-dev
>  wrote:
>> I made it work:
>> https://github.com/llvm-mirror/lldb/pull/3
>> (note: also requires the D plugin on D side which I can submit to
>> another repo separately, and which is small)
>>
>> not sure if lldb accepts github PR's but that's the simplest I could do
>>
>>
>
> No, llvm/lldb is still on svn so we don't really accept pull requests
> yet. You can submit a new review on Phabricator though.
> That said, thank you for your contribution.
> For new languages, we want to have a high quality barrier for entry. I
> really appareciate the fact that you took the time to split in
> multiple patches.
> Every change that needs to be committed to lldb needs to have a test
> associated.
> You may consider taking a look at the tests in `lit/` or the ones in
> `test/` and add tests for your changes.
> Don't hesitate to ask if you get stuck/have other questions.
>
> Thank you,
>
> --
> Davide
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] Adding D language demangling support

2018-02-26 Thread Davide Italiano via lldb-dev
On Mon, Feb 26, 2018 at 8:45 PM, Timothee Cour via lldb-dev
 wrote:
> I made it work:
> https://github.com/llvm-mirror/lldb/pull/3
> (note: also requires the D plugin on D side which I can submit to
> another repo separately, and which is small)
>
> not sure if lldb accepts github PR's but that's the simplest I could do
>
>

No, llvm/lldb is still on svn so we don't really accept pull requests
yet. You can submit a new review on Phabricator though.
That said, thank you for your contribution.
For new languages, we want to have a high quality barrier for entry. I
really appareciate the fact that you took the time to split in
multiple patches.
Every change that needs to be committed to lldb needs to have a test
associated.
You may consider taking a look at the tests in `lit/` or the ones in
`test/` and add tests for your changes.
Don't hesitate to ask if you get stuck/have other questions.

Thank you,

--
Davide
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] Adding D language demangling support

2018-02-26 Thread Timothee Cour via lldb-dev
I made it work:
https://github.com/llvm-mirror/lldb/pull/3
(note: also requires the D plugin on D side which I can submit to
another repo separately, and which is small)

not sure if lldb accepts github PR's but that's the simplest I could do


On Sun, Feb 25, 2018 at 3:53 PM, Timothee Cour  wrote:
> update:
>
> * D now correctly prefixes its symbols with an extra underscore on OSX
> (cf https://dlang.org/changelog/2.079.0.html#fix8207) and gdb
> correctly demangles D symbols
> * in https://github.com/dlang/druntime/pull/2083 I had a PR to support
> demangling C++ symbols along with D symbols for D programs via runtime
> loading (dlopen) of libc++ ; could we use a similar technique for lldb
> by allowing user to dlopen a shared library that would customize
> demangling?
>
>
>
>
>
> On Mon, Sep 26, 2016 at 8:50 AM, Greg Clayton  wrote:
>> Just did, and it looks good.
>>
>>> On Sep 26, 2016, at 3:49 AM, Johan Engelen  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 
>>>  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  
>>> > wrote:
>>> >
>>> >
>>> >
>>> > On Wed, Sep 21, 2016 at 4:13 PM, Greg Clayton via lldb-dev 
>>> >  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  
>>> > > wrote:
>>> > >
>>> > >
>>> > >
>>> > > On Wed, Sep 21, 2016 at 3:35 PM, Greg Clayton via lldb-dev 
>>> > >  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  
>>> > > > wrote:
>>> > > >
>>> > > >
>>> > > >
>>> > > > On Wed, Sep 21, 2016 at 3:10 PM, Greg Clayton  
>>> > > > 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?
>>> > > > 

Re: [lldb-dev] Adding D language demangling support

2018-02-25 Thread Timothee Cour via lldb-dev
update:

* D now correctly prefixes its symbols with an extra underscore on OSX
(cf https://dlang.org/changelog/2.079.0.html#fix8207) and gdb
correctly demangles D symbols
* in https://github.com/dlang/druntime/pull/2083 I had a PR to support
demangling C++ symbols along with D symbols for D programs via runtime
loading (dlopen) of libc++ ; could we use a similar technique for lldb
by allowing user to dlopen a shared library that would customize
demangling?





On Mon, Sep 26, 2016 at 8:50 AM, Greg Clayton  wrote:
> Just did, and it looks good.
>
>> On Sep 26, 2016, at 3:49 AM, Johan Engelen  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 
>>  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  
>> > wrote:
>> >
>> >
>> >
>> > On Wed, Sep 21, 2016 at 4:13 PM, Greg Clayton via lldb-dev 
>> >  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  
>> > > wrote:
>> > >
>> > >
>> > >
>> > > On Wed, Sep 21, 2016 at 3:35 PM, Greg Clayton via lldb-dev 
>> > >  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  
>> > > > wrote:
>> > > >
>> > > >
>> > > >
>> > > > On Wed, Sep 21, 2016 at 3:10 PM, Greg Clayton  
>> > > > 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 

Re: [lldb-dev] Adding D language demangling support

2016-09-26 Thread Johan Engelen via lldb-dev
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 
> 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 
> 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 
> wrote:
> > > >
> > > >
> > > >
> > > > On Wed, Sep 21, 2016 at 3:10 PM, Greg Clayton 
> 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);
> 

Re: [lldb-dev] Adding D language demangling support

2016-09-21 Thread Greg Clayton via lldb-dev
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  wrote:
> 
> 
> 
> On Wed, Sep 21, 2016 at 3:35 PM, Greg Clayton via lldb-dev 
>  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  wrote:
> >
> >
> >
> > On Wed, Sep 21, 2016 at 3:10 PM, Greg Clayton  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  
> > > 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 
> > >  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 
> > > >  wrote:
> > > >
> > > > Hi all,
> > > >   I 

Re: [lldb-dev] Adding D language demangling support

2016-09-21 Thread Timothee Cour via lldb-dev
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 
> wrote:
> >
> >
> >
> > On Wed, Sep 21, 2016 at 3:10 PM, Greg Clayton 
> 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 
> 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
> > > > 

Re: [lldb-dev] Adding D language demangling support

2016-09-21 Thread Greg Clayton via lldb-dev
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

> On Sep 21, 2016, at 3:30 PM, Timothee Cour  wrote:
> 
> 
> 
> On Wed, Sep 21, 2016 at 3:10 PM, Greg Clayton  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  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 
> >  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 
> > >  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


Re: [lldb-dev] Adding D language demangling support

2016-09-21 Thread Timothee Cour via lldb-dev
On Wed, Sep 21, 2016 at 3:10 PM, Greg Clayton  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 
> 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


Re: [lldb-dev] Adding D language demangling support

2016-09-21 Thread Greg Clayton via lldb-dev
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

> On Sep 21, 2016, at 3:00 PM, Timothee Cour  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 
>  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 
> >  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


Re: [lldb-dev] Adding D language demangling support

2016-09-21 Thread Timothee Cour via lldb-dev
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


Re: [lldb-dev] Adding D language demangling support

2016-09-21 Thread Greg Clayton via lldb-dev
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 
>  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


Re: [lldb-dev] Adding D language demangling support

2016-09-21 Thread Mehdi Amini via lldb-dev

> On Sep 21, 2016, at 5:52 AM, Johan Engelen via lldb-dev 
>  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.

C++ demangler is in libcxxabi (and a copy is kept in LLVM itself).

LLDB includes a “fast” demangler and falls back to the libcxxabi one when the 
“fast” one fails.

David Majnemer mentioned he was interested in rewriting a demangler 
functionality in LLVM, I don’t know the scope though (could it have a common 
infrastructure for multiple language/scheme?).


— 
Mehdi___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


[lldb-dev] Adding D language demangling support

2016-09-21 Thread Johan Engelen via lldb-dev
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