Thread Specific Breakpoints in Remote Targets

[Josh Watt <jpewdev at gmail dot com>]

Hello,

I'm working on implementing an GDB remote stub for a project, and I
had a question
about the behavior of GDB.

For starters, I'm running GDB 7.3a compiled from vanilla source using
MinGW on Windows
XP with the following configure options:
--target=arm-eabi

The target device runs a custom RTOS, and I was able to get the remote
stub to correctly
report the OS threads back to GDB, thus allowing GDB to examine the
individual threads.

My question in particular is related to Thread Specific breakpoints.
Our remote stub has
the ability to internally implement thread specific breakpoints which
saves a lot of overhead
when the breakpoints are in frequently visited locations, since it
means that we don't have
to talk over the slow serial link to GDB just for it to tells us we
can continue execution.

However, it appears that GDB is doing some weird things with regard to
the thread selection.
See the log below:

(gdb) info threads
? Id?? Target Id???????? Frame
? 41?? Thread 1040 ("Thread 1040") at ...
  40   Thread 1039 ("Thread 1039") at ...
<output truncated for brevity>
? 4??? Thread 1004 ("Thread 1004") at ...
? 3??? Thread 1003 ("Thread 1003") at ...
? 2??? Thread 1002 ("Thread 1002") at ...
* 1??? Thread 1000 ("Thread 1000") at ...
(gdb) break *$pc thread 1
Breakpoint 1 at 0x80232ce4: file ..., line 134.
(gdb) set debug remote 1
(gdb) cont
Continuing.
Sending packet: $vCont?#49...Ack
Packet received:
Packet vCont (verbose-resume) is NOT supported
Sending packet: $Hc3e8#7b...Ack
Packet received: OK
Sending packet: $s#73...Ack
Packet received: T05thread:3e8;0:d05da48c;1:02000000;2:01000000;3:00000000;4:000
00000;5:00000000;6:00000000;7:00000000;8:00000000;9:00000000;A:00000000;B:000000
00;C:00000000;D:00a9b782;E:69ec4080;F:e42c2380;19:3f000000;
Sending packet: $Hg410#44...Ack
Packet received: OK
Sending packet: $g#67...Ack
Packet received: 000000000000000000000000000000000100000000000000000000000000000
00000000000000000000000000000000023280900086d6c87c1ef238068f04080
Sending packet: $Z0,80232ce2,2#0d...Ack
Packet received: OK
Sending packet: $Hg3e8#7f...Ack
Packet received: OK
Sending packet: $g#67...Ack
Packet received: d05da48c0200000001000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000a9b78269ec4080e42c2380
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $c#63...Ack
Packet received: T05thread:3e8;0:e0302380;1:02000000;2:01000000;3:00000000;4:000
00000;5:00000000;6:00000000;7:00000000;8:00000000;9:00000000;A:00000000;B:000000
00;C:00000000;D:00a9b782;E:69ec4080;F:e22c2380;19:3f000000;
Sending packet: $Hg410#44...Ack
Packet received: OK
Sending packet: $g#67...Ack
Packet received: 000000000000000000000000000000000100000000000000000000000000000
00000000000000000000000000000000023280900086d6c87c1ef238068f04080
Sending packet: $z0,80232ce2,2#2d...Ack
Packet received: OK
Sending packet: $Hg3e8#7f...Ack
Packet received: OK
Sending packet: $g#67...Ack
Packet received: e03023800200000001000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000a9b78269ec4080e22c2380

Breakpoint 1, Sending packet: $m80232ce2,4#c6...Ack
Packet received: ff4803c8
0x80232ce2 in ...
(gdb)


As can been seen from the log, the stub is sending a message to switch
to thread 1040 ($Hg410#44)
right before setting the breakpoint (and again before deleting it). In
subsequent operation, it is apparent
that it is always switching to this thread when setting and clearing a
breakpoint. Because of this,
our remote stub cannot rely on the currently selected thread as the
target thread for a given breakpoint
and must communicate with GDB every time a breakpoint is hit.

I also find it interesting that the selected thread is number 1040,
which is the last thread reported to GDB
by the remote stub.

I looked through some of the code, and I think it is due to the following:

In breakpoint.c there are calls to switch_to_program_space_and_thread() at
lines 1895 and 2662 which must be selecting the wrong thread, but I'm not sure
how to make it select the correct thread (if it is even supposed to).


Thanks,
--
~JPEW