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