ted added a comment.
I'm seeing the same issue as Nitesh, except in a different spot. The Hexagon
Simulator doesn't support QSaveRegisterState, so lldb calls
GDBRemoteRegisterContext::ReadAllRegisterValues. It gets a lock on the
communication client, then calls ReadAllRegisters, which tries to
nitesh.jain added a comment.
In https://reviews.llvm.org/D23802#528804, @labath wrote:
> Thanks for the heads up. I'll need to give this some thought. I've pulled the
> change out until I can figure out what to do.
>
> BTW, have you guys considered putting up a mips buildbot to detect these
> k
labath added a comment.
Thanks for the heads up. I'll need to give this some thought. I've pulled the
change out until I can figure out what to do.
BTW, have you guys considered putting up a mips buildbot to detect these kinds
of things?
Repository:
rL LLVM
https://reviews.llvm.org/D23802
nitesh.jain added a comment.
Forgot to mention that this case has been observed for MIPS architecture. Since
for MIPS, the floating point register size is calculated at runtime.
-NJ
Repository:
rL LLVM
https://reviews.llvm.org/D23802
___
lldb-c
nitesh.jain added inline comments.
Comment at:
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp:131
@@ +130,3 @@
+
+GDBRemoteClientBase::Lock lock(gdb_comm, false);
+if (!lock)
Hi labath,
This patch cause deadlock when we try to
This revision was automatically updated to reflect the committed changes.
Closed by commit rL279725: gdb-remote: Make the sequence mutex non-recursive
(authored by labath).
Changed prior to commit:
https://reviews.llvm.org/D23802?vs=69088&id=69208#toc
Repository:
rL LLVM
https://reviews.llv
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
Looks good.
https://reviews.llvm.org/D23802
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/l
labath updated this revision to Diff 69088.
labath added a comment.
Sounds good. I like that this enables us to get rid of the NoLock suffix.
Maybe eventually we could event replace the runtime assert with some sort of a
static lock
discipline checking framework, where you annotate functions wit
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
Maybe instead of "NoLock" on the functions we those functions take an extra
argument? Then someone can't accidentally run one of those without locking. We
need to somehow enforce
labath added a comment.
In https://reviews.llvm.org/D23802#523244, @clayborg wrote:
> The old mutex was there so that you could send a packet and get a result
> without worrying about other threads getting your response. It was recursive
> for the case where we needed to send two packets as one
clayborg added a comment.
The old mutex was there so that you could send a packet and get a result
without worrying about other threads getting your response. It was recursive
for the case where we needed to send two packets as one (set thread ID, then
send packet), and for reading all register
labath created this revision.
labath added a reviewer: clayborg.
labath added a subscriber: lldb-commits.
This is a preparatory commit for D22914, where I'd like to replace this mutex
by an R/W lock
(which is also not recursive). This required a couple of changes:
- Read/WriteRegister expect the
12 matches
Mail list logo
