Relaunch gdbserver target does not reload elf? [message #211913] |
Fri, 14 March 2008 01:47  |
Eclipse User |
|
|
|
Originally posted by: burgess.greeneridge.com
Using the "Debug" button to relaunch a gdbserver debug session appears NOT
TO RELOAD THE ELF DATA when there have been no changes.
Static global variables declared at compile/load time and changed at run
time retain their changed settings when the program is relaunched.
On top of this, interrupt settings from the previous launch remain in
effect so the relaunched program immediately jumps to an unprepared
interrupt service routine before executing a single instruction from the
initialization startup code.
Are there any tricks to force Eclipse/CDT/gdb to reload an elf file when a
target is relaunched? Otherwise this setup is working incredibly well for
me for which I am eternally grateful.
Thanks --Bill
Eclipse 3.4M5/CDT 4.0.2 on Mac OS X 10.5.2
Debug via gdbserver/Ethernet to ARM RealView ICE JTAG
ARM 926EJ-S target
gdbinit script sets target, loads file.elf, and disconnects
(Am *not* using gdbjtag plugin, could never get it to work)
|
|
|
Re: Relaunch gdbserver target does not reload elf? [message #211958 is a reply to message #211913] |
Sat, 15 March 2008 01:00  |
Eclipse User |
|
|
|
Originally posted by: burgess.greeneridge.com
Problem solved.
I am still not sure why the same .elf file worked sometimes and not
others, however, my .gdbinit file now disables interrupts (via a
memory-mapped register) and explicitly sets the start address. With these
additions I can debug the same .elf file repeatedly with no trouble.
Again, this is using standard CDT with gdbserver debugging, no embedded
plugins.
This is the .gdbinit file that works with the RealView ICE via
Ethernet/gdbserver. __ml_reset is my start vector (symbol acquired via
the file command). 0x40008000 is the address of the main interrupt-enable
register for this target (an ARM9-based LPC3180).
file load.elf
target remote 192.168.100.50:4001
load load.elf
set {int}0x40008000 = 0
set $pc = __ml_reset
disconnect
|
|
|
Powered by
FUDForum. Page generated in 0.06343 seconds