Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

[Chunseok Lee via lldb-dev]

Actually, I am trying to remote-debug from lldb(win host) to 
lldb-server(arm/x64 linux). In my case, The problem is that no lldb-sever-4.0 
is available(I only have lldb-server 3.8 for arm/x64 linux). 
Q) lldb 4.0 and lldb-server 3.8 are compatible each other?
Thank you

나의 iPhone에서 보냄

2016. 9. 22. 오후 12:23 Zachary Turner  작성:

> Does the 4.0 binary not work for you?  It is the first release that contains 
> prebuilt lldb binary.  Probably you are one of the first people to test it, 
> so if you encounter problems, let me know what they are.
> 
> The version of windows shouldn't matter as long as you are Win7 or higher.  
> No vista.
> 
>> On Wed, Sep 21, 2016 at 8:22 PM Chunseok Lee via lldb-dev 
>>  wrote:
>> Is there any prebuilt lldb binary for windows7?
>> I tried snapshot llvm binary 3.8, but it does not include lldb. Note that 
>> latest prebuilt(4.0) contains lldb.
>> 
>> 나의 iPhone에서 보냄
>> ___
>> 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] lldb-3.8.1 prebuilt binary for windows7

[Zachary Turner via lldb-dev]

Does the 4.0 binary not work for you?  It is the first release that
contains prebuilt lldb binary.  Probably you are one of the first people to
test it, so if you encounter problems, let me know what they are.

The version of windows shouldn't matter as long as you are Win7 or higher.
No vista.

On Wed, Sep 21, 2016 at 8:22 PM Chunseok Lee via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Is there any prebuilt lldb binary for windows7?
> I tried snapshot llvm binary 3.8, but it does not include lldb. Note that
> latest prebuilt(4.0) contains lldb.
>
> 나의 iPhone에서 보냄
> ___
> 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-3.8.1 prebuilt binary for windows7

[Chunseok Lee via lldb-dev]

Is there any prebuilt lldb binary for windows7?
I tried snapshot llvm binary 3.8, but it does not include lldb. Note that 
latest prebuilt(4.0) contains lldb. 

나의 iPhone에서 보냄
___
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

