m68k reloc types

[Roman Zippel]

Hi,

With the 2.15 release the situation regarding the m68k linker has gotten 
worse and e.g. random gcc tests start to fail. I decided to do something 
about it and basically merged the i386 linker into the m68k one. I'm 
currently running some tests (recompiling glibc and gcc) with it.
One issue that really confused me at first is that some m68k pic reloc 
types do something completely different than their i386 counterparts.
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 and to make things worse the 
m68k linker has hard coded checks for _GLOBAL_OFFSET_TABLE_ to do the 
right thing (instead of something completely different, where I'm not sure 
what it is).
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. gcc generates correct "@GOTPC" and "@GOT" suffixes, gas 
needs to create the same reloc type numbers of course, so the only visible 
difference would be the readelf/objdump output. The only thing I'm not 
sure about is /usr/include/elf.h, which is provided by glibc, although 
glibc itself doesn't use these reloc types, so I think binutils is the 
only program which has intimate knowledge about these reloc types and I 
think it's better for maintainability to keep these close to the i386 
counterparts.
Does anyone sees a problem with fixing this or does someone even know the 
reason for these anomalies?

bye, Roman