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 _______________________________________________ elfutils-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/elfutils-devel
