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