| Age | Commit message (Collapse) | Author |
|---|
|
libgcc_s.so's unwinder could not access unwind tables of statically
linked binaries, so we really want to use _Unwind_* stuff from
libgcc_eh.a.
It required to build backtrace.c differentiating between shared and
static case.
Signed-off-by: Filippo Arcidiacono <filippo.arcidiacono@st.com>
Signed-off-by: Carmelo Amoroso <carmelo.amoroso@st.com>
|
|
for consistency
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|
|
Arm has a different mechanism of getting
_Unwind_GetIP. Therefore we provide arch
specific backtrace file.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
|
|
From gcc documentation, we can read:
" ...
-fasynchronous-unwind-tables
Generate unwind table in dwarf2 format, if supported by target
machine. The table is exact at each instruction boundary, so it can be
used for stack unwinding from asynchronous events (such as debugger or
garbage collector)
..."
So it seems better rather than using -funwind-tables (glibc seems to prefer
-fasynchronous-unwind-tables).
Signed-off-by: Carmelo Amoroso <carmelo.amoroso@st.com>
Acked-by: Mike Frysinger <vapier@gentoo.org>
|
|
For backtrace to work is enough to use -funwind-tables instead
of -fexceptions.
Signed-off-by: Carmelo Amoroso <carmelo.amoroso@st.com>
|
|
Use the initial implementation for SH4 based on dwarf for all archs.
Indeed there are not obvious reason for which it should not work in general.
Signed-off-by: Carmelo Amoroso <carmelo.amoroso@st.com>
|
|
A new shared object, libubacktrace.so.0 is added to uClibc
to provide backtrace functions to support application self-debugging.
This set of functions requires to dynamically load libgcc_s.so so they
need to call dlopen/dlsym that are provided by libdl. For this reason
they cannot be included into libc.so.0 but are provided by a new library.
User application that wants to use backtrace needs to be compiled with
-fexceptions option and -rdynamic to get full symbols printed and must be
linked against libubacktrace.so
Signed-off-by: Carmelo Amoroso <carmelo.amoroso@st.com>
|
