Commit dbce594d33
added unconditional dwarf usage into unw_get_proc_name.
Unfortunately ia64 is the only architecture that
does not support it in libunwind (configure.ac):
```
if test x$target_arch != xia64; then
use_dwarf=yes
else
use_dwarf=no
fi
```
As a result build fails on ia64 as:
```
ia64-unknown-linux-gnu-gcc ... -c mi/Lget_proc_name.c ...
In file included from mi/Lget_proc_name.c:4:0:
mi/Gget_proc_name.c: In function '_ULia64_get_proc_name':
mi/Gget_proc_name.c:107:8: error: 'struct cursor' has no member named 'dwarf'
if (c->dwarf.use_prev_instr)
^~
mi/Gget_proc_name.c:111:8: error: 'struct cursor' has no member named 'dwarf'
if (c->dwarf.use_prev_instr && offp != NULL && error == 0)
^~
```
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Add interface for configurable dwarf cache size
* Use item size and round up to nearest power of 2.
* Initial cache still exists in BSS. Without this, it means we would fail
backtrace when out of memory. The test-mem test fails without this
By default, the start_ip_offset in libunwind's table_entry struct is
relative to the unw_dyn_info_t's segbase. This presents a problem
for us in conjunction with using LLVM's MCJIT because it likes to
spread text sections and the corresponding eh_frame sections quite
far apart. This represents my attempt to support this use case in the
simplest manner that is backwards compatible, by adding a new format
kind (UNW_INFO_FORMAT_REMOTE_TABLE2) that indicates that the
`start_ip_offset` should be interpreted as relative to `start_ip`
rather than segbase.
Fix returning the name of the function containing the frame PC,
for the non-interrupted frames. The symbol lookup code should
take use_prev_instr value into account, otherwise it could return
the name of the function adjacent to the caller.
Instead of maintaining a pointer to the `sos_memory' array, maintain an
index that tells the next free position. When atomic operations are
available, the allocation boils down to a single fetch-and-add
operation.
To ensure that we return properly aligned pointers from sos_alloc(),
MAX_ALIGN must be a power-of-two. On i386 the power-of-two assumption
fails as sizeof(long double) = 12. Fix this by rounding up to 16.
Use the __BIGGEST_ALIGNMENT__ macro provided by GCC for sos_alloc()
allocation alignment. The macro gives ``the largest alignment ever used
for any data type on the target machine you are compiling for.''
__BIGGEST_ALIGNMENT__ also has some other nice properties, e.g. it is
power-of-two on all architectures (note that on i386, sizeof(long
double) = 12), and on some architectures (e.g. SuperH) the alignment
requirement can be lower than sizeof(long double).
Rename the `ALIGN' macro to `UNW_ALIGN', and move it from
`_UCD_internal.h' to `libunwind_i.h' so that we can share it with the
mempool code. `ALIGN' was clashing with system headers on FreeBSD:
In file included from src/coredump/_UCD_access_reg_freebsd.c:26:
src/coredump/_UCD_internal.h:102:1: warning: "ALIGN" redefined
In file included from /usr/include/sys/param.h:115,
from src/coredump/_UCD_lib.h:52,
from src/coredump/_UCD_access_reg_freebsd.c:24:
/usr/include/machine/param.h:79:1: warning: this is the location of the previous definition
Insert static branch prediction predicates in useful places and avoid
unnecessary code in the hottest paths. Bypass unnecessary indirect
calls, in particular to access_mem(), when known to be safe.
Since the fast unwinding code path doesn't need the full context,
a faster target dependent getcontext is implemented.
Signed-off-by: Lassi Tuura <lat@cern.ch>
Dropping the extra frame for unw_backtrace itself using unw_step is
approximately 15% slower than skipping the frame in tdep_trace. So
drop the frame in the latter, and make the function a private
implementation detail for libunwind, not an exported interface.
Also moves unw_getcontext call back into unw_backtrace to avoid an
extra call frame in case slow_backtrace does not get inlined into
unw_backtrace.
