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
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.