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

2016-03-29 Thread Ted Woodward via lldb-dev
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

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

2016-03-29 Thread Greg Clayton via lldb-dev
> 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

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

2016-03-29 Thread Aidan Dodds via lldb-dev
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

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

2016-03-29 Thread Zachary Turner via lldb-dev
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: >

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

2016-03-29 Thread Pavel Labath via lldb-dev
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

2016-03-29 Thread Aidan Dodds via lldb-dev
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

[lldb-dev] Inquiry about LLDB remote protocol

2016-03-29 Thread Ravitheja Addepally via lldb-dev
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

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

2016-03-29 Thread Pavel Labath via lldb-dev
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,

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

2016-03-29 Thread Pavel Labath via lldb-dev
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