Re: [PATCH dwarves v2 0/2] dwarf_loader: Fix --lang_exclude on merged CUs

[Alan Maguire <almagui@kernel.org>]

> From: Alan Derk <linux@alanderk.com>
> To: Arnaldo Carvalho de Melo <acme@kernel.org>,
> 	Alan Maguire <alan.maguire@oracle.com>
> Cc: dwarves@vger.kernel.org,
> 	bpf@vger.kernel.org,
> 	rust-for-linux@vger.kernel.org
> Subject: [PATCH dwarves v2 0/2] dwarf_loader: Fix --lang_exclude on merged CUs
> Date: Sat, 10 Oct 2026 00:52:25 +0000
> Message-ID: <20261010005227.976-1-linux@alanderk.com>
> X-Mailer: git-send-email 2.55.0
> Precedence: bulk
> X-Mailing-List: dwarves@vger.kernel.org
> List-Id: <dwarves.vger.kernel.org>
> List-Subscribe: <mailto:dwarves+subscribe@vger.kernel.org>
> List-Unsubscribe: <mailto:dwarves+unsubscribe@vger.kernel.org>
> MIME-Version: 1.0
> Content-Transfer-Encoding: 8bit
> 
> Two fixes for --lang_exclude when CUs are merged, as for LTO objects.
> 
> Patch 1 takes the merged CU's language from a CU that is kept, so that
> excluding the language of the first CU no longer drops the whole
> object. With LTO, this is what makes BTF generation fail for kernel
> modules that mix Rust and C.
> 
> Patch 2 fixes a second bug from the same commit, which I found while
> testing userspace LTO objects after sending v1. With clang LTO, a type
> such as int is emitted once and shared through DW_FORM_ref_addr, so
> skipping the excluded CUs left references into them dangling: pahole
> crashed printing such members, and -J encoded them as void. Patch 2
> loads the types that kept CUs use from the excluded CUs. Output without
> --lang_exclude does not change, and neither does the BTF of the LTO
> kernels I tested.
> 
> Patch 1 exposes this bug in one more link order. For a C++ object
> linked before a C one, pahole used to drop the C types without any
> error; with patch 1 alone it keeps them, and then crashes printing them,
> or encodes them as void with -J. Please apply the two together.
> 
> As far as I know, patch 1 removes the last thing that keeps the kernel's
> RUST option off when LTO and BTF are both on. Once these fixes are in a
> release, I'd like to propose relaxing that dependency to something like:
> 
>   depends on !DEBUG_INFO_BTF || (PAHOLE_HAS_LANG_EXCLUDE && (!LTO || PAHOLE_VERSION >= 133))
> 
> assuming they land in 1.33. The kernel tests in patch 1 ran with
> "&& !LTO" dropped from that line, hence the Cc to rust-for-linux.
> 
> Changes in v2:
> - Add patch 2.
> - Patch 1 is unchanged; its note about the Kconfig follow-up moved here.
> 
> v1: https://lore.kernel.org/all/20261009201032.40105-1-linux@alanderk.com/

Thanks for doing this work! Sorry for the delay in getting to it, I'm looking
at the patches now. 

In terms of enabling kernel builds to support adding BTF data for Rust, that's a
goal we're working towards too, but it turns out there are some complications.
We discussed a bit of this in Linux Plumbers in the BPF track [1], but the
main issue boils down to how bindgen-generated structures differ somewhat
from the C-based types; enums aren't always faithfully represented for example.
This has knock-on effects for BTF generation and we often end up with duplicate 
types for key kernel data structures; the bindgen and C versions of "struct sock"
for example. This in turn can confuse tooling which expects a canonical type
for the critical kernel structures.

We've been working on a solution; essentially, the idea is to detect such cases
and fix up the type graph in pahole using a new "rust_bindgen_replace" feature
so that the final BTF does not have to carry such duplicates. It will only run for
Rust CUs, and it is implemented in a work-in-progress series at [2]; the bindgen-related
changes are in [3].

The other commits in the series add BTF tags to allow tracers to use demangled names
in function tracing descriptors, and add testing etc.

[1] https://lpc.events/event/20/contributions/2408/
[2] https://github.com/alan-maguire/dwarves/tree/pahole-next-btf-rust
[3] https://github.com/acmel/dwarves/commit/68954b9e0d1b4a191a6d7e3329875c2acc983c8c