This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.


Before posting, please read the FAQ:
and search the list archive:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]