m68k reloc types

[Roman Zippel]

Hi,

On Mon, 16 Aug 2004, Andreas Schwab wrote:

> > 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 
> > mind?
> 
> That the m68k can address directly relative to the pc obviates the need
> for the klugey way the GOT register is set up on i386.

But why does i386 doesn't need the kludgy hack in R_386_GOTPC to setup the 
pic register?

> > That R_68K_GOT32O is the same as R_386_GOT32 is not a little confusing? 
> 
> No.  Why?

I could live it, if it would be documented somewhere publicly.

> > What should we call R_386_GOTOFF if we wanted to implement it for the m68k 
> > linker?
> 
> There is no corresponding relocation defined for m68k, because it is not
> needed.

Ok, m68k could simply use pc relative addressing to access local symbols, 
but which reloc type should be used to void creating the plt/got entry?
E.g. R_386_GOTOFF never creates a got entry.

> > (especially the difference between R_68K_GOT32 and R_68K_GOT32O).
> 
> The first is a pc-relative offset to the GOT, the latter is the offset
> from the start of the GOT.

Should both create a got entry? In what other situation can R_68K_GOT32 be 
used for?
BTW what's the difference between R_68K_PLT32O and R_68K_PLT32? A small 
code example would be useful here. The former isn't generated by binutils.

> > 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.
> 
> This is a special symbol that always points to the start of the GOT.

This doesn't really explain, why a reloc type should behave differently 
dependening on the symbol.

bye, Roman