From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: "Steve Simon" To: 9fans@cse.psu.edu Subject: Re: [9fans] arm compiler info In-Reply-To: <59a028e5e416c7482661502ee195ddf5@terzarima.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-trbpisgafgcfzwnsmgfmvdomqw" Date: Thu, 6 May 2004 13:24:59 +0100 Topicbox-Message-UUID: 731f2856-eacd-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-trbpisgafgcfzwnsmgfmvdomqw Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit some more detail: Embedded APM system. We have a kernel with a flash file system and serial console, user programs (ls, cp, mv, The-big-app) are run from flash. We don't program the MMU except to configure memory to be flat. All user programs are relocated on load, under GCC the elf file contains special global offset table sections which must be fixed-up, GreenHills actually compiles code into crt0 to do this in every executable. Data is referenced via a single register that contains the offset of the start of data. User progs get access to kernel resources vla a jump table they are passed on the stack when they start. What I am really after is a nicer enviroment to work under than XP and Greenhills (GCC helps but still ties me to MSDOS). However my major concern is how much time I might spend getting this working, if its a few days then no problem... I guess I need to start looking at 5l, or understanding the MMU properly so all programs can run at the same virtual address. -Steve --upas-trbpisgafgcfzwnsmgfmvdomqw Content-Type: message/rfc822 Content-Disposition: inline Return-Path: <9fans-admin@cse.psu.edu> Received: from mail.cse.psu.edu ([130.203.4.6]) by mta03-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040506103032.PALH16511.mta03-svc.ntlworld.com@mail.cse.psu.edu> for ; Thu, 6 May 2004 11:30:32 +0100 Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id C6F1D1A149; Thu, 6 May 2004 06:31:12 -0400 (EDT) Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id B2ED019CB3; Thu, 6 May 2004 06:31:08 -0400 (EDT) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id 886E719FD2; Thu, 6 May 2004 06:30:30 -0400 (EDT) Received: from lavoro.terzarima.net (spc1-york1-5-0-cust44.leed.broadband.ntl.com [80.0.45.44]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 309C219CB3 for <9fans@cse.psu.edu>; Thu, 6 May 2004 06:30:29 -0400 (EDT) Message-ID: <59a028e5e416c7482661502ee195ddf5@terzarima.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] arm compiler info From: Charles Forsyth In-Reply-To: <4098F165.5050504@chunder.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Thu, 6 May 2004 11:29:37 +0100 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psuvax1.cse.psu.edu X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Level: >>it isn't hard to get ELF output, both vl and el have >>a flag for it so changing 5l is a snarf/paste or too. or it would be if the elf weren't demented. one of those scary ones. 5c/5l code will run on arm 9 (there are possibly some extensions in arm 9, and if so, they won't use them, though even that is usually easily dealt with). possibly the bigger complication is the extent to which the output is PIC enough (or can easily be made so) for this application. i remember looking at an ARM application note about that but just remember my resulting dismay, not what caused it. it might not have been the PIC conventions as such but its interaction with something else. as to that ELF, is the loading program expecting a completely linked program or something that is then linked dynamically into one already running? if the former, the existing ELF-header producing code might well suffice (with the usual changes to account for dementia, hence some of the "??" in comments in existing code); if the latter, you'd need to convert the symbols as well, and perhaps capture and convert data for relocation (which isn't normally produced except for dynamically-loaded modules). i'm assuming you're safe from the elf's mate, a sly dwarf. --upas-trbpisgafgcfzwnsmgfmvdomqw--