"Bad reloc" Problem

Hello !

Does the “Bad reloc in text…” problem still exist
in the current SDL CVS ?

CU

Hello !

Does the “Bad reloc in text…” problem still exist
in the current SDL CVS ?

Yes. You are welcome to see if you can fix it. I don’t know assembly
well enough to figure out what’s going on. As far as I can tell it has
something to do with the code nasm outputs for local jmp instructions.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

Sam Lantinga wrote:

Hello !

Does the “Bad reloc in text…” problem still exist
in the current SDL CVS ?

Yes. You are welcome to see if you can fix it. I don’t know assembly
well enough to figure out what’s going on. As far as I can tell it has
something to do with the code nasm outputs for local jmp instructions.

Does anyone have the mmxp2_32.o file that was causing problems ? I don’t
have windows or the file, but if someone with both could run “objdump
-Crt mmxp2_32.o” and send the output, we would at least be able to see
if the jmp instructions are correct…

Stephane

Is this ok ?

Stephane Marchesin wrote:

Does anyone have the mmxp2_32.o file that was causing problems ? I don’t
have windows or the file, but if someone with both could run “objdump
-Crt mmxp2_32.o” and send the output, we would at least be able to see
if the jmp instructions are correct…

Stephane

John at ezri /compile/SDL/SDL12
$ objdump.exe -Crt ./src/hermes/.libs/mmxp2_32.o

./src/hermes/.libs/mmxp2_32.o: file format pe-i386

