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

[Grant Edwards <grante at visi dot com>]

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