Re: Object File Loader

[Nick Garnett <nickg at ecoscentric dot com>]

Anthony Tonizzo <atonizzo@gmail.com> writes:

> Andrew:
> 
> > Would this be better if it was an interface. I expect the architecture
> > files will end up in the individial HALs, and it then implements the
> > interface. You can then also remove the define_proc since the HAL
> > would provide a <cyg/hal/relocate.h>
> 
> I too expected the architecture files to end up in the the HAL, but further
> e-conversations with Nick and Bart convinced me that a self-enclosed
> package is perhaps a cleaner solution. I am saying "perhaps" because
> there are pros/cons for both solution. I am not sure you would gain much
> by moving it into the HAL.

I think the files are better living here rather than in the HALs since
they are all about interpreting ELF files rather than directly
relevant to the architecture itself. Keeping them here means that the
loader is self-contained and avoids having to make changes to the
HALs. It would allow code sharing, and makes generating new relocators
easier since there are examples right there.

> 
> > Should these have cyg_ldr_ prefixes to avoid name space problems?
> 
> Yes, they do have cyg_ldr_. I added cyg_ldr after writing the documentation,
> and forgot to update it.

There are two sets of labels here. The loader API routines should have
cyg_ldr prefixes, and they all currently do. However, the
library_open() and library_close() functions are a different
case. These are visible as labels only in the loaded object, and are
really part of the application. So I'm not sure that they should have
cyg_ldr prefixes.

> 
> > How about putting a variation of this into the main src directory. 
> > Have CDL control each group of symbols:
> 
> This was the original idea. In a posting on ecos-discuss of a couple of
> months ago, we talked about a way to use CDL to selectively include
> these functions.
> 
> We can put them on CDL as long as we _also_ give the user an
> opportunity to place his/her own. During development and use of this
> package I realized that I call a surprisingly small number of eCos
> functions (about 20 to 30) and in this case I find it better to just 
> add them manually just like I show in the test case. Of course my 
> usage patterns are my own, and for other people it would just be 
> easier to add the entire "kapi.h" via a CDL setting.
> 
> Let's reach a consensus and I will go back to the drawing board...

I guess it depends on whether one considers this set of symbols to be
a property of the eCos configuration or a property of the application
being built. The former means that it is difficult for the application
to trim the list to the minimum set, whereas the latter places an
additional burden on the application writer. I'm tending towards the
idea that it should be under application control since the other
approach would need eCos to be reconfigured and rebuilt if the chosen
set needed to be changed.

Perhaps a middle way is to define a set of super-macros that include
blocks of functionality and are defined only when the equivalent
packages are present. So we can have the following in the application:

CYG_LDR_TABLE_INFRA_DIAG()
CYG_LDR_TABLE_KAPI_MUTEX()
CYG_LDR_TABLE_KAPI_THREAD()
etc.

rather than individual references to each function. The way is still
open for the application to move to individual references if it needs
that level of control, and doesn't need a reconfiguration to do it.

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