On Tuesday 22 July 2008 23:17:40 you wrote: > Take #2 > > Perhaps poll() has not been invoked?
That didn't fix it either. The situation is actually worse than just a bogus 0x0 which can be easily identified. [EMAIL PROTECTED]:~/arm$ ntoarm-gdb /home/vmaster/arm/qnx/workspace/sam9_l9260/Images/startup-at91sam9263ek.sym GNU gdb 6.7 Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-unknown-nto-qnx6.3.0"... (no debugging symbols found) (gdb) target remote localhost:3333 Remote debugging using localhost:3333 0x23f1c8b4 in ?? () (gdb) poll Undefined command: "poll". Try "help". (gdb) mon reg pc pc (/32): 0x23f1a8f8 Here GDB showed the PC from when the _previous_ GDB session last entered debug state. The comments from gdb_server.c seems to indicate this is actually desired behaviour?! /* a gdb session just attached, try to put the target in halt mode. * * DANGER!!!! * * If the halt fails(e.g. target needs a reset, JTAG communication not * working, etc.), then the GDB connect will succeed as * the get_gdb_reg_list() will lie and return a register list with * dummy values. * * This allows GDB monitor commands to be run from a GDB init script to * initialize the target * * Also, since the halt() is asynchronous target connect will be * instantaneous and thus avoiding annoying timeout problems during * connect. */ The above comment means that OpenOCD knowingly replies with stale data, even if there's absolutely no reason for doing so... Best regards, Dominic _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
