* [ECOS] remote debugging
@ 2005-03-13 18:32 B.E.Comp Project
2005-03-14 4:47 ` Gary Thomas
0 siblings, 1 reply; 6+ messages in thread
From: B.E.Comp Project @ 2005-03-13 18:32 UTC (permalink / raw)
To: ecos-discuss
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.
(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 ?
2) How can other breakpoints be set ?
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] remote debugging
2005-03-13 18:32 [ECOS] remote debugging B.E.Comp Project
@ 2005-03-14 4:47 ` Gary Thomas
2005-03-14 11:09 ` B.E.Comp Project
0 siblings, 1 reply; 6+ messages in thread
From: Gary Thomas @ 2005-03-14 4:47 UTC (permalink / raw)
To: B.E.Comp Project; +Cc: eCos Discussion
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] remote debugging
2005-03-14 4:47 ` Gary Thomas
@ 2005-03-14 11:09 ` B.E.Comp Project
2005-03-15 2:35 ` Gary Thomas
0 siblings, 1 reply; 6+ messages in thread
From: B.E.Comp Project @ 2005-03-14 11:09 UTC (permalink / raw)
To: eCos Discussion; +Cc: Gary Thomas
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] remote debugging
2005-03-14 11:09 ` B.E.Comp Project
@ 2005-03-15 2:35 ` Gary Thomas
0 siblings, 0 replies; 6+ messages in thread
From: Gary Thomas @ 2005-03-15 2:35 UTC (permalink / raw)
To: B.E.Comp Project; +Cc: eCos Discussion
On Mon, 2005-03-14 at 10:19 +0530, B.E.Comp Project wrote:
> 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 ?
Just put the name of the executable on the command line where you
started GDB:
# i386-elg-gdb <program>
>
> 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!
>
The 'load' step assumed that you were running RedBoot on the target.
>
> 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 ?
>
RedBoot
>
> 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 ?
>
That your code was linked at the wrong address :-( [Wrong startup
type - it should be RAM for applications using RedBoot]
>
>
>
>
>
>
> 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
> > ------------------------------------------------------------
> >
> >
>
--
------------------------------------------------------------
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] remote debugging
2002-07-22 9:35 Vinayak P Risbud
@ 2002-07-22 9:43 ` Gary Thomas
0 siblings, 0 replies; 6+ messages in thread
From: Gary Thomas @ 2002-07-22 9:43 UTC (permalink / raw)
To: Vinayak P Risbud; +Cc: eCos Discussion, gdb
On Mon, 2002-07-22 at 10:34, Vinayak P Risbud wrote:
> Hi,
> I am trying to use remote debugging using LAN (Tcp/Ip) on
> Redboot
> What I understood till now is,
> 1. the main polls net_io_test function during idle
> time
> 2. The function net_io_test checks for
> tcp_sock.state == _ESTABLISHED
> 3. If established, the control calls
> net_io_assume_console
> to setup debug channel.
More than that - at this point, all "console" I/O to RedBoot now goes
through the TCP/IP connection.
>
> But, after this, how the flow goes, I am not able to
> trace.
> my gdb client on remote PC sends $Hc-1#09 command,
> over tcp/ip link.
> I am not able to trace, where and how exactly this gdb
> command is read and processed (i.e trap is generated ?)
As soon as RedBoot sees a "$" at the start of a command line, it
switches to GDB (via a call to 'breakpoint()'). This happens whether
you are using serial or network I/O. GDB will then continue to use the
network connection for it's I/O to the target device.
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ECOS] remote debugging
@ 2002-07-22 9:35 Vinayak P Risbud
2002-07-22 9:43 ` Gary Thomas
0 siblings, 1 reply; 6+ messages in thread
From: Vinayak P Risbud @ 2002-07-22 9:35 UTC (permalink / raw)
To: Ecos-Discuss; +Cc: gdb
Hi,
I am trying to use remote debugging using LAN (Tcp/Ip) on
Redboot
What I understood till now is,
1. the main polls net_io_test function during idle
time
2. The function net_io_test checks for
tcp_sock.state == _ESTABLISHED
3. If established, the control calls
net_io_assume_console
to setup debug channel.
But, after this, how the flow goes, I am not able to
trace.
my gdb client on remote PC sends $Hc-1#09 command,
over tcp/ip link.
I am not able to trace, where and how exactly this gdb
command is read and processed (i.e trap is generated ?)
Can any one help in tracing the flow ?
Thanks in advance
Vinayak
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-03-14 11:15 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-03-13 18:32 [ECOS] remote debugging B.E.Comp Project
2005-03-14 4:47 ` Gary Thomas
2005-03-14 11:09 ` B.E.Comp Project
2005-03-15 2:35 ` Gary Thomas
-- strict thread matches above, loose matches on Subject: below --
2002-07-22 9:35 Vinayak P Risbud
2002-07-22 9:43 ` Gary Thomas
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).