GNU C and ROM based code

Keith Wright
Thu Jun 7 23:23:00 GMT 2001

> From:
> Cc:,
> Keith, Rafael:
> > 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).

> > PIC just to make the code movable, e.g. so it can run either in
> > ROM or RAM?

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

Well it would be nice to be able to make a version of my bootloader
that would run in ROM but could be copied to RAM at run time.
Currently I have to make multiple version depending upon where
they are to reside.

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

Nor I---that seems to be the first occurrence of that phrase.
In general there is no very specific situation, just a desire
for PIC.

> After a fashion, gcc can do PIC for most processors.

Unfortunately, the Motorola 68000 family is not among them.

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

Mostly it does, if you mean using PC-relative branches.  That's why
I asked, it seems so close.  The 68000 is to a great extent naturally
position independant.  If you say -fPIC you get syntax errors
in the generated assembler, but it is clear that somebody was
trying to make it work.

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

More information about the crossgcc mailing list