This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Gdb stubs debugging an a-priori executable?
- From: Grant Edwards <grante at visi dot com>
- To: ecos-discuss at sources dot redhat dot com
- Date: Wed, 21 Nov 2001 12:13:44 -0600
- Subject: Re: [ECOS] Gdb stubs debugging an a-priori executable?
- References: <20011121103958.A31449@visi.com>
On Wed, Nov 21, 2001 at 10:40:00AM -0600, Grant Edwards wrote:
> I'm having problems establishing a gdb remote connection when I
> want to debug an eCos app that's already in RAM.
[...]
> However, if I load the file and then attempt a remote gdb
> connection the program starts to execute, and gdb is unable to
> establish a connection. [The program runs fine, but it's not
> supposed to be running yet.]
If I skip the first 48 bytes of the download, everything is
fine. My file executable file layout looks like this:
0000: jump to 0x140
0004
to null bytes
013f
0140: eCos entry point
...
I have the entry point at 0000 for backwards compatibility. If
download starting at 0x30, I can connect, set the PC to 0x140,
and debug as usual.
So the question is: why does loading data to the first 48 bytes
in RAM break the gdb stubs? It's an ARM7 platform, in case
that matters. Do the gdb stubs expect the interrupt vectors to
be in a certain state?
--
Grant Edwards
grante@visi.com