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.

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.

[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

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,

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.

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

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

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

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

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 = *nullptr; It's a > reference. > > I might be a good idea to add an overloaded

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 = *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

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 >

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

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.

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

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

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