[PATCH]Replace -shared with -r -nostdlib in gcc.dg/lto/pr61526 pr54709 pr64415 test cases.

Richard Biener richard.guenther@gmail.com
Thu Mar 3 10:13:00 GMT 2016


On Wed, Mar 2, 2016 at 5:12 PM, Renlin Li <renlin.li@foss.arm.com> wrote:
> Hi Richard,
>
>
> On 02/03/16 13:35, Richard Biener wrote:
>>
>> On Tue, Mar 1, 2016 at 4:56 PM, Renlin Li <renlin.li@foss.arm.com> wrote:
>>>
>>> Hi Richard,
>>>
>>>
>>> On 01/03/16 09:16, Richard Biener wrote:
>>>>
>>>> On Mon, Feb 29, 2016 at 5:13 PM, Renlin Li <renlin.li@foss.arm.com>
>>>> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> The gcc.dg/lto/pr54709, pr61526, pr64415 linking testcases keep failing
>>>>> on
>>>>> arm/aarch64 bare-metal target.
>>>>>
>>>>> It's because statically built newlib library is used to link with
>>>>> shared
>>>>> object.
>>>>> And the linker complains about relocations which cannot be used in
>>>>> shared object.
>>>>>
>>>>> For example, the following errors are produced:
>>>>>
>>>>> crtbegin.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can
>>>>> not
>>>>> be
>>>>> used when making a shared object; recompile with -fPIC
>>>>>
>>>>> crtbegin.o: relocation R_ARM_THM_MOVW_ABS_NC against `a local symbol'
>>>>> can
>>>>> not
>>>>> be used when making a shared object; recompile with -fPIC
>>>>>
>>>>> librdimon.a(rdimon-syscalls.o): relocation R_AARCH64_ADR_PREL_PG_HI21
>>>>> against
>>>>> external symbol `_impure_ptr' can not be used when making a shared
>>>>> object;
>>>>> recompile with -fPIC
>>>>>
>>>>> Presumably, bare-metal toolchain for other architecture have those test
>>>>> case
>>>>> failures as well?
>>>>>
>>>>> In this patch, -shared option is replace by -r -nostdlib. So that the
>>>>> standard
>>>>> system startup files or libraries are not used when linking.
>>>>
>>>> Note that -shared is not equivalent to -r -nostdlib so please verify
>>>> that
>>>> the
>>>> original issue can be still reproduced with its fix reverted but -r
>>>> -nostdlib
>>>> used with the new -r -nostdlib handling on trunk.
>>>
>>>
>>> pr54709_0.c: Cannot be reproduced with even -shared. The error message is
>>> the same as shown above.
>>> pr64415_0.c: Reproduced with "-r -nostdlib".
>>> pr61526_0.c: Reproduced with "-r -nostdlib".
>>>
>>> By the way, those linking test cases all pass for linux toolchain. Only
>>> fail
>>> for aarch64/arm baremetal toolchain.
>>>
>>> Andrew, I saw you have done similar things in r153555
>>> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=153555
>>>
>>> Do you have any thoughts?
>>>
>>> And also here, the last comments in this ticket suggests to add
>>> check_effective_target_shared to the exp file to limit it to linux
>>> targets
>>> only:
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61526
>>
>> As said LTO testcases tend to be somewhat fragile so limiting them to
>> targets known to work might be the best option.
>>
>> Richard.
>
>
> Forgot the mention that, by purely adding "-nostdlib" option (instead of
> replacing -shared)
> fixes the failures as well.
>
> I test those test cases again with fix reverted, keep "-shared" option, add
> "-nostdlib" option.

Ok, so I discovered we have a "shared" target which means if a target doesn't
support shared libs we can guard against it with using

/* { dg-require-effective-target shared } */

does adding that to the three testcases fix the issue for you?

Thanks,
Richard.

> pr54709_0.c: Cannot be reproduced even with test case unmodified.
> The error message is the same as shown above. with "-nostdlib", no failure.
>
> pr64415_0.c: Reproduced.
> pr61526_0.c: Reproduced.
>
> Regards,
> Renlin
>
>
>
>>
>>> Regards,
>>> Renlin
>>>
>>>
>>>> Otherwise simply dg-skip for aarch64.
>>>>
>>>> Richard.
>>>>
>>>>> arm-none-eabi, aarch64-none-elf regression test OK, OK for trunk?
>>>>>
>>>>> Regards,
>>>>> Renlin Li
>>>>>
>>>>> gcc/testsuite/ChangeLog:
>>>>>
>>>>> 2016-02-29  Renlin Li<renlin.li@arm.com>
>>>>>
>>>>>           * gcc.dg/lto/pr54709_0.c: Replace -shard with -r -nostdlib.
>>>>>           * gcc.dg/lto/pr61526_0.c: Ditto.
>>>>>           * gcc.dg/lto/pr64415_0.c: Ditto.
>>>>>
>



More information about the Gcc-patches mailing list