[API RFC] unwinder
jan.kratochvil at redhat.com
Mon Oct 8 09:44:23 UTC 2012
the issue below is resolved by 6b768d4aa016f3d9748d2195b82c1cdbe18503aa ,
one has to supply the right executable file by Dwfl_Callbacks->find_elf .
Or one could also patch the filename path in Dwfl_Module after
dwfl_core_file_report but still before it is tried to be opened by later
symbol resolving calls; but own find_elf wrapper seems OK to me.
On Sun, 07 Oct 2012 17:18:38 +0200, Jan Kratochvil wrote:
> The initial reporting is a bit problematic for me. For example
> src/stack -e ~/t/sleep6000-32 --core=$HOME/t/sleep6000-32.core
> # 1 0xf75e64f0 - 1 __nanosleep
> # 2 0xf75e632f - 1 sleep
> # 3 0x80483d9 - 1 (null)
> ^^^^^^ main is not resolved, we need to use:
> src/stack --core=$HOME/t/sleep6000-32.core -e ~/t/sleep6000-32
> - as otherwise dwfl_addrmodule will find the one from a core file without
> symbols first which dwfl_module_addrname will not work for.
> Still currently does not work after uncommenting run-backtrace.sh line:
> # mytestrun ./backtrace ./$child ./$core
> ./backtrace ./backtrace-child ./core.20860
> 0x7fa68624b000 0x7fa68644d000 [pie]
> 0x7fffa49ff000 0x7fffa4a00000 linux-vdso.so.1
> 0x7fa685e0b000 0x7fa686027000 libpthread.so.0
> 0x7fa685a53000 0x7fa685e0b000 libc.so.6
> 0x7fa686027000 0x7fa68624b000 ld-linux-x86-64.so.2
> 0x200000 0x401558 <executable>
> TID 20860:
> # 0 0x7fa685e14080 pthread_join
> # 1 0x7fa68624beba - 1 (null)
> No DWARF information found
> Because <executable> which is PIE is reported with different VMA than [pie].
> I had this case working in the past but apparently the bias adjustments are
> still not right, I will try more.
More information about the elfutils-devel