This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] PR ld/19636: pie changes program behavior and generate unnecessary dynamic symbols
- From: Alan Modra <amodra at gmail dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Mon, 22 Feb 2016 13:23:08 +1030
- Subject: Re: [PATCH] PR ld/19636: pie changes program behavior and generate unnecessary dynamic symbols
- Authentication-results: sourceware.org; auth=none
- References: <20160215150032 dot GA26273 at gmail dot com> <20160217052322 dot GA14941 at gmail dot com> <CAMe9rOoOKPsrxf51pzBzouREZYP0TUyFNq2XTZGY61p3kzrEgA at mail dot gmail dot com> <20160218004245 dot GG31757 at bubble dot grove dot modra dot org> <CAMe9rOqhYY6R7gUgaw7L5ab-Rs=3VDCVdBEsGcGCWde4aA6a8Q at mail dot gmail dot com> <20160218063124 dot GA10657 at bubble dot grove dot modra dot org> <CAMe9rOoKfOTQ5jT10oS1HBXMSBfhB2h9Me91_briyzD2GWScHw at mail dot gmail dot com>
On Sat, Feb 20, 2016 at 09:59:24PM -0800, H.J. Lu wrote:
> On Wed, Feb 17, 2016 at 10:31 PM, Alan Modra <amodra@gmail.com> wrote:
> > On Wed, Feb 17, 2016 at 08:24:06PM -0800, H.J. Lu wrote:
> >> On Wed, Feb 17, 2016 at 4:42 PM, Alan Modra <amodra@gmail.com> wrote:
> >> > This change is incorrect. Some targets (even x86_64 with -fPIC)
> >> > support
> >> > if (fun)
> >> > fun ();
> >> > for an undefined weak fun at link time, making fun dynamic and
> >> > emitting dynamic relocs against fun. So when the executable is linked
> >> > against a new shared library that provides fun, fun will be called.
> >
> >> Yes, it should be moved before
> >
> > No, that change should not be added at all!
>
> I moved it to x86 backend via elf_backend_fixup_symbol.
Where it is just as wrong as anywhere else. You are changing the
behaviour of the following program.
cat > undefweak.c <<EOF
extern void __attribute__ ((weak)) fun (void);
int main (void)
{
if (&fun != 0)
fun ();
return 0;
}
EOF
gcc -c -fPIC -O2 undefweak.c
gcc -o undefweak undefweak.o
If some later version of libc.so defines "fun", then with your change,
"fun" won't be called. I can't cite real-world examples of this
behaviour off the top of my head, where "fun" is likely to be some
function multiple levels deep in a tree of user shared libraries, but
I'm almost certain you will break some people's expectations.
--
Alan Modra
Australia Development Lab, IBM