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(-)
diff --git a/scripts/livepatch/klp-build b/scripts/livepatch/klp-build
index 809e198a561d..b6c057e2120f 100755
--- a/scripts/livepatch/klp-build
+++ b/scripts/livepatch/klp-build
@@ -404,6 +404,14 @@ validate_patches() {
revert_patches
}
+cross_compile_init() {
+ if [[ -v LLVM ]]; then
+ OBJCOPY=llvm-objcopy
+ else
+ OBJCOPY="${CROSS_COMPILE:-}objcopy"
+ fi
+}
+
do_init() {
# We're not yet smart enough to handle anything other than in-tree
# builds in pwd.
@@ -420,6 +428,7 @@ do_init() {
validate_config
set_module_name
set_kernelversion
+ cross_compile_init
}
# Refresh the patch hunk headers, specifically the line numbers and counts.
@@ -783,7 +792,7 @@ build_patch_module() {
cp -f "$kmod_file" "$kmod_file.orig"
# Work around issue where slight .config change makes corrupt BTF
- objcopy --remove-section=.BTF "$kmod_file"
+ "$OBJCOPY" --remove-section=.BTF "$kmod_file"
# Fix (and work around) linker wreckage for klp syms / relocs
"$SRC/tools/objtool/objtool" klp post-link "$kmod_file" || die "objtool klp post-link failed"
--
2.53.0
On Wed, Mar 4, 2026 at 7:32 PM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>
> 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(-)
>
> diff --git a/scripts/livepatch/klp-build b/scripts/livepatch/klp-build
> index 809e198a561d..b6c057e2120f 100755
> --- a/scripts/livepatch/klp-build
> +++ b/scripts/livepatch/klp-build
> @@ -404,6 +404,14 @@ validate_patches() {
> revert_patches
> }
>
> +cross_compile_init() {
> + if [[ -v LLVM ]]; then
> + OBJCOPY=llvm-objcopy
> + else
> + OBJCOPY="${CROSS_COMPILE:-}objcopy"
> + fi
> +}
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.
Thanks,
Song
On Wed, Mar 11, 2026 at 04:18:40PM -0700, Song Liu wrote:
> On Wed, Mar 4, 2026 at 7:32 PM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> >
> > 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(-)
> >
> > diff --git a/scripts/livepatch/klp-build b/scripts/livepatch/klp-build
> > index 809e198a561d..b6c057e2120f 100755
> > --- a/scripts/livepatch/klp-build
> > +++ b/scripts/livepatch/klp-build
> > @@ -404,6 +404,14 @@ validate_patches() {
> > revert_patches
> > }
> >
> > +cross_compile_init() {
> > + if [[ -v LLVM ]]; then
> > + OBJCOPY=llvm-objcopy
> > + else
> > + OBJCOPY="${CROSS_COMPILE:-}objcopy"
> > + fi
> > +}
>
> 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.
--
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:
> > On Wed, Mar 4, 2026 at 7:32 PM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> > >
> > > 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(-)
> > >
> > > diff --git a/scripts/livepatch/klp-build b/scripts/livepatch/klp-build
> > > index 809e198a561d..b6c057e2120f 100755
> > > --- a/scripts/livepatch/klp-build
> > > +++ b/scripts/livepatch/klp-build
> > > @@ -404,6 +404,14 @@ validate_patches() {
> > > revert_patches
> > > }
> > >
> > > +cross_compile_init() {
> > > + if [[ -v LLVM ]]; then
> > > + OBJCOPY=llvm-objcopy
> > > + else
> > > + OBJCOPY="${CROSS_COMPILE:-}objcopy"
> > > + fi
> > > +}
> >
> > 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
On Tue, Mar 17, 2026 at 10:52 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
[...]
> >
> > 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 <jpoimboe@kernel.org> wrote:
> [...]
> > >
> > > 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.
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
On Tue, Mar 17, 2026 at 11:53 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote: [...] > > > > 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
© 2016 - 2026 Red Hat, Inc.