* Re: eCos Loader testing
2005-05-12 6:50 ` eCos Loader testing Andrew Lunn
@ 2005-05-12 8:51 ` Nick Garnett
0 siblings, 0 replies; 2+ messages in thread
From: Nick Garnett @ 2005-05-12 8:51 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Anthony Tonizzo, eCos Maintainers
Andrew Lunn <andrew@lunn.ch> writes:
> On Wed, May 11, 2005 at 06:19:03PM -0500, Anthony Tonizzo wrote:
> > Andrew:
> >
> > Are you interested in testing an eCos loader, before I
> > submit it? I would like to do some extensive test, since right
> > now the whole thing is pretty crude. For obvious reasons,
> > I would like to draft some "expert witnesses" for the job.
> >
> > Currently it is working in my PowerPC system. I can compile
> > libraries into .o files, then load the files from a file
> > system with dlopen() (I use Savin's FAT on a CardFlash, but JFFS2
> > will work as well) and access symbols through dlsym() calls.
> > The libraries can also make calls to the operating system using
> > selected functions of your choice. I have compiled a simple
> > library that holds a disassembler function for the PowerPC and the
> > threads of the twothread example, for a total of about 40K of code.
> > The library works flawlessy now.
> >
> > There are two architecture dependent function (which ideally
> > would go in packages/hal): One is to test that a specific
> > library was written for the proper architecture (endiannes
> > and all...) and the second does the actual relocation.
> >
> > The rest is architecture independent.
> >
> > I need direction and plenty of suggestions for improvement.
> > Any interest?
>
> Hi Anthony
>
> Unfortunetely i go on Holiday for three weeks starting tomorrow. So i
> think it would be better for a different maintainer to take a look at
> your code. The obvious candidate is Nick Garrett.
>
> Nick, can you do this?
I already have a copy, and have been giving Tony a little informal
guidance along the way. This has been burning a hole in my TODO list
for a few days now, so here are my initial thoughts:
I don't have a PowerPC based system available at present to try it
out, so I've only taken a quick read through of the sources. In
general it looks good and should easily form the basis for a new
loader package. There are, however, a few things that would need to be
done before it can be added to the repository:
1. Symbols should begin with cyg_ or maybe cyg_ldr_ to avoid name
space pollution. This is particularly important for external
symbols to avoid interfering with application code.
2. The external facilities that the loader uses should be abstracted a
little. It will not always be the case that the object is loaded
from a filesystem, it might be coming straight from ROM/FLASH or
via the network using TFTP, FTP or HTTP. So we need either an
abstract object, or maybe an extension to the ELF_OBJECT structure,
to allow us to support a variety of different methods for fetching
the file. The same goes for allocating memory, not all systems will
have malloc() available, so there should be an abstract interface
here to allow the user to do something else if required.
3. The loader should make sure that it keeps track of all the memory
it allocates for each object and frees it all in [cyg_]dlclose(). It
doesn't look like the code currently does that.
4. I'm not entirely sure that the machine dependent code needs to go
into the HAL. The choice is between keeping all the loader specific
stuff together against keeping all machine dependent stuff
together. On balance I think I prefer to keep the loader as a
self-contained package, the relocation stuff is much more a
loader/ELF dependent thing than it is a machine thing. We can
easily choose which source file to compile with a bit of CDL.
5. To complete the package it needs a CDL file, a ChangeLog and
documentation. You can get started on the CDL file by stealing the
current loader's file and removing all the stuff that was there for
testing.
That's all I can think of for now.
--
Nick Garnett eCos Kernel Architect
http://www.ecoscentric.com The eCos and RedBoot experts
^ permalink raw reply [flat|nested] 2+ messages in thread