This is the mail archive of the
mailing list for the elfutils project.
Re: [API RFC] unwinder
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Tue, 09 Oct 2012 15:17:59 +0200
- Subject: Re: [API RFC] unwinder
On Tue, 09 Oct 2012 13:58:28 +0200, Mark Wielaard wrote:
> I think that makes it slightly easier to review, so please do if you
Pushed jankratochvil/unwind to git.fedorahosted.org/git/elfutils.git.
> > It requires CFI now
> Do you mean it only supports Dwarf_CFI gotten through
> dwarf_getcfi_elf//dwfl_module_eh_cfi aka eh_frame? Or would debug_frame
> unwind data be fine too?
Both dwfl_module_eh_cfi and dwfl_module_dwarf_cfi are used in
> > , no per-arch frames unwinding possible now.
> What do you mean by that?
In some cases there is neither .eh_frame nor .debug_frame entry but one still
can unwind the core with some arch-specific frame layout assumptions.
backends/s390_frame_unwind.c is there to be able to unwind s390/s390x signal
frames which have neither .eh_frame nor .debug_frame entry.
But for example i386 -fno-omit-frame-pointer -fno-asynchronous-unwind-tables
code could be unwound via %ebp/%esp chain with neither .eh_frame nor
.debug_frame but this unwinder currently cannot.
I think non-CFI unwinding is rather useful only for a crash backtrace feature
where more heuristics are useful in general. Current unwinder should be used
only for non-crashed PIDs/cores, it has no heuristics.
> > Live PIDs and core files are supported.
> Those are certainly the most interesting use cases. But I think we would
> like to have some more generic interface to add an initial
> Dwarf_Frame_State to a Dwfl. I do realize that defining that generically
> is hard though. So maybe just having "magic" pid/core initializers is
> the easiest way to go for now.
I understand it is possible, there is now already some "abstraction" for
a callback libdwfl/dwfl_frame_unwind.c memory_read. I wrote it only as
a shortest path to the goal so I just ask if it is good enough for upstreaming
> As far as I can see the Dwarf_Frame_State represents both all
> thread/register states and a particular thread. You can identify the
> state through dwfl_frame_tid_get() and you switch through
> dwfl_frame_thread_next(). I think having a separate handle per thread
> (as you internally already seem to be using Dwarf_Frame_State_Thread)
> might be more natural.
That may be but it may make the user interface more "complicated" if you are
not interested in threads.
I am OK to change it, though. Not comitting to it yet.
> In general libdw is "pure DWARF" and libdwfl adds a frontend to tie
> Dwarf and Elf objects into address spaces. You are adding thread and
> register value states. So I think libdwl is the right spot.
OK, thanks. So I will move some remaining scattered bits to libdwfl.
> Since adding public API is really hard to get right. Maybe we should
> first do a version without any new public API except for a new
> src/stack.c program that uses the internal interfaces so we have the
> actual code working and can then decide how to expose it as a
> library/stable API?
I would like to have public API in several few months at least in Fedora.
src/stack.c I do not find useful at all on its own.