[PATCH] PR ld/19636: pie changes program behavior and generate unnecessary dynamic symbols
H.J. Lu
hjl.tools@gmail.com
Mon Feb 22 03:05:00 GMT 2016
On Sun, Feb 21, 2016 at 6:53 PM, Alan Modra <amodra@gmail.com> wrote:
> 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.
>
I am very surprised to see PIC in relocatable input make a difference
in output. I will ask on gABI list.
H.J.
More information about the Binutils
mailing list