https://sourceware.org/bugzilla/show_bug.cgi?id=27217
Nick Clifton <nickc at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|RESOLVED |REOPENED
Last reconfirmed| |2021-03-29
Resolution|DUPLICATE |---
--- Comment #4 from Nick Clifton <nickc at redhat dot com> ---
(In reply to Joel Sherrill from comment #3)
Hi Joel,
> It changes the failure to one I've never see before. :)
>
> /home/opticron/rtems-development/tools/lib/gcc/aarch64-rtems6/10.2.1/../../..
> /../aarch64-rtems6/bin/ld: testsuites/sptests/spconfig01/init.c.568.o: in
> function `test_stack_config':
> /home/opticron/rtems-development/rtems/build/aarch64/xilinx_zynqmp_lp64_qemu/
> ../../../testsuites/sptests/spconfig01/init.c:95: undefined reference to `no
> symbol'
Ah- that should not happen. Your test case shows it too, although I only ever
assembled it, I did not try to link it. The reloc is for the ADRP
instruction's reference to the zero'ed "bar" symbol.
I am not sure of the best thing to do here. I am going to upload a patch that
stops the relocation from being generated, but that might not be the right
thing to do. Since the symbol has been, effectively, deleted, maybe generating
a linker error is correct.
> This PR is marked as resolved/duplicate but is that right?
Nope - that was a snafu. I am reopening the PR.
Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
