[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug ld/27098] New: aarch64 kernel fails to link due to the __patchable_
From: |
jakub at redhat dot com |
Subject: |
[Bug ld/27098] New: aarch64 kernel fails to link due to the __patchable_function_entries changes |
Date: |
Sat, 19 Dec 2020 16:56:31 +0000 |
https://sourceware.org/bugzilla/show_bug.cgi?id=27098
Bug ID: 27098
Summary: aarch64 kernel fails to link due to the
__patchable_function_entries changes
Product: binutils
Version: 2.36 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: jakub at redhat dot com
Target Milestone: ---
Kernel built by gcc 11 latest snapshots configured against latest binutils
fails to link:
ld: .init.data has both ordered [`__patchable_function_entries' in init/main.o]
and unordered [`.init.data' in ./drivers/firmware/efi/libstub/vsprintf.stub.o]
sections
ld: final link failed: bad value
The problem is that gcc now uses SHF_LINK_ORDER for
__patchable_function_entries
sections, and the kernel linker script has:
.init.data : {
KEEP(*(SORT(___kentry+*))) *(.init.data init.data.*) . = ALIGN(8);
__start_mcount_loc = .; KEEP(*(__mcount_loc))
KEEP(*(__patchable_function_entries)) __stop_mcount_loc = .; ... }
Seems the linker refuses to put those SHF_LINK_ORDER input sections into the
same output section with non-SHF_LINK_ORDER sections.
I can understand this being a fatal error for relocatable links, but does
SHF_LINK_ORDER matter after final link of executable or shared library?
I mean, can't we just make the resulting section non-SHF_LINK_ORDER rather than
error?
Or is this a kernel bug?
--
You are receiving this mail because:
You are on the CC list for the bug.
- [Bug ld/27098] New: aarch64 kernel fails to link due to the __patchable_function_entries changes,
jakub at redhat dot com <=