Bogosity of merging GLOB_DATs with JUMP_SLOTs (was: Re: [PATCH] Fix PLT infinite loop for cris-*-*.)

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

CC: to binutils, because it's a GNU ld issue too.  Summary:
don't merge .got.plt with .got.  Film at 11.
Uwe, please see the testcase below.

> Date: Wed, 17 Sep 2003 15:34:31 -0700
> From: Roland McGrath <roland@redhat.com>

Roland, thank you for your reply and consideration.

> It's already well-specified that when a symbol is being resolved for a
> purpose other than PLT resolution itself, the value resolved must be the
> PLT entry in the prevailing object.

I see now what's going on.  It's not mentioned in the gABI,
(other documentation pointers welcome) so I can't agree that
it's generally "well-specified", but the i386 psABI at
<URL:http://www.caldera.com/developers/devspecs/abi386-4.ps>
(newer pointer?) has a related note in 5-6 "Function Addresses".
Quoted for the record: "References from within shared objects
will normally be resolved by the dynamic linker to the virtual
address of the function itself. References from within the
executable file to a function defined in a shared object will
normally be resolved by the link editor to the address of the
procedure linkage table entry for that function within the
executable file.  To allow comparisons of function addresses to
work as expected, if an executable file references a function
defined in a shared object, the link editor will place the
address of the procedure linkage table entry for that function
in its associated symbol table entry."

So, for visible-pointer equality, a PLT in the executable is
always required for the referenced function even if there are no
calls, which also seems to happen (for at least ia32 and CRIS).

This whole thing is arguably processor-specific (psABI-specific)
behavior, but I can't see how to implement it otherwise if you
want to use *_GLOB_DAT and *_JUMP_SLOT -type relocs, lazy
linking and when taking function addresses, avoiding the use of
dynamic relocs unless -fpic/-fPIC.

Because *_GLOB_DATs and *_JUMP_SLOTs (a.k.a. .got and .plt.got)
relocs don't always have the same contents after relocation, the
optimization in the CRIS linker backend to merge them is bogus.
A test-case follows, showing that with the kind of change in the
glibc patch at
<URL:http://sources.redhat.com/ml/libc-alpha/2003-09/msg00149.html>,
the R_CRIS_GLOB_DAT for "y" in libb.so is incorrectly
initialized to the real function address, where it should have
been the stub in the main function.

Uwe, can you please confirm that you see the bug exposed by this
test-case with your glibc with the patch mentioned above?  I've
only run this test on an older glibc version, but will get the
cris-axis-linux-gnu glibc port up and running before checking in
the GNU ld (or rather, BFD) correction.  I'll post it before
that, though.

(I have definitely not been as forthcoming as I should with
keeping up-to-date with glibc, but having said that, the glibc
maintainers side could improve communications too.  Oh well.)

cat <<'EOF' >Makefile
CC=gcc-cris -mlinux -O2

main: main.c libb.so
	$(CC) -o $@ $^

libb.so: b.c
	$(CC) -fpic -shared -o $@ $^
EOF
cat <<'EOF' >b.c
int y(void) {}

void *b(void)
{
  return y;
}
EOF
cat >main.c <<'EOF'
extern void *b(void);
extern int y(void);
int
main ()
{
  printf ("b: %x y: %x\n",
	  b(), y);
  exit (0);
}
EOF
Edit CC in Makefile to comply with local installation, then "make".

Running ./main, expect:
b: 80428 y: 80428
You will observe, with the referred glibc patch:
b: 40000680 y: 80428
(numbers should be same; actual numbers unimportant)

There now seems to be bugs in both glibc and the linker.  Sorry.
I'll fix the linker.

How to proceed on reverting the glibc patch?

brgds, H-P