SYMBOL TABLE:
[ 0](sec -2)(fl 0x00)(ty 0)(scl 103) (nx 1) 0x00000000 mmxp2_32.asm
File
[ 2](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .data
AUX scnlen 0x40 nreloc 0 nlnno 0
[ 4](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .text
AUX scnlen 0x2ef nreloc 20 nlnno 0
[ 6](sec -1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .absolut
[ 7](sec 0)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 mmxreturn
[ 8](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 mmx32_rgb888_mask
[ 9](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000008 mmx32_rgb565_b
[ 10](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000010 mmx32_rgb565_g
[ 11](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000018 mmx32_rgb565_r
[ 12](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000020 mmx32_rgb555_rb
[ 13](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000028 mmx32_rgb555_g
[ 14](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000030 mmx32_rgb555_mul
[ 15](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000038 mmx32_bgr555_mul
[ 16](sec 2)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 ConvertMMXpII32_24RGB888
[ 17](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000019
ConvertMMXpII32_24RGB888.L1
[ 18](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000066
ConvertMMXpII32_24RGB888.L2
[ 19](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x0000006d
ConvertMMXpII32_24RGB888.L3
[ 20](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000086
ConvertMMXpII32_24RGB888.L4
[ 21](sec 2)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0000008b ConvertMMXpII32_16RGB565
[ 22](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x000000ac
ConvertMMXpII32_16RGB565.L1
[ 23](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000102
ConvertMMXpII32_16RGB565.L2
[ 24](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000109
ConvertMMXpII32_16RGB565.L3
[ 25](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000132
ConvertMMXpII32_16RGB565.L4
[ 26](sec 2)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000137 ConvertMMXpII32_16BGR565
[ 27](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000158
ConvertMMXpII32_16BGR565.L1
[ 28](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x000001b0
ConvertMMXpII32_16BGR565.L2
[ 29](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x000001b5
ConvertMMXpII32_16BGR565.L3
[ 30](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x000001de
ConvertMMXpII32_16BGR565.L4
[ 31](sec 2)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x000001e3 ConvertMMXpII32_16BGR555
[ 32](sec 2)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x000001ef ConvertMMXpII32_16RGB555
[ 33](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x000001f6 convert_bgr555_cheat
[ 34](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000209 convert_bgr555_cheat.L_OK
[ 35](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x0000022d convert_bgr555_cheat.L1
[ 36](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x000002b5 convert_bgr555_cheat.L2
[ 37](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x000002bc convert_bgr555_cheat.L3
[ 38](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x000002ea convert_bgr555_cheat.L4

RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
00000003 dir32 .data
00000087 DISP32 mmxreturn
0000008e dir32 .data
00000095 dir32 .data
0000009c dir32 .data
00000133 DISP32 mmxreturn
0000013a dir32 .data
00000141 dir32 .data
00000148 dir32 .data
000001df DISP32 mmxreturn
000001e6 dir32 .data
000001f2 dir32 .data
000001f9 dir32 .data
00000216 dir32 .data
00000220 dir32 .data
0000024c dir32 .data
0000025c dir32 .data
0000028d dir32 .data
00000297 dir32 .data
000002eb DISP32 mmxreturn

John Drinkwater wrote:

RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
00000003 dir32 .data
00000087 DISP32 mmxreturn

This means the relocation table awaits a 32 bit displacement.

0000008e dir32 .data
00000095 dir32 .data
0000009c dir32 .data
00000133 DISP32 mmxreturn
0000013a dir32 .data
00000141 dir32 .data
00000148 dir32 .data
000001df DISP32 mmxreturn
000001e6 dir32 .data
000001f2 dir32 .data
000001f9 dir32 .data
00000216 dir32 .data
00000220 dir32 .data
0000024c dir32 .data
0000025c dir32 .data
0000028d dir32 .data
00000297 dir32 .data
000002eb DISP32 mmxreturn

Now we have to see what code was assembled for that instruction.
Could you please run “objdump -Csdr mmxp2_32.o” ? :slight_smile:
There should be a 32 bit displacement, or that means nasm assembled a
non relocatable adress.

Stephane

Here you go :slight_smile:

I really wish I could help a bit more, but this is the first time i’ve tried
compiling SDL myself.

John at ezri /compile/SDL/SDL12
$ objdump.exe -Csdr ./src/hermes/.libs/mmxp2_32.o

./src/hermes/.libs/mmxp2_32.o: file format pe-i386

Contents of section .data:
0000 ffffff00 ffffff00 f8000000 f8000000 …
0010 00fc0000 00fc0000 0000f800 0000f800 …
0020 f800f800 f800f800 00f80000 00f80000 …
0030 08000020 08000020 00200800 00200800 … … . … …
Contents of section .text:
0000 0f6f3500 0000000f efff89ca 81e1fcff .o5…
0010 ffff7505 e94d0000 000f6f06 0fdbc60f …u…M…o…
0020 6f4e080f dbce0f6f d00f6ad7 0f62c70f oN…o…j…b…
0030 73f2180f ebc20f6f d90f73f3 300febc3 s…o…s.0…
Disassembly of section .text:

00000000 <ConvertMMXpII32_24RGB888>:
0: 0f 6f 35 00 00 00 00 movq 0x0,%mm6
3: dir32 .data
7: 0f ef ff pxor %mm7,%mm7
a: 89 ca mov %ecx,%edx
c: 81 e1 fc ff ff ff and $0xfffffffc,%ecx
12: 75 05 jne 19 <ConvertMMXpII32_24RGB888.L1>
14: e9 4d 00 00 00 jmp 66 <ConvertMMXpII32_24RGB888.L2>

00000019 <ConvertMMXpII32_24RGB888.L1>:
19: 0f 6f 06 movq (%esi),%mm0
1c: 0f db c6 pand %mm6,%mm0
1f: 0f 6f 4e 08 movq 0x8(%esi),%mm1
23: 0f db ce pand %mm6,%mm1
26: 0f 6f d0 movq %mm0,%mm2
29: 0f 6a d7 punpckhdq %mm7,%mm2
2c: 0f 62 c7 punpckldq %mm7,%mm0
2f: 0f 73 f2 18 psllq $0x18,%mm2
33: 0f eb c2 por %mm2,%mm0
36: 0f 6f d9 movq %mm1,%mm3
39: 0f 73 f3 30 psllq $0x30,%mm3
3d: 0f eb c3 por %mm3,%mm0

Stephane Marchesin wrote:

John Drinkwater wrote:

RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
00000003 dir32 .data
00000087 DISP32 mmxreturn

This means the relocation table awaits a 32 bit displacement.

*snip *>

Now we have to see what code was assembled for that instruction.
Could you please run “objdump -Csdr mmxp2_32.o” ? :slight_smile:
There should be a 32 bit displacement, or that means nasm assembled a
non relocatable adress.

Stephane

John Drinkwater wrote:

Here you go :slight_smile:

I really wish I could help a bit more, but this is the first time i’ve
tried compiling SDL myself.

That’s a good start : straight into assembly code :slight_smile:

John at ezri /compile/SDL/SDL12
$ objdump.exe -Csdr ./src/hermes/.libs/mmxp2_32.o

./src/hermes/.libs/mmxp2_32.o: file format pe-i386

Contents of section .data:
0000 ffffff00 ffffff00 f8000000 f8000000 …
0010 00fc0000 00fc0000 0000f800 0000f800 …
0020 f800f800 f800f800 00f80000 00f80000 …
0030 08000020 08000020 00200800 00200800 … … . … …
Contents of section .text:
0000 0f6f3500 0000000f efff89ca 81e1fcff .o5…
0010 ffff7505 e94d0000 000f6f06 0fdbc60f …u…M…o…
0020 6f4e080f dbce0f6f d00f6ad7 0f62c70f oN…o…j…b…
0030 73f2180f ebc20f6f d90f73f3 300febc3 s…o…s.0…
Disassembly of section .text:

00000000 <ConvertMMXpII32_24RGB888>:
0: 0f 6f 35 00 00 00 00 movq 0x0,%mm6
3: dir32 .data
7: 0f ef ff pxor %mm7,%mm7
a: 89 ca mov %ecx,%edx
c: 81 e1 fc ff ff ff and $0xfffffffc,%ecx
12: 75 05 jne 19 <ConvertMMXpII32_24RGB888.L1>
14: e9 4d 00 00 00 jmp 66 <ConvertMMXpII32_24RGB888.L2>

00000019 <ConvertMMXpII32_24RGB888.L1>:
19: 0f 6f 06 movq (%esi),%mm0
1c: 0f db c6 pand %mm6,%mm0
1f: 0f 6f 4e 08 movq 0x8(%esi),%mm1
23: 0f db ce pand %mm6,%mm1
26: 0f 6f d0 movq %mm0,%mm2
29: 0f 6a d7 punpckhdq %mm7,%mm2
2c: 0f 62 c7 punpckldq %mm7,%mm0
2f: 0f 73 f2 18 psllq $0x18,%mm2
33: 0f eb c2 por %mm2,%mm0
36: 0f 6f d9 movq %mm1,%mm3
39: 0f 73 f3 30 psllq $0x30,%mm3
3d: 0f eb c3 por %mm3,%mm0

Wow, it seems the file is truncated ! This file should contain more than
this little snippet of code (especially, the 0x87 adress where we would
look for a relocatable adress isn’t there, because the file stops
before, at 0x3f)

What is your file size for mmxp2_32.o ? When I cross-compile SDL for
windows, I get a 2587 byte file.

Stephane

John at ezri hermes
$ ls -la mmxp2_32.o
-rw-r–r-- 1 John None 2587 Oct 23 00:39 mmxp2_32.o

John at ezri hermes
$ objdump.exe -Csdr mmxp2_32.o

previous output contents here
39: 0f 73 f3 30 psllq $0x30,%mm3
3d: 0f eb c3 por %mm3,%mm0

John at ezri hermes
$

When I produced the output, I thought it a little short, but thats all it gives
me ~:| Tried a few options like --start-address, but even jumping into it at 3d
doesnt give anymore output

Stephane Marchesin wrote:> John Drinkwater wrote:

36: 0f 6f d9 movq %mm1,%mm3
39: 0f 73 f3 30 psllq $0x30,%mm3
3d: 0f eb c3 por %mm3,%mm0

Wow, it seems the file is truncated ! This file should contain more than
this little snippet of code (especially, the 0x87 adress where we would
look for a relocatable adress isn’t there, because the file stops
before, at 0x3f)

What is your file size for mmxp2_32.o ? When I cross-compile SDL for
windows, I get a 2587 byte file.

Stephane

John Drinkwater wrote:

John at ezri hermes
$ ls -la mmxp2_32.o
-rw-r–r-- 1 John None 2587 Oct 23 00:39 mmxp2_32.o

John at ezri hermes
$ objdump.exe -Csdr mmxp2_32.o

previous output contents here
39: 0f 73 f3 30 psllq $0x30,%mm3
3d: 0f eb c3 por %mm3,%mm0

John at ezri hermes
$

When I produced the output, I thought it a little short, but thats all
it gives me ~:| Tried a few options like --start-address, but even
jumping into it at 3d doesnt give anymore output

Could you please send me the file ? I’ll see if I can cross-objdump it /
if it links with my SDL cross compilation / if it’s different from the
one I have and if so, where it’s different.

Oh and what nasm & ld versions are you using ?

Thanks !

Stephane

Looked through the threads, jumped through various mailinglists, it seems they
have a fix for the bug, and have patched it.

They’ve applied a fix :slight_smile:
http://sources.redhat.com/ml/binutils/2003-10/msg00565.html

http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/bfd/peicode.h?cvsroot=src

I just wonder when cygwin will get an update for their precompiled binutils.
*cvs more stuff

John

Stephane Marchesin wrote:Date: Wed, 22 Oct 2003 16:07:07 +0100

Ok, so this is not an nasm bug ; the file you sent me has no problems.
This is a binutils bug (binutils is the package that contains ld and
objdump, and both are broken, the first refuses to link the .o file, and
the second thinks it’s truncated). I googled a little and found this :
http://sourceware.org/ml/binutils/2003-10/msg00497.html
This is the same problem we currently see.

AFAICT, the bug is not fixed yet. Until it’s fixed, a possible solution
is to downgrade your binutils to 2.13.90

Stephane