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

[Jiong Wang]

On 01/03/16 14:37, H.J. Lu wrote:
> On Tue, Mar 1, 2016 at 6:02 AM, Kyrill Tkachov
> <kyrylo.tkachov@foss.arm.com> wrote:
>> Hi HJ,
>>
>> On 26/02/16 12:51, H.J. Lu wrote:
>>> On Thu, Feb 25, 2016 at 10:59 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>> Here is the updated patch I am testing.  The linker behavior is changed
>>>> in 2 cases when creating executable:
>>>>
>>>> 1. When there are mixed PIC and non-PIC references to undefined
>>>> weak symbols, undefined weak symbols are resolved to 0 at link-time.
>>>> 2. If all references to undefined weak symbols are PIC, dynamic
>>>> relocations against undefined weak symbols will be generated unless
>>>> -z nodynamic-undefined-weak is passed to linker.
>>>>
>>>> BTW,  We have to resolve R_X86_64_32/R_X86_64_PC32 relocations
>>>> against undefined weak symbols to zero.  Otherwise, we will get run-time
>>>> relocation overflow for dynamic R_X86_64_32/R_X86_64_PC32 relocations.
>>>>
>>> This is what I am checking in.
>>>
>>>
>> I'm seeing:
>>
>> NA->FAIL: Mixing PIC and non-PIC
>> on aarch64-none-linux-gnu.
> You can either fix aarch64 backend or skip the test for aarch64.

H.J,

   For your testcase, AArch64 is not generating dynamic relocation for
   weak undefined symbol referenced from non-pic code when linking
   exectuable, instead, it's resolved to zero during static linking stage.
   As far as I know, this behavior is exactly what's described here at

     https://sourceware.org/ml/binutils/2008-04/msg00269.html

   And reading those historical discussions,

    https://sourceware.org/ml/binutils/2008-04/msg00032.html
    https://sourceware.org/ml/binutils/2008-02/msg00264.html

   Looks to me the ld behavior changes introduced by your patch is quite
   sensitive and there still be lack of consensus.

   Therefore, instead of skipping this testcase on AArch64 (I guess a few
   other targets will fail on native tests as well), can you please only
   enable this testcase on x86 arches firstly?