Hi list, is it possible that GDB support in OpenOCD is currently at least partially broken? Are there known bugs that came with TCL, is this something unrelated, but known, or is this something new?
I let the OpenOCD attach to a running target (AT91SAM9260, currently executing u-boot), poll the state via telnet, and then attach a GDB connection: -telnet--------------telnet--------------telnet--------------telnet------------- Open On-Chip Debugger > poll target state: running accepting 'gdb' connection from 0 acknowledgment received, but no packet pending target not halted target not halted target not halted target state: halted target halted in ARM state due to debug request, current mode: Supervisor cpsr: 0x400000d3 pc: 0x23f09764 MMU: disabled, D-Cache: disabled, I-Cache: enabled > -telnet--------------telnet--------------telnet--------------telnet------------- -gdb-----------------gdb-----------------gdb-----------------gdb---------------- [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 warning: while parsing target memory map (at line 2): Required element <memory> is missing 0x00000000 in ?? () (gdb) -gdb-----------------gdb-----------------gdb-----------------gdb---------------- As you can see, GDB's idea of the current PC is wrong. I'm not completely sure where GDB gets the wrong address from, but a "continue", "ctrl-c" sequence gets me the correct address: -gdb-----------------gdb-----------------gdb-----------------gdb---------------- (gdb) c Continuing. target state: halted target halted in ARM state due to debug request, current mode: Supervisor cpsr: 0x400000d3 pc: 0x23f09764 MMU: disabled, D-Cache: disabled, I-Cache: enabled Program received signal SIGINT, Interrupt. 0x23f09764 in ?? () (gdb) c Continuing. target state: halted target halted in ARM state due to debug request, current mode: Supervisor cpsr: 0x400000d3 pc: 0x23f09764 MMU: disabled, D-Cache: disabled, I-Cache: enabled -gdb-----------------gdb-----------------gdb-----------------gdb---------------- I've also had problems with breakpoints not taken by GDB, but these problems were not reproduceable so far. I've tested both the GDB that came with QNX Momentics 6.3.2 and the version from Code Sourcery's 2007q3 release. Attached is the config file I've used. There was no GDB init script involved. Best regards, Dominic
#daemon configuration telnet_port 4444 gdb_port 3333 gdb_report_data_abort enable #interface interface ft2232 #ft2232_device_desc "Olimex OpenOCD JTAG" #ft2232_layout olimex-jtag #ft2232_vid_pid 0x15ba 0x0003 ft2232_device_desc "Amontec JTAGkey" ft2232_serial AMTJKV31 #ft2232_serial T1P3S2W8 ft2232_layout jtagkey ft2232_vid_pid 0x0403 0xcff8 jtag_speed 1400 #use combined on interfaces or targets that can't set TRST/SRST separately reset_config trst_and_srst separate #jtag scan chain #format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE) jtag_device 4 0x1 0xf 0xe jtag_nsrst_delay 300 jtag_ntrst_delay 300 #target configuration #target <type> <endianess> <reset mode> target arm926ejs little 0 #target_script 0 reset csb337_init.script working_area 0 0x00200000 0x1000 nobackup
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
