Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description

Thanks, I will try this escape mechanism for the returned C string. On Mon, Mar 28, 2016 at 1:04 PM, Greg Clayton wrote: > > > On Mar 28, 2016, at 11:38 AM, Jeffrey Tan > wrote: > > > > Thanks Greg for the detailed explanation, very helpful. > > 1.

Re: [lldb-dev] Help debugging OSX build error

How did you install swig? Sounds like it isn't installed correctly. If you used homebrew, install "swig" and "swig-python". And if that doesn't work email Todd Fiala directly. Just for kicks, here is a list of files that we install for swig to give you an idea of everything we install

Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description

> On Mar 28, 2016, at 11:38 AM, Jeffrey Tan wrote: > > Thanks Greg for the detailed explanation, very helpful. > 1. Just to confirm, the weird string displayed is because 'data_' points to > some random memory? Yes. > So what gdb displays is also some random memory

Re: [lldb-dev] Help debugging OSX build error

And btw, to get the obvious out of the way, I do have swig installed, and "which swig" finds it in /opt/local/bin/swig On Mon, Mar 28, 2016 at 12:48 PM Zachary Turner wrote: > Trying to get an Xcode build working, and I keep getting this error: > > ERROR:root:Unable to find

[lldb-dev] Help debugging OSX build error

Trying to get an Xcode build working, and I keep getting this error: ERROR:root:Unable to find swig executable: 'module' object has no attribute 'OSError' Command /bin/sh failed with exit code 250 Does anyone know how to diagnose this? There's no other useful information in the log file. I

Re: [lldb-dev] LLDB /w Windows and MinGW64

Sorry, the current status is that lldb-server is no longer needed, however the debuggee process hangs and the lldb.exe is "froze" (i.e. it does not accept user input) Here is the backtrace: http://pastebin.com/mbLFgCA6 I will try and get lldb built in debug mode for better debugging... but this

Re: [lldb-dev] LLDB /w Windows and MinGW64

I was able to locate the problematic code: ProcessWindowsLive::Initialize() was not called due to wrong macros http://reviews.llvm.org/D18520 On Mon, Mar 28, 2016 at 9:31 PM, Eran Ifrah wrote: > Done. > > http://reviews.llvm.org/D18519 > > > On Mon, Mar 28, 2016 at 9:28

Re: [lldb-dev] SBListener not using a shared_ptr internally? (Update: Segfault after r262863)

Yes, that should work too. The thing that doesn't work is to just let the C++ destructor chain tear down the debuggers you've made. It should be possible to make that work, but nobody's had time to make that happen, and given you can avoid the crashes if you exit cleanly, it hasn't been a

Re: [lldb-dev] SBListener not using a shared_ptr internally? (Update: Segfault after r262863)

Ah, Thanks adding Debugger::Destroy at the end of my code made the segfaults disappear. Also as far as I understood the lldb code (Core/Debugger.cpp) it should also be possible to call SBDebugger::Terminate() for "destroy" all instances of lldb related objects. 2016-03-28 20:22 GMT+02:00 Jim

Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description

This is kind of orthogonal to your problem, but the reason why you are not seeing the kind of simplified printing Greg is suggesting, is because your std::string doesn’t look like any of the kinds we recognize Specifically, LLDB data formatters work by matching against type names, and once

Re: [lldb-dev] LLDB /w Windows and MinGW64

Done. http://reviews.llvm.org/D18519 On Mon, Mar 28, 2016 at 9:28 PM, Zachary Turner wrote: > Almost, there's one more step. Click Create a New Revision on that > screen, then give it a title and a description. For reviewers put zturner, > and for subscribers put

Re: [lldb-dev] LLDB /w Windows and MinGW64

Almost, there's one more step. Click Create a New Revision on that screen, then give it a title and a description. For reviewers put zturner, and for subscribers put lldb-commits On Mon, Mar 28, 2016 at 11:20 AM Eran Ifrah wrote: > Is this what you meant: >

Re: [lldb-dev] SBListener not using a shared_ptr internally? (Update: Segfault after r262863)

