Re: [9fans] arm compiler info

["Steve Simon" <steve.simon@snellwilcox.com>]

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]

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

[-- Attachment #2: Type: message/rfc822, Size: 3157 bytes --]

From: Charles Forsyth <forsyth@terzarima.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] arm compiler info
Date: Thu, 6 May 2004 11:29:37 +0100
Message-ID: <59a028e5e416c7482661502ee195ddf5@terzarima.net>

>>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.