GNU C and ROM based code
Thu Jun 7 18:52:00 GMT 2001

Keith, Rafael:

> > > What I want is to produce a program with GCC and put it into the
> > > user Flash area using UPDUSER command. I am using a 5206eLite
> > > board.
> > This has nothing to do with GCC, you can't blame the compiler for
> > generating code that won't run in ROM if you can't get it into ROM.
> Well, I'm in a bellicose mood; I'm going to argue with myself.
> It's true that gcc/ld can be used to put code into ROM, but the whole
> process would be easier if gcc could generate Position Independant
> Code for the Motorola 68000/Coldfire family (the -fPIC option).

Having truly PIC code solves a lot of problems, but I'm at a loss to
see how it would help any process that involves getting code into ROM.
If you're running code from ROM, why do you need to relocate it?

(I'm coming into this discussion from crossgcc, so I don't know what
the "this situation" refers to).

> Is anybody working on this?  Does anybody have any advice for one
> who might be tempted to attempt it?  Is there any essential
> difference between PIC for dynamic linking and PIC just to make the
> code movable, e.g. so it can run either in ROM or RAM?

After a fashion, gcc can do PIC for most processors.  It kicks out a
"GOT", Global Offset Table, and seems to generate code that is
relative to that.  The catch is that you have to do some "fixups" to
the code/GOT at runtime (I used to know exactly how the process works,
but I haven't looked at it in quite some time) to bind everything

I suspect that the GOT approach was a poor-man's dynamic linker in an
OS-based environment, and not intended for embedded execute-from-ROM
setting.  But still, depending on the "this situation" you're
referring to, it may be what you are looking for.

Although, I *am* curious as to why gcc doesn't kick out PIC code using
PIC-type relative instructions...

Bill Gatliff

Want more information?  See the CrossGCC FAQ,
Want to unsubscribe? Send a note to

More information about the crossgcc mailing list