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. _______________________________________________ elfutils-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/elfutils-devel
