This is the mail archive of the crossgcc@cygnus.com mailing list for the crossgcc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
thankyou for your detailed information. I think in the moment we can live with absolute code/data addressing. My intent was to load pieces of user code dynamically as required, but this is not very important for us at the moment. > ---------- > Von: Olivier Carmona[SMTP:Olivier.Carmona@epfl.ch] > Gesendet: Montag, 22. Februar 1999 17:45 > An: crossgcc@cygnus.com > Betreff: Re: position independent code > > At 05:24 PM 2/5/99 -0800, Scott Howard wrote: > >Gnu CC does support position independant code with the -fpic and -fPIC > >options. It is only supported when the compiler & assembler use the ELF > >object file format, it does not work when using COFF (as you have > >already discovered, judging from the listing you enclosed). ELF for the > >m68k will be supported in a forthcoming release of EGCS. > > > >There is an additional complication: the gnu implementation is designed > >with shared libraries in mind; it creates an address translation table > >which must be 'fixed up' at run time to point to the absolute address of > >functions and variables. This is not really useful for an embedded > >(diskless, OS-less) system. This is a more complicated issue, and it > >would take some work to implement for a low-end system (essentially you > >would need a run-time loader of some sort). > > Even if this is not intentionally built for embedded system, GNU PIC > could be used for it. The loader could be left to the designer, for > instance on a m68k : > > start: > > .... > > /* Load the address relative to the PC */ > lea (_GLOBAL_OFFSET_TABLE_,pc),a5 > /* Load the address given by the linker */ > movea.l #_GLOBAL_OFFSET_TABLE_,a2 > /* Then find the offset */ > suba.l a5,a2 > beq L1 /* Null Offset ? */ > > /* Add the offset to all of the Global Offset Table */ > move.l #gotsize,d1 /* gostize : linker variable */ > L0: subq.l #4,d1 > blt.b L1 /* End of GOT ? */ > movea.l (a5,d1.l),a3 /* Read the GOT */ > adda.l a2,a3 /* Add the offset */ > move.l a3,(a5,d1.l) /* Write back in the GOT */ > bra L0 > > .... > > BUT there is a major concern, what if everything is in ROM ? Alas, THE > GOT NEED TO BE IN RAM or, at least, the _GLOBAL_OFFSET_TABLE_ pointer. > > A solution is to set the _GLOBAL_OFFSET_TABLE_ in a fixed position in > RAM via the linker (e.g.: at the top of the stack) and to memorize the > position of the offset table in another variable like > __GLOBAL_OFFSET_TABLE_. You then need to write another loader. > > Hope it helps, > > -- > Olivier Carmona > Research Assistant > IN-F-132, LAMI-EPFL, 1015 Lausanne, Switzerland > Tel: ++41(21).693.3908, Fax: ++41(21).693.5263 > http://diwww.epfl.ch/lami/team/carmona > _______________________________________________ > New CrossGCC FAQ: http://www.objsw.com/CrossGCC > _______________________________________________ > To remove yourself from the crossgcc list, send > mail to crossgcc-request@cygnus.com with the > text 'unsubscribe' (without the quotes) in the > body of the message. > _______________________________________________ New CrossGCC FAQ: http://www.objsw.com/CrossGCC _______________________________________________ To remove yourself from the crossgcc list, send mail to crossgcc-request@cygnus.com with the text 'unsubscribe' (without the quotes) in the body of the message.