Re: [PATCH] PR ld/19636: [x86] Resolve undefweak and defined symbols in executable

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Wed, Feb 24, 2016 at 9:04 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Wed, Feb 24, 2016 at 8:58 AM, Michael Matz <matz@suse.de> wrote:
>> Hi,
>>
>> On Wed, 24 Feb 2016, H.J. Lu wrote:
>>
>>> >> My change will make ld guarantees the consistent behavior, regardless
>>> >> PIC or non-PIC.
>>> >
>>> > As you keep repeating this, I'll do so as well: yes, and you resolved
>>> > that consistency into the wrong direction, break PIC and non-PIC,
>>> > instead of fixing both.  That makes no sense, just because there are
>>> > broken circumstances should not make us break all others as well.
>>>
>>> You keep saying non-PIC is broken, which I disagree.
>>
>> Simple, if this testcase (which unlike your made-up ones to show various
>> inconsistencies actually does occur in the wild) doesn't print "works", I
>> call it broken:
>>
>> % cat main.c
>> extern int __attribute__ ((weak)) printme (void);
>> void
>> main (void)
>> {
>>   if (printme)
>>     printme ();
>> }
>> % cat lib.c
>> #include <stdio.h>
>> void printme (void)
>> {
>>   printf ("works\n");
>> }
>> % gcc -fPIC -shared -o lib.so lib.c
>> % gcc -fPIC -o main main.c
>> % LD_PRELOAD=./lib.so ./main
>> works
>>
>> I can't fathom why anyone would call the above behaviour unexpected or
>> broken, or would desire the above to _not_ print "works".
>>
>
> This is the unintended behavior, similar to LD_DYNAMIC_WEAK in
> ld.so.

I should have mentioned that I have a followup patch to
re-encode compare and branch instructions

extern int __attribute__ ((weak)) printme (void);
...

if (printme)
  printme ();

in executable, PIE or non-PIE, to remove memory load.

-- 
H.J.