Bug 27098 - aarch64 kernel fails to link due to the __patchable_function_entries changes
Summary: aarch64 kernel fails to link due to the __patchable_function_entries changes
Status: RESOLVED DUPLICATE of bug 26256
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.36
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-19 16:56 UTC by Jakub Jelinek
Modified: 2020-12-19 18:12 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jakub Jelinek 2020-12-19 16:56:31 UTC
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?
Comment 1 H.J. Lu 2020-12-19 18:12:57 UTC
Dup.

*** This bug has been marked as a duplicate of bug 26256 ***