gdbserver thread event breakpoint

[Amol Dixit <dixit at netapp dot com>]

While debugging gdbserver with thread program (compiled w/ libthr) on 
_FreeBsd_, I am seeing that when a thread is created it correctly 
signals a SIGTRAP. In gbdserver we then call target routine 
get_stop_pc() to obtain the pc where it stopped so that we can check 
against our breakpoints. When the first primary thread is created, the 
address returned from get_stop_pc() matches thread-creation breakpoint 
address.
But when the next thread is created using pthread_create(), I correctly 
get a SIGTRAP (since we have reinserted breakpoint) but get_stop_pc() 
returns an incorrect pc; we are expecting pc of _thread_bp_create() but 
instead we get pc of its caller pthread_create(). So it seems like the 
pc has changed under us after SIGTRAP is reported to gdbserver.

In this gdbserver debug session below, I break in check_breakpoints -

location for thread creation breakpoint 0x88082e30 << this is expected 
pc of _thread_bp_create()

(gdb) c
Continuing.
_libpthread_init: new thread 100317 << 'primary' thread creation

Breakpoint 6, check_breakpoints (stop_pc=-2012729808) at ../mem-break.c:205
205 bp = find_breakpoint_at (stop_pc);
(gdb) p/x stop_pc
$4 = 0x88082e30 << pc is correct for 'primary' thread

(gdb) c
Continuing.
Creating thread for fn1 << next thread being created

Breakpoint 6, check_breakpoints (stop_pc=-2012733393) at ../mem-break.c:205
205 bp = find_breakpoint_at (stop_pc);
(gdb) p/x stop_pc
$5 = 0x8808202f << pc is incorrect of pthread_create().
(gdb) c

So now there is mismatch and we cannot find the correct breakpoint.
Does anyone have any insights into why reported pc is different from the 
breakpoint pc (where we insert 'int 3')?

Here is the log from host side

Packet received: qSymbol:5f7468726561645f6f66665f6576656e745f627566
Sending packet: 
$qSymbol:88084020:5f7468726561645f6f66665f6576656e745f627566#e0...Ack
Packet received: OK
Sending packet: $qSymbol::#5b...Ack
Packet received: OK
Sending packet: $qSymbol::#5b...Ack
Packet received: OK
Sending packet: $vCont;s:c001#e6...Ack
Packet received: T0505:d8ebbfbf;04:38eabfbf;08:81da0488;thread:c001;
[New Thread 49153]
Sending packet: $m8804da80,1#cb...Ack
Packet received: 55
Sending packet: $X8804da80,1:?bc...Ack
Packet received: OK
Sending packet: $vCont;c#a8...Ack
Packet received: T0505:00000000;04:f0ef9fbf;08:30200888;thread:c001; << 
Incorrect thread ID c001, since we couldn't match breakpoint

Program received signal SIGTRAP, Trace/breakpoint trap.
Sending packet: $X8804da80,1:U#45...Ack
Packet received: OK
Sending packet: $g#67...Ack
Packet received: 
c701000008b1040800b10408b4430888f0ef9fbf0000000000b00408010000003020088896020000330000003b0000003b0000003b0000003b0000001b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080fe3f7f12000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
thread_start (curthread=0x804b000)
at 
/amd/nanebb/share/bammbamm/nane/scratch/dixit/vfs_808897_07011143/freebsd/usr/src/lib/libthr/thread/thr_create.c:219
219 {

(gdb) info sym 0x88082e30
_thread_bp_create in section .text
(gdb) info sym 0x8808202f
pthread_create + 1415 in section .text

Host side gets sigtrap since I believe we are sending incorrect 
thread-id and it thinks this is a legit breakpoint set by user.

Hope I explained clearly and didn't confuse with extra info.
Thanks a lot,
Amol