Re: [PATCH v2 08/10] perf symbol: Do not set binary type from symtab type

[Namhyung Kim <namhyung@kernel.org>]

On Tue, Oct 06, 2026 at 11:57:13PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [High] perf: data-only DSOs fail to open due to strict .text section requirement
> - [High] perf: compat offline DWARF unwinding broken due to missing binary_type
> - [Medium] perf: redundant double-decompression of compressed kernel modules
> --
> 
> commit 0528580a893b2b2066f28586347977aa4bf1e268
> Author: Namhyung Kim <namhyung@kernel.org>
> 
> perf symbol: Do not set binary type from symtab type
> 
> The DSO binary type is to access the binary (e.g. instruction) data
> while symtab type is for the symbol table.  They may or may not be in
> the same file.  We should track them separately and correctly.
> 
> > diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> > index 389dbd7e5192f..1175cb60f8206 100644
> > --- a/tools/perf/util/symbol.c
> > +++ b/tools/perf/util/symbol.c
> > @@ -1956,19 +1956,6 @@ int dso__load(struct dso *dso, struct map *map)
> >  
> >  		if (next_slot) {
> >  			ss_pos++;
> > -
> > -			/*
> > -			 * The binary type is used to find the file containing
> > -			 * the executed instructions, so prefer the types that
> > -			 * refer to the actual object over debug-only files such
> > -			 * as DSO_BINARY_TYPE__DEBUGLINK.
> > -			 */
> > -			if (dso__binary_type(dso) == DSO_BINARY_TYPE__NOT_FOUND ||
> > -			    symtab_type == DSO_BINARY_TYPE__BUILD_ID_CACHE ||
> > -			    (symtab_type == DSO_BINARY_TYPE__SYSTEM_PATH_DSO &&
> > -			     dso__binary_type(dso) != DSO_BINARY_TYPE__BUILD_ID_CACHE))
> > -				dso__set_binary_type(dso, symtab_type);
> > -
[SNIP]
> [Severity: High]
> Could this removal also break offline DWARF stack unwinding for compat tasks?
> 
> Because user-space maps now have a binary type of DSO_BINARY_TYPE__NOT_FOUND
> during early processing, when thread__e_machine_endian() calls
> dso__e_machine_endian() to determine the architecture, it hits the fallback:
> 
> tools/perf/util/dso.c:dso__e_machine_endian() {
>     ...
>     switch (dso__binary_type(dso)) {
>     ...
>     case DSO_BINARY_TYPE__NOT_FOUND:
>     default:
>         if (e_flags)
>             *e_flags = 0;
>         return EM_NONE;
>     }
> }
> 
> It immediately fails and returns EM_NONE without attempting to open the file.
> Consequently, thread__e_machine_endian() fails to extract the architecture
> from any map and falls back to perf_env__e_machine(), which incorrectly
> applies the host architecture to the compat thread.

Looks possible.  I'll add dso__find_binary_type() before.

But probably we can cache e_machine and e_flags in the DSO when loading
symbols.

Thanks,
Namhyung