From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3122 invoked by alias); 27 Apr 2005 17:34:35 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 1564 invoked from network); 27 Apr 2005 17:33:25 -0000 Received: from unknown (HELO smtpauth06.mail.atl.earthlink.net) (209.86.89.66) by sourceware.org with SMTP; 27 Apr 2005 17:33:25 -0000 Received: from [70.33.96.36] (helo=PAULD) by smtpauth06.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1DQqPa-0008PS-R4 for ecos-discuss@ecos.sourceware.org; Wed, 27 Apr 2005 13:33:23 -0400 From: "Paul D. DeRocco" To: "eCos Discuss" Date: Wed, 27 Apr 2005 18:06:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In-Reply-To: X-ELNK-Trace: bd7d5d4e6f8f652c74cfc7ce3b1ad11381c87f5e51960688494247a0122e5fa4632ba03101680f98350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Subject: RE: [ECOS] RE: eCos Loader X-SW-Source: 2005-04/txt/msg00284.txt.bz2 > 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