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

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

[Shimin Guo]

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?

Best,
Shimin

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

[Ian Rogers]

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.

Thanks,
Ian Rogers

> Best,
> Shimin
>

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

[Shimin Guo]

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.
>
> Thanks,
> Ian Rogers
>
> > Best,
> > Shimin
> >

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.

-Shimin

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

[Namhyung Kim]

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