This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Thread Specific Breakpoints in Remote Targets

On 31.08.2011 20:09, Pedro Alves wrote:
On Wednesday 31 August 2011 15:47:32, Tom Tromey wrote:
"Josh" == Josh Watt<> 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
about it).
You're right, we don't.
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).

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.
Very much.


Sending packet: $vCont?#49...Ack
Packet received:
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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]