public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] Dynamic loader
@ 2005-04-26 16:54 ecos
  2005-04-26 21:01 ` Paul D. DeRocco
  0 siblings, 1 reply; 2+ messages in thread
From: ecos @ 2005-04-26 16:54 UTC (permalink / raw)
  To: ecos-discuss

Hi,

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?

Thanks.


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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* RE: [ECOS] Dynamic loader
  2005-04-26 16:54 [ECOS] Dynamic loader ecos
@ 2005-04-26 21:01 ` Paul D. DeRocco
  0 siblings, 0 replies; 2+ messages in thread
From: Paul D. DeRocco @ 2005-04-26 21:01 UTC (permalink / raw)
  To: eCos Discuss

> 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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2005-04-26 17:10 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-04-26 16:54 [ECOS] Dynamic loader ecos
2005-04-26 21:01 ` Paul D. DeRocco

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).