linux.git/tools/objtool/Makefile, branch master

Merge tag 'objtool-urgent-2026-03-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2026-03-15T17:36:01+00:00

Pull objtool fixes from Ingo Molnar:

 - Fix cross-build bug by using HOSTCFLAGS for HAVE_XXHASH test

 - Fix klp bug by fixing detection of corrupt static branch/call entries

 - Handle unsupported pr_debug() usage more gracefully

 - Fix hypothetical klp bug by avoiding NULL pointer dereference when
   printing code symbol name

 - Fix data alignment bug in elf_add_data() causing mangled strings

 - Fix confusing ERROR_INSN() error message

 - Handle unexpected Clang RSP musical chairs causing false positive
   warnings

 - Fix another objtool stack overflow in validate_branch()

* tag 'objtool-urgent-2026-03-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  objtool: Fix another stack overflow in validate_branch()
  objtool: Handle Clang RSP musical chairs
  objtool: Fix ERROR_INSN() error message
  objtool: Fix data alignment in elf_add_data()
  objtool: Use HOSTCFLAGS for HAVE_XXHASH test
  objtool/klp: Avoid NULL pointer dereference when printing code symbol name
  objtool/klp: Disable unsupported pr_debug() usage
  objtool/klp: Fix detection of corrupt static branch/call entries

objtool: Use HOSTCFLAGS for HAVE_XXHASH test

2026-03-06T15:48:41+00:00

Previously, HAVE_XXHASH is tested by invoking HOSTCC without HOSTCFLAGS.

Consider the following scenario:

- The host machine has libxxhash installed
- We build the kernel with HOSTCFLAGS containing a --sysroot that does
  not have xxhash.h (for hermetic builds)

In this case, HAVE_XXHASH is set to y, but when it builds objtool with
HOSTCFLAGS, because the --sysroot does not contain xxhash.h, the
following error is raised:

<...>/common/tools/objtool/include/objtool/checksum_types.h:12:10: fatal error: 'xxhash.h' file not found
   12 | #include 
      |          ^~~~~~~~~~

To resolve the error, we test HAVE_XXHASH by invoking HOSTCC with
HOSTCFLAGS.

Signed-off-by: HONG Yifan 
Reviewed-by: Carlos Llamas 
Link: https://patch.msgid.link/20260303010340.306164-1-elsk@google.com
Signed-off-by: Josh Poimboeuf

kbuild: Leave objtool binary around with 'make clean'

2026-03-02T21:22:39+00:00

The difference between 'make clean' and 'make mrproper' is documented in
'make help' as:

  clean     - Remove most generated files but keep the config and
              enough build support to build external modules
  mrproper  - Remove all generated files + config + various backup files

