[ECOS] Making fragmented applications

[Guilly A]

Hi Andrew,
Thank you for your prompt response...
So, there is no way for the GNU linker to behave like armlink ? I used to 
think it was just a linker option issue.
I'm in trouble, because the application will be made by a third party. I 
need to provide them with eCos API, and my custom API, and my objectives was 
to provide the feature to update the application only, or the bios 
(including ecos) only, while maintaining a backward compatibility. (any 
version of the application should be runnable, without compilation, on top 
of any version of the bios). Maybe the objloader could do the job. This is 
my last hope. Is the objloader reliable ? Does somebody regularly use it ? I 
need feedbacks.
Regards,
Guilly




>From: Andrew Lunn <andrew@lunn.ch>
>To: Guilly A <guilly_work@hotmail.com>
>CC: ecos-discuss@sources.redhat.com
>Subject: Re: [ECOS] Making fragmented applications
>Date: Tue, 27 Sep 2005 19:03:18 +0200
>
>On Tue, Sep 27, 2005 at 04:07:08PM +0000, Guilly A wrote:
> > 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...
>
>eCos is not designed to allow this. The design is that you link your
>application to eCos. There is no concept of jump tables.
>
>Unless you have a really good reason which needs the jump tables, i
>suggest you stay with the eCos way of doing things. If you absolutely
>must have jump tables take a look at the objloader package.
>
>         Andrew
>
>--
>Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>

_________________________________________________________________
250 Mo de stockage avec MSN Hotmail ! 
http://www.imagine-msn.com/hotmail/default.aspx?locale=fr-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