leighf at iprimus.com.au
Wed Apr 24 07:33:11 EDT 2002
On Tue, 23 Apr 2002 09:57, you wrote:
> Jivin mathias.fritzson at mecel.se lays it down ...
> > >Jivin mathias.fritzson at mecel.se lays it down ...
> > >
> > >> Hello again,
> > >>
> > >> Thanks for the latest tip David, the -m68000 flag worked..
> > >
> > >Ok, but if you are using a 683XX, is there an option specific for that
> > > ? Check your kernel compile and see what options (-m options) are used.
> > The kernel uses the -mcpu32 flag, and that seems to work alright but when
> > I tried to use it for the apps and init I got the same error.
> Doesn't look good, I've never targeted a cpu32 board, anyone out there
> used the compiler on CPU32 stuff successfully ?
I am using 68360 and had this problem some time ago. If I remember correctly
I eventually isolated it to the following GCC behaviour:
1)First part of GCC produces some type of intermediate code which includes a
pseudo-instruction JBRA for jumps. I expect the intention is to convert this
to a BRA instruction if possible (so no relocation needed) or a JMP if not
2) Code generator part of GCC (when -mcpu32 specified) knows that CPU32 has
32-bit branch and so substitites BRA for JBRA. (Note: Not BRA.S or BRA.L)
3) Assembler assumes BRA is an alias for BRA.S for all 68K CPU types, and so
produces 16-bit offset instruction.
4) If the target of the BRA is more than +/- 32768 then the branch is out of
range and produces the "relocation truncated to fit: R_68K_PLT16" errors.
It is possible to patch GCC to always produce BRA.L but I ended up just using
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
More information about the uClinux-dev