Port objtool and the klp-build tooling (for building livepatch modules)
to arm64.
Note this doesn't bring all the objtool bells and whistles to arm64, nor
any of the CFG reverse engineering. This only adds the bare minimum
needed for 'objtool --checksum'.
And note that objtool still doesn't get enabled at all for normal arm64
kernel builds, so this doesn't affect any users other than those running
klp-build directly.
Josh Poimboeuf (14):
objtool: Fix data alignment in elf_add_data()
objtool: Fix ERROR_INSN() error message
arm64: Annotate intra-function calls
arm64: head: Move boot header to .head.data
arm64: Fix EFI linking with -fdata-sections
crypto: arm64: Move data to .rodata
objtool: Extricate checksum calculation from validate_branch()
objtool: Allow setting --mnop without --mcount
kbuild: Only run objtool if there is at least one command
objtool: Ignore jumps to the end of the function for non-CFG arches
objtool: Allow empty alternatives
objtool: Reuse consecutive string references
objtool: Introduce objtool for arm64
klp-build: Support cross-compilation
arch/arm64/Kconfig | 2 +
arch/arm64/kernel/entry.S | 2 +
arch/arm64/kernel/head.S | 2 +-
arch/arm64/kernel/proton-pack.c | 12 +-
arch/arm64/kernel/vmlinux.lds.S | 2 +-
arch/x86/boot/startup/Makefile | 2 +-
include/asm-generic/vmlinux.lds.h | 2 +-
include/linux/init.h | 1 +
lib/crypto/arm64/sha2-armv8.pl | 11 +-
scripts/Makefile.build | 4 +-
scripts/Makefile.lib | 46 +++----
scripts/Makefile.vmlinux_o | 15 +--
scripts/livepatch/klp-build | 11 +-
tools/objtool/Makefile | 4 +
tools/objtool/arch/arm64/Build | 2 +
tools/objtool/arch/arm64/decode.c | 116 ++++++++++++++++++
.../arch/arm64/include/arch/cfi_regs.h | 11 ++
tools/objtool/arch/arm64/include/arch/elf.h | 13 ++
.../objtool/arch/arm64/include/arch/special.h | 21 ++++
tools/objtool/arch/arm64/special.c | 21 ++++
tools/objtool/builtin-check.c | 5 -
tools/objtool/check.c | 83 +++++++++----
tools/objtool/elf.c | 11 +-
tools/objtool/include/objtool/checksum.h | 6 +-
tools/objtool/include/objtool/warn.h | 2 +-
25 files changed, 323 insertions(+), 84 deletions(-)
create mode 100644 tools/objtool/arch/arm64/Build
create mode 100644 tools/objtool/arch/arm64/decode.c
create mode 100644 tools/objtool/arch/arm64/include/arch/cfi_regs.h
create mode 100644 tools/objtool/arch/arm64/include/arch/elf.h
create mode 100644 tools/objtool/arch/arm64/include/arch/special.h
create mode 100644 tools/objtool/arch/arm64/special.c
--
2.53.0
Any data added to a section needs to be aligned in accordance with the
section's sh_addralign value. Particularly strings added to a .str1.8
section. Otherwise you may get some funky strings.
Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files")
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
tools/objtool/elf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The arm64 boot header is mostly data. Move it to a data section to
prevent objtool and other tools from trying to disassemble it. The
final linked result is the same.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
arch/arm64/kernel/head.S | 2 +-
include/asm-generic/vmlinux.lds.h | 2 +-
include/linux/init.h | 1 +
3 files changed, 3 insertions(+), 2 deletions(-)
@@ -663,7 +663,7 @@__static_call_text_end=.;/* Section used for early init (in .S files) */-#define HEAD_TEXT KEEP(*(.head.text))+#define HEAD_TEXT KEEP(*(.head.data .head.text))#define HEAD_TEXT_SECTION \.head.text:AT(ADDR(.head.text)-LOAD_OFFSET){\
When building with func-fdata-sections, the .init.bss section gets split
up into a bunch of .init.bss.<var> sections. Make sure they get linked
into .init.data.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
arch/arm64/kernel/vmlinux.lds.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Data embedded in .text pollutes i-cache and confuses objtool and other
tools that try to disassemble it. Move it to .rodata.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
lib/crypto/arm64/sha2-armv8.pl | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
In preparation for porting the checksum code to other arches, make its
functionality independent from validate_branch().
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
tools/objtool/check.c | 71 +++++++++++++++++-------
tools/objtool/include/objtool/checksum.h | 6 +-
2 files changed, 53 insertions(+), 24 deletions(-)
@@ -4012,9 +4058,6 @@ static int do_validate_branch(struct objtool_file *file, struct symbol *func,insn->trace=0;next_insn=next_insn_to_validate(file,insn);-if(opts.checksum&&func&&insn->sec)-checksum_update_insn(file,func,insn);-if(func&&insn_func(insn)&&func!=insn_func(insn)->pfunc){/* Ignore KCFI type preambles, which always fall through */if(is_prefix_func(func))
@@ -4080,9 +4123,6 @@ static int validate_unwind_hint(struct objtool_file *file,structsymbol*func=insn_func(insn);intret;-if(opts.checksum)-checksum_init(func);-ret=validate_branch(file,func,insn,*state);if(ret)BT_INSN(insn,"<=== (hint)");
Instead of returning an error for --mnop without --mcount, just silently
ignore it. This will help simplify kbuild's handling of objtool args.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
tools/objtool/builtin-check.c | 5 -----
1 file changed, 5 deletions(-)
Split the objtool args into commands and options, such that if no
commands have been enabled, objtool doesn't run.
This is in preparation in enabling objtool and klp-build for arm64.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
arch/x86/boot/startup/Makefile | 2 +-
scripts/Makefile.build | 4 +--
scripts/Makefile.lib | 46 ++++++++++++++++++----------------
scripts/Makefile.vmlinux_o | 15 ++++-------
4 files changed, 33 insertions(+), 34 deletions(-)
@@ -36,7 +36,7 @@ $(patsubst %.o,$(obj)/%.o,$(lib-y)): OBJECT_FILES_NON_STANDARD := y# relocations, even if other objtool actions are being deferred.#$(pi-objs):objtool-enabled = 1-$(pi-objs):objtool-args = $(if$(delay-objtool),--dry-run,$(objtool-args-y)) --noabs+$(pi-objs):objtool-args = $(if$(delay-objtool),--dry-run,$(objtool-cmds-y)$(objtool-opts-y)) --noabs## Confine the startup code by prefixing all symbols with __pi_ (for position
@@ -36,18 +36,13 @@ endif# For !delay-objtool + CONFIG_NOINSTR_VALIDATION, it runs on both translation# units and vmlinux.o, with the latter only used for noinstr/unret validation.-objtool-enabled:=$(or$(delay-objtool),$(CONFIG_NOINSTR_VALIDATION))--ifeq ($(delay-objtool),y)-vmlinux-objtool-args-y+=$(objtool-args-y)-else-vmlinux-objtool-args-$(CONFIG_OBJTOOL_WERROR)+=--werror+ifneq ($(delay-objtool),y)+objtool-cmds-y=+objtool-opts-y+=--linkendif-vmlinux-objtool-args-$(CONFIG_NOINSTR_VALIDATION)+=--noinstr\-$(if$(or$(CONFIG_MITIGATION_UNRET_ENTRY),$(CONFIG_MITIGATION_SRSO)),--unret)--objtool-args=$(vmlinux-objtool-args-y)--link+objtool-cmds-$(CONFIG_NOINSTR_VALIDATION)+=--noinstr\+$(if$(or$(CONFIG_MITIGATION_UNRET_ENTRY),$(CONFIG_MITIGATION_SRSO)),--unret)# Link of vmlinux.o used for section mismatch analysis# ---------------------------------------------------------------------------
Sometimes Clang arm64 code jumps to the end of the function for UB.
No need to make that an error, arm64 doesn't reverse engineer the CFG
anyway.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
tools/objtool/check.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
@@ -1630,10 +1630,12 @@ static int add_jump_destinations(struct objtool_file *file)/**GCOV/KCOVdeadcodecanjumptotheendof*thefunction/section.+*+*Clangonarm64alsodoesthissometimesfor+*undefinedbehavior.*/-if(file->ignore_unreachables&&func&&-dest_sec==insn->sec&&-dest_off==func->offset+func->len)+if((file->ignore_unreachables||(!opts.stackval&&!opts.orc))&&+func&&dest_sec==insn->sec&&dest_off==func->offset+func->len)continue;ERROR_INSN(insn,"can't find jump dest instruction at %s",
For duplicate strings, elf_add_string() just blindly adds duplicates.
That can be a problem for arm64 which often uses two consecutive
instructions (and corresponding relocations) to put an address into a
register, like:
d8: 90000001 adrp x1, 0 <meminfo_proc_show> d8: R_AARCH64_ADR_PREL_PG_HI21 .rodata.meminfo_proc_show.str1.8
dc: 91000021 add x1, x1, #0x0 dc: R_AARCH64_ADD_ABS_LO12_NC .rodata.meminfo_proc_show.str1.8
Referencing two different string addresses in the adrp+add pair can
result in a corrupt string addresses. Detect such consecutive reuses
and force them to use the same string.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
tools/objtool/elf.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
Add support for cross-compilation. The user must export ARCH, and
either CROSS_COMPILE or LLVM.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
scripts/livepatch/klp-build | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
On Tue, Mar 10, 2026 at 11:47:41AM +0100, Miroslav Benes wrote:
Hi,
quoted
@@ -3691,9 +3691,30 @@ static void checksum_update_insn(struct objtool_file *file, struct symbol *func, struct instruction *insn) { struct reloc *reloc = insn_reloc(file, insn);+ struct alternative *alt; unsigned long offset; struct symbol *sym;+ for (alt = insn->alts; alt; alt = alt->next) {+ struct alt_group *alt_group = alt->insn->alt_group;++ checksum_update(func, insn, &alt->type, sizeof(alt->type));++ if (alt_group && alt_group->orig_group) {+ struct instruction *alt_insn;++ checksum_update(func, insn, &alt_group->feature, sizeof(alt_group->feature));++ for (alt_insn = alt->insn; alt_insn; alt_insn = next_insn_same_sec(file, alt_insn)) {+ checksum_update_insn(file, func, alt_insn);+ if (alt_insn == alt_group->last_insn)+ break;+ }+ } else {+ checksum_update(func, insn, &alt->insn->offset, sizeof(alt->insn->offset));+ }+ }+
does this hunk belong to the patch? Unless I am missing something, it
might be worth a separate one.
It belongs, but I should have clarified that in the patch description.
This hunk wasn't needed before because validate_branch() already
iterates all the alternatives, so it was calling checksum_update_insn()
for every instruction in the function, including the alternatives.
Now that it's no longer called by validate_branch(),
checksum_update_insn() has to manually iterate the alternatives.
--
Josh
From: Miroslav Benes <mbenes@suse.cz> Date: 2026-03-11 08:24:24
On Tue, 10 Mar 2026, Josh Poimboeuf wrote:
On Tue, Mar 10, 2026 at 11:47:41AM +0100, Miroslav Benes wrote:
quoted
Hi,
quoted
@@ -3691,9 +3691,30 @@ static void checksum_update_insn(struct objtool_file *file, struct symbol *func, struct instruction *insn) { struct reloc *reloc = insn_reloc(file, insn);+ struct alternative *alt; unsigned long offset; struct symbol *sym;+ for (alt = insn->alts; alt; alt = alt->next) {+ struct alt_group *alt_group = alt->insn->alt_group;++ checksum_update(func, insn, &alt->type, sizeof(alt->type));++ if (alt_group && alt_group->orig_group) {+ struct instruction *alt_insn;++ checksum_update(func, insn, &alt_group->feature, sizeof(alt_group->feature));++ for (alt_insn = alt->insn; alt_insn; alt_insn = next_insn_same_sec(file, alt_insn)) {+ checksum_update_insn(file, func, alt_insn);+ if (alt_insn == alt_group->last_insn)+ break;+ }+ } else {+ checksum_update(func, insn, &alt->insn->offset, sizeof(alt->insn->offset));+ }+ }+
does this hunk belong to the patch? Unless I am missing something, it
might be worth a separate one.
It belongs, but I should have clarified that in the patch description.
This hunk wasn't needed before because validate_branch() already
iterates all the alternatives, so it was calling checksum_update_insn()
for every instruction in the function, including the alternatives.
Now that it's no longer called by validate_branch(),
checksum_update_insn() has to manually iterate the alternatives.
After writing the email I had a suspicion it must have been something like
above but failed to find it. Now I see that next_insn_to_validate() called
in do_validate_branch() handles exactly that. Thanks for the pointer. The
patch looks good to me then (and the rest as well as far as I can judge).
I must admit that objtool has gotten so complex that I have a hard time to
track everything in the code :).
Regards
Miroslav
From: Song Liu <song@kernel.org> Date: 2026-03-11 23:12:48
On Wed, Mar 4, 2026 at 7:31 PM Josh Poimboeuf [off-list ref] wrote:
The arm64 boot header is mostly data. Move it to a data section to
prevent objtool and other tools from trying to disassemble it. The
final linked result is the same.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
From: Song Liu <song@kernel.org> Date: 2026-03-11 23:13:09
On Wed, Mar 4, 2026 at 7:31 PM Josh Poimboeuf [off-list ref] wrote:
When building with func-fdata-sections, the .init.bss section gets split
up into a bunch of .init.bss.<var> sections. Make sure they get linked
into .init.data.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
From: Song Liu <song@kernel.org> Date: 2026-03-11 23:13:43
On Wed, Mar 4, 2026 at 7:31 PM Josh Poimboeuf [off-list ref] wrote:
Instead of returning an error for --mnop without --mcount, just silently
ignore it. This will help simplify kbuild's handling of objtool args.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
From: Song Liu <song@kernel.org> Date: 2026-03-11 23:14:49
On Wed, Mar 4, 2026 at 7:31 PM Josh Poimboeuf [off-list ref] wrote:
Sometimes Clang arm64 code jumps to the end of the function for UB.
No need to make that an error, arm64 doesn't reverse engineer the CFG
anyway.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
From: Song Liu <song@kernel.org> Date: 2026-03-11 23:15:41
On Wed, Mar 4, 2026 at 7:31 PM Josh Poimboeuf [off-list ref] wrote:
For duplicate strings, elf_add_string() just blindly adds duplicates.
That can be a problem for arm64 which often uses two consecutive
instructions (and corresponding relocations) to put an address into a
register, like:
d8: 90000001 adrp x1, 0 <meminfo_proc_show> d8: R_AARCH64_ADR_PREL_PG_HI21 .rodata.meminfo_proc_show.str1.8
dc: 91000021 add x1, x1, #0x0 dc: R_AARCH64_ADD_ABS_LO12_NC .rodata.meminfo_proc_show.str1.8
Referencing two different string addresses in the adrp+add pair can
result in a corrupt string addresses. Detect such consecutive reuses
and force them to use the same string.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
From: Song Liu <song@kernel.org> Date: 2026-03-11 23:18:53
On Wed, Mar 4, 2026 at 7:32 PM Josh Poimboeuf [off-list ref] wrote:
quoted hunk
Add support for cross-compilation. The user must export ARCH, and
either CROSS_COMPILE or LLVM.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
scripts/livepatch/klp-build | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
From: Song Liu <song@kernel.org> Date: 2026-03-11 23:23:54
On Wed, Mar 4, 2026 at 7:31 PM Josh Poimboeuf [off-list ref] wrote:
Port objtool and the klp-build tooling (for building livepatch modules)
to arm64.
Note this doesn't bring all the objtool bells and whistles to arm64, nor
any of the CFG reverse engineering. This only adds the bare minimum
needed for 'objtool --checksum'.
And note that objtool still doesn't get enabled at all for normal arm64
kernel builds, so this doesn't affect any users other than those running
klp-build directly.
On Wed, Mar 04, 2026 at 07:31:28PM -0800, Josh Poimboeuf wrote:
Split the objtool args into commands and options, such that if no
commands have been enabled, objtool doesn't run.
This is in preparation in enabling objtool and klp-build for arm64.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
I assume this will go with the rest of the series.
@@ -36,7 +36,7 @@ $(patsubst %.o,$(obj)/%.o,$(lib-y)): OBJECT_FILES_NON_STANDARD := y# relocations, even if other objtool actions are being deferred.#$(pi-objs):objtool-enabled = 1-$(pi-objs):objtool-args = $(if$(delay-objtool),--dry-run,$(objtool-args-y)) --noabs+$(pi-objs):objtool-args = $(if$(delay-objtool),--dry-run,$(objtool-cmds-y)$(objtool-opts-y)) --noabs## Confine the startup code by prefixing all symbols with __pi_ (for position
@@ -36,18 +36,13 @@ endif# For !delay-objtool + CONFIG_NOINSTR_VALIDATION, it runs on both translation# units and vmlinux.o, with the latter only used for noinstr/unret validation.-objtool-enabled:=$(or$(delay-objtool),$(CONFIG_NOINSTR_VALIDATION))--ifeq ($(delay-objtool),y)-vmlinux-objtool-args-y+=$(objtool-args-y)-else-vmlinux-objtool-args-$(CONFIG_OBJTOOL_WERROR)+=--werror+ifneq ($(delay-objtool),y)+objtool-cmds-y=+objtool-opts-y+=--linkendif-vmlinux-objtool-args-$(CONFIG_NOINSTR_VALIDATION)+=--noinstr\-$(if$(or$(CONFIG_MITIGATION_UNRET_ENTRY),$(CONFIG_MITIGATION_SRSO)),--unret)--objtool-args=$(vmlinux-objtool-args-y)--link+objtool-cmds-$(CONFIG_NOINSTR_VALIDATION)+=--noinstr\+$(if$(or$(CONFIG_MITIGATION_UNRET_ENTRY),$(CONFIG_MITIGATION_SRSO)),--unret)# Link of vmlinux.o used for section mismatch analysis# ---------------------------------------------------------------------------
On Wed, Mar 11, 2026 at 04:18:40PM -0700, Song Liu wrote:
On Wed, Mar 4, 2026 at 7:32 PM Josh Poimboeuf [off-list ref] wrote:
quoted
Add support for cross-compilation. The user must export ARCH, and
either CROSS_COMPILE or LLVM.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
scripts/livepatch/klp-build | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
On Wed, Mar 11, 2026 at 09:24:22AM +0100, Miroslav Benes wrote:
On Tue, 10 Mar 2026, Josh Poimboeuf wrote:
quoted
On Tue, Mar 10, 2026 at 11:47:41AM +0100, Miroslav Benes wrote:
quoted
Hi,
quoted
@@ -3691,9 +3691,30 @@ static void checksum_update_insn(struct objtool_file *file, struct symbol *func, struct instruction *insn) { struct reloc *reloc = insn_reloc(file, insn);+ struct alternative *alt; unsigned long offset; struct symbol *sym;+ for (alt = insn->alts; alt; alt = alt->next) {+ struct alt_group *alt_group = alt->insn->alt_group;++ checksum_update(func, insn, &alt->type, sizeof(alt->type));++ if (alt_group && alt_group->orig_group) {+ struct instruction *alt_insn;++ checksum_update(func, insn, &alt_group->feature, sizeof(alt_group->feature));++ for (alt_insn = alt->insn; alt_insn; alt_insn = next_insn_same_sec(file, alt_insn)) {+ checksum_update_insn(file, func, alt_insn);+ if (alt_insn == alt_group->last_insn)+ break;+ }+ } else {+ checksum_update(func, insn, &alt->insn->offset, sizeof(alt->insn->offset));+ }+ }+
does this hunk belong to the patch? Unless I am missing something, it
might be worth a separate one.
It belongs, but I should have clarified that in the patch description.
This hunk wasn't needed before because validate_branch() already
iterates all the alternatives, so it was calling checksum_update_insn()
for every instruction in the function, including the alternatives.
Now that it's no longer called by validate_branch(),
checksum_update_insn() has to manually iterate the alternatives.
After writing the email I had a suspicion it must have been something like
above but failed to find it. Now I see that next_insn_to_validate() called
in do_validate_branch() handles exactly that. Thanks for the pointer. The
patch looks good to me then (and the rest as well as far as I can judge).
Actually, next_insn_to_validate() helps with an edge case for directing
code flow from the end of an alternative back to the original code.
The code which traverses the alternatives is in validate_insn():
if (insn->alts) {
for (alt = insn->alts; alt; alt = alt->next) {
TRACE_ALT_BEGIN(insn, alt, alt_name);
ret = validate_branch(file, func, alt->insn, *statep);
TRACE_ALT_END(insn, alt, alt_name);
if (ret) {
BT_INSN(insn, "(alt)");
return ret;
}
}
TRACE_ALT_INFO_NOADDR(insn, "/ ", "DEFAULT");
}
I must admit that objtool has gotten so complex that I have a hard time to
track everything in the code :).
The code hasn't changed *too* much, it's just that validate_branch() got
split up more when the tracing code went in, so things are organized a
bit differently. Most of that code is now in validate_insn().
--
Josh
On Mon, Mar 16, 2026 at 12:15:28PM -0700, Josh Poimboeuf wrote:
On Wed, Mar 11, 2026 at 04:18:40PM -0700, Song Liu wrote:
quoted
On Wed, Mar 4, 2026 at 7:32 PM Josh Poimboeuf [off-list ref] wrote:
quoted
Add support for cross-compilation. The user must export ARCH, and
either CROSS_COMPILE or LLVM.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
scripts/livepatch/klp-build | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
Shall we show a specific warning if
- ARCH is set; and
- ARCH is not the same as (uname -m); and
- neither LLVM nor CROSS_COMPILE is set.
Yeah, I think that would be a good idea. Will do that for v2.
So, in general ARCH is complicated. For example:
- ARCH=arm64 would never match "uname -m" (aarch64)
- ARCH=i386 would use the same gcc binary (no cross-compiler needed)
- I'm sure there are many other edge cases...
Instead of a manual error, it may be simpler to just let the build fail
naturally if the user doesn't set the right ARCH.
Though, I think the check can be improved slightly, as ARCH is a
reasonably good indicator that cross-compiling is happening. So I can
at least add an ARCH check at the beginning like so?
cross_compile_init() {
if [[ ! -v ARCH ]]; then
OBJCOPY=objcopy
return 0
fi
if [[ -v LLVM ]]; then
OBJCOPY=llvm-objcopy
else
OBJCOPY="${CROSS_COMPILE:-}objcopy"
fi
}
--
Josh
From: Song Liu <song@kernel.org> Date: 2026-03-17 18:21:55
On Tue, Mar 17, 2026 at 10:52 AM Josh Poimboeuf [off-list ref] wrote:
[...]
quoted
Yeah, I think that would be a good idea. Will do that for v2.
So, in general ARCH is complicated. For example:
- ARCH=arm64 would never match "uname -m" (aarch64)
- ARCH=i386 would use the same gcc binary (no cross-compiler needed)
- I'm sure there are many other edge cases...
Agreed. I haven't worked with i386 for a long time, but I did notice
the arm64 vs. aarch64 difference.
Instead of a manual error, it may be simpler to just let the build fail
naturally if the user doesn't set the right ARCH.
Though, I think the check can be improved slightly, as ARCH is a
reasonably good indicator that cross-compiling is happening. So I can
at least add an ARCH check at the beginning like so?
cross_compile_init() {
if [[ ! -v ARCH ]]; then
OBJCOPY=objcopy
return 0
fi
if [[ -v LLVM ]]; then
OBJCOPY=llvm-objcopy
else
OBJCOPY="${CROSS_COMPILE:-}objcopy"
fi
}
Do we need ARCH when CROSS_COMPILE is set? I was
under the impression that CROSS_COMPILE doesn't require
ARCH.
Thanks,
Song
On Tue, Mar 17, 2026 at 11:21:43AM -0700, Song Liu wrote:
On Tue, Mar 17, 2026 at 10:52 AM Josh Poimboeuf [off-list ref] wrote:
[...]
quoted
quoted
Yeah, I think that would be a good idea. Will do that for v2.
So, in general ARCH is complicated. For example:
- ARCH=arm64 would never match "uname -m" (aarch64)
- ARCH=i386 would use the same gcc binary (no cross-compiler needed)
- I'm sure there are many other edge cases...
Agreed. I haven't worked with i386 for a long time, but I did notice
the arm64 vs. aarch64 difference.
quoted
Instead of a manual error, it may be simpler to just let the build fail
naturally if the user doesn't set the right ARCH.
Though, I think the check can be improved slightly, as ARCH is a
reasonably good indicator that cross-compiling is happening. So I can
at least add an ARCH check at the beginning like so?
cross_compile_init() {
if [[ ! -v ARCH ]]; then
OBJCOPY=objcopy
return 0
fi
if [[ -v LLVM ]]; then
OBJCOPY=llvm-objcopy
else
OBJCOPY="${CROSS_COMPILE:-}objcopy"
fi
}
Do we need ARCH when CROSS_COMPILE is set? I was
under the impression that CROSS_COMPILE doesn't require
ARCH.
If CROSS_COMPILE is used without ARCH, it will just try to use the host
arch. I'm not sure if that's considered cross-compiling? I suppose it
should use the CROSS_COMPILE version of objcopy in that case? Though in
practice it probably doesn't matter.
I guess the original version of the function is probably fine and we
don't need to complicate matters.
--
Josh
From: Song Liu <song@kernel.org> Date: 2026-03-17 18:58:33
On Tue, Mar 17, 2026 at 11:53 AM Josh Poimboeuf [off-list ref] wrote:
[...]
quoted
Do we need ARCH when CROSS_COMPILE is set? I was
under the impression that CROSS_COMPILE doesn't require
ARCH.
If CROSS_COMPILE is used without ARCH, it will just try to use the host
arch. I'm not sure if that's considered cross-compiling? I suppose it
should use the CROSS_COMPILE version of objcopy in that case? Though in
practice it probably doesn't matter.
I guess the original version of the function is probably fine and we
don't need to complicate matters.
Agreed that the original version works fine. Thanks for bearing with my
nitpick on this.
Song