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

[Richard Biener <richard dot guenther at gmail dot com>]

On Thu, Mar 3, 2016 at 6:53 PM, Renlin Li <renlin.li@foss.arm.com> wrote:
> Hi Richard,
>
>
> On 03/03/16 12:47, Richard Biener wrote:
>>
>> On Thu, Mar 3, 2016 at 1:07 PM, Renlin Li <renlin.li@foss.arm.com> wrote:
>>>
>>> Hi Richard,
>>>
>>>
>>> On 03/03/16 10:13, Richard Biener wrote:
>>>>
>>>> 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?
>>>
>>> By adding this target check
>>> /* { dg-require-effective-target shared } */
>>>
>>> Those test cases aredeemed to be unsupported, and thus skipped for
>>> aarch64-none-elf target.
>>>
>>> However, it's a little bit tricky for arm bare-metal target.
>>>
>>> The shared option check actually successes for arm-none-eabi toolchain.
>>> This is because the default cpu for arm-none-eabi toolchain is arm7tdmi.
>>> And
>>> the start file crtbegin.o doesn't contains any modifications not allowed
>>> in
>>> shared object.
>>>
>>> arm-none-eabi is built with multilib. When running this testcase, it's
>>> compiled with "-march=armv7-a".
>>> The crtbegin.o for this architecture version contains relocations which
>>> cannot be used in shared object.
>>> That's why they fails to linking test.
>>
>> For -shared it should provide a crtbeginS.o then.  Why not fix it
>> properly?
>>
>> Richard.
>
>
> That's the case for linux toolchain. Multiple versions of startfile are
> generated.
> crtbegin.o, crtbeginS.o, crtbeginT.o etc.
>
> If I understand it correctly, this is not applicable to bare-metal
> tool-chain?
> Because, normally bare-metal toolchain will not be used to create shared
> object.
>
> I have double checked, almost all bare-metal toolchain only requires
> crtbegin.o.
> The targets define STARTFILE_SPEC in a simple way.

So why do they advertise hey can handle 'shared' then?

> The failures here are complaining creating shared object including
> statically generated object.
> The code in start files is not used or interact with the test cases.
> So I think it's reasonable to use "-nostdlib" to exclude standard startup
> file or libraries when testing the linking.
>
> Certainly, we can skip the test cases for bare-metal toolchain.
> However, as explained above, it seems this support checker is not fully
> capable to do this.
> /* { dg-require-effective-target shared } */

Then it should be fixed.

Richard.

> Regards,
> Renlin
>
>
>
>
>>
>>> Will adding "-nostdlib" (instead of replace -shared) option be an
>>> reasonable
>>> fix given my previous check?
>>>
>>> Regards,
>>> Renlin
>>>
>>>
>>>
>>>> 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.
>>>>>>>>>
>