Re: [BUG] perf: libdw not working for data collected on a different arch than host

[Namhyung Kim <namhyung@kernel.org>]

Hello,

On Tue, Nov 25, 2025 at 06:55:54PM -0800, Shimin Guo wrote:
> On Tue, Nov 25, 2025 at 5:43 PM Ian Rogers <irogers@google.com> wrote:
> >
> > On Mon, Nov 24, 2025 at 10:39 AM Shimin Guo <shimin.guo@skydio.com> wrote:
> > >
> > > Hi,
> > >
> > > I see there have been patches aimed at enabling perf to unwind stacks
> > > collected on a different arch than the host perf itself is running on,
> > > for example, https://lore.kernel.org/all/20230606014559.21783-4-leo.yan@linaro.org/.
> > >
> > > I believe there is still one issue that prevents me from doing
> > > unwinding on arm64 stacks on a x86 host. As of v6.18-rc6, I still see
> > > the following in tools/perf/util/unwind-libdw.c:
> > >
> > > static const Dwfl_Thread_Callbacks callbacks = {
> > >     .next_thread = next_thread,
> > >     .memory_read = memory_read,
> > >     .set_initial_registers = libdw__arch_set_initial_registers,
> > > };
> > >
> > > libdw__arch_set_initial_registers is defined for each architecture,
> > > and the version is chosen at compile time, not for the arch the data
> > > is collected on. After fixing this issue, I was able to get the call
> > > chains. Is my analysis correct?
> >
> > Hi Shimin,
> >
> > I think your analysis is correct. I've been trying to clean up other
> > cases of this, such as with dwarf_regs:
> > https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/log/tools/perf/util/include/dwarf-regs.h?h=perf-tools-next
> > Or with syscalltbl:
> > https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/commit/tools/perf/util/syscalltbl.c?h=perf-tools-next&id=1470eaa574870da3f78942927b15e0b75da3ffbe
> >
> > My belief is the arch directory is a code smell where we've most
> > likely broken cross-architecture support. Were you in the process of
> > putting together a patch series to fix this? My hope is to move away
> > from the CPUID feature strings for things like this and just use ELF
> > values like EM_X86_64.
> 
> I don't have immediate plans to put together a patch series. I'm not
> familiar with the Linux development process, coding standards, and
> common practices. Conceptually it's not that complicated, but whatever
> I come up with is likely not the best way to do it.

That's fine, we can find the best way during the review process if
you're willing to. :)

Thanks,
Namhyung