Re: [ECOS] RE: eCos Loader

[Nick Garnett <nickg at ecoscentric dot com>]

"David Bonfrer" <ecos@bonfrer.com> writes:

> Hi,
> 
> I'm using ELF executable and shared libs.

If you mean proper shared libraries, like on Linux, then I don't think
this is a good idea. The support/loader package is the wreckage from
my attempts to get this working. The basic problem was that the
xxx-elf- toolchains we use for eCos do not all contain the dynamic
library support. If we try to use the linux toolchains, which do have
this support, we run into problems with calling conventions and code
generation issues. We would also have to introduce full support for
the GOT and PLT. Essentially, large chunks of all the HALs would have
to be rewritten -- something we really don't want to do.

Instead, as Tony indicates, I believe the best approach is to
implement a .o file loader, similar to the mechanism used in the Linux
kernel to load kernel modules. 


> 
> I know that *diag_printf points to the function diag_printf.
> 
> The question is: How do I get this in general?
> 
> I don't want to fill my own tables with:
> 
> If ("printf"){location = *printf}
> If ("scanf") {location = *scanf}
> Etc. Can I get a symbol table from eCos for these functionsymbols?

Andrew has indicated a simple mechanism for this. However, doing that
would force the whole of the eCos library to be linked into the main
application. This would include hundreds of routines that you may not
need which would bloat the executable considerably.

Instead the approach described by Tony would be more appropriate: the
application developer generates a table of just the symbols that he
expects his loaded modules to access. This way the main application
will be kept small.


Also, there will have to be an asymmetry between how functions in the
loaded code are accessed from the main application and how main
application functions are accessed from the loaded code.

When the object file is loaded, it is relocated into its current
memory location and its symbol table scanned for external
references. These are looked up in the table and the code fixed up
appropriately.

We cannot do this the other way round, however, since we cannot build
the main application with dangling references. So any references from
the main application to the loaded code must be done dynamically. Each
symbol must be looked up and assigned to a pointer variable.



-- 
Nick Garnett                                     eCos Kernel Architect
http://www.ecoscentric.com                The eCos and RedBoot experts


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