Re: [ECOS] RE: eCos Loader

Re: [ECOS] RE: eCos Loader

[Nick Garnett]

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

> The GOT and PLT are no problem, I already have those working,

I don't know which architecture you are working on, but I suspect you
have been lucky.

> I loaded the
> following module:
> 
> ----- Begin
> 
> #include <cyg/infra/diag.h>
> int a = 1;
> int b = 2;
> int c = 3;
> 
> void optel() {
> 	a += 1;
> 	b += a;
> 	c += b;
> }
> 
> void print() {
> 	diag_printf("Testfile: TEST_OK\n");
> }
> 
> ----- End
>

Yep, that's about as far as I got before realizing that there were
many more hurdles to overcome, particularly the toolchain issues I
mentioned before.


> Both optel and print are working. 
> But diag_printf is hardcoded in my code. 
> If you put "foo("Testfile: TEST_OK\n");" It does exactly the same now.
> 
> I was wondering, I do use location = *diag_printf in my code, that uses the
> symbol table of the main ecos lib. I thought maybe there is a way to access
> it, and get the right pointer locations from there.

I'm not really sure what you mean here. You should be resolving any
symbols in the loaded library against the symbol table in the
main executable. However, for this to happpen, the main executable
must have been linked against the load library to build its symbol
table. 




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

Re: [ECOS] RE: eCos Loader

[David Bonfrer]

Where did it go wrong in your dynamic loader?

I now have the relocation types R_386_GLOB_DAT and R_386_JMP_SLOT 
implemented.

I only used pointers, mallocs and file I/O(read and lseek) so it should 
be usable on all platforms.


Nick Garnett wrote:

>"David Bonfrer" <ecos@bonfrer.com> writes:
>
>  
>
>>The GOT and PLT are no problem, I already have those working,
>>    
>>
>
>I don't know which architecture you are working on, but I suspect you
>have been lucky.
>
>  
>
>>I loaded the
>>following module:
>>
>>----- Begin
>>
>>#include <cyg/infra/diag.h>
>>int a = 1;
>>int b = 2;
>>int c = 3;
>>
>>void optel() {
>>	a += 1;
>>	b += a;
>>	c += b;
>>}
>>
>>void print() {
>>	diag_printf("Testfile: TEST_OK\n");
>>}
>>
>>----- End
>>
>>    
>>
>
>Yep, that's about as far as I got before realizing that there were
>many more hurdles to overcome, particularly the toolchain issues I
>mentioned before.
>
>
>  
>
>>Both optel and print are working. 
>>But diag_printf is hardcoded in my code. 
>>If you put "foo("Testfile: TEST_OK\n");" It does exactly the same now.
>>
>>I was wondering, I do use location = *diag_printf in my code, that uses the
>>symbol table of the main ecos lib. I thought maybe there is a way to access
>>it, and get the right pointer locations from there.
>>    
>>
>
>I'm not really sure what you mean here. You should be resolving any
>symbols in the loaded library against the symbol table in the
>main executable. However, for this to happpen, the main executable
>must have been linked against the load library to build its symbol
>table. 
>
>
>
>
>  
>


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

Re: [ECOS] RE: eCos Loader

[Nick Garnett]

David Bonfrer <ecos@bonfrer.com> writes:

> Where did it go wrong in your dynamic loader?
> 
> I now have the relocation types R_386_GLOB_DAT and R_386_JMP_SLOT
> implemented.

It might work for i386, perhaps the elf tools have all the dynamic
support still in place. It didn't work for ARM, MIPS, PowerPC, SH4
etc. The toolchains don't all have the support. It has to work for all
of the architecture we support, not just one. This is why I believe
that object file loading is better than shared libraries, we won't
have to change the toolchains and rewrite the HALs to support this.

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

Re: [ECOS] RE: eCos Loader

[Nick Garnett]

"Paul D. DeRocco" <pderocco@ix.netcom.com> writes:

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


The things being loaded will be application specific: device drivers,
video/audio codecs, protocol handlers, libraries etc. You just need to
define the API that they will use and build a symbol table to
match. There's no need to add stuff that they won't be calling.

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

That may be true in Linux, where the init routine then registers the
module into the OS data structures with function tables and the
like. This will also be the way that things like device drivers and
codec will work too. However, a more general library may have a
variety of interface calls.


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

RE: [ECOS] RE: eCos Loader

[Paul D. DeRocco]

> 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

Re: [ECOS] RE: eCos Loader

[Nick Garnett]

"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

Re: [ECOS] RE: eCos Loader

[Andrew Lunn]

On Tue, Apr 26, 2005 at 11:01:07PM +0200, David Bonfrer wrote:
> Hi,
> 
> I'm using ELF executable and shared libs.
> 
> 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}

How about 

arm-elf-nm libtarget.ld | some_script.tcl > linker_table.c
gcc linker_table.c

        Andrew

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

[ECOS] RE: eCos Loader

[David Bonfrer]

Hi,

I'm using ELF executable and shared libs.

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?

Thanks.

P.S. Anthony, I am in a starting stage for this loader. 

I'm not ready to put it here because it's not finished and it's not very
readable source code yet. 

-----Original Message-----
From: Anthony Tonizzo [mailto:atonizzo@lycos.com] 
Sent: dinsdag 26 april 2005 22:45
To: ecos@bonfrer.com
Subject: eCos Loader

Hi:

I am working on an ecos loader too.

Following some conversations with Nick Garnett on the subject,
I wanted to create an interface that was more similar to Linux
insmod() that to a shared library. In this case, your module
gets compiled with a simple 

gcc -c hello.c

and then the loader must act as linker, and resolve relocation
and references.

I am still involved in the project, but I disagree with DeRocco:
Inventing your own linker format is a bad idea. Because you now
have to use special linkers to compile your module, or worse you
have to write one. eCos libraries are ELF modules, and so should
the libraries.

As far as resolving external symbols, the only valid approach is
a table of this type:

struct
{
    char*   symbol_name;
    void (*fp)(void);
} symbol;

symbol symbol_table[] = { { "diag_printf", diag_printf }, ...

which you can then fill up with the values of the functions you need.
Since this table would be in memory all the time, you can selectively
eliminate the functions you do not need via a CDL option or some
other form of compile time option (for example, you only have
pointers for kernel and semaphores, and nothing else). This should
help in getting a handle on an otherwise huge table.

In my application, I do not need to call external functions, but I
definitely need relocation and symbol resolution. How far away is your
code from prime time? Can I take a look at it to see if I can use it
(and act as a beta tester in the process)?

I am sorry if I replied to you personally, but the ecoscentric reflector
does not seem to like my posting when I am behind my company's
firewall.

Regards
Tony
-- 
_______________________________________________
NEW! Lycos Dating Search. The only place to search multiple dating sites at
once.
http://datingsearch.lycos.com



-- 
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.10.3 - Release Date: 25-4-2005



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