Re: [ECOS] remote debugging

["B.E.Comp Project" <comp dot project at gmail dot com>]

Hello,

i have an executable hello with startup type GRUb on the target
running upto the initial breakpoint set by the flag
CYGDBG_HAL_DEBUG_GDB_INITIAL_BREAK


>When you start GDB, tell it the name of your program [binary] and
>you won't need to do this step.

1. when starting GBD how can the name of the program [binary] on remote 
target be specified ?

2. Also without doing this step how does the 'Hello, eCos world!' run ?:


> (gdb) set remotebaud 38400
> (gdb) target remote /dev/ttyS0
> Remote debugging using /dev/ttyS0
> 0x0010bbf0 in ?? ()
> (gdb) continue
> Continuing.
> Hello, eCos world!


3.
>Somewhere in there you need to 'load' the application (using
>GDB's load command which you did not show).

When loading, what should be running on the target ? 


4.
i tried with target booted through RedBoot.

On host:

(gdb) target remote 10.0.0.2:9000
Remote debugging using 10.0.0.2:9000
0x001129f4 in Cyg_Mempool_dlmalloc_Implementation::try_alloc(int)
(this=0x1146c8, bytes=8)
    at /opt/curr_ecos/ecos/ecos/packages/services/memalloc/common/current/src/dlmalloc.cxx:1206
1206                unlink(victim, bck, fwd);
Current language:  auto; currently c++
(gdb)


Same msg appears when we tried through serial line.

What does this imply ? 







On Sun, 13 Mar 2005 08:54:39 -0700, Gary Thomas <gary@mlbassoc.com> wrote:
> On Sun, 2005-03-13 at 21:06 +0530, B.E.Comp Project wrote:
> > Hi,
> >
> > I am trying remote debugging, using GDB stubs,
> > with GRUB as the startup for running a simple application.
> >
> > i set the following flags:
> >
> > CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS
> > CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT
> > CYGDBG_HAL_DEBUG_GDB_INITIAL_BREAK
> >
> > Remote debugging msgs are:
> >
> > (gdb) set remotebaud 38400
> > (gdb) target remote /dev/ttyS0
> > Remote debugging using /dev/ttyS0
> > 0x0010bbf0 in ?? ()
> > (gdb) info breakpoints
> > No breakpoints or watchpoints.
> > (gdb) break main
> > No symbol table is loaded.  Use the "file" command.
> > (gdb) file hello.c
> > A program is being debugged already.  Kill it? (y or n) n
> > Program not killed.
> 
> When you start GDB, tell it the name of your program [binary] and
> you won't need to do this step.
> 
> > (gdb) continue
> > Continuing.
> > Hello, eCos world!
> >
> >
> > 1) Why is the initial breakpoint set by the option
> > 'CYGDBG_HAL_DEBUG_GDB_INITIAL_BREAK' not displayed with command
> > info breakpoints ?
> 
> Because 'info breakpoints' only displays information about the
> breakpoints that GDB knows about and sets itself.  The initial
> break that you can configure via CDL merely causes eCos to execute
> a breakpoint instruction before the application actually starts.
> GDB doesn't really know about this, but will handle it properly.
> n.b. it will probably tell you that it ran into an illegal instruction
> at the startup location, not that it hit a breakpoint.
> 
> >
> > 2) How can other breakpoints be set ?
> >
> 
> Somewhere in there you need to 'load' the application (using
> GDB's load command which you did not show).
> 
> After the application has been loaded, but before you start it
> up via 'continue', set as many breakpoints as you like.  GDB will
> stop and report when it hits the first one.  Also, as you experienced,
> GDB needs to know the symbols for your program before you can set
> any symbolic breakpoints.  Be sure and specify the program/application
> on the command line and things will proceed much smoother.
> 
> --
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------
> 
>

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