lldb doesn't currently work if you leave the process of cleaning up to the C++ destructor chain. You need to call Debugger::Destroy on your way out. I think there's a bunch more cleanup than just the broadcaster/listener stuff before we'll do this right. Jim > On Mar 28, 2016, at 8:55 AM,

Re: [lldb-dev] LLDB /w Windows and MinGW64

Is this what you meant: http://reviews.llvm.org/differential/diff/51809/ Thanks On Mon, Mar 28, 2016 at 8:58 PM, Zachary Turner wrote: > For the patch, can you create an account on reviews.llvm.org, and upload > your patch there? This makes interactive reviewing /

Re: [lldb-dev] LLDB /w Windows and MinGW64

If you compile with MSVC or Clang-cl it wouldn't ask for lldb-server. So most likely there is some code that is using #if defined(_MSC_VER) when it should be using #if defined(LLVM_ON_WINDOWS). You'll have to hunt that down, but a good starting point might be to put a breakpoint in

Re: [lldb-dev] LLDB /w Windows and MinGW64

For the patch, can you create an account on reviews.llvm.org, and upload your patch there? This makes interactive reviewing / commenting much easier. Let me know if you need help getting that set up. On Mon, Mar 28, 2016 at 10:58 AM Zachary Turner wrote: > If you compile

Re: [lldb-dev] DW_TAG_member extends beyond the bounds error on Linux

Thanks Greg. Yes, as I tried in another thread, the error seems to go away after patching with this fix. On Mon, Mar 28, 2016 at 9:33 AM, Greg Clayton wrote: > This seems to have been fixed with the http://reviews.llvm.org/D18008. > > > On Mar 28, 2016, at 9:31 AM, Greg

Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description

So you need to be prepared to escape any text that can have special characters. A "std::string" or any container can contain special characters. If you are encoding stuff into JSON, you will either need to escape any special characters, or hex encode the string into ASCII hex bytes. In

Re: [lldb-dev] DW_TAG_member extends beyond the bounds error on Linux

This seems to have been fixed with the http://reviews.llvm.org/D18008. > On Mar 28, 2016, at 9:31 AM, Greg Clayton via lldb-dev > wrote: > > Is it possible for me to see the "biggrep_master_server_async" binary? I > would like to look at the DWARF and try to figure

Re: [lldb-dev] DW_TAG_member extends beyond the bounds error on Linux

Is it possible for me to see the "biggrep_master_server_async" binary? I would like to look at the DWARF and try to figure out what is wrong. It seems that this code is what is causing the problem: CompilerType member_clang_type = member_type->GetLayoutCompilerType (); if

Re: [lldb-dev] LLDB /w Windows and MinGW64

On Mon, Mar 28, 2016 at 6:56 PM, Zachary Turner wrote: > Patches welcome. If you can split it into independent pieces that would be > helpful, but it's not always possible. > > Patch is attached, I think you will find it quite straight forward - feel free to comment and send

Re: [lldb-dev] LLDB /w Windows and MinGW64

Patches welcome. If you can split it into independent pieces that would be helpful, but it's not always possible. The NativeProcessProtocol error, that's the interface that converts debugging events that occur on the inferior into packets that can be sent to the server, and vice versa. Since

Re: [lldb-dev] SBListener not using a shared_ptr internally? (Update: Segfault after r262863)

Hey again, I've noticing segfaults after r262863 (dc5ef2da510f3adba99cd8b2fe18c2e6d417227d). Could you try reproducing this bug with this code please? int main() { using namespace lldb; SBDebugger::Initialize(); SBDebugger debugger = SBDebugger::Create(true); if(!debugger.IsValid()) {

Re: [lldb-dev] LLDB /w Windows and MinGW64

On Mon, Mar 28, 2016 at 6:10 PM, Zachary Turner wrote: > I'm the main Windows maintainer, Hi ​ > and while We've gotten things working pretty well on Windows, our effort > has been 100% on building with msvc and/or clang-cl. Building with mingw > has a different set of pre

Re: [lldb-dev] LLDB /w Windows and MinGW64

I'm the main Windows maintainer, and while We've gotten things working pretty well on Windows, our effort has been 100% on building with msvc and/or clang-cl. Building with mingw has a different set of pre processor defines and some other subtle differences, so it doesn't surprise me that things