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

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

Hi Alan,

On Mon, 17 Apr 2017, Alan Modra wrote:

> This fixes a generic ELF bug I noticed when looking at
> https://sourceware.org/ml/binutils/2017-04/msg00137.html
> 
> We already handle the case of an object file first defining a symbol
> that a later shared library also defines where the symbol types are
> incompatible.  This patch handles the reverse, when a later object
> file defines an incompatible symbol defined by an earlier shared
> library.
> 
> The new testcases expose bugs in a number of ELF backends, the ones I
> saw being aarch64, arm, mips, mips64, nios2 and sparc64.  There are
> likely more that I wouldn't see due to not having cross-compilers
> installed.

 In an attempt to prevent new MIPS target failures in preparation for the 
2.29 release I have now looked into it and what the MIPS backend produces 
looks correct to me according to the MIPS psABI.

 Specifically, while linking the `indirect5a' executable, in the 
`indirect5a.o' object supplied we have a locally-defined global `bar' 
symbol referred to -- in the case of the o32 ABI -- with an R_MIPS_GOT16 
relocation, which is absolutely fine for a MIPS SVR4 psABI executable.  
In response the MIPS backend creates the mandatory global GOT entry and 
its corresponding dynsym entry for `bar'.  It does not create a GOT or 
dynsym entry for `bar@@foo' seen while processing `libindirect5.so'; 
there's no previously created dynsym for `bar' in `libindirect5.so' 
either.

 So by claiming that the MIPS backend has bugs what do you say it is 
supposed to do here?  There is not enough context here, I am afraid, for 
me to decide, and based solely on your description and code you have 
committed I am leaning towards concluding that either:

1. it is the task of the dynamic loader to resolve this clash,

or:

2. you need to force `bar' local in the link, i.e. refrain from clearing 
   `h->forced_local' once `bed->elf_backend_hide_symbol' has been called.

I will appreciate pointers to old discussions or documentation too, and in 
particular the justification for what we're trying to do here, that is 
IIUC preventing a symbol from being preempted by a symbol of a different 
type rather than just following the ELF gABI that has nothing interesting 
to say about mixing symbol types in preemption.

 Also what if we have a second shared library, say `libdirect5.so', also 
present in the link, that actually has a global `bar' symbol of the object 
type defined, which I suppose will have to be preempted by the main 
executable's symbol regardless of what we do about `libindirect5.so' (and 
which presumably rules out my case #2 above, leaving the dynamic loader 
option #1 as the only one at all possible)?

 Overall I'm not sure if we shouldn't follow the general engineering 
principle of the least surprise and simply fail the link, as it's hard to 
imagine a valid use case for interposition between symbols of a different 
object vs function type.

 NB I get clear:

PASS: Run indirect5 1
PASS: Run indirect5 2
PASS: indirect5a dynsym
PASS: indirect5b dynsym

results in an o32 `-mplt' test run, because MIPS PLT executables do not 
follow the SVR4 MIPS psABI and do not have to have GOT/dynsym entries for 
global symbols.  However:

FAIL: Run indirect5 3
FAIL: Run indirect5 4
FAIL: Run indirect6 3
FAIL: Run indirect6 4
FAIL: indirect5c dynsym
FAIL: indirect5d dynsym
FAIL: indirect6c dynsym
FAIL: indirect6d dynsym

result regardless, because `-fPIE' forces the use of the SVR4 model.

 Questions, thoughts, answers?

  Maciej