Currently, perf script uses host unwind methods(local unwind) to parse
perf.data callchain info regardless of the target architecture. So we
get wrong result and no promotion when do remote unwind on other
This patchset checks whether a dso is 32-bit or 64-bit according to
elf class info for each thread to let perf use the correct remote
unwind methods instead.
Only x86 and aarch64 is added in this patchset to show the work flow,
other platforms can be added easily.
We can see the right result for unwind info on different machines, for
example: perf.data recorded on i686 qemu with '-g' option and parsed
on x86_64 machine.
and now we can use LIBUNWIND_DIR to specific custom dirctories
containing libunwind libs.
- Support LIBUNWIND_DIR args for detect remote libunwind libraries.
- Change patch 2/5 commit messages for better understanding.
- Self test for local (un)supported, remote un(supported) cases and
fix some bugs in v4.
- Move reference of buildid dir to 'symfs/.debug' if --symfs is
- Split makefile changes out from patch 'Add support for
- Use existing code normalize_arch() for testing the arch of
- Remove --vdso option, store vdso buildid in perf.data and let perf
fetch it automatically.
- Use existing dso__type() function to test if dso is 32-bit or
- Explain the reason why we can omit dwarf judgement when recording
in commit message.
- Elaborate on why we need to add a custom vdso path option, and
change the type name to DSO_BINARY_TYPE__VDSO.
- Hide the build tests status for cross platform unwind.
- Keep generic version of libunwind-debug-frame test.
- Put 32/64-bit test functions into separate patch.
- Extract unwind related functions to unwind-libunwind.c and add new
file for common parts used by both local and remote unwind.
- Eliminate most of the ifdefs in .c file.
He Kuang (5):
perf tools: Use LIBUNWIND_DIR for remote libunwind feature check
perf tools: Show warnings for unsupported cross-platform unwind
perf callchain: Add support for cross-platform unwind
perf callchain: Support x86 target platform
perf callchain: Support aarch64 cross-platform
[PATCH v5 3/5] perf callchain: Add support for cross-platform unwind
Use thread specific unwind ops to unwind cross-platform callchains.
Currently, unwind methods is suitable for local unwind, this patch
changes the fixed methods to thread/map related. Each time a map is
inserted, we find the target arch and see if this platform can be
remote unwind. We test for x86 platform and only show proper
messages. The real unwind methods are not implemented, will be
introduced in next patch.
CONFIG_LIBUNWIND/NO_LIBUNWIND are changed to
CONFIG_LOCAL_LIBUNWIND/NO_LOCAL_LIBUNWIND for retaining local unwind
features. CONFIG_LIBUNWIND stands for either local or remote or both
unwind are supported and NO_LIBUNWIND means neither local nor remote
libunwind are supported.
Currently, perf script uses host unwind methods to parse perf.data
callchain info regardless of the target architecture. So we get wrong
result without any warnings when unwinding callchains of x86(32-bit)
on x86(64-bit) machine.
This patch shows warning messages when we do remote unwind x86(32-bit)
on other machines. Same thing for other platforms will be added in
Common functions which will be used by both local unwind and remote
unwind are separated into new file 'unwind-libunwind_common.c'.
On Tue, May 24, 2016 at 09:20:27AM +0000, He Kuang wrote:
> Use thread specific unwind ops to unwind cross-platform callchains.
> Currently, unwind methods is suitable for local unwind, this patch
> changes the fixed methods to thread/map related. Each time a map is
> inserted, we find the target arch and see if this platform can be
> remote unwind. We test for x86 platform and only show proper
> messages. The real unwind methods are not implemented, will be
> introduced in next patch.
> CONFIG_LIBUNWIND/NO_LIBUNWIND are changed to
> CONFIG_LOCAL_LIBUNWIND/NO_LOCAL_LIBUNWIND for retaining local unwind
> features. CONFIG_LIBUNWIND stands for either local or remote or both
> unwind are supported and NO_LIBUNWIND means neither local nor remote
> libunwind are supported.
I think this is too complex and error prone, I'd rather see it split
to several pieces. Basically every logicaly single piece should be
in separate patch for better readablebility and review.
I might be missing some but I'd mainly sepatate following:
- introducing struct unwind_libunwind_ops for local unwind
- moving unwind__prepare_access from thread_new into thread__insert_map
- keep unwind__prepare_access name instead of unwind__get_arch
and keep the return value, we need to bail out in case of error
- I wouldn't use null ops.. just check for for ops == NULL in wrapper function
- I understand we need to compile 3 objects from unwind-libunwind.c,
how about we create 3 files like: