From: Ard Biesheuvel <ardb@kernel.org>

Compiler emitted absolute references are often section-relative, as the
objects in question sometimes don't even exist in the C code (e.g., jump
tables) or have static linkage.

Enhance the diagnostic that is printed when detecting absolute
references in .head.text, but printing the addend of the symbol
reference, and the location in vmlinux where the reference can be found.

So instead of printing

  Absolute reference to symbol '.rodata' detected not permitted in .head.text

and failing the build, print the below but only as a warning.

  Absolute reference to symbol '.rodata+0x180' detected in .head.text (0xffffffff820cb4ba).
  This kernel may might not boot.

Not failing the build also works around the issue that the file vmlinux
will be deleted by make when an error occurs, which is not very helpful
in trying to narrow down the problem.

Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
 arch/x86/tools/relocs.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index e937be979ec8..134cf5cfe7bd 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -901,9 +901,10 @@ static int do_reloc64(struct section *sec, Elf_Rel *rel, ElfW(Sym) *sym,
 		}
 
 		if (headtext) {
-			die("Absolute reference to symbol '%s' not permitted in .head.text\n",
-			    symname);
-			break;
+			fprintf(stderr,
+				"Absolute reference to symbol '%s+0x%lx' detected in .head.text (0x%lx).\n"
+				"This kernel might not boot.\n",
+				symname, rel->r_addend, offset);
 		}
 
 		/*
-- 
2.48.1.262.g85cc9f2d1e-goog

On Mon, 27 Jan 2025 at 03:43, Ard Biesheuvel <ardb+git@google.com> wrote:
>
>   Absolute reference to symbol '.rodata+0x180' detected in .head.text (0xffffffff820cb4ba).

Do we have any symbol name lookup logic anywhere?

Because it would be much more helpful if it also printed out the
source symbol and target symbol name, not just the offsets in the
section..

Yes, with the offsets - and the lack of fatal error, so that the
vmlinux file stays around - you can now much more easily do some gdb
or objdump magic to then pinpoint what's up, but it still ends up
being very much a "you _really_ need to understand what's up" kind of
thing.

                  Linus

On Mon, 27 Jan 2025 at 17:57, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Mon, 27 Jan 2025 at 03:43, Ard Biesheuvel <ardb+git@google.com> wrote:
> >
> >   Absolute reference to symbol '.rodata+0x180' detected in .head.text (0xffffffff820cb4ba).
>
> Do we have any symbol name lookup logic anywhere?
>

I can look into that. In this particular case, though, there is no
symbol to look up as it is a anonymous jump table generated by the
compiler. And the function name would be inaccurate too, as
snp_cpuid_postprocess() got inlined into its caller. But I guess with
the right DWARF data, at least the call site could be narrowed down a
bit better.