Hi Jan, On Mon, 2013-06-10 at 13:07 +0200, Jan Kratochvil wrote: > > Let me just hack up an example of the interface as proposed above to > > make it more concrete (or to show me why it shouldn't/cannot be done). > > Do what you want to but I am fine with for example editing just the proposed > API and I can refactor the code in a moment.
I started on the simplest part, renaming MINUSONE to ISACTIVATION (and flipping the meaning). BTW. Did you mean to use dwfl_frame_unwind () in dwfl_frame_state_pc (), would have_unwound () work? While doing that I added a few small things: - Need to include sys/types.h before sys/user.h on older systems. On RHEL6 x86_64 at least. - GCC version check attributes, noclone was introduced with GCC 4.5 That is for the testcase. But I might have misunderstood. I never could make the selfdump tests work since it tries to find the "jmp" symbol (which seems to never be used?). - tests/backtrace.c: Drop out of dwfl_getmodules when done. Just to show that you can return from a callback early and don't have to iterate over all modules once you found your match. - src/stack.c: Print usage also when number of arguments wrong. The abort was a little too strong IMHO when someone (me) made a typo. Those are all on the mjw/unwind branch I just pushed. Please take a look if any of those make sense (they can just be squashed into the actual commit, no need to make them separate, just did that so you can cherrypick and drop those that are not correct). Then I thought I could just write up the rest of the interface with extra callbacks for dwfl_begin when you want state (threads, registers and memory). Since I had said attaching such state callbacks would "freeze" the process (with dwfl_end) "releasing" it. But I now think that was a wrong suggestion. It makes the interface too heavy weight. We could later add a "unfreeze" api, but that means we would always stop the whole process first. Even if later someone decides that is not really what they are interested in. They might just want to get the backtrace of one thread, while they expect the rest of the process to keep running. So now I am thinking we should do "the opposite". Only while starting an iteration over the frames to unwind for one thread should we ptrace attach, and after we are done with unwinding for that thread we should detach it again. That would make things much lighter weight. What do you think? I am struggling a bit with this because I can see the user might want both (full freeze on begin or minimal thread freeze at use only). Cheers, Mark _______________________________________________ elfutils-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/elfutils-devel
