This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: VxWorks type embedded "shell" for eCos
But you can do nearly all of this from GDB already. And those things
that you cannot do are of very little utility anyway.
Is there a way to create a new thread running a specified function from
GDB ? I find this very useful and don't think GDB supports it. It's very
convenient for running quick tests - you can run a test function with
different arguments without going through a rebuild and redownload cycle.
In general eCos is an embedded operating system, not an interactive
one. When you finally deploy whatever system you are building, it
won't have a shell. I, for one, prefer to debug the program that I am
actually going to execute. Having called arbitrary functions and
spawned various threads, the resulting system would be totally unlike
anything that gets deployed. I really don't see how you gain anything
useful from that.
It's just my personal preference. I found the VxWorks shell made me more
productive and enabled me to quickly run a bunch of tests on a target.
Obviously these are not real-world tests and you wouldn't put something
out the door having just run it from a shell internally. But it has a
time and a place, and during development I found it made my life easier.
The shell plus symbol tables is likely to occupy 100k+ of target-side
memory. GDB uses minimal user side memory. We would also need some
sort of host side processing to extract the symbol table from a built
executable and then turn it into something that can be downloaded with
the executable, presumably by relinking it. VxWorks has Tornado, a
vast host-side infrastructure, to make all this invisible, we would
have to create that from scratch.
I'm not sure what would be needed on the host-side. When I did a similar
shell for Nucleus, I just downloaded a COFF file to the target
containing the symbol information, and extracted the symbols at runtime
from the image in RAM. It takes a fair amount of memory so it's not
suitable for everyone.
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
complicated enough managing the interaction between RedBoot, eCos and
GDB, adding a shell into the mix would make things even harder to
maintain.
I agree that it shouldn't impose dependencies etc in the rest of the
system but I don't think it needs to. Depending on the feature-set I
think it could be well self-contained.
Cheers,
Kelvin.
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss