Ian Munsie wrote: > From: Ian Munsie <imun...@au.ibm.com> > > The perf userspace tool included some architecture specific code to map > registers from the DWARF register number into the names used by the regs > and stack access API. > > This patch moves the architecture specific code out into a separate > arch/x86 directory along with the infrastructure required to use it. > > Signed-off-by: Ian Munsie <imun...@au.ibm.com> > --- > Changes since v1: From Masami Hiramatsu's suggestion, I added a check in the > Makefile for if the arch specific Makefile defines PERF_HAVE_DWARF_REGS, > printing a message during build if it has not. This simplifies the code > removing the odd macro from the previous version and the need for an arch > specific arch_dwarf-regs.h. I have not entirely disabled DWARF support for > architectures that don't implement the register mappings, so that they can > still add a probe based on a line number (they will be missing the ability to > capture the value of a variable from a register).
Hmm, sorry, I don't think it is a good way to go... IMHO, porting dwarf-regs.c is so easy (you can just refer systemtap/runtime/loc2c-runtime.h), easier than porting kprobe-tracer on another arch. And perf is a part of kernel tree. It means that someone who are porting kprobe-tracer, he should port dwarf-regs.c too. In that case, PERF_HAVE_DWARF_REGS flag will be used only between those two patches in same patchset. So, I suggested you to drop dwarf support if dwarf-regs mapping doesn't exist. AFAIK, at this point, only s390 users are affected. I'd like to ask them to just port a register mapping on perf and test it too. Thank you, -- Masami Hiramatsu e-mail: mhira...@redhat.com _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev