Hi Mark, On Mon, 10 Jun 2013 11:24:00 +0200, Mark Wielaard wrote: > On Sat, 2013-06-01 at 20:30 +0200, Jan Kratochvil wrote: > The only issue I have with dwfl_end to mark the process "unfrozen" again > is that it means you have to reconstruct the whole Dwfl again for the > next backtrace. Something which is a bit expensive if you like to use > the unwinder for something like a profiler that is periodically taking > backtraces of a process it is monitoring. I think we must convince > ourselves that we can introduce something a bit more subtle that > preserves the Dwfl in the future for that use case. But we can go with > the "freeze at begin", "unfreeze at end" policy for now.
OK, understood. But some dwfl_detach() can be introduced later as a simple extension. > I think that is a bit of a bug in the design/interface though. If we > introduce a register callback that is called when inspecting a different > thread the user can (in theory) emulate either a core, pid or data > backed Dwfl. And the other frame/state function would just work > similarly without the user having to adjust code depending on how things > were initialized. That makes sense to unify access to multiple TIDs for core/PID/callbacks in the caller. > Maybe ISACTIVATION might be more descriptive (which would be the inverse of > MINUSONE, it shows the return pc is equal to the frame "call" address)? OK, fine with ISACTIVATION as it conforms to the DWARF terminology. > 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. Thanks, Jan _______________________________________________ elfutils-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/elfutils-devel
