This is the mail archive of the mailing list for the elfutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [API RFC] unwinder


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 line:
>   # mytestrun ./backtrace ./$child ./$core
> ./backtrace ./backtrace-child ./core.20860
> 0x7fa68624b000	0x7fa68644d000	[pie]
> 0x7fffa49ff000	0x7fffa4a00000
> 0x7fa685e0b000	0x7fa686027000
> 0x7fa685a53000	0x7fa685e0b000
> 0x7fa686027000	0x7fa68624b000
> 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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]