Subject: binutils: Heads up!

From: Ralf Baechle <[email-masked]>
Date: Mon, 9 Aug 1999 14:40:50 +0200

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