Re: [ECOS] GDB help ?

[Jonathan Larmour <jifl at eCosCentric dot com>]

Mark Salter wrote:
> > > > > > Laurent GONZALEZ writes:
>
>
> > On Fri, 20 Jun 2003 10:00:29 -0400 (EDT)
> > Mark Salter <msalter@redhat.com> wrote:
>
>
> > > > > > > > SOMARAJAN,SUNIL (HP-India,unix2) writes:
> > >
> > > > Specifically if I do a CTRL-C and then quit gdb and enter gdb again this 
> > > > is what I see
> > >
> > > > (gdb) target remote 15.11.40.75:9000
> > > > Remote debugging using 15.11.40.75:9000
> > > > 0x0000b2f0 in ?? ()
> > > > (gdb) load
> > > > Loading section .text, size 0x58d17 lma 0x108000
> > > > Loading section .rodata, size 0x8984 lma 0x160d18
> > > > Loading section .data, size 0x4fe0 lma 0x1696a0
> > > > Ignoring packet error, continuing...
> > > > Remote communication error: Connection reset by peer.
> > >
> > >
> > > > I am using eCOs2.0, x86 target
> > >
> > > You don't need to quit gdb. After the Ctrl-C, use the
> > > 'kill' command. Or just reuse the 'target' command and
> > > answer 'y' when you are prompted about killing the
> > > currently running program.
> > >
> > > It is odd that the load command fails at this point. It
> > > could be that the program you are running is overwriting
> > > some resource that the stub needs. This would explain
> > > why the program loads the first time, but not subsequent
> > > times.

Could be the virtual vector table depending on the config for example.

> > When gdb sends a kill packet to the stubs, it should reset the board and restart redboot. I noticed that this behaviour does not work for all platforms.
>
>
> You really don't want a reboot every time you get a kill packet. If
> you are running the GDB testsuite, you'd get thousands of reboots.
> That would take way too much time on a PC platform. When RedBoot
> sees a kill packet, it restores the CPU context so that you get
> back to the RedBoot prompt. You can get RedBoot to reset the
> target board by using "maint packet r" before using the "kill"
> command.

Althoguh I've found that, of course, depending on what the calling program 
did, it can change the board or device state such that a subsequent 
program won't run as expected.

If your board port includes support for software reset, it can be more 
reliable to use a special eCos-specific hack - the "maintenance packet r" 
command.

If you use a .gdbinit file you can make a macro for this. You need to do 
it at a GDB prompt after the target remote though. Putting this in 
.gdbinit is useful for example:

define trem
 target remote myboard:9000
 maintenance packet r
 load
 rbreak cyg_test_exit
 rbreak cyg_assert_fail
end

Jifl
--
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss