RE: [ECOS] Dynamic loader

["Paul D. DeRocco" <pderocco at ix dot netcom dot com>]

> From: ecos
>
> I'm working on a new dynamic loader, because the existing is discontinued.
>
> My loader works using only pointers and software relocation.
>
> Simple functions like adding are working now, but I have trouble
> getting the
> external symbols like "diag_printf" to work. The problem is that I do not
> know how to find the location in memory of diag_printf.
> (diag_printf can be
> any other function is eCos too)
>
> Anyone has some ideas?

I've done this for other systems, but not for eCos. It seems to me you have
to do one of two things.

1) You can add an interface layer to the OS, invoked via a software
interrupt, that decodes a numeric code in a register to vector to each OS
routine you need to be able to call from the application. Then, you need a
library of stubs to link with the app that loads the numeric code and does
the software interrupt. On some processors, you may be able to implement the
transfer of control as a jump, so that the OS routine reads the parameters
from the stack where the original caller put them.

2) You can add a run-time symbol table to the OS, and make the loader read
the object file for ASCII function names, and resolve them to memory
addresses by looking them up in the symbol table. The initial contents of
the symbol table would have to be built at link time, typically by including
a module that explicitly lists pointers to all the routines you want.

Either way, if I were doing it, I'd invent my own loadable object format.
ELF files are needlessly huge, being filled with information of no interest
to a loader, and padded with lots of zeroes so that things start on block
boundaries, for the benefit of virtual memory systems.

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com


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