Re: [rfc] linux-nat: Never PTRACE_CONT a stepping thread

[Pedro Alves <pedro@codesourcery.com>]

On Monday 18 October 2010 09:51:38, Jan Kratochvil wrote:
> On Sun, 17 Oct 2010 21:04:18 +0200, Pedro Alves wrote:
> > I just belatedly realized that this probably
> > breaks software single-step archs though.  :-/
> 
> I have run the testsuite on arm-fedora12-linux-gnu and the only (...)

Thanks for testing.  Does the new test pass there?

What I actually remembered was that using PTRACE_SINGLESTEP,
and leaving lwp->step true on software single-step archs
probably isn't a good idea.  And it crossed my mind that we'd
probably need to make infrun.c know it needs to insert
software single-step breakpoint in this case too.

> I do not see why it should fail in general.  insert_single_step_breakpoint
> already supports two existing single step breakpoints, one gets used for
> inferior_ptid and one for stepping ptid.  

But hmm, you left me confused.  In the case at hand, from reading the code,
by the time you get to linux_nat_resume, infrun.c has context-switched
inferior_ptid to the thread that we're "delivering" the signal to.  Right
after context-switching, infrun pulled the previous single-step breakpoints
out of target:

  if (singlestep_breakpoints_inserted_p)
    {
      /* Pull the single step breakpoints out of the target. */
      remove_single_step_breakpoints ();
      singlestep_breakpoints_inserted_p = 0;
    }

when handle_inferior_event handles the random signal, and decides
to forward it to the target, it calls keep_going, which then
calls resume, passing it currently_stepping(ecs->event_thread).
ecs->event_thread was _not_ stepping, so _no_ single step
breakpoints are inserted in the target.  I'm following this
only by reading the code, but since I see:
 
 "vCont;C1e:795a;s:7959;c"

coming out, and not

 "vCont;S1e:795a;s:7959;c"

I'm led to believe the analysis is correct.

> Maybe the support of two single step
> breakpoints is there for some inferior code constructs, in such case
> I understand two would be no longer enough.

Yes, there are constructs where we need two breakpoints, usually in
cases related to conditional branching where we can't tell whether
the branch will be taken or not, so we need one breakpoint at the
branch destination and a breakpoint after the branch instruction.
Grepping for insert_single_step_breakpoint will find all cases.


I'm also wondering if tweaking the test to use a signal less than
SIGTRAP (5) rather than SIGUSR1 (10) so that waitpid always
picks it up over SIGTRAP if both are pending simulateneously
reveals that we need to rethink this?

-- 
Pedro Alves