[Bug gas/27217] aarch64 as Internal error in md_apply_fix at ....../gas/config/tc-aarch64.c:8330.

[nickc at redhat dot com]

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.