Re: [API RFC] unwinder

[Mark Wielaard <mjw at redhat dot com>]

Hi Jan,

I haven't read your full patches yet, so just some small initial
remarks. Apologies if any of my questions are answered by closer
inspection of the patches (please just say so).

On Sun, 2012-10-07 at 17:18 +0200, Jan Kratochvil wrote:
> It is 1.2MB due to non-x86* core file testcases, I can push it as
> jankratochvil/unwind to the main repo upon request.

I think that makes it slightly easier to review, so please do if you
like. Personal branches may be rebased when needed (just let the
reviewers know).

> User API is to unwind PC, nothing more.

Keeping the new API small at first is probably a good thing.

> 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? Most binaries these days have full eh_frame,
but supporting debug_frame would be nice (the kernel only has this for
example).

> , no per-arch frames unwinding possible now.

What do you mean by that?

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

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.

> I have some issues with the API, what is libdw vs. libdwfl etc.  I have put
> now mostly all to libdwfl, should I really keep it there?

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. Or maybe a
new public interface on top of 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?

Cheers,

Mark