ptrace: bogus breakpoint trap

ptrace: bogus breakpoint trap

[Hinko Kocevar]

Hi,

While trying to solve my previous problem with dynamic shared libraries 
and automated symbol loading I stumbled accross another problem.

On ARM target (that uses same libs and binary as ones provided to gdb on 
host) program execution does not stop on set breakpoint instead it 
continues and program exits normally. Here is my setup:

on ARM target:
/staging # gdbserver noa:2345 ./debug-test-ARM
Process ./debug-test-ARM created; pid = 39
Remote debugging from host 192.168.0.77
ptrace: bogus breakpoint trap
Izpisujem val: 999
Izpisujem val drugic: 1998

Child exited with retcode = 0

Child exited with status 0
GDBserver exiting

on host:
(gdb) file /home/xtrm/delo/tmp/mojj/debug-test-ARM
Reading symbols from /home/xtrm/delo/tmp/mojj/debug-test-ARM...done.
Reading in symbols for debug-test.c...done.

(gdb) info breakpoints
Num Type           Disp Enb Address    What
7   breakpoint     keep y   0x000084c0 in main at debug-test.c:10

(gdb) target remote 192.168.0.99:2345
0x40001460 in ?? ()
(gdb) cont
Reading symbols from 
/opt/arm-linux/gcc-3.3.3-glibc-2.3.2/arm-softfloat-linux-gnu/lib/libc.so.6...done.
Reading symbols from 
/opt/arm-linux/gcc-3.3.3-glibc-2.3.2/arm-softfloat-linux-gnu/lib/ld-linux.so.2...done.

Program exited normally.

Now, the symbols seem to be read, but I can't verify 'cause the program 
doesn't halt on set breakpoint. On target I get "ptrace: bogus 
breakpoint trap" - is this the problem?

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]

Re: ptrace: bogus breakpoint trap

[Daniel Jacobowitz]

On Thu, Aug 26, 2004 at 12:34:10PM +0200, Hinko Kocevar wrote:
> Now, the symbols seem to be read, but I can't verify 'cause the program 
> doesn't halt on set breakpoint. On target I get "ptrace: bogus 
> breakpoint trap" - is this the problem?

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

-- 
Daniel Jacobowitz

Re: ptrace: bogus breakpoint trap

[Hinko Kocevar]

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]

Re: ptrace: bogus breakpoint trap

[Hinko Kocevar]

Little more info from target debugging.
First ARM platform - bogus operation:
...
<- "Num Type           Disp Enb Address    What\n"
    "1   breakpoint     keep y   0x000084a8 in main at debug-test.c:6\n"
<- "(gdb) "
-> "cont\n"
<- "target_xfer_memory (0x84a8, xxx, 4, read, xxx) = 4, bytes = f9 3f a0 
e3\n"
<- "target_xfer_memory (0x84a8, xxx, 4, write, xxx) = 4, bytes = 01 00 
9f ef\n"
    "target_insert_breakpoint (0x84a8, xxx) = 0\n"
    "target_xfer_memory (0x4000c258, xxx, 4, read, xxx) = 4, bytes =\n"
    " 1e ff 2f e1\n"
<- "target_xfer_memory (0x4000c258, xxx, 4, write, xxx) = 4, bytes = 01 
00 9f ef\n"
    "target_insert_breakpoint (0x4000c258, xxx) = 0\n"
    "target_terminal_inferior ()\n"
    "target_resume (-1, continue, 0)\n"
<- "target_wait (-1, status) = 42000,   status->kind = stopped, signal = 
SIGTRAP\n"
<- "target_xfer_memory (0x84a8, xxx, 4, write, xxx) = 4, bytes = f9 3f 
a0 e3\n"
    "target_remove_breakpoint (0x84a8, xxx) = 0\n"
    "target_xfer_memory (0x4000c258, xxx, 4, write, xxx) = 4, bytes =\n"
    " 1e ff 2f e1\n"
    "target_remove_breakpoint (0x4000c258, xxx) = 0\n"
    "target_terminal_ours_for_output ()\n"
...

Second ARM platform - correct operation:
...
<- "Num Type           Disp Enb Address    What\n"
    "1   breakpoint     keep y   0x000084a8 in main at debug-test.c:6\n"
<- "(gdb) "
-> "cont\n"
<- "target_xfer_memory (0x84a8, xxx, 4, read, xxx) = 4"
<- ", bytes ="
<- "\n"
<- " f9 3f a0 e3\n"
<- "target_xfer_memory (0x84a8, xxx, 4, write, xxx) = 4, bytes = 01 00 
9f ef\n"
    "target_insert_breakpoint (0x84a8, xxx) = 0\n"
<- "target_xfer_memory (0x4000b8d8, xxx, 4, read, xxx) = 4, bytes =\n"
    " 04 b0 4c e2\n"
<- "target_xfer_memory (0x4000b8d8, xxx, 4, write, xxx) = 4, bytes = 01 
00 9f ef\n"
    "target_insert_breakpoint (0x4000b8d8, xxx) = 0\n"
    "target_terminal_inferior ()\n"
<- "target_resume (-1, continue, 0)\n"
<- "target_wait (-1, status) = 42000,   status->kind = stopped, signal = 
SIGTRAP\n"
<- "target_xfer_memory (0x84a8, xxx, 4, read, xxx) = 4"
<- ", bytes = 01 00 9f ef\n"
<- "target_fetch_registers (cpsr) = 10000060 0x60000010 1610612752\n"
<- "target_xfer_memory (0x84a8, xxx, 4, read, xxx) = 4, bytes = 01 00 9f 
ef\n"
<- "target_xfer_memory (0x8498, xxx, 4, read, xxx) = 4, bytes = 0d c0 a0 
e1\n"
<- "target_xfer_memory (0x849c, xxx, 4, read, xxx) = 4, bytes = 00 d8 2d 
e9\n"
<- "target_xfer_memory (0x84a0, xxx, 4, read, xxx) = 4, bytes = 04 b0 4c 
e2\n"
<- "target_xfer_memory (0x84a4, xxx, 4, read, xxx) = 4, bytes = 04 d0 4d 
e2\n"
<- "target_xfer_memory (0x84a8, xxx, 4, read, xxx) = 4"
...

reagrds,
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]

Re: ptrace: bogus breakpoint trap

[Hinko Kocevar]

Hinko Kocevar wrote:
> Hi,
> 
> While trying to solve my previous problem with dynamic shared libraries 
> and automated symbol loading I stumbled accross another problem.
> 

I got this issue sorted out - partly - by using latest gdb - 6.2.
But as the problems just won't go away there is another issue!!

Now dynamic lib symbols load fine and execution stops at set breakpoint.

Proceeding after BP that I can only use 'step' cmd to continue. If issue 
'next' once it continues to the next line of source, but if I use 'next' 
twice or more execution is stopped and pc holds location in .plt 
section. On further attempts to proceed with 'next or 'step' gdb gives 
'Cannot find bounds of current function'.

Looking at the remote protocol log for 'next' and 'step' they start to 
differ after reading contents of accessed location in .plt section. 
After that for 'step' gdb issues read general registers packet while for 
'next' gdb reads some memory location where it gets address of the 
(only) breakpoint set - after that it stops.

Any comments ?

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]