[ld/testsuite] Skip "Mixing PIC and non-PIC" testcase on ARM/AArch64 if when no -fpie or -fPIE

[Jiong Wang]

>>>>>>>> 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.
>>>>> What linker change were you referring to?  I only added a testcase.
>>>>
>>>> I mean those linker changes added together with this testcase.
>>>>
>>>> commit aec6b87e0b66d707ead62ca40d220ee78b4cf5a5
>>>> Author: H.J. Lu <hjl.tools@gmail.com>
>>>> Date:   Fri Feb 26 04:16:15 2016 -0800
>>>>
>>>>       [x86] Resolve non-PIC undefweak symbols in executable
>>>>
>>> As far as aarch64 backend is concerned, I only added a testcase.
>>
>> Well, then why you put it under generic directory? and without restricting
>> it
>> on x86? this is implicitly affect all targets, and enforcing all targets to
>> follow
>> the changes on x86.  I think similar changes should only be encouraged to
>> other target
>> if it's conventional rules, or it's clearly documented by generic or that
>> target's ELF
>> specification.
>>
>> While reading from http://www.skyfree.org/linux/references/ELF_Format.pdf,
>>
>>    "The link editor does not extract archive members to resolve undefined
>>    weak symbols. Unresolved weak symbols have a zero value."
>>
>> Looks to me the spec is even more strict that weak symbol's life is defined
>> to be ended
>> after static linking stage. All unresolved weak symbols are assigned zero
>> value.
>>
>> IMO, the support of weak symbol under various rare and complex scenarios are
>> very
>> target specific, thus I'd either move this testcase under x86 directory or
>> put it under
>> generic directory but enabling it on x86 only initially.  If other targets
>> want and start
>> to support similar features like x86 on weak symbol, then they can be
>> enabled seperately.
>> This looks to me is a more clean & acceptable way to other targets.
>>
> Have you looked at the testcase I added? Are there anything
> which are target specific?

I do have looked at the testcase, they do be purely C code.

If the convention of generic is syntax generic instead of both syntax and
sematics, I don't have further comment on this.

Anyway, attached patch skips the non-pie version "Mixing PIC and non-PIC"
testcase.

Not sure if it's trivial enough to qualify obvious, so OK for master branch?

2016-03-02  Jiong Wang  <jiong.wang@arm.com>

ld/testsuite/

   * ld-elf/shared.exp (mix_pic_and_non_pic): Only run on ARM and AArch64
     when -fPIE or -fpie specified.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: k.patch
Type: text/x-patch
Size: 566 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20160302/34aa0c7a/attachment.bin>