[ECOS] Gdb stubs debugging an a-priori executable?

Grant Edwards grante@visi.com
Wed Nov 14 01:29:00 GMT 2001





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




More information about the Ecos-discuss mailing list