[API RFC] unwinder

Jan Kratochvil jan.kratochvil at redhat.com
Mon Oct 8 09:44:23 UTC 2012


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.


More information about the elfutils-devel mailing list