[Bug gas/28811] New: Binutils emits non-PE relocations in PE object

[tnfchris at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28811

            Bug ID: 28811
           Summary: Binutils emits non-PE relocations in PE object
           Product: binutils
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gas
          Assignee: unassigned at sourceware dot org
          Reporter: tnfchris at sourceware dot org
  Target Milestone: ---
            Target: *-w64-mingw32

Consider the following simple assembly

$ printf "jmp *foo\n" | as - -o a.out && objdump -dr a.out

a.out:     file format pe-x86-64


Disassembly of section .text:

0000000000000000 <.text>:
   0:   ff 24 25 00 00 00 00    jmp    *0x0
                        3: R_X86_64_32S foo
   7:   90                      nop
   8:   90                      nop

on an assembler configured for x86_64-w64-mingw32.

Gas has assembled an object file using an ELF/Unix relocation R_X86_64_32S
instead of a PE one.  I had expected IMAGE_REL_AMD64_ADDR32 here.

This means gas is producing an object file that only ld can link and no other
linker (like lld) and that causes problems for loading the object file into
languages with their own runtime linker.

This bug seems to be as old as the target exists (16 years for x86_64 PE and 23
for i386).

What looks like happened is that the COFF format, while today mainly used by
Microsoft is also used by some Unix targets from vendors like Texas
Instruments.

The Microsoft PE and the non-PE coff standards have different relocations, But
some of them overlap. e.g. R_X86_64_32S and IMAGE_REL_AMD64_ADDR32 are exactly
the same, but their reloc numbers are different.

Because of this, due to simple ordering, gas ends up picking the Unix one
first.

This bug happens because the howto tables
https://github.com/bminor/binutils-gdb/blob/master/bfd/coff-x86_64.c#L236 don't
properly ifdef for PE and not-PE when the reloc numbers don't overlap.

However I'm not sure how to fix this.. The relocations exist in 16-23 years of
libraries that we still need to continue being able to link, but gas shouldn't
produce relocations that the target can't handle.  But I don't think the howto
table gives that level of control.

We can't simply change the order as that would break the non-PE targets.

-- 
You are receiving this mail because:
You are on the CC list for the bug.