This is the mail archive of the
mailing list for the binutils project.
m68k reloc types
- From: Roman Zippel <zippel at linux-m68k dot org>
- To: binutils at sources dot redhat dot com
- Date: Mon, 16 Aug 2004 12:56:02 +0200 (CEST)
- Subject: m68k reloc types
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:
3e: 4e56 0000 linkw %fp,#0
42: 2f0d movel %a5,%sp@-
44: 4bfb 0170 0000 lea %pc@(46 <f+0x8>),%a5
48: R_68K_GOT32 _GLOBAL_OFFSET_TABLE_+0x2
4c: 2075 0170 0000 moveal %a5@(00000000),%a0
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
Does anyone sees a problem with fixing this or does someone even know the
reason for these anomalies?