Re: ptrace: bogus breakpoint trap

[Hinko Kocevar <hinko dot kocevar at iskramedical dot si>]

Daniel Jacobowitz wrote:
> No, the message is harmless.  You'll have to look at the remote
> protocol transcript and check what gdbserver is doing.

Enabling 'Debugging of remote protocol' reveals following on first ARM 
platform:
...
<- "(gdb) "
-> "info breakpoints\n"
<- "Num Type           Disp Enb Address    What\n"
   "1   breakpoint     keep y   0x000084a8 in main at debug-test.c:6\n"
   "(gdb) "
...
-> "target remote 192.168.0.99:2345\n"
<- "Sending packet: $Hc-1#09..."
<- "Ack\n"
<- "Packet received: OK\n"
   "Sending packet: $qC#b4...Ack\n"
   "Packet received: \n"
   "Sending packet: $qOffsets#4b..."
<- "Ack\n"
   "Packet received: \n"
   "Sending packet: $?#3f...Ack\n"
   "Packet received: T050b:00000000;0d:a0feffbf;0f:60140040;\n"
   "Sending packet: $m40001460,4#5c...Ack\n"
   "Packet received: 0d00a0e1\n"
   "Sending packet: $Hg0#df...Ack\n"
   "Packet received: OK\n"
   "Sending packet: $g#67..."
<- "Ack\n"
   "Packet received: 
0000000058ffffbf0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a0feffbf00000000601400400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000\n"
   "0x40001460 in ?? ()\n"
   "Sending packet: $m10658,a8#36..."
...
  "Packet received: \n"
   "binary downloading NOT suppported by target\n"
   "Sending packet: $M84a8,4:01009fef#17..."
<- "Ack\n"
   "Packet received: OK\n"
   "Sending packet: $m4000c258,4#93..."
<- "Ack\n"
   "Packet received: 1eff2fe1\n"
   "Sending packet: $M4000c258,4:01009fef#d8..."
<- "Ack\n"
   "Packet received: OK\n"
   "Sending packet: $Hc0#db...Ack\n"
...

Later execution stops due to shared library event. Info shared gives out
0x40001460  0x40011914  Yes 
/opt/arm-linux/gcc-3.3.3-glibc-2.3.2/arm-softfloat-linux-gnu/lib/ld-linux.so.2

Breakpoint in main() is set at 0x000084a8 but ignored and execution 
continues till shared lib event occurs at 0x40001460 - gdb entry when I 
issue first 'cont'. At 0x4000c258 is shlib events breakpoint for 
function <_dl_debug_state_internal>.


I tried same procedure on second ARM platform I have, with the same 
binary, and gdb enters at 0x40000ae0 instead of 0x40001460, and this 
time execution _does_ stop at breakpoint set in main(). Note: this 
platform does _not_ have same libs as the first one above!

With second platform gdb log shows:
...
-> "info breakpoints\n"
<- "Num Type           Disp Enb Address    What\n"
   "1   breakpoint     keep y   0x000084a8 in main at debug-test.c:6\n"
   "(gdb) "
...
-> "target remote ipaq:2345\n"
<- "Sending packet: $Hc-1#09..."
<- "Ack\n"
<- "Packet received: OK\n"
   "Sending packet: $qC#b4..."
<- "Ack\n"
<- "Packet received: \n"
   "Sending packet: $qOffsets#4b..."
<- "Ack\n"
<- "Packet received: \n"
   "Sending packet: $?#3f..."
<- "Ack\n"
<- "Packet received: T050b:00000000;0d:10feffbf;0f:e00a0040;\n"
   "Sending packet: $m40000ae0,4#b7..."
<- "Ack\n"
<- "Packet received: 0d00a0e1\n"
   "Sending packet: $Hg0#df..."
<- "Ack\n"
<- "Packet received: OK\n"
   "Sending packet: $g#67..."
<- "Ack\n"
<- "Packet received: 
00000000dffeffbf000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010feffbf00000000e00a00400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000\n"
   "0x40000ae0 in ?? ()\n"
   "Sending packet: $m10658,a8#36..."
...
<- "Packet received: \n"
   "binary downloading NOT suppported by target\n"
   "Sending packet: $M84a8,4:01009fef#17..."
<- "Ack\n"
<- "Packet received: OK\n"
   "Sending packet: $m4000b8d8,4#c7..."
<- "Ack\n"
<- "Packet received: 04b04ce2\n"
   "Sending packet: $M4000b8d8,4:01009fef#0c..."
<- "Ack\n"
<- "Packet received: OK\n"
   "Sending packet: $Hc0#db..."
<- "Ack\n"
...

Those excerpts are shown 'cause logs start to differ there (and further 
on). First log is for bogus operation and the second log is for correct 
operation.
I can tell that gdb enters at different mem locations, from the packets 
sent/recieved, but I can't fully decode this packets myself (Is there 
some reference to this cryptic info?). In bogus operation gdb enters in 
ld-linux.so.2; skipping my app?

If this gives anyone some clues, please, let me know...

regards,
h

--
hinko <dot> kocevar <at> iskramedical <dot> si
Hinko Kocevar, developer
Iskra Medical d.o.o., Stegne 23, 1k LJ, SLO-EU

	"Aì rén"	|	[Analects XII:22]