Re: [libunwind] suggest adding unw_init_local_accessors

[Mark Young]

Consider pushing the unwind info cache search and insertion responsibility
down inside the find_proc_info accessor function. The address space creator
could then choose an appropriate policy, perhaps using utility routines exported
by libunwind to manage a cache if desired. In my case, since the dynamic
procedure address map and unwind info can be maintained outside libunwind,
I could define an address space and find_proc_info accessor function to fill
in the proc_info structure for ip addresses in dynamic procedures. For other
ip addresses, I could simply call the find_proc_info function associated
with unw_local_addr_space and allow libunwind to follow its default caching
policy for non-dynamic procedures.
--Mark

David Mosberger wrote:
> > > > > > On Fri, 06 Dec 2002 00:38:53 -0800, Mark Young <address@hidden> said:
> > > > > >           
> > > > >         
> > > >       
> > >     
> >   
>
>   Mark> If the application has crashed then the libunwind code itself
>   Mark> is vulnerable when unwinding in the target address space.
>
> Not for a debugger (unless the unwind info got corrupted, which is
> possible, but not very likely; even the static unwind tables could get
> corrupted by a crash).
>
>   Mark> Our procedures are usually but not always contiguous. If a
>   Mark> code block fills up while generating code for a procedure, we
>   Mark> allocate another block and insert a jump to the new
>   Mark> block.
>
> That's OK.  As far as the unwinder is concerned, this would be
> described as two separate "procedures".
>
>   Mark> Most prologs are alike and most epilogs are alike but the
>   Mark> distance between them varies.
>
> Thanks for reminding me of that point: I think we may be able to give
> special meaning to negative "when" values.  If they mean to count
> instructions downwards from end_ip, we should be able to share the
> region list across all procedures with the same prologue/epilogue, no
> matter how long they are.  But I need to code this up, still.
>
>   Mark> Since we must maintain our own records to map source lines and
>   Mark> statements to code addresses, I'd prefer not to burden
>   Mark> libunwind with an elaborate and redundant data structure that
>   Mark> might suit us but not work at all for the next user.
>
> I appreciate that, but I'm afraid that callbacks are a non-starter.
> We really need something else.  Besides, it's well possible that other
> applications have similar needs as yours (and I'll certainly keep an
> eye on things to ensure that we don't end up with something that's
> completely specific to one particular application).
>
> 	--david

-- 
Mark Young            address@hidden     Tel: 503.526.1661
Staff Engineer         www.model.com      Fax: 503.526.5473
Model Technology, Inc.
10450 SW Nimbus Avenue/Bldg RB, Portland, OR 97223-4347 USA