* ptrace: bogus breakpoint trap
@ 2004-08-26 10:34 Hinko Kocevar
2004-08-26 13:35 ` Daniel Jacobowitz
2004-08-27 16:27 ` Hinko Kocevar
0 siblings, 2 replies; 5+ messages in thread
From: Hinko Kocevar @ 2004-08-26 10:34 UTC (permalink / raw)
To: gdb
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]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ptrace: bogus breakpoint trap
2004-08-26 10:34 ptrace: bogus breakpoint trap Hinko Kocevar
@ 2004-08-26 13:35 ` Daniel Jacobowitz
2004-08-26 15:58 ` Hinko Kocevar
2004-08-27 16:27 ` Hinko Kocevar
1 sibling, 1 reply; 5+ messages in thread
From: Daniel Jacobowitz @ 2004-08-26 13:35 UTC (permalink / raw)
To: Hinko Kocevar; +Cc: gdb
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ptrace: bogus breakpoint trap
2004-08-26 13:35 ` Daniel Jacobowitz
@ 2004-08-26 15:58 ` Hinko Kocevar
2004-08-26 16:14 ` Hinko Kocevar
0 siblings, 1 reply; 5+ messages in thread
From: Hinko Kocevar @ 2004-08-26 15:58 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
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]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ptrace: bogus breakpoint trap
2004-08-26 15:58 ` Hinko Kocevar
@ 2004-08-26 16:14 ` Hinko Kocevar
0 siblings, 0 replies; 5+ messages in thread
From: Hinko Kocevar @ 2004-08-26 16:14 UTC (permalink / raw)
To: gdb; +Cc: Daniel Jacobowitz
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]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ptrace: bogus breakpoint trap
2004-08-26 10:34 ptrace: bogus breakpoint trap Hinko Kocevar
2004-08-26 13:35 ` Daniel Jacobowitz
@ 2004-08-27 16:27 ` Hinko Kocevar
1 sibling, 0 replies; 5+ messages in thread
From: Hinko Kocevar @ 2004-08-27 16:27 UTC (permalink / raw)
To: gdb
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]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2004-08-27 16:27 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-08-26 10:34 ptrace: bogus breakpoint trap Hinko Kocevar
2004-08-26 13:35 ` Daniel Jacobowitz
2004-08-26 15:58 ` Hinko Kocevar
2004-08-26 16:14 ` Hinko Kocevar
2004-08-27 16:27 ` Hinko Kocevar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).