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. > 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. >>> >
