-1

I am trying to compile a project on an aws t4g instance (arm graviton), and everything compiles, except a unit tests project, which dies with the following:

"internal error in update_erratum_insn, at ../../gold/aarch64.cc:1005"

ld.gold --version
GNU gold (GNU Binutils for Ubuntu 2.38) 1.16

I downloaded the ld.gold source, and the dying assert is:

gold_assert(Insn_utilities::aarch64_rd(insn) == Insn_utilities::aarch64_rd(this->erratum_insn()));

I have no idea what this means, and was unable to google it.

I compile an "usual" google test file, containing 5 tests. If I do even as much as replacing an ASSERT_EQ(a, b) with ASSERT_EQ(true, a == b) or ASSERT_TRUE(a == b), where a and b are int64_t. Delete any test, add any new test. Basically do anything that does not result in exactly the same code. So I can't write an example code. The same linking (and running) works with ld instead of ld.gold

What is the meaning of this assert?

Could this be a linker bug?

Zoltán Mártonka
  • 33
  • 4
  • "internal error" is a synonym for "linker / compiler bug" yes. Also note that binutils is up to 2.41. Your bug may already have been fixed. – Botje Aug 30 '23 at 19:33

1 Answers1

1

Yes, this looks like a bug in gold. At the point of the error, gold has created an erratum stub to workaround Cortex-A53 Erratum 834419, where an adrp instruction located in the last 8 bytes of a page may trigger a processor bug under certain other circumstances. It's trying to update the copy of the original instruction in the stub to match the relocated original instruction, but it discovered that the rd field of the original doesn't match the rd field of the copy. That shouldn't happen, but it's not immediately obvious to me what went wrong.

If you're not planning to use a Cortex-A53 processor, you could add -Wl,--no-fix-cortex-a53-843419 to your link options as a workaround.

Cary Coutant
  • 606
  • 3
  • 7