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