On Thu, Mar 3, 2016 at 6:53 PM, Renlin Li <renlin...@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...@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...@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...@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...@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...@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. >>>>>>>>> >