libunwind-devel
[Top][All Lists]
Advanced

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

[Libunwind-devel] [PATCH 16/19] ARM: invalidate proc info after non-dwar


From: Tommi Rantala
Subject: [Libunwind-devel] [PATCH 16/19] ARM: invalidate proc info after non-dwarf unw_step()
Date: Wed, 5 Sep 2012 14:50:24 +0300

After successfully stepping the cursor on ARM, the proc info is
invalidated only in dwarf_step(). Invalidate the proc info also when
stepping with the non-dwarf based methods. This fixes
unw_get_proc_info() returning stale data.

The core dump unwinder can be used for demonstrating the bug. When
unwinding based only on DWARF data, the proc info is correct:

$ UNW_ARM_UNWIND_METHOD=1 ./test-coredump-unwind core `cat backing_files` 
2>/dev/null
    ip=0x000086d8 proc=000086d4-000086dc handler=0x00000000 lsda=0x00000000
    ip=0x000086ef proc=000086dc-000086f2 handler=0x00000000 lsda=0x00000000
    ip=0x000086e7 proc=000086dc-000086f2 handler=0x00000000 lsda=0x00000000
    ip=0x00008597 proc=00008584-0000859a handler=0x00000000 lsda=0x00000000
    ip=0x76e3ac3b proc=76e3aba0-76e3acec handler=0x00000000 lsda=0x00000000

When unwinding based only on the exidx method, we see the proc info
lagging behind:

$ UNW_ARM_UNWIND_METHOD=4 ./test-coredump-unwind core `cat backing_files` 
2>/dev/null
    ip=0x000086d8 proc=000086d4-000086db handler=0x00000000 lsda=0x00000000
    ip=0x000086ef proc=000086d4-000086db handler=0x00000000 lsda=0x00000000
    ip=0x000086e7 proc=000086dc-000086f3 handler=0x00000000 lsda=0x00000000
    ip=0x00008597 proc=000086dc-000086f3 handler=0x00000000 lsda=0x00000000
    ip=0x76e3ac3b proc=00008584-0000859b handler=0x00000000 lsda=0x00000000
    ip=0x000085c3 proc=76e3aba0-76e3ae4b handler=0x00000000 lsda=0x00000000

Finally, with this patch applied, we get the desired proc info also with
the exidx unwinder:

$ UNW_ARM_UNWIND_METHOD=4 ./test-coredump-unwind core `cat backing_files` 
2>/dev/null
    ip=0x000086d8 proc=000086d4-000086db handler=0x00000000 lsda=0x00000000
    ip=0x000086ef proc=000086dc-000086f3 handler=0x00000000 lsda=0x00000000
    ip=0x000086e7 proc=000086dc-000086f3 handler=0x00000000 lsda=0x00000000
    ip=0x00008597 proc=00008584-0000859b handler=0x00000000 lsda=0x00000000
    ip=0x76e3ac3b proc=76e3aba0-76e3ae4b handler=0x00000000 lsda=0x00000000
    ip=0x000085c3 proc=0000859c-00008613 handler=0x00000000 lsda=0x00000000
---
 src/arm/Gstep.c |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/src/arm/Gstep.c b/src/arm/Gstep.c
index b96d5e2..3c65ac0 100644
--- a/src/arm/Gstep.c
+++ b/src/arm/Gstep.c
@@ -68,6 +68,8 @@ arm_exidx_step (struct cursor *c)
       return -UNW_EBADFRAME;
     }
 
+  c->dwarf.pi_valid = 0;
+
   return (c->dwarf.ip == 0) ? 0 : 1;
 }
 
@@ -157,6 +159,8 @@ unw_handle_signal_frame (unw_cursor_t *cursor)
   dwarf_get (&c->dwarf, c->dwarf.loc[UNW_ARM_R13], &c->dwarf.cfa);
   dwarf_get (&c->dwarf, c->dwarf.loc[UNW_ARM_R15], &c->dwarf.ip);
 
+  c->dwarf.pi_valid = 0;
+
   return 1;
 }
 
@@ -253,6 +257,7 @@ unw_step (unw_cursor_t *cursor)
                 }
               c->dwarf.loc[UNW_ARM_R12] = ip_loc;
               c->dwarf.loc[UNW_ARM_R11] = fp_loc;
+              c->dwarf.pi_valid = 0;
               Debug(15, "ip=%lx\n", c->dwarf.ip);
             }
           else
-- 
1.7.9.5




reply via email to

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