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

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

[Grant Edwards]

I'm having problems establishing a gdb remote connection when I
want to debug an eCos app that's already in RAM.

If I download my eCos app into RAM via a legacy TCP protocol
I've added to RedBoot and then execute it with a "go" command
at the RedBoot prompt, everything works fine.  Likewis if I
load it with the "load" command or "fis load" command.

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.]

The same thing happens if I load an app into RAM using "fis
load".  When I subsequently do a "target remote /dev/ttyXX"
command the app starts and the remote connection fails.

Can others do an "fis load foobar" to get the app into RAM and
then connect using gdb remote target?

Yes, connecting and then downloading with gdb works fine.

I've probably broken something in my version of RedBoot. :(


Background:

  Several of my customers have been complaining about how long
  it takes to download when debugging via serial/remote.
  They're right -- downloading several MB at 57.6K using gdb's
  remote protocol can get tiring.

  I don't have debugging via TCP working because of the
  multiple IP address requirement.  Solving that problem is the
  "right" thing to do, but it's going to take a fair bit of
  work. However, I do have a way to download quickly using TCP
  and a legacy protocol I've built into my version of RedBoot.
  So, I thought that loading the app into RAM before I start
  gdb would be the thing to do.

-- 
Grant Edwards
grante@visi.com

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

[Grant Edwards]

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

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

[Jesper Skov]

On Fri, 2001-11-23 at 03:08, Grant Edwards wrote:
> On Thu, Nov 22, 2001 at 10:19:15AM +0100, Jesper Skov wrote:
> > >>>>> "Grant" == Grant Edwards <grante@visi.com> writes:
> > 
> > Grant> So the question is: why does loading data to the first 48 bytes
> > Grant> in RAM break the gdb stubs?  It's an ARM7 platform, in case
> > Grant> that matters.  Do the gdb stubs expect the interrupt vectors to
> > Grant> be in a certain state?
> > 
> > Because RedBoot enters GDB mode hitting a berakpoint - and you just
> > changed the vector to point at your program's entry address by
> > overloading the bottom of RAM.
> 
> I see. Breakpoints are done via SW interrupt?

No, undefined instructions.

Jesper

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

[Grant Edwards]

On Thu, Nov 22, 2001 at 10:19:15AM +0100, Jesper Skov wrote:
> >>>>> "Grant" == Grant Edwards <grante@visi.com> writes:
> 
> Grant> So the question is: why does loading data to the first 48 bytes
> Grant> in RAM break the gdb stubs?  It's an ARM7 platform, in case
> Grant> that matters.  Do the gdb stubs expect the interrupt vectors to
> Grant> be in a certain state?
> 
> Because RedBoot enters GDB mode hitting a berakpoint - and you just
> changed the vector to point at your program's entry address by
> overloading the bottom of RAM.

I see. Breakpoints are done via SW interrupt?

-- 
Grant Edwards
grante@visi.com

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

[Jesper Skov]

>>>>> "Grant" == Grant Edwards <grante@visi.com> writes:

Grant> So the question is: why does loading data to the first 48 bytes
Grant> in RAM break the gdb stubs?  It's an ARM7 platform, in case
Grant> that matters.  Do the gdb stubs expect the interrupt vectors to
Grant> be in a certain state?

Because RedBoot enters GDB mode hitting a berakpoint - and you just
changed the vector to point at your program's entry address by
overloading the bottom of RAM.

Jesper

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

[Grant Edwards]

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