Re: Undo dynamic symbol state after regular object sym type mismatch

["Maciej W. Rozycki" <macro at imgtec dot com>]

On Tue, 25 Jul 2017, Alan Modra wrote:

> >  However this will cause 
> > trouble for undefined weak symbols in PIE executables, as making these 
> > symbols local will make the corresponding GOT entries relocated by the 
> > base address and consequently any NULL pointer checks which typically 
> > guard the use of such symbols will not work anymore, as already noted in 
> > PR ld/21375.
> 
> I don't see why this is an issue.  You surely can make undefined weak
> symbols global, if you would like them to potentially be resolved by a
> definition at run-time not available at link time.  (Undefined weaks
> are a special case.  I wasn't careful enough in saying which symbols
> should be made dynamic.)  On the other hand, if you want undefined
> weaks to *not* be resolved at run-time then you do have a problem to
> make sure their value stays zero..

 Having read some more I have come across this note in the ELF gABI[1]:

"When the link editor searches archive libraries [see ``Archive File'' in 
Chapter 7], it extracts archive members that contain definitions of 
undefined global symbols.  The member's definition may be either a global 
or a weak symbol.  The link editor does not extract archive members to 
resolve undefined weak symbols.  Unresolved weak symbols have a zero 
value."

which I think makes it clear that undefined weaks are not supposed to make 
it beyond the static link.  And as I noted in the previous message I find 
it the most consistent approach, preventing additional symbols present in 
a DSO which were not there in the static link from making any difference 
for the executable at the load time.

> In either case, we're not talking about the indirect5a testcase, where
> we have a strong definition of "bar" in both the executable and a
> shared library (the definition in the shared library counting as an
> implicit reference to allow overriding), and you don't want the
> executable definition to be exported because it doesn't match the
> shared library symbol type.

 Correct, however there is nothing specifically wrong about the 
`indirect5a' testcase in the MIPS backend and the symptoms we see with 
this backend are just one of the effects of the backend's global 
peculiarity of not supporting `--no-export-dynamic'.  And obviously if we 
want to add such support, then we need to get all the cases right, or at 
least the immediately identified ones.  Once `--no-export-dynamic' works 
as expected the issue with `indirect5a' (and a couple of other tests, 
currently XFAILed for the MIPS target) will clear as I have observed in my 
testing of the preliminary fix I have been working on.

> >  The only solution to PR ld/21375 I have come up with so far is using a 
> > global absolute symbol for GOT entries used for any local references to 
> > undefined weak symbols, either by tweaking the attributes of the original 
> > symbol (setting SHN_ABS/STB_GLOBAL combined with STV_HIDDEN or 
> > STV_INTERNAL; but that breaks strict gABI compliance) or by redirecting to 
> > a special reserved symbol, say `__gnu_absolute_zero', whose value is 
> > globally zero (and SHN_ABS/STB_GLOBAL/STV_DEFAULT).  The latter approach 
> > has the advantage of reducing the number of GOT entries (which is always 
> > advantageous) where multiple undefined weak symbols are present.
> 
> Another approach is to edit the code, changing it from referencing the
> GOT to loading zero by some other means.

 This is actually a great idea that will allow us to avoid the issue with 
the dynamic loader an SHN_ABS symbols, at least in the usual cases, 
thanks!

 References to weak symbols made via GOT are only allowed by using one of 
the: R_MIPS_GOT16, R_MIPS_GOT_LO16, R_MIPS_CALL16, R_MIPS_GOT_DISP or 
R_MIPS_GOT_OFST relocations (or their MIPS16 and microMIPS equivalents), 
which in reality are always associated with an LW or an LD instruction 
(always encoded in their 32-bit length in the compressed instruction set).  
These instructions can be easily substituted by the static linker with a 
single instruction that will load 0 into the target register instead.

 There is some complication with software that just might use a different 
instruction with one of these relocations, such as ADDIU or DADDIU to load 
the address of the GOT slot instead and then pass it along.  That would 
have to be handled in the manner I previously outlined, however I expect 
it to be uncommon enough not to require an ABIVERSION update.

> >  So I think the correct way to address the problem with the MIPS backend 
> > is to:
> > 
> > 1. Fix glibc BZ 19818, the dynamic loader's absolute symbol bug.
> > 
> > 2. Bump ABIVERSION up in `ld.so' for correct SHN_ABS support.
> > 
> > 3. Fix PR ld/21375, the local undefined weak symbol bug.
> > 
> > 4. Document `--export-dynamic' as the default with MIPS PIE binaries.
> 
> OK, in that case you'll need to make ld.so check symbol type before
> allowing an override.  Sounds like something that should be done for
> all targets..

 I think we need to do this anyway, as I noted earlier on, because a 
second DSO might have caused an offending symbol to get exported with no 
type conflict.  I'll file a BZ against the dynamic loader separately, once 
I have made a suitable test case.

 With your proposal to patch code out to load zero I think there will be 
no need to make `--export-dynamic' the default though.

> >  I am yet reviewing past discussions about our handling of undefined weak 
> > symbols in PIE executables, in particular PR ld/2218 and the corresponding 
> > thread at: <https://sourceware.org/ml/binutils/2006-01/msg00193.html> and 
> > then <https://sourceware.org/ml/binutils/2006-02/msg00023.html>, because 
> > it seems we're a bit inconsistent here among targets as far as making them 
> > global or local is concerned, and this is not covered by the ELF gABI 
> > AFAICT.
> 
> Right.  Undefined weaks are a grey area.

 I have not completed reviewing the PR ld/2218 thread of discussion yet, 
however with the observations I made at the beginning of this message I 
how believe we need to resolve undefined weaks to zero at the static link 
time.  Perhaps unless a specific psABI says otherwise, but the MIPS psABI 
does not.

  Maciej

References:

[1] "System V Application Binary Interface - DRAFT - 19 October 2010",
    The SCO Group, Section "Symbol Table",
    <http://www.sco.com/developers/gabi/2012-12-31/ch4.symtab.html>