Re: [lldb-dev] lldb compiled from source 5X slower than homebrew or default lldb

[Timothee Cour via lldb-dev]

after further inspection it turns out it's a performance regression
between llvm 5 and llvm 6:

$homebrew_D/Cellar/llvm/5.0.1/lldb -s test_lldb.txt -- prog
8 seconds
$homebrew_D/Cellar/llvm/6.0.0/bin/lldb -s test_lldb.txt -- prog
40 seconds

cat test_lldb.txt:
```
b FOO
r
bt
q
```

prog is some binary I'm debugging. It's unfortunately hard to reduce.
What are good ways to investigate this?



On Mon, Mar 12, 2018 at 1:42 PM, Adrian Prantl <apra...@apple.com> wrote:
> Have you tried diff'ing your cmake invocation against the on used by homebrew?
>
> -- adrian
>
>> On Mar 9, 2018, at 12:59 AM, Timothee Cour via lldb-dev 
>> <lldb-dev@lists.llvm.org> wrote:
>>
>> while testing out https://github.com/llvm-mirror/lldb/pull/3 I noticed
>> that when I compiled lldb from source (even un-modified from git HEAD)
>> it was 5X slower than homebrew lldb or default lldb:
>>
>> I'm compiling lldb as follows:
>> ```
>> git clone https://github.com/llvm-mirror/llvm.git
>> cd llvm/tools
>> git clone https://github.com/llvm-mirror/lldb
>> ## also, patch in https://github.com/llvm-mirror/lldb/pull/3
>> git clone https://github.com/llvm-mirror/clang
>> cd ..
>> mkdir build
>> cd build
>> ccmake .. -G Ninja
>> # here I set: CMAKE_BUILD_TYPE  Release
>> ninja all
>> ```
>>
>> I also tried setting `LLVM_ENABLE_ASSERTIONS OFF` but no difference
>>
>>
>> commands.txt
>> ```
>> b FOO
>> r
>> bt
>> q
>> ```
>>
>> ./test is some program i have.
>>
>> ```
>> time lldb -s commands.txt -- ./test
>> 8 seconds
>> time ./build/bin/lldb -s commands.txt -- ./test
>> 40 seconds
>> ```
>> ___
>> 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

[Timothee Cour via lldb-dev]

moved to: https://reviews.llvm.org/D44321

On Mon, Feb 26, 2018 at 10:06 PM, Davide Italiano <dccitali...@gmail.com> wrote:
> On Mon, Feb 26, 2018 at 8:45 PM, Timothee Cour via lldb-dev
> <lldb-dev@lists.llvm.org> 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] how do i submit my patch for 'Support demangling for D symbols via dlopen'

[Timothee Cour via lldb-dev]

moved to https://reviews.llvm.org/D44321
it would've saved time if instructions had a TLDR that showed:

```
brew install homebrew/php/arcanist
arc diff master
# and following instructions
```


On Fri, Mar 9, 2018 at 8:44 AM, Ted Woodward via lldb-dev
<lldb-dev@lists.llvm.org> wrote:
> Also see http://llvm.org/docs/Contributing.html
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
>
>> -Original Message-
>> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Davide
>> Italiano via lldb-dev
>> Sent: Friday, March 09, 2018 10:27 AM
>> To: Timothee Cour <timothee.co...@gmail.com>
>> Cc: LLDB <lldb-dev@lists.llvm.org>
>> Subject: Re: [lldb-dev] how do i submit my patch for 'Support demangling for 
>> D
>> symbols via dlopen'
>>
>> On Fri, Mar 9, 2018 at 12:44 AM, Timothee Cour via lldb-dev > d...@lists.llvm.org> wrote:
>> > I've registered to
>> > http://lists.llvm.org/cgi-bin/mailman/subscribe/lldb-commits and sent
>> > my patch via that email to lldb-comm...@lists.llvm.org but doesn't
>> > appear yet on http://lists.llvm.org/pipermail/lldb-commits/ ; how long
>> > does it take for
>> > http://lists.llvm.org/cgi-bin/mailman/subscribe/lldb-commits to
>> > subscribe?
>> >
>>
>> Again, please sign-up for Phabricator as pointed out on the previous mail and
>> submit the patch there https://llvm.org/docs/Phabricator.html
>>
>> > Still not sure why github PR's can't be accepted to remove all this
>> > friction for outside developpers.
>> >
>>
>> Because llvm main repo is still on svn. Once the migration to GitHub will
>> happen, probably PR will be accepted at some point.
>>
>> Thanks,
>>
>> --
>> Davide
>> ___
>> 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] lldb compiled from source 5X slower than homebrew or default lldb

[Timothee Cour via lldb-dev]

while testing out https://github.com/llvm-mirror/lldb/pull/3 I noticed
that when I compiled lldb from source (even un-modified from git HEAD)
it was 5X slower than homebrew lldb or default lldb:

I'm compiling lldb as follows:
```
git clone https://github.com/llvm-mirror/llvm.git
cd llvm/tools
git clone https://github.com/llvm-mirror/lldb
## also, patch in https://github.com/llvm-mirror/lldb/pull/3
git clone https://github.com/llvm-mirror/clang
cd ..
mkdir build
cd build
ccmake .. -G Ninja
# here I set: CMAKE_BUILD_TYPE  Release
ninja all
```

I also tried setting `LLVM_ENABLE_ASSERTIONS OFF` but no difference


commands.txt
```
b FOO
r
bt
q
```

./test is some program i have.

```
time lldb -s commands.txt -- ./test
8 seconds
time ./build/bin/lldb -s commands.txt -- ./test
40 seconds
```
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] how do i submit my patch for 'Support demangling for D symbols via dlopen'

[Timothee Cour via lldb-dev]

I've registered to
http://lists.llvm.org/cgi-bin/mailman/subscribe/lldb-commits and sent
my patch via that email to lldb-comm...@lists.llvm.org but doesn't
appear yet on http://lists.llvm.org/pipermail/lldb-commits/ ; how long
does it take for
http://lists.llvm.org/cgi-bin/mailman/subscribe/lldb-commits to
subscribe?

Still not sure why github PR's can't be accepted to remove all this
friction for outside developpers.


On Tue, Feb 27, 2018 at 9:25 AM, Jim Ingham <jing...@apple.com> wrote:
> I only briefly scanned the patch, but I'm not sure treating D as another 
> mangling variant of C++ is the best model - I think it will be easier if we 
> gather all the separate language features up in the individual languages.  
> You might have a look at the swift-enabled lldb 
> (https://github.com/apple/swift-lldb/) to see how it is handled there.  
> That's a little weak because we iterate over supported languages by hand.  
> When there were a few that wasn't an issue, but as we pick up more languages, 
> we should introduce a "do over supported languages" feature which would clean 
> up the logic there.
>
> Jim
>
>
>> On Feb 26, 2018, at 9:01 PM, Timothee Cour via lldb-dev 
>> <lldb-dev@lists.llvm.org> wrote:
>>
>> https://github.com/llvm-mirror/lldb/pull/3
>>
>> it would be *really* nice if llvm or lldb accepted industry standard
>> github PR's, at least as an option. Would make contributing so much
>> easier for outsiders
>> ___
>> 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] how do i submit my patch for 'Support demangling for D symbols via dlopen'

[Timothee Cour via lldb-dev]

https://github.com/llvm-mirror/lldb/pull/3

it would be *really* nice if llvm or lldb accepted industry standard
github PR's, at least as an option. Would make contributing so much
easier for outsiders
___
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

[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

[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

[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

[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

[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