This is the mail archive of the
mailing list for the binutils project.
Re: m68k reloc types
On Mon, 16 Aug 2004, Andreas Schwab wrote:
> Roman Zippel <email@example.com> writes:
> > One issue that really confused me at first is that some m68k pic reloc
> > types do something completely different than their i386 counterparts.
> The m68k has different capabilites than the i386.
The capabilities are actually quite similiar, i386 has no direct pc
relative addressing mode, but the trick used has the same effect from the
linker pointer of view. What different kind of capabilities do you have in
> > Here an example:
> > 0000003e <f>:
> > 3e: 4e56 0000 linkw %fp,#0
> > 42: 2f0d movel %a5,%sp@-
> > 44: 4bfb 0170 0000 lea %pc@(46 <f+0x8>),%a5
> > 4a: 0000
> > 48: R_68K_GOT32 _GLOBAL_OFFSET_TABLE_+0x2
> > 4c: 2075 0170 0000 moveal %a5@(00000000),%a0
> > 52: 0000
> > 50: R_68K_GOT32O x
> > 54: 2010 movel %a0@,%d0
> > 56: 2a5f moveal %sp@+,%a5
> > 58: 4e5e unlk %fp
> > 5a: 4e75 rts
> > i386 uses R_386_GOTPC and R_386_GOT32 here
> Which are basically the same as R_68K_GOT32 and R_68K_GOT32O, resp.
That R_68K_GOT32O is the same as R_386_GOT32 is not a little confusing?
What should we call R_386_GOTOFF if we wanted to implement it for the m68k
> > AFAICS it should be possible to fix this, existing binaries may not break
> > of course, but I think it should be possible to just rename this
> > within binutils.
> Why do you need to rename them? The names are defined by the ELF specs.
Which I don't have access to. A quote of relevant parts would be helpful
(especially the difference between R_68K_GOT32 and R_68K_GOT32O).
> > Does anyone sees a problem with fixing this or does someone even know the
> > reason for these anomalies?
> I see nothing broken here.
Could you please explain the rationale behind the _GLOBAL_OFFSET_TABLE_
checks in elf32-m68k.c? Unfortunately the cvs history doesn't go that far.