Re: [Libunwind-devel] [PATCH 3/5] Rework the lookup of the ARM specific unwind entry for local unwinding

[Ken Werner]

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.

Thanks,
Ken