This is the mail archive of the
mailing list for the elfutils project.
Re: [patch 4/4 v2] unwinder: The unwinder (x86* only)
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Mon, 10 Jun 2013 13:07:10 +0200
- Subject: Re: [patch 4/4 v2] unwinder: The unwinder (x86* only)
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
> 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
> 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.