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