[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

[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

[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

[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

[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

[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] LLDB Evolution - Final Form

[Zachary Turner via lldb-dev]

The =delete overload of StringRef is also a great idea.  It just helped me
catch all the places where we were initializing global option tables from
const char *s

On Wed, Sep 21, 2016 at 2:28 PM Zachary Turner  wrote:

> On Wed, Sep 21, 2016 at 2:20 PM Greg Clayton  wrote:
>
>
> > On Sep 21, 2016, at 1:55 PM, Zachary Turner  wrote:
> >
> > :-/  The same thing happens if you write Foo  = *nullptr;   It's a
> reference.
>
> I might be a good idea to add an overloaded constructor for nullptr and
> void * and delete them so that we can't implicitly create a StringRef from
> nullptr or NULL and cause as crash as it wouldn't compile in the first
> place.
>
> >
> > Did you try StringRef::withNullAsEmpty()?
>
> I am still catching code conversion issues with things like:
>
> if (name == nullptr)
>
>
> Yea you have to handle it on a case by case basis.  What I've been doing
> is to look around the surrounding code.  If it's obvious that it's not null
> (because it was just checked above, or because it's .c_str() of something,
> or it came from a string literal, or whatever, then i just call
> llvm::StringRef(name);  If I don't know, even if I can probably guess, I do
> one of two things.  If it seems like a rabbit hole you don't want to
> venture into, just do withNullAsEmpty.  If it's a trivial utility function
> that doesn't pass the string through many layers of nested calls, go change
> that function to return a StringRef, then come back.
>
> Another thing that's helped me a lot (although it will make the code
> slightly verbose in the short term) is that any function I'm changing the
> signature of from const char* to StringRef, copy the declaration and
> =delete the const char* version.  This way the compiler won't allow the
> implicit conversion, and you'll be forced to fix up every callsite.  This
> is annoying because 99% of the time you end up explicitly constructing
> StringRefs from literals, which will obviously work, but it's the only way
> to guarantee that the conversion won't introduce null pointer errors.
>
> Once the code is more or less done, we can go back and remove all the
> =delete functions we added so you don't have to write explicit conversions
> anymore.
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB Evolution - Final Form

[Zachary Turner via lldb-dev]

On Wed, Sep 21, 2016 at 2:20 PM Greg Clayton  wrote:

>
> > On Sep 21, 2016, at 1:55 PM, Zachary Turner  wrote:
> >
> > :-/  The same thing happens if you write Foo  = *nullptr;   It's a
> reference.
>
> I might be a good idea to add an overloaded constructor for nullptr and
> void * and delete them so that we can't implicitly create a StringRef from
> nullptr or NULL and cause as crash as it wouldn't compile in the first
> place.
>
> >
> > Did you try StringRef::withNullAsEmpty()?
>
> I am still catching code conversion issues with things like:
>
> if (name == nullptr)
>

Yea you have to handle it on a case by case basis.  What I've been doing is
to look around the surrounding code.  If it's obvious that it's not null
(because it was just checked above, or because it's .c_str() of something,
or it came from a string literal, or whatever, then i just call
llvm::StringRef(name);  If I don't know, even if I can probably guess, I do
one of two things.  If it seems like a rabbit hole you don't want to
venture into, just do withNullAsEmpty.  If it's a trivial utility function
that doesn't pass the string through many layers of nested calls, go change
that function to return a StringRef, then come back.

Another thing that's helped me a lot (although it will make the code
slightly verbose in the short term) is that any function I'm changing the
signature of from const char* to StringRef, copy the declaration and
=delete the const char* version.  This way the compiler won't allow the
implicit conversion, and you'll be forced to fix up every callsite.  This
is annoying because 99% of the time you end up explicitly constructing
StringRefs from literals, which will obviously work, but it's the only way
to guarantee that the conversion won't introduce null pointer errors.

Once the code is more or less done, we can go back and remove all the
=delete functions we added so you don't have to write explicit conversions
anymore.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB Evolution - Final Form

[Greg Clayton via lldb-dev]

> On Sep 21, 2016, at 1:55 PM, Zachary Turner  wrote:
> 
> :-/  The same thing happens if you write Foo  = *nullptr;   It's a 
> reference.

I might be a good idea to add an overloaded constructor for nullptr and void * 
and delete them so that we can't implicitly create a StringRef from nullptr or 
NULL and cause as crash as it wouldn't compile in the first place.

> 
> Did you try StringRef::withNullAsEmpty()?

I am still catching code conversion issues with things like:

if (name == nullptr)

For normal string ref construction we can cut over to using withNullAsEmpty.

> 
> BTW what code are you converting?  I'm working on some of the options code as 
> we speak.

Its the cut over to using the DWARF parser in LLVM. There are many functions 
that were missing and I have added them and other things we had in our DWARF 
parser. Any DWARF attribute that is a "const char *" will now be returned as a 
llvm::StringRef. That has wide implications in all of the existing DWARF 
parsing code that was using "const char *" for things like names and mangled 
names and also the ClangASTContext functions, like say to create a RecordDecl, 
it now takes an llvm::StringRef as an argument.

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

Re: [lldb-dev] LLDB Evolution - Final Form

[Greg Clayton via lldb-dev]

I am laughing as I convert code over to using StringRef and I get crashes:

if (name == NULL)

StringRef is nice enough to implicitly construct a StringRef from NULL or 
nullptr so that it can crash for me...

> On Sep 21, 2016, at 11:09 AM, Zachary Turner via lldb-dev 
>  wrote:
> 
> Adding another thing to my list (thanks to Mehdi and Eric Christopher for the 
> idea).
> 
> Apply libfuzzer to LLDB.  Details sparse on what parse of LLDB and how, but I 
> think it would be easy to come up with candidates.
> 
> On Mon, Sep 19, 2016 at 1:18 PM Zachary Turner  wrote:
> Following up with Kate's post from a few weeks ago, I think the dust has 
> settled on the code reformat and it went over pretty smoothly for the most 
> part.  So I thought it might be worth throwing out some ideas for where we go 
> from here.  I have a large list of ideas (more ideas than time, sadly) that 
> I've been collecting over the past few weeks, so I figured I would throw them 
> out in the open for discussion.
> 
> I’ve grouped the areas for improvement into 3 high level categories.
> 
>   • De-inventing the wheel - We should use more code from LLVM, and 
> delete code in LLDB where LLVM provides a solution.  In cases where there is 
> an LLVM thing that is *similar* to what we need, we should extend the LLVM 
> thing to support what we need, and then use it.  Following are some areas 
> I've identified.  This list is by no means complete.  For each one, I've 
> given a personal assessment of how likely it is to cause some (temporary) 
> hiccups, how much it would help us in the long run, and how difficult it 
> would be to do.  Without further ado:
>   • Use llvm::Regex instead of lldb::Regex
>   • llvm::Regex doesn’t support enhanced mode.  Could we 
> add support for this to llvm::Regex?
>   • Risk: 6
>   • Impact: 3
>   • Difficulty / Effort: 3  (5 if we have to add enhanced 
> mode support)
>   • Use llvm streams instead of lldb::StreamString
>   • Supports output re-targeting (stderr, stdout, 
> std::string, etc), printf style formatting, and type-safe streaming operators.
>   • Interoperates nicely with many existing llvm utility 
> classes
>   • Risk: 4
>   • Impact: 5
>   • Difficulty / Effort: 7
>   • Use llvm::Error instead of lldb::Error
>   • llvm::Error is an error class that *requires* you to 
> check whether it succeeded or it will assert.  In a way, it's similar to a 
> C++ exception, except that it doesn't come with the performance hit 
> associated with exceptions.  It's extensible, and can be easily extended to 
> support the various ways LLDB needs to construct errors and error messages.
>   • Would need to first rename lldb::Error to LLDBError 
> so that te conversion from LLDBError to llvm::Error could be done 
> incrementally.
>   • Risk: 7
>   • Impact: 7
>   • Difficulty / Effort: 8
>   • StringRef instead of const char *, len everywhere
>   • Can do most common string operations in a way that is 
> guaranteed to be safe.
>   • Reduces string manipulation algorithm complexity by 
> an order of magnitude.
>   • Can potentially eliminate tens of thousands of string 
> copies across the codebase.
>   • Simplifies code.
>   • Risk: 3
>   • Impact: 8
>   • Difficulty / Effort: 7
>   • ArrayRef instead of const void *, len everywhere
>   • Same analysis as StringRef
>   • MutableArrayRef instead of void *, len everywhere
>   • Same analysis as StringRef
>   • Delete ConstString, use a modified StringPool that is 
> thread-safe.
>   • StringPool is a non thread-safe version of 
> ConstString.
>   • Strings are internally refcounted so they can be 
> cleaned up when they are no longer used.  ConstStrings are a large source of 
> memory in LLDB, so ref-counting and removing stale strings has the potential 
> to be a huge savings.
>   • Risk: 2
>   • Impact: 9
>   • Difficulty / Effort: 6
>   • thread_local instead of lldb::ThreadLocal
>   • This fixes a number of bugs on Windows that cannot be 
> fixed otherwise, as they require compiler support.
>   • Some other compilers may not support this yet?
>   • Risk: 2
>   • Impact: 3
>   • Difficulty: 3
>   • Use llvm::cl for the command line arguments to the primary 

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

[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] LLDB Evolution - Final Form

[Greg Clayton via lldb-dev]

I agree that for case #1, we must handle that by checking the pointer. Same 
thing for #2. For #3 we just need to fix the bug in clang. Our case in more of 
a different issue.

The cause of most crashes for us is in the clang::ASTContext class as we try to 
create types from DWARF. clang::ASTContext is used mainly by the compiler and 
this has a very rigid set of assumptions it can make about what inputs it gets. 
We create types like enums, CXXRecordDecl, Typedefs, arrays, etc by making 
types in the clang::ASTContext as we parse the DWARF. In the debugger, we are 
often creating classes from DWARF where information can be missing or not 
emitted. The -gline-tables-only feature emits DWARF, but takes the contents of 
all functions and removes all debug info children. This means you might have a 
function definition for say "bool Foo::operator <(const Foo&)" that has no 
parameters because the DWARF is truncated. This is one example of things that 
would make clang::ASTContext crash as it says you must have arguments for an 
"operator <" function which is understandable. We found that and fix the assert 
crash. But there are many many things in clang::ASTContext that mostly work, 
but as soon as we get fancier DWARF from a variety of people and test every 
variation, we end up crashing due to assertions. And the functions on the 
clang::ASTContext and many of the clang::Decl and clang::Type stuff don't have 
a ton of documentation saying "you must satisfy X or I will assert". Many of 
the assertions do make sense and are the kinds of things you want to see when 
debugging the creation of new types while you have a debug build. But in 
production, we would rather be able to try and survive just about anything.


> On Sep 21, 2016, at 8:25 AM, Zachary Turner  wrote:
> 
> BTW, one more comment about this.  If you've got a situation where LLDB is 
> using LLVM in a way that makes LLDB crash, there are 3 possibilities:
> 
> 1) LLVM / Clang is vending a pointer and we're supposed to be checking it for 
> null.
> 2) We used the LLVM / Clang API incorrectly causing it to return us a null 
> pointer.
> 3) There is a bug in the LLVM / Clang API.
> 
> Case #1 is the only case where we checking for null is the correct fix.  
> Blindly adding a null check and calling it a day is making the code *worse* 
> IMO.  If it's case 2 then we need to understand where in LLDB we are doing 
> the wrong thing and fix that.  If it's case 3 we need to dive into the LLVM / 
> Clang code and fix the real problem (presumably with help from someone with 
> expertise).  But "not crashing" is not the same as "fixing the bug".
> 
> FWIW, I expect a lot of these types of problems to fall somewhere between 
> categories 2 and 3.  LLDB is one of (if not the only) user of the clang 
> external ast source so that entire subsystem is not as battle hardened as the 
> rest of clang / llvm.
> 
> On Tue, Sep 20, 2016 at 2:31 PM Greg Clayton  wrote:
> We should avoid crashing if there is a reasonable work around when the input 
> is bad. StringRef with NULL is easy, just put NULL and zero length and don't 
> crash. Just because it is documented, doesn't mean it needs to stay that way, 
> but I am not going to fight that battle.
> 
> We should make every effort to not crash if we can. If it is way too 
> difficult, document the issue and make sure clients know that this is the way 
> things are. StringRef does this and we accept it. Doesn't mean it won't crash 
> us. I just hate seeing the crash logs where we have:
> 
> StringRef s(die.GetName());
> 
> It shouldn't crash IMHO, but we know it does and we now code around it. Yes, 
> we put in code like:
> 
> StringRef s;
> const char *cstr = die.GetName();
> if (cstr)
> s = cstr;
> 
> Is this nice code? I am glad it makes it simple for the LLVM side, but I 
> would rather write:
> 
> StringRef s(die.GetName());
> 
> Maybe I will subclass llvm::StringRef as lldb::StringRef and override the 
> constructor.
> 
> 
> > On Sep 20, 2016, at 2:24 PM, Zachary Turner  wrote:
> >
> > Well, but StringRef for example is well documented.  So it seems to me like 
> > there's an example of a perfectly used assert.  It's documented that you 
> > can't use null, and if you do it asserts.  Just like strlen.
> >
> > The issue I have with "you can't ever assert" is that it brings it into an 
> > absolute when it really shouldn't be.  We already agreed (I think) that 
> > certain things that are well documented can assert.  But when we talk in 
> > absolutes, it tends to sway people that they should always do that thing, 
> > even when it's not the most appropriate solution.  And I think some of that 
> > shows in the LLDB codebase where you've got hugely complicated logic that 
> > is very hard to follow, reason about, or test, because no assumptions are 
> > ever made about any of the inputs.  Even when they are internal inputs that 
> > are entirely 

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

[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

Re: [lldb-dev] LLDB Evolution - Final Form

[Zachary Turner via lldb-dev]

BTW, one more comment about this.  If you've got a situation where LLDB is
using LLVM in a way that makes LLDB crash, there are 3 possibilities:

1) LLVM / Clang is vending a pointer and we're supposed to be checking it
for null.
2) We used the LLVM / Clang API incorrectly causing it to return us a null
pointer.
3) There is a bug in the LLVM / Clang API.

