Re: [PATCH v2 1/2] libbpf: fix BTF dedup to support recursive typedef definitions

[Eduard Zingerman]

On Wed, 2025-11-12 at 15:11 +0100, Paul Houssel wrote:
> Handle recursive typedefs in BTF deduplication
> 
> Pahole fails to encode BTF for some Go projects (e.g. Kubernetes and
> Podman) due to recursive type definitions that create reference loops
> not representable in C. These recursive typedefs trigger a failure in
> the BTF deduplication algorithm.
> 
> This patch extends btf_dedup_ref_type() to properly handle potential
> recursion for BTF_KIND_TYPEDEF, similar to how recursion is already
> handled for BTF_KIND_STRUCT. This allows pahole to successfully
> generate BTF for Go binaries using recursive types without impacting
> existing C-based workflows.
> 
> Co-developed-by: Martin Horth <martin.horth@xxxxxxxxxxxxxxxxxxx>
> Signed-off-by: Martin Horth <martin.horth@xxxxxxxxxxxxxxxxxxx>
> Co-developed-by: Ouail Derghal <ouail.derghal@xxxxxxxxxxxxxxxxx>
> Signed-off-by: Ouail Derghal <ouail.derghal@xxxxxxxxxxxxxxxxx>
> Co-developed-by: Guilhem Jazeron <guilhem.jazeron@xxxxxxxx>
> Signed-off-by: Guilhem Jazeron <guilhem.jazeron@xxxxxxxx>
> Co-developed-by: Ludovic Paillat <ludovic.paillat@xxxxxxxx>
> Signed-off-by: Ludovic Paillat <ludovic.paillat@xxxxxxxx>
> Co-developed-by: Robin Theveniaut <robin.theveniaut@xxxxxxx>
> Signed-off-by: Robin Theveniaut <robin.theveniaut@xxxxxxx>
> Suggested-by: Tristan d'Audibert <tristan.daudibert@xxxxxxxxx>
> Signed-off-by: Paul Houssel <paul.houssel@xxxxxxxxxx>
> 
> ---

No differences in BTF generated for kernel when using pahole built
against libbpf with and without this patch.

Acked-by: Eduard Zingerman <eddyz87@xxxxxxxxx>

> @@ -4939,7 +4979,7 @@ static int btf_dedup_struct_types(struct btf_dedup *d)
>  /*
>   * Deduplicate reference type.
>   *
> - * Once all primitive and struct/union types got deduplicated, we can easily
> + * Once all primitive, struct/union and typedef types got deduplicated, we can easily
>   * deduplicate all other (reference) BTF types. This is done in two steps:
>   *
>   * 1. Resolve all referenced type IDs into their canonical type IDs. This

Nit: this passage continues as:

      * There is no danger of encountering cycles because in C type
      * system the only way to form type cycle is through struct/union, so any chain
      * of reference types, even those taking part in a type cycle, will inevitably
      * reach struct/union at some point.

     I think it needs adjustment to refer to typedef as well.

[...]