Re: [PATCH v2 1/8] perf event: Factor build_id out into its own top-level struct

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] perf/libperf: API breakage in perf_record_mmap2 due to renamed fields
--

commit cfeda23f684f7f8aa6b272dc2febc41f9f8eb93c
Author: Ian Rogers <irogers@google.com>

perf event: Factor build_id out into its own top-level struct
    
This commit factors the build ID structure out into its own top-level type,
struct perf_build_id, for consistency. It updates the usage of build IDs
across various perf events to use this new type.

> diff --git a/tools/lib/perf/include/perf/event.h b/tools/lib/perf/include/perf/event.h
> index fdced574c889e..173eab43c1484 100644
> --- a/tools/lib/perf/include/perf/event.h
> +++ b/tools/lib/perf/include/perf/event.h

[ ... ]

> @@ -39,12 +48,7 @@ struct perf_record_mmap2 {
>  			__u64	 ino;
>  			__u64	 ino_generation;
>  		};
> -		struct {
> -			__u8	 build_id_size;
> -			__u8	 __reserved_1;
> -			__u16	 __reserved_2;
> -			__u8	 build_id[20];
> -		};
> +		struct perf_build_id build_id;

[Severity: High]
Does this break the source-level API for external libperf consumers?

External user-space applications (like bpftool, pahole, or custom perf data
parsers) that rely on event->mmap2.build_id_size or treat
event->mmap2.build_id as a byte array will fail to compile against the
updated libperf headers.

While this preserves the binary ABI since the memory layout is exactly 24
bytes in both cases, the renamed fields and altered types will break the
API for existing libperf users. Could this transition be handled with an
anonymous union to preserve source compatibility during the update?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261002173848.3228217-1-irogers@google.com?part=1