This is the mail archive of the
mailing list for the binutils project.
Re: Undo dynamic symbol state after regular object sym type mismatch
- From: "Maciej W. Rozycki" <macro at imgtec dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: <binutils at sourceware dot org>
- Date: Tue, 11 Jul 2017 02:01:31 +0100
- Subject: Re: Undo dynamic symbol state after regular object sym type mismatch
- Authentication-results: sourceware.org; auth=none
- References: <20170417140540.GX24006@bubble.grove.modra.org>
On Mon, 17 Apr 2017, Alan Modra wrote:
> This fixes a generic ELF bug I noticed when looking at
> 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
> 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
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'
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,
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?