The "running" attribute (readable through
gimp_backtrace_is_thread_running(), and recorded in the performance
log) specifies if the thread was in a running or suspended state at
the time the backtrace was taken. It is accurate on Linux, but
only approximated on Windows.
Adapt the performance-log-expand.py tool to maintain this attribute
(and any future thread attributes we might add).
Add source filename and line number fields to the
GimpBacktraceAddressInfo struct, populated through
gimp_backtrace_get_address_info(). This is not currently supported
by the Linux backend, but is supported by the Windows backend,
which we'll be added in the next commit.
This function returns information about the given address, which
is currently mostly limited to the corresponding symbol
information, but we might want to add address-specific information
in the future, such as a line number.
GimpBacktrace provides an interface for creating and traversing
multi-threaded backtraces, as well as querying symbol information.
While we already have some backtrace functionality, it relies on
external tools for the most part, and as such is rather expensive,
and is only meant for producing opaque backtraces. GimpBacktrace,
on the other hand, is meant to be relatively cheap (we're going to
use it for profiling,) and allow inspection of the backtrace data.
In the future, it might make sense to replace some, or all, of the
other backtrace functions with GimpBacktrace.
GimpBacktrace currently only supports Linux. By default, it uses
dladdr() to query symbol information, which is somewhat limited (in
particular, it doesn't work for static functions.) When libunwind
is installed, GimpBacktrace uses it to get more complete symbol
information. libunwind is currently an optional dependency, but it
might make sense to promote it to a mandatory, or opt-out,
dependency, as it's lightweight and widely available.
On other platforms, the GimpBacktrace interface can still be used,
but it always returns NULL backtraces.