Re: [hjl@valinux.com: Re: An ELF/PPC patch for ld/testsuite]

[Geoff Keating <geoffk at cygnus dot com>]

> Mail-Followup-To: hjl@valinux.com,
>   binutils@sources.redhat.com,
>   geoffk@cygnus.com
> Date: 19 Oct 2000 12:55:46 -0700
> From: Ian Lance Taylor <ian@zembu.com>
> CC: hjl@valinux.com, binutils@sources.redhat.com
> 
>    Date: Thu, 19 Oct 2000 12:43:12 -0700
>    From: Geoff Keating <geoffk@cygnus.com>
> 
>    - by creating a non-PIC shared object without a load offset, which
>      causes it to be loaded just under the application at
>      0x0FFFsomething, and having it branch to an undefined weak symbol
>      which means location 0.  non-PIC code using undefined weak symbols
>      is not supported on powerpc because it can't work.
> 
> This could be fixed by having the linker permit a relocation to an
> undefined weak symbol even if that relocation appears to be out of
> range.  The presumption is that the application will not actually call
> such a symbol.

It's ld.so that complains.  I don't think ld.so should be trying to do
tricky stuff, it's hard enough to explain its behaviour at present.
It is also easier if you simply explain that undefined weak symbols
and non-PIC code don't mix.

>    The other restriction is a generic ELF one, which is that non-PIC
>    applications cannot reliably reference undefined weak symbols.  The
>    symbols will sometimes appear to be zero and sometimes not.
> 
> I don't understand this.  An undefined weak symbol should always
> appear to be zero.  In what circumstance would that not be true?  I
> think I can write a non-PIC application which uses undefined weak
> symbols.
>     if (&foo) foo();

If you write this in a non-PIC application, the code will look like:

	lis %r3,foo@ha
	addi %r3,foo@l,%r3
	cmpwi %r3,0
	bne 0f
	bl  foo
0:

it loads up the address of foo(), using an immediate load.  It
compares it to 0.  It then calls foo().  Since there are no
relocations permitted in the text section of applications, after
linking this code will either always call foo() or will never call
foo().  If foo() is not defined in the application, then it's possible
that with different shared library combinations foo() could be defined
in one run and not defined in the next, without the application being
re-linked, and so this will not work.

-- 
- Geoffrey Keating <geoffk@cygnus.com>