From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8650 invoked by alias); 12 May 2005 08:51:35 -0000 Mailing-List: contact ecos-maintainers-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: ecos-maintainers-owner@sources.redhat.com Received: (qmail 8612 invoked from network); 12 May 2005 08:51:24 -0000 Received: from unknown (HELO anchor-post-31.mail.demon.net) (194.217.242.89) by sourceware.org with SMTP; 12 May 2005 08:51:24 -0000 Received: from calivar.demon.co.uk ([83.104.54.243] helo=xl5.calivar.com) by anchor-post-31.mail.demon.net with esmtp (Exim 4.42) id 1DW9L5-000Fpy-3c; Thu, 12 May 2005 08:46:45 +0000 Received: from xl5.calivar.com (localhost [127.0.0.1]) by xl5.calivar.com (Postfix) with ESMTP id 736442C6FF; Thu, 12 May 2005 09:49:48 +0100 (BST) To: Andrew Lunn Cc: Anthony Tonizzo , eCos Maintainers Subject: Re: eCos Loader testing References: <20050511231903.8E03A3384B@ws7-3.us4.outblaze.com> <20050512065018.GZ31731@lunn.ch> From: Nick Garnett Original-Sender: nickg@ecoscentric.com Date: Thu, 12 May 2005 08:51:00 -0000 In-Reply-To: <20050512065018.GZ31731@lunn.ch> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-05/txt/msg00005.txt.bz2 Andrew Lunn 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