Re: [PATCH v9 2/9] perf c2c: add function view model skeleton

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] symbol_name_equal() uses host-architecture logic for cross-platform analysis.
--

--- Patch [2]: [PATCH v9 2/9] perf c2c: add function view model skeleton ---
commit 4a0efb41e4b472e806fe1942f44d90ab0a7857c6
Author: Jiebin Sun <[email protected]>
    
perf c2c: add function view model skeleton

This commit adds the initial common model for the c2c function view. It
introduces model state and small helpers shared by hierarchy construction
and formatting, building the model independently from util/.

> diff --git a/tools/perf/util/c2c-function.c b/tools/perf/util/c2c-function.c
> new file mode 100644
> index 0000000000000..ca82425a28dc3
> --- /dev/null
> +++ b/tools/perf/util/c2c-function.c

[ ... ]

> +static inline __maybe_unused bool symbol_name_equal(struct symbol *a, struct symbol *b)
> +{
> +	/* Two unknown symbols compare equal, matching cmp_null() in util/sort.c. */
> +	if (!a || !b)
> +		return a == b;
> +	return arch__compare_symbol_names(a->name, b->name) == 0;

[Severity: Medium]
Does this break cross-platform analysis?

Calling arch__compare_symbol_names() delegates symbol comparison to a
host-specific weak function rather than checking the target architecture.

If someone analyzes a perf.data file recorded on a different architecture
(like PowerPC) on an x86 host using perf c2c, could this lead to incorrect
symbol matching and inaccurate profiling reports because functions fail to
coalesce properly?

Would it be safer to query the e_machine constant dynamically via the
perf_env or session to handle architectural variations here?

> +}
> +

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2