This is the mail archive of the
mailing list for the GDB project.
Re: Thread Specific Breakpoints in Remote Targets
- From: Raphael Zulliger <zulliger at indel dot ch>
- To: gdb at sourceware dot org
- Date: Thu, 01 Sep 2011 15:23:31 +0200
- Subject: Re: Thread Specific Breakpoints in Remote Targets
- References: <CAEPrYjQnadK872r5dXz2-KFBsoXcpBj0CMPc3gcSmtAvcrUBpg@mail.gmail.com> <firstname.lastname@example.org> <email@example.com>
On 31.08.2011 20:09, Pedro Alves wrote:
On Wednesday 31 August 2011 15:47:32, Tom Tromey wrote:
Just to mention that: My company would be very interested in (optional)
'thread specific breakpoints' support for remote targets. gdb could ask
a gdbstub whether it supports this feature (by the qSupported packet).
You're right, we don't.
"Josh" == Josh Watt<firstname.lastname@example.org> writes:
Josh> As can been seen from the log, the stub is sending a message to
Josh> switch to thread 1040 ($Hg410#44) right before setting the
Josh> breakpoint (and again before deleting it). In subsequent
Josh> operation, it is apparent that it is always switching to this
Josh> thread when setting and clearing a breakpoint.
FWIW I found your note very clear, thanks for the dump and background
Josh> Because of this, our remote stub cannot rely on the currently
Josh> selected thread as the target thread for a given breakpoint and
Josh> must communicate with GDB every time a breakpoint is hit.
I did not understand this though.
It sounds like you are making breakpoints on the target thread-specific
based on the current thread. But I thought we didn't (yet) have a way
to inform the target that a given breakpoint was thread-specific (but I
don't know this area extremely well -- if I'm wrong I'd like to know
In our case, our proprietary real-time OS already offers support for
'thread specific breakpoints' and it is definitely not an option for our
system to use the 'thread specific breakpoint emulation' performed by
the gdb frontend today as it would disrupt real-time behavior. The lack
of this feature causes major troubles for us during single-stepping,
where temporary (global) breakpoints are set by the gdb frontend... to
circumvent this "problem", I had to slightly extend the remote protocol
for real 'thread specific breakpoints' (I just added a new breakpoint
type (5) that also passes the Pid/Tid to the stub and which is used
during step operations). I really hope we can make this feature (however
it'll be implemented) part of the original gdb sometime in the future!
I think it would be preferable to
implement real target support for thread-specific breakpoints.
Sending packet: $vCont?#49...Ack
Packet vCont (verbose-resume) is NOT supported
Sending packet: $s#73...Ack
Please implement vCont support in your stub. s and c
are deprecated on multi-threaded targets. There's no
way to make them work correctly in some cases.