Over the last couple of days I've been working on bashing all bugs out of
current CVS binutils from Cygnus. The result is that as of yesterday
my working version is probably better then ever.
The downside: one of the bugs, misstreating R_MIPS_32 relocations was
present in all previous versions of binutils. Here the details for those
who care:
Assume two source file, the first one:
.data
.globl var
var: .word external_reference
Using binutils 2.8.1 the assembler outputs the following relocation record:
RELOCATION RECORDS FOR [.data]:
OFFSET TYPE VALUE
0000000000000000 R_MIPS_32 external_reference
That's the correct behaviour. So, now make that a reference to a
global variable defined in the same source:
.data
.globl var
var: .word other
.globl other
other: .word 42
This time the assembler will emit:
RELOCATION RECORDS FOR [.data]:
OFFSET TYPE VALUE
0000000000000000 R_MIPS_32 .data
This relocation should be against other. Why is this a problem? Assume
both files would be referencing the same global variable. They get
linked together as part of a final program / library. Then at runtime
the linker will resolve the one reference to the local instance of the
variable and possibly to another instance for the other reference.
This problem may sound rather theoretical. Well, it isn't. Lots of
software out there does nasties like ``int errno = 0;''. So once we're
finished with fixing binutils every single binary should be recompiled
and eventually exchanged in order to finally get rid of it's effect.
It's probably only causing actual problems in a very small number of
binaries but I though I should mention it.
Ralf
|