Re: [ECOS] Questions about GDB Ctrl-C support.

[Grant Edwards <grante at visi dot com>]

On Tue, Sep 11, 2001 at 05:14:05PM +0200, Jesper Skov wrote:

> >>  Well, the stub uses the debug channel and hence the driver RedBoot
> >> provided for driving that channel. however, the stub code
> >> internally uses VV (IIRC) so you should be able to CLAIM_COMMS in
> >> the application (i.e., the application provides the drivers used by
> >> printf) and still be able to use the GDB support (which will then
> >> call into RAM for printing).

Is CLAIM_COMMS a macro?  My snapshot doesn't have it anywhere.
It also doesn't have *_INHERIT_CONSOLE or *_DIAG_TO_DEBUG_CHAN.
Now that I'm overhauling my HAL, I guess I should update to a
newer snapshot (something I haven't been looking forward to).
I'm not flying to visit a customer (an airline) tomorrow as I
had planned...

> Grant> I'm not sure what you mean by "call into RAM".  Do you mean
> Grant> that the GDB stubs in RedBoot will use routines in the eCos
> Grant> application (via the VV table) to do I/O to/from GDB?  [In my
> Grant> case both RedBoot and the eCos application are in RAM.]
> 
> Indeed. The VV table allows calling from RAM to ROM or vice
> versa. Effectively removing the need for callee and caller to be in
> the same (linker) address space.

When the eCos app takes over the comm channels, is there any
state info that gets lost?  Where is the identity of the diag
channel (1) stored?  Does RedBoot remember (outside of the VV
routines) which channel is in use for debug? Redboot knows
about three serial ports (we'll call them 0,1,2), and it will
have chosen #1 as the debug and console channel since that's
the first one upon which received input.  Since I want the app
to send diag_printf() output to #0, I disable
C_H_V_V_INHERIT_CONSOLE and C_H_DIAG_TO_DEBUG_CHAN, and
configure chan 0 and diag and chan 1 as debug (or something
along those lines.

-- 
Grant Edwards
grante@visi.com