Il giorno ven, 31/01/2014 alle 09.47 -0800, Arun Sharma ha scritto:
> On Thu, Jan 23, 2014 at 7:07 AM, Mauro Andreolini
> <[email protected]> wrote:
>
> > To which function would 0x7facc1df12a0 match? It does not even seem to
> > be in the mapped address space of "ls". I am clueless.
>
> Did you try asking the perf guys who did the integration? It'd be
> useful to compile libunwind with --enable-debug and then get a trace
> around what happened during unwinding of this particular address.
Hi, thanks for your time. Yes, I talked to the perf guys and two
problems were solved by patching perf and the kernel event code:
* the 0x0 numbers;
* the numbers in the printf() stack trace.
One address is not unwinded in the dynamic linker code path:
5.26% ls [kernel.kallsyms] [k]
lock_release
|
--- lock_release
__mem_cgroup_try_charge
mem_cgroup_charge_common
mem_cgroup_newpage_charge
do_wp_page
handle_mm_fault
__do_page_fault
do_page_fault
do_async_page_fault
async_page_fault
__init_cpu_features
0x7fd2357470de <---- HERE
_dl_relocate_object
dl_main
_dl_sysdep_start
_dl_start
_dl_start_user
> If this is happening only in glibc, there is a good chance that there
> is a piece of hand written assembly and some dwarf CFI that libunwind
> doesn't understand yet.
It might be. Are there any instructions on how to recompile libunwind
with debug support and run some tests?
Thanks.
Mauro
_______________________________________________
Libunwind-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/libunwind-devel
