[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libunwind-devel] [PATCH 3/5] Rework the lookup of the ARM specific

From: Ken Werner
Subject: Re: [Libunwind-devel] [PATCH 3/5] Rework the lookup of the ARM specific unwind entry for local unwinding
Date: Mon, 08 Aug 2011 22:03:03 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11

On 08/08/2011 06:08 PM, Arun Sharma wrote:
On Mon, Aug 8, 2011 at 7:41 AM, Ken Werner<address@hidden>  wrote:
I'm a bit concerned about the arch-specific stuff getting added to
callback_data. What are the minimal arch specific hooks you need to
get this to work without an #ifdef UNW_TARGET_ARM? Something along the
lines of:

unw_dyn_info_t *di_tdep;

I'm not sure I can follow. I agree that these ifdefs aren't very nice but
what are the alternatives given the design of the libunwind API? The
libunwind ARM backend could define its own tdep_find_proc_info but almost
all of the code would be identical. It would walk the program headers using
dl_iterate_phdr to collect the unw_dyn_info_t information and then call
tdep_search_unwind_table to fill unw_proc_info_t.

Could we make just the callback from dl_iterate_phdr target dependent?

You mean to register a target dependent callback with dl_iterate_phdr or to call a target dependent routine from the callback itself? In both cases we'd want check for .eh_frame/.ARM.exidx infos and fall back to DWARF (.debug_frame) parsing if there are no unwind infos for the given IP. The tdep_find_proc_info is supposed to find the corresponding unwind info which means to populate unw_proc_info. Since this is a fairly complicated task the implementations of that routine (e.g. dwarf_search_unwind_table, _UPT_find_proc_info or GDB) only walk the program headers to find ELF segments that contain unwind informations (unw_dyn_info) and call back to libunwinds tdep_search_unwind_table (sometimes multiple times) to get a proper unw_proc_info. I didn't want to change this sequence because these two functions are part of the public API. Maybe I'm missing something. Any suggestions are welcome.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]