Hi,
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.
Jan
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.