| Message ID | 56D46E41.7090708@foss.arm.com |
|---|---|
| State | New |
| Headers | show |
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. 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. >
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 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. >>
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. > 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. >>> >
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. 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. >>>>
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. >>>>> >
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. 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. >>>>>>
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. > 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. >>>>>>> >
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. 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 } */ 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. >>>>>>>>
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. >>>>>>>>> >
diff --git a/gcc/testsuite/gcc.dg/lto/pr54709_0.c b/gcc/testsuite/gcc.dg/lto/pr54709_0.c index f3db5dc..12a10e0 100644 --- a/gcc/testsuite/gcc.dg/lto/pr54709_0.c +++ b/gcc/testsuite/gcc.dg/lto/pr54709_0.c @@ -1,7 +1,7 @@ /* { dg-lto-do link } */ /* { dg-require-visibility "hidden" } */ /* { dg-require-effective-target fpic } */ -/* { dg-extra-ld-options { -shared } } */ +/* { dg-extra-ld-options { -r -nostdlib } } */ /* { dg-lto-options { { -fPIC -fvisibility=hidden -flto } } } */ void foo (void *p, void *q, unsigned s) diff --git a/gcc/testsuite/gcc.dg/lto/pr61526_0.c b/gcc/testsuite/gcc.dg/lto/pr61526_0.c index 8a631f0..5e2f7acf 100644 --- a/gcc/testsuite/gcc.dg/lto/pr61526_0.c +++ b/gcc/testsuite/gcc.dg/lto/pr61526_0.c @@ -1,7 +1,7 @@ /* { dg-require-effective-target fpic } */ /* { dg-lto-do link } */ /* { dg-lto-options { { -fPIC -flto -flto-partition=1to1 } } } */ -/* { dg-extra-ld-options { -shared } } */ +/* { dg-extra-ld-options { -r -nostdlib } } */ static void *master; void *foo () { return master; } diff --git a/gcc/testsuite/gcc.dg/lto/pr64415_0.c b/gcc/testsuite/gcc.dg/lto/pr64415_0.c index 4faab2b..0f583a5 100644 --- a/gcc/testsuite/gcc.dg/lto/pr64415_0.c +++ b/gcc/testsuite/gcc.dg/lto/pr64415_0.c @@ -1,7 +1,7 @@ /* { dg-lto-do link } */ /* { dg-require-effective-target fpic } */ /* { dg-lto-options { { -O -flto -fpic } } } */ -/* { dg-extra-ld-options { -shared } } */ +/* { dg-extra-ld-options { -r -nostdlib } } */ /* { dg-extra-ld-options "-Wl,-undefined,dynamic_lookup" { target *-*-darwin* } } */ extern void bar(char *, int);