Converting COFF objects to ELF with objcopy seems to generate wrong ELF relocations, introducing a 4-byte offset systematically $ ld -v GNU ld version 2.15.94 20041229 (reworked ld/configure.tgt to add extra_emuls i[3-7]86-*-cygwin*) targ_emul=i386pe ; targ_extra_ofiles="deffilep.o pe-dll.o" targ_extra_emuls="elf_i386 i386coff i386msdos" ) See example below ________________________________ # get COFF objects gcc -c x.s y.s # get ELF copies objcopy x.o x.obj -O elf32-i386 objcopy y.o y.obj -O elf32-i386 # link / locate program $ ./ld x.obj y.obj -m elf_i386 --oformat elf32-i386 -o z.x -Map z.map ./ld: warning: cannot find entry symbol _start; defaulting to 08048080 ________________________________ X: ________________________________ .xref y .globl x .text x: call y ________________________________ Y: ________________________________ .global y .text y: ret ________________________________ Relocation is off by 4 bytes! ________________________________ $ ./objdump -rS z.x z.x: file format elf32-i386 Disassembly of section .text: 08048080 <x>: 8048080: e8 0f 00 00 00 call 8048094 <y+0x4> ; HUUUUUH ???? 8048085: 90 nop 8048086: 90 nop 8048087: 90 nop 8048088: 90 nop 8048089: 90 nop 804808a: 90 nop 804808b: 90 nop 804808c: 90 nop 804808d: 90 nop 804808e: 90 nop 804808f: 90 nop 08048090 <y>: 8048090: c3 ret ________________________________ $ objdump -rS x.obj x.obj: file format elf32-i386 Disassembly of section .text: 00000000 <x>: 0: e8 00 00 00 00 call 5 <x+0x5> 1: R_386_PC32 y 5: 90 nop ________________________________ $ objdump -rS x.o x.o: file format pe-i386 Disassembly of section .text: 00000000 <x>: 0: e8 00 00 00 00 call 5 <x+0x5> 1: DISP32 y 5: 90 nop BUT When linking the original objects NOT ELF-ized $ objdump -rS x.o x.o: file format pe-i386 Disassembly of section .text: 00000000 <x>: 0: e8 00 00 00 00 call 5 <x+0x5> 1: DISP32 y 5: 90 nop $ ./ld x.o y.o -m elf_i386 --oformat elf32-i386 -o z.x -Map z.map ./ld: warning: cannot find entry symbol _start; defaulting to 08048080 $ objdump -rS z.x z.x: file format elf32-i386 Disassembly of section .text: 08048080 <x>: 8048080: e8 0b 00 00 00 call 8048090 <y> ; OK THIS TIME 8048085: 90 nop 8048086: 90 nop 8048087: 90 nop 8048088: 90 nop 8048089: 90 nop 804808a: 90 nop 804808b: 90 nop 804808c: 90 nop 804808d: 90 nop 804808e: 90 nop 804808f: 90 nop 08048090 <y>: 8048090: c3 ret 8048091: 90 nop
Created attachment 496 [details] relocation source
Created attachment 497 [details] Symbol definition source
It is expected. See http://sourceware.org/ml/binutils/2003-10/msg00376.html for possible solution.
I may be tempted to fix the bug by patch up the .text DWORD content on the fly at the location of the jump/call (turning it from 0 to -4) when the ELF .text section is output ... Another solution could be to had a another relocation (adding the -4) on the same location pointed to by the initial JMP/CALL relocation... since - for whatever reason - the addend flavor of the ELF relocation is NOT used for the x86 (but IS for the x86_64 - go figure :-( ! )... This -4 issue seems to be a headache for a number of targets Any comments? Suggestions? Before I attempt to embark on a fix?
Closing since I doubt any active developer will work on this.