This is the mail archive of the
mailing list for the elfutils project.
Re: Some stuff for 0.159+
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Mon, 20 Jan 2014 10:55:25 +0100
- Subject: Re: Some stuff for 0.159+
On Sat, 2014-01-18 at 21:18 +0100, Jan Kratochvil wrote:
> On Wed, 15 Jan 2014 22:55:27 +0100, Mark Wielaard wrote:
> > I forgot about that one. It is completely different from what we provide
> > since it was designed to be used in-process and doesn't actually do
> > unwinding (it just uses the system/libgcc _Unwind_Backtrace to get the
> > raw call stack). Since it is in-process and could be called from a
> > signal handler it also needs to do everything in a signal safe way.
> While GCC uses it for self-unwind via backtrace_full()->_Unwind_Backtrace()
> libbacktrace is not bound to such use.
It certainly looks like it is.
> libbacktrace provides also backtrace_pcinfo() where one can feed arbitrary
> sequence of PC addresses.
Yes, backtrace_pcinfo () is like elfutils dwarf_getscopes[_die] for the
current executable. But it caches all scopes and it has a more familiar
callback interface to iterate the DIEs making memory management slightly
easier. I'll add something like that to eu-stack to show inlined frames.
It is a nice idea.
> Also backtrace_create_state() can specify arbitrary
> ELF filename (and not just the default "/proc/self/exe").
The given filename should be the name of the current executable,
normally argv, if NULL it will use getexecname () or /proc/self/exe.
It is used for printing error messages and when dl_phdr_info doesn't
provide the module name.
> I do not see now how to specify different filenames for different PCs during
> the backtrace but that could be at least easily patched/improved.
There is none, it uses dl_iterate_phdr and only works for the current
executable. I am sure that if you really wanted you could add support
for other dwfl_report like mechanisms, support 32-on-64 bit, separate
debuginfo through debug_link or build-id elf lookups, core file support,
etc. It might even make sense to use libdwfl for that. But I don't
understand why you want to rearchitecturing libbacktrace like that.
IMHO it seems easier to steal any missing functionality (DWARF debuginfo
function name lookups and inline frames) and add it to eu-stack directly
using libdw. Which seem easy, we just need to decide whether or not we
also want to cache the results somewhere.
> I do not push for libbacktrace but I still see it as a valid option.
It is a valid option if you need to generate backtraces with names in a
language runtime or your current executable that needs to be (mostly)
signal safe and don't need the flexibility that elfutils provides. I
would certainly recommend it for that.