On 08/08/2011 06:08 PM, Arun Sharma wrote:
On Mon, Aug 8, 2011 at 7:41 AM, Ken Werner<[email protected]> 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.
Thanks,
Ken
_______________________________________________
Libunwind-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/libunwind-devel
