1
0
Fork 0
mirror of https://github.com/tobast/libunwind-eh_elf.git synced 2024-06-16 23:11:44 +02:00
Commit graph

7 commits

Author SHA1 Message Date
Tommi Rantala 890e23eb9d Prefer NULL over zero 2012-09-28 14:51:21 +03:00
Tommi Rantala 5d0f376b08 Invert tdep_init() flag logic
Invert the flag that signals that tdep_init() was called, to move the
symbol from data to BSS.
2012-09-28 14:06:07 +03:00
Lassi Tuura a9dce3c06e During the stack unwinding process, the return address points to
the instruction after the call for a normal frame. libunwind uses
IP-1 to lookup unwind information. However, this is not necessary for
interrupted frames such as signal frames (or interrupt frames) in
the kernel context.

This patch handles both cases correctly.

Based on work by Mark Wielaard <mwielaard@redhat.com>
2010-04-24 19:16:09 -07:00
Arun Sharma 649f1fb344 [X86-64] For local unwinding, we have a defence mechanism against
bad/missing unwind information, which could result in libunwind
dereferencing bad pointers. This mechanism is based on msync(2) system
call and significantly reduces the chances of a bad pointer
dereference in libunwind.

The original idea was to turn this mechanism on only when necessary
i.e. libunwind didn't find proper unwind information for a IP.

There are a couple of problems in the current implementation.

* The flag is global and is modified without locking
* The flag isn't reset when starting a new unwind

The attached patch makes ->validate a per-thread setting by moving it
into struct cursor from unw_local_addr_space and resets it to false
when starting a new unwind. As a result, cursor->as_arg points to the
cursor itself instead of the ucontext (for the local case).

This was found to reduce the number of msync() system calls from an
application using libunwind significantly.

Signed-off-by: Paul Pluzhnikov <ppluzhnikov@google.com>
Signed-off-by: Arun Sharma <arun.sharma@google.com>
2008-06-16 14:35:53 -06:00
hp.com!davidm f576cce748 Drop debug-level for function-trace to 1.
(Logical change 1.257)
2004-08-26 10:02:46 +00:00
ibm.com!masbock a766efd844 (Logical change 1.249) 2004-08-19 13:39:10 +00:00
ibm.com!masbock 58e37267be Initial revision 2004-08-19 13:39:10 +00:00