Re: [ECOS] VxWorks type embedded "shell" for eCos

[Mark Grosberg <mark at nolab dot conman dot org>]

On Fri, 6 Feb 2004, Nick Garnett wrote:

> But you can do nearly all of this from GDB already. And those things
> that you cannot do are of very little utility anyway.

How about having the shell use the GDB stubs then?

I think the only thing that GDB can't readily do is download code at
runtime to a running target (although I could be mistaken about that). If
this could be done by writing a different front end for the GDB stubs,
then I'm all for it.

The tricky part about loading code dynamically is that not all of the eCos
routines are present in the target; so loaded code may need an OS routine
that isn't there.

VxWorks solves this by using config.h to force linking of OS modules in
the target binary. Its an ugly hack and I'm sure I'm not the only one who
has been bitten by config.h not pulling in everything required and then
finding out that you have to rebuild and reboot.

Perhaps there is a way to use the host linker (which has knowledge of what
the target is running) to do an additional link pass when uploading new
code and then upload the code and any parts of eCos that are needed in one
fell swoop.

> I am also concerned that even the simplest of shells would be a thin
> end of the wedge for shoehorning lots of other interactive features
> into eCos, which would further bloat the code. Things are already

I agree to some extent. But if it can be done on the host side using the
GDB stubs then there isn't that much cause for alarm. Think of it as a GDB
with a slightly different interface.

I certainly wouldn't like to see any code added target side for this. eCos
is much smaller than VxWorks (at least for the archs I've used) and I
think we should keep it that way.

L8r,
Mark G.
 - Just my $0.02 worth.


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