This is the mail archive of the mailing list for the elfutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [API RFC] unwinder

Hi Mrk,

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

Pushed jankratochvil/unwind to

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

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]