libunwind-devel
[Top][All Lists]
Advanced

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

Re: [libunwind] sos_alloc()


From: David Mosberger
Subject: Re: [libunwind] sos_alloc()
Date: Thu, 25 Mar 2004 15:37:24 -0800

>>>>> On Thu, 25 Mar 2004 17:10:35 -0600 (CST), Todd L Miller <address@hidden> 
>>>>> said:

  Todd>         sos_alloc() is abort()ing on me as I'm using the
  Todd> single-step method to determine the correctness of the unwind
  Todd> information.

It could be a side-effect of a memory-leak in parse_dynamic() which I
fixed very recently:

diff -Nru a/src/ia64/Gparser-ia64.c b/src/ia64/Gparser-ia64.c
--- a/src/ia64/Gparser-ia64.c   Thu Mar 25 15:26:58 2004
+++ b/src/ia64/Gparser-ia64.c   Thu Mar 25 15:26:58 2004
@@ -868,6 +868,7 @@
              ret = ia64_fetch_proc_info (c, new_ip, 1);
              if (ret < 0)
                return ret;
+             ia64_free_state_record (sr);
              return create_state_record_for (c, sr, new_ip);
 
            case UNW_DYN_STOP:

There was a similar leak in the ia64-version of unw_is_signal_frame().

  Todd>         The problem I mentioned above is the following: if I
  Todd> overwrite part of the prologue with a jump (common), the
  Todd> prologue will have correctly executed by the time execution
  Todd> returns to the function, but the unwind information will
  Todd> expect (parts of it) to be done much sooner, that is, by the
  Todd> jump instruction itself.  (I'm overwriting the bundle with a
  Todd> nop and a long branch.)  I thought about inserting dynamic
  Todd> unwind information for this bundle (which would say, in
  Todd> effect, that nothing interesting was going on) to correct this
  Todd> issue.  However, would that screw up unwinding through the
  Todd> rest of the function, because the static information about the
  Todd> prologue actions that were done (by the time normal execution
  Todd> resumes) had been overridden?

Yes, that's certainly a challenge.  I think the way to do this cleanly
would be to replace the static unwind info for the entire procedure
with dynamic unwind info which matches the static info, except that
the directives for the instructions in the patched bundle have their
"when" values tweaked so that they take effect only after the branch
returns.

This would be fairly easy if there were a support routine that parses
static unwind info into the dynamic format.  Alas, that doesn't exist
yet.

        --david


reply via email to

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