After commit 68b4fe32d737 ("kbuild: Add objtool to top-level clean
target"), running 'make clean' then attempting to build an external
module with the resulting build directory fails with

  $ make ARCH=x86_64 O=build clean

  $ make -C build M=... MO=...
  ...
  /bin/sh: line 1: .../build/tools/objtool/objtool: No such file or directory

as 'make clean' removes the objtool binary.

Split the objtool clean target into mrproper and clean like Kbuild does
and remove all generated artifacts with 'make clean' except for the
objtool binary, which is removed with 'make mrproper'. To avoid a small
race when running the objtool clean target through both objtool_mrproper
and objtool_clean when running 'make mrproper', modify objtool's clean
up find command to avoid using find's '-delete' command by piping the
files into 'xargs rm -f' like the rest of Kbuild does.

Cc: stable@vger.kernel.org
Fixes: 68b4fe32d737 ("kbuild: Add objtool to top-level clean target")
Reported-by: Michal Suchanek 
Closes: https://lore.kernel.org/20260225112633.6123-1-msuchanek@suse.de/
Reported-by: Rainer Fiebig 
Closes: https://lore.kernel.org/62d12399-76e5-3d40-126a-7490b4795b17@mailbox.org/
Acked-by: Josh Poimboeuf 
Acked-by: Peter Zijlstra (Intel) 
Reviewed-by: Nicolas Schier 
Tested-by: Nicolas Schier 
Link: https://patch.msgid.link/20260227-avoid-objtool-binary-removal-clean-v1-1-122f3e55eae9@kernel.org
Signed-off-by: Nathan Chancellor

kbuild: Add objtool to top-level clean target

2026-02-12T16:30:20+00:00

Objtool is an integral part of the build, make sure it gets cleaned by
"make clean" and "make mrproper".

Fixes: 442f04c34a1a ("objtool: Add tool to perform compile-time stack metadata validation")
Reported-by: Jens Remus 
Closes: https://lore.kernel.org/15f2af3b-be33-46fc-b972-6b8e7e0aa52e@linux.ibm.com
Signed-off-by: Josh Poimboeuf 
Tested-by: Jens Remus 
Link: https://patch.msgid.link/968faf2ed30fa8b3519f79f01a1ecfe7929553e5.1770759919.git.jpoimboe@kernel.org
[nathan: use Closes: instead of Link: per checkpatch.pl]
Signed-off-by: Nathan Chancellor

objtool: Fix libopcodes linking with static libraries

2026-01-21T19:25:14+00:00

Commit 436326bc525d ("objtool: fix build failure due to missing libopcodes
check") tests for libopcodes using an empty main(), which passes even when
static libraries lack their dependencies. This causes undefined reference
errors (xmalloc, bfd_get_bits, etc.) when linking against static libopcodes
without its required libbfd and libiberty.

Fix by testing with an actual libopcodes symbol and trying increasingly
complete library combinations until one succeeds.

Fixes: 436326bc525d ("objtool: fix build failure due to missing libopcodes check")
Reported-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin 
Signed-off-by: Peter Zijlstra (Intel) 
Tested-by: Rafael J. Wysocki (Intel) 
Link: https://patch.msgid.link/20260121162532.1596238-1-sashal@kernel.org

objtool: fix build failure due to missing libopcodes check

2026-01-13T10:37:51+00:00

Commit 59953303827e ("objtool: Disassemble code with libopcodes instead
of running objdump") added support for using libopcodes for disassembly.
However, the feature detection checks for libbfd availability but then
unconditionally links against libopcodes:

  ifeq ($(feature-libbfd),1)
      OBJTOOL_LDFLAGS += -lopcodes
  endif

This causes build failures in environments where libbfd is installed but
libopcodes is not, since the test-libbfd.c feature test only links
against -lbfd and -ldl, not -lopcodes:

  /usr/bin/ld: cannot find -lopcodes: No such file or directory
  collect2: error: ld returned 1 exit status
  make[4]: *** [Makefile:109: objtool] Error 1

Additionally, the shared feature framework uses $(CC) which is the
cross-compiler in cross-compilation builds. Since objtool is a host tool
that links with $(HOSTCC) against host libraries, the feature detection
can falsely report libopcodes as available when the cross-compiler's
sysroot has it but the host system doesn't.

Fix this by replacing the feature framework check with a direct inline
test that uses $(HOSTCC) to compile and link a test program against
libopcodes, similar to how xxhash availability is detected.

Fixes: 59953303827e ("objtool: Disassemble code with libopcodes instead of running objdump")
Assisted-by: claude-opus-4-5-20251101
Signed-off-by: Sasha Levin 
Signed-off-by: Peter Zijlstra (Intel) 
Link: https://patch.msgid.link/20251223120357.2492008-1-sashal@kernel.org

objtool: Build with disassembly can fail when including bdf.h

2025-11-27T08:32:46+00:00

Building objtool with disassembly support can fail when including
the bdf.h file:

  In file included from tools/objtool/include/objtool/arch.h:108,
                   from check.c:14:
  /usr/include/bfd.h:35:2: error: #error config.h must be included before this header
     35 | #error config.h must be included before this header
        |  ^~~~~

This check is present in the bfd.h file generated from the binutils
source code, but it is not necessarily present in the bfd.h file
provided in a binutil package (for example, it is not present in
the binutil RPM).

The solution to this issue is to define the PACKAGE macro before
including bfd.h. This is the solution suggested by the binutil
developer in bug 14243, and it is used by other kernel tools
which also use bfd.h (perf and bpf).

Fixes: 59953303827ec ("objtool: Disassemble code with libopcodes instead of running objdump")
Closes: https://lore.kernel.org/all/3fa261fd-3b46-4cbe-b48d-7503aabc96cb@oracle.com/
Reported-by: Nathan Chancellor 
Suggested-by: Nathan Chancellor 
Signed-off-by: Alexandre Chartre 
Signed-off-by: Peter Zijlstra (Intel) 
Link: https://sourceware.org/bugzilla/show_bug.cgi?id=14243
Link: https://patch.msgid.link/20251126134519.1760889-1-alexandre.chartre@oracle.com

objtool: Add Function to get the name of a CPU feature

2025-11-24T19:39:47+00:00

Add a function to get the name of a CPU feature. The function is
architecture dependent and currently only implemented for x86. The
feature names are automatically generated from the cpufeatures.h
include file.

Signed-off-by: Alexandre Chartre 
Signed-off-by: Peter Zijlstra (Intel) 
Acked-by: Josh Poimboeuf 
Link: https://patch.msgid.link/20251121095340.464045-27-alexandre.chartre@oracle.com

objtool: Disassemble code with libopcodes instead of running objdump

2025-11-21T14:30:07+00:00

objtool executes the objdump command to disassemble code. Use libopcodes
instead to have more control about the disassembly scope and output.
If libopcodes is not present then objtool is built without disassembly
support.

Signed-off-by: Alexandre Chartre 
Signed-off-by: Peter Zijlstra (Intel) 
Acked-by: Josh Poimboeuf 
Link: https://patch.msgid.link/20251121095340.464045-4-alexandre.chartre@oracle.com

objtool: Set minimum xxhash version to 0.8

2025-11-18T08:59:25+00:00

XXH3 is only supported starting with xxhash 0.8.  Enforce that.

Fixes: 0d83da43b1e1 ("objtool/klp: Add --checksum option to generate per-function checksums")
Closes: https://lore.kernel.org/SN6PR02MB41579B83CD295C9FEE40EED6D4FCA@SN6PR02MB4157.namprd02.prod.outlook.com
Reported-by: Michael Kelley 
Signed-off-by: Josh Poimboeuf 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Michael Kelley 
Tested-by: Michael Kelley 
Link: https://patch.msgid.link/7227c94692a3a51840278744c7af31b4797c6b96.1762990139.git.jpoimboe@kernel.org