Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

We’re currently still using Python 2.7 and VS 2013 on the Qualcomm Hexagon team. We expect to keep pulling from upstream until about the middle of June, then branch for a release. We’d rather not switch to Python 3.5/VS 2105 for this release. -- Qualcomm Innovation Center, Inc. The Qualcom

Re: [lldb-dev] SBProcess::Detach kills target

I believe this is not SIGHUP on debugger exit. I am using my own C++ program that calls into LLDB API. So, this program is still alive after calling SBProcess::Detach() but the target dies. Also, the target intercepts SIGHUP to do cleanup before exiting. I put printf there, it was not hit. I tri

Re: [lldb-dev] Inquiry about LLDB remote protocol

> On Mar 29, 2016, at 2:57 AM, Ravitheja Addepally via lldb-dev > wrote: > > Hello, > I wanted to know if the remote protocol of LLDB is state less or not ? > When i say state I am referring to if LLDB remembers the current process or > thread being debugged (which would mean we dont ne

Re: [lldb-dev] How to detach from stop mode without causing signal in inferior on Linux?

Thanks Pavel. I think I know what's going on. We do call SBProcess.Detach() during exiting python process normally. However, our stop debugging code seems to only kill python process directly without letting it exit normally. Killing python process seems to detach from inferior on Mac but kills inf

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

Keep in mind that llvm bumps minimum vs version roughly once a year, and it's probably about that time. So the discussion here is just about whether to do it earlier than llvm, not whether to do it all. So whether it's now or a few months from now, at some point you're going to have to handle thes

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

At Codeplay we are currently building on windows using a split of MSVC 2013 and MSVC 2015. In theory we are happy to move entirely to 2015, but until then we would have to work around any 2013 breakages. On 29/03/2016 16:16, Pavel Labath via lldb-dev wrote: Zachary, all, after overcoming som

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

Great work all. I would certainly welcome that, greg might want to weigh in as well. The other big one is thread_local keyword, lldb's ThreadLocal class remains broken on Windows, and thread_local is the only way to fix it On Tue, Mar 29, 2016 at 8:17 AM Pavel Labath wrote: > Zachary, all, > > a

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

Zachary, all, after overcoming some problems, mostly unrelated to MSVC, we have finally managed to switch to VS2015. I think that means there are no more VS2013 users remaining. Given that, shall we start the process to formally allow c++ features, which were blocked due to VS2013 until now? I am

Re: [lldb-dev] Inquiry about LLDB remote protocol

The GDB RSP, which LLDB RSP is derived from is certainly state-full and maintains an notion of the current thread for queries (reading registers, etc..) and for execution commands (stepping), see the 'H' packet. The RSP has evolved quite a bit however and extended packets were introduced that do

[lldb-dev] Inquiry about LLDB remote protocol

Hello, I wanted to know if the remote protocol of LLDB is state less or not ? When i say state I am referring to if LLDB remembers the current process or thread being debugged (which would mean we dont need to specify that in the client to server packets ) . I was looking at the GDBRemoteComm

Re: [lldb-dev] How to detach from stop mode without causing signal in inferior on Linux?

Hi, are you doing a SBProcess.Detach() before you kill the debugger? If that doesn't help could you send me the gdb-remote packet form (execute command: log enable -f /some/file.log gdb-remote packets), so I can get a better idea of what is going on. cheers, pl On 29 March 2016 at 00:21, Jeffre

Re: [lldb-dev] SBProcess::Detach kills target

There is no system restriction which prevents you from doing this. (Without any investigation) my guess would be that your inferior is dying of SIGHUP, which it receives when we close the master end of its pty. Could you check whether the behavior persists if your app blocks SIGHUP and/or you launc

Re: [lldb-dev] Hang of LLDB 3.8.0 on Debian 8

Hi, I suspect this may be related to . Could you try removing the -DLLVM_LINK_LLVM_DYLIB=ON option and trying again? cheers, pl On 24 March 2016 at 14:52, David Jones via lldb-dev wrote: > I am trying to run LLDB from the 3.8.0 release on a Debian 8