[Bug ld/6945] ld -r severely broken on 64-bit mingw / pe-x86-64

[mikpe at it dot uu dot se]

------- Additional Comments From mikpe at it dot uu dot se  2008-10-09 15:02 
-------
(In reply to comment #1)
> Hi Mikael,
> 
>   So - what is the difference between bug.o and bug2.o ?

objdump -h bug*.o

bug.o:     file format pe-x86-64

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .text         000000a0  0000000000000000  0000000000000000  000000b4  2**4
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00000000  0000000000000000  0000000000000000  00000000  2**4
                  ALLOC, LOAD, DATA
  2 .bss          00000000  0000000000000000  0000000000000000  00000000  2**4
                  ALLOC
  3 .rdata        00000050  0000000000000000  0000000000000000  00000154  2**4
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA

bug2.o:     file format pe-x86-64

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .text         000000a0  0000000000000000  0000000000000000  000000b4  2**4
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00000000  00000000000000a0  00000000000000a0  00000000  2**4
                  ALLOC, LOAD, DATA
  2 .rdata        00000050  00000000000000a0  00000000000000a0  00000154  2**4
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
  3 .bss          00000000  00000000000000f0  00000000000000f0  00000000  2**4
                  ALLOC

The files are the same size, but ld -r changes the order of the sections, and
appears to add the size of .text (0x0a) to the VMA/LMA of .data and .rdata.
And the offsets in the jump table are also off by 0x0a, but since the code and
the jump table haven't moved the jump table targets are now wrong.

>   Is it possible to reproduce the bug without using inline assembly ?

Certainly, it's just a gcc switch() jump table. I used inline asm in order to
write a test program that could inspect and verify the jump table instead of
crashing. The program below (cbug.c) shows the bug in plain C:

x86_64-pc-mingw32-gcc -O -c cbug.c
x86_64-pc-mingw32-ld -r -o cbug2.o cbug.o
x86_64-pc-mingw32-gcc -o cbug cbug.o
x86_64-pc-mingw32-gcc -o cbug2 cbug2.o
./cbug
at state 0
at state 1
at state 2
at state 3
at state 4
at state 5
at state 6
at state 7
2173
echo $?
0
./cbug2
at state 0
echo $?
128

Running cbug2 in gdb confirms that it branches to la-la land the first time it
enters the switch(), and then SEGVs.

#include <stdio.h>

enum state { q0, q1, q2, q3, q4, q5, q6, q7 };

int run(int x)
{
    enum state state = q0;

    for (;;) {
        printf("at state %d\n", state);
        fflush(stdout);
        switch (state) {
        case q0: x += 1; state = q1; continue;
        case q1: x *= 2; state = q2; continue;
        case q2: x += 3; state = q3; continue;
        case q3: x *= 4; state = q4; continue;
        case q4: x += 5; state = q5; continue;
        case q5: x *= 6; state = q6; continue;
        case q6: x += 7; state = q7; continue;
        case q7: return x;
        }
    }
}

int main(void)
{
    printf("%d\n", run(42));
    return 0;
}



-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6945

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.