Case #1 is the only case where we checking for null is the correct fix.
Blindly adding a null check and calling it a day is making the code *worse*
IMO.  If it's case 2 then we need to understand where in LLDB we are doing
the wrong thing and fix that.  If it's case 3 we need to dive into the LLVM
/ Clang code and fix the real problem (presumably with help from someone
with expertise).  But "not crashing" is not the same as "fixing the bug".

FWIW, I expect a lot of these types of problems to fall somewhere between
categories 2 and 3.  LLDB is one of (if not the only) user of the clang
external ast source so that entire subsystem is not as battle hardened as
the rest of clang / llvm.

On Tue, Sep 20, 2016 at 2:31 PM Greg Clayton  wrote:

> We should avoid crashing if there is a reasonable work around when the
> input is bad. StringRef with NULL is easy, just put NULL and zero length
> and don't crash. Just because it is documented, doesn't mean it needs to
> stay that way, but I am not going to fight that battle.
>
> We should make every effort to not crash if we can. If it is way too
> difficult, document the issue and make sure clients know that this is the
> way things are. StringRef does this and we accept it. Doesn't mean it won't
> crash us. I just hate seeing the crash logs where we have:
>
> StringRef s(die.GetName());
>
> It shouldn't crash IMHO, but we know it does and we now code around it.
> Yes, we put in code like:
>
> StringRef s;
> const char *cstr = die.GetName();
> if (cstr)
> s = cstr;
>
> Is this nice code? I am glad it makes it simple for the LLVM side, but I
> would rather write:
>
> StringRef s(die.GetName());
>
> Maybe I will subclass llvm::StringRef as lldb::StringRef and override the
> constructor.
>
>
> > On Sep 20, 2016, at 2:24 PM, Zachary Turner  wrote:
> >
> > Well, but StringRef for example is well documented.  So it seems to me
> like there's an example of a perfectly used assert.  It's documented that
> you can't use null, and if you do it asserts.  Just like strlen.
> >
> > The issue I have with "you can't ever assert" is that it brings it into
> an absolute when it really shouldn't be.  We already agreed (I think) that
> certain things that are well documented can assert.  But when we talk in
> absolutes, it tends to sway people that they should always do that thing,
> even when it's not the most appropriate solution.  And I think some of that
> shows in the LLDB codebase where you've got hugely complicated logic that
> is very hard to follow, reason about, or test, because no assumptions are
> ever made about any of the inputs.  Even when they are internal inputs that
> are entirely controlled by us.
> >
> > On Tue, Sep 20, 2016 at 2:19 PM Greg Clayton  wrote:
> > Again, strlen is a stupid example as it is well documented. All of llvm
> and clang are not.
> > > On Sep 20, 2016, at 1:59 PM, Zachary Turner 
> wrote:
> > >
> > >
> > >
> > > On Tue, Sep 20, 2016 at 1:55 PM Greg Clayton 
> wrote:
> > >
> > > > On Sep 20, 2016, at 1:45 PM, Zachary Turner 
> wrote:
> > > >
> > > > I do agree that asserts are sometimes used improperly.  But who's to
> say that the bug was the assert, and not the surrounding code?  For
> example, consider this code:
> > > >
> > > > assert(p);
> > > > int x = *p;
> > >
> > > Should be written as:
> > >
> > > assert(p);
> > > if (!p)
> > > do_something_correct();
> > > else
> > > int x = *p;
> > >
> > > >
> > > > Should this assert also not be here in library code?  I mean it's
> obvious that the program is about to crash if p is invalid.  Asserts should
> mean "you're about to invoke undefined behavior", and a crash is *better*
> than undefined behavior.  It surfaces the problem so that you can't let it
> slip under the radar, and it also alerts you to the point that the UB is
> invoked, rather than later.
> > > >
> > > > What about this assert?
> > > >
> > > > assert(ptr);
> > > > int x = strlen(ptr);
> > > >
> > > > Surely that assert is ok right?  Do we need to check whether ptr is
> valid EVERY SINGLE TIME we invoke strlen, or any other function for that
> matter?  The code would be a disastrous mess.
> > >
> > > Again, check before you call if this is in a shared library! What is
> so hard about that? It is called software that doesn't crash.
> > >
> > > assert(ptr)
> > > int x = ptr ? strlen(ptr) : 0;
> > >
> > > I find it hard to believe that you are arguing that you cannot EVER
> know ANYTHING about the state of your program.  :-/
> > >
> > > This is like 

[lldb-dev] Adding D language demangling support

[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