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