This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Making fragmented applications
- From: "Guilly A" <guilly_work at hotmail dot com>
- To: ecos-discuss at sources dot redhat dot com
- Date: Tue, 27 Sep 2005 16:07:08 +0000
- Subject: [ECOS] Making fragmented applications
- Bcc:
Hi,
I used to work on a project, under pSos OS, ARM7 core, and isiarm (armcc &
armlink) compilation chain.
Now we moved on eCos, ARM9 core, and GNU compilation chain (arm-elf-gcc for
compiling and linking).
My project was composed by a "bios", (embedding eCos OS (libsys.32l) and
armlib_rc.32l (ANSI C lib)), and a customer "application".
This customer application was compiled independantly of the bios, but linked
with the libsys.32l and armlib_rc.32l library, with the -ro-base option to
tell the linker where the application will be ran in memory. The access to
the bios was made by a custom jumptable.
The given application was the pretty small. It seems that the used ANSI C
function where duplicated in the application binary, but the OS functions
where accessed by a sort of jumptable, and everything was going fine.
Now with eCos and GNU compilation chain, I would like to have the same
results, but is seems that my "application" has all the eCos kernel whithin,
exceptions handler, and so on. I don't know how to tell the linker to just
build a binary with static jumps to eCos API, based on a given execution
address, and not to embbed all the kernel...
Thank you for your advices.
_________________________________________________________________
Trouvez vos fichiers en un clin d??il : Windows Desktop Search
http://desktop.msn.fr/
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss