libunwind-devel
[Top][All Lists]
Advanced

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

Re: [libunwind] suggest adding unw_init_local_accessors


From: David Mosberger
Subject: Re: [libunwind] suggest adding unw_init_local_accessors
Date: Fri, 6 Dec 2002 08:46:40 -0800

>>>>> 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


reply via email to

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