[lldb-dev] Adding D language demangling support

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. T

Re: [lldb-dev] running lldb-mi with LLDB_DISABLE_PYTHON

Please provide a little bit more details about the problem. Which command is giving the wrong output? Regards, Abid From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Chunseok Lee via lldb-dev Sent: 21 September 2016 03:15 To: Ilia K Cc: lldb-dev@lists.llvm.org Subject: Re: [l

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

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

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

> 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 > ) > >

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

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::ASTContex

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

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::G

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

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

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

the variable used to be a "const char *" in the last example... > On Sep 21, 2016, at 1:43 PM, Greg Clayton wrote: > > 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

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

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 anothe

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

:-/ The same thing happens if you write Foo &f = *nullptr; It's a reference. Did you try StringRef::withNullAsEmpty()? BTW what code are you converting? I'm working on some of the options code as we speak. On Wed, Sep 21, 2016 at 1:43 PM Greg Clayton wrote: > I am laughing as I convert cod

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

> On Sep 21, 2016, at 1:55 PM, Zachary Turner wrote: > > :-/ The same thing happens if you write Foo &f = *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

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

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 &f = *nullptr; It's a > reference. > > I might be a good idea to add an overloaded constructor for nullptr and > void * and delete t

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

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,

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

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

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

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 c

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

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 a

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

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

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

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. Demang

Re: [lldb-dev] running lldb-mi with LLDB_DISABLE_PYTHON

oh, I just asked whether there is a poosibility of such regression since original code (before workaround 1) seems not allow to use lldm-mi without python support. 2016. 9. 21. 오후 10:44 Abid, Hafiz 작성: > Please provide a little bit more details about the problem. Which command is > giving t

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

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, Ti

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

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

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

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

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

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. 2

[lldb-dev] Converting global option tables to use ArrayRef

I have a patch I'd like to submit tomorrow which converts all of the global command option tables from C-style arrays to llvm ArrayRefs. Actually they are still declared internally in each translation unit as C-style arrays, but the Option classes are updated so that they return ArrayRefs instead