egcs-1.1/ld-2.9.1 bug loading shared objects on axp under Linux

[Tom Holroyd]

I don't know if this is a bug in egcs or in ld or in both -- hopefully
somebody here can tell.

My system is an Alpha AXP EV56 running Linux 2.0.34.
I've installed egcs-1.1 and binutils-2.9.1.

The attached code consists of a file moo.c that is compiled and linked
into a shared object, which is then loaded into a small main.  The bug
does not manifest itself when moo.o is linked statically.

I've attached a tar file that contains everything to generate the bug.

Here's a snip from moo.c:

	x0 = 0x2222;
	if (type == 30) {
		Uxy.XY[0] = 0x4321;
		i0 = 0x1234;
	} else {
		i0 = 0x1111;
	}
fprintf(stderr, "i0 = 0x%0X\n", i0);
	for (i = 2; i < 3; i++) {
		Uxy.XY[i] = x0 + XY[i];
#ifdef BUGGY
		i++;
#endif
	}

I'm using -O3, so the effect of including the 'i++' statement is to
(drastically) alter the generated assembly code.  I chose that for
simplicity -- changing virtually anything else above alters the behavior.

Here is the output from running the 'doit' script (which compiles and
runs the test code):

cc -v:
Reading specs from /usr/local/lib/gcc-lib/alphaev56-unknown-linux-gnu/egcs-2.91.57/specs
gcc version egcs-2.91.57 19980901 (egcs-1.1 release)

ld -v:
GNU ld version 2.9.1 (with BFD 2.9.1.0.4)

OK (dynamic link):
i0 = 0x1234
Uxy.XY[0]=0x4321

BUGGY (dynamic link):
i0 = 0x1234
Uxy.XY[0]=0x2222                <-- should be 0x4321

Also OK (static link):
i0 = 0x1234
Uxy.XY[0]=0x4321

------------------------
The value at Uxy.XY[0] is being overwritten when it should not be.

Here is my analysis: the code that is generated seems to be valid in
both cases, however the _GLOBAL_OFFSET_TABLE_ is not being set up
correctly during the dynamic link.  When Uxy.XY[0] is set to 0x4321, the
compiler generates (useless junk elided, full listing in attachment):
	ldq     s0,-32744(gp)           == &Uxy
	lda     t0,17185(zero)          == 0x4321
	stw     t0,4(s0)                == Uxy.XY[0]
and when it does the assignment in the loop, it generates:
	ldq     t4,-32752(gp)           == &Uxy.XY[0] (supposedly)
	code to increment the address to &Uxy.XY[i] and store it in t2
	more code to get x0 + XY[i] in t0
	stw     t0,0(t2)                == ***

The final store writes to the wrong address in the -DBUGGY case because the
ldq to t4 is getting the wrong address.  In the non-buggy case, -32744(gp)
and -32752(gp) contain different addresses.  In the buggy case, both
addresses are the *same*.  That's the problem.

Cheers,

Dr. Tom Holroyd, tomh@nibh.go.jp
Behavior Control Lab, Human Informatics Dept.            The basis of
National Institute of Bioscience and Human-Technology    stability is
1-1 Higashi, Tsukuba-shi, Ibaraki 305, Japan             instability.
The 9th Amendment of the U.S. Constitution:
"The enumeration in the Constitution, of certain rights, shall not be
construed to deny or disparage others retained by the people."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bugreport.tar
Type: application/x-tar
Size: 10240 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-bugs/attachments/19980925/e46153ac/attachment.tar>