* 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).