From mboxrd@z Thu Jan 1 00:00:00 1970 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 Date: Thu, 6 May 2004 11:29:37 +0100 Topicbox-Message-UUID: 731ae958-eacd-11e9-9e20-41e7f4b1d025 >>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.