This is the mail archive of the ecos-discuss@sources.redhat.com 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: RE: eCos Loader


> From: Nick Garnett
>
> 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.

This is an intrinsic problem with a loader: you have to create an OS that
has an API suitable for loaded applications that haven't yet been written.
In general, the most useful OS image would include symbol table entries for
all documented functions in the included eCos subsystems. Otherwise you have
to arbitrarily constrain the writers of loaded applications, and document
those constraints. Yes, this means that the linked portion of the system may
be larger than necessary for a particular app, but that's the only way to
decouple the design of the OS from the design of the app.

> 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.

Typically, the only reference _into_ a loaded module is the start address.
That is, the code is loaded, and a thread is started (or a function is
called) at the module's start address.

--

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


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