This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [commit] Re: [rfc][1/2] Signal delivery + software single-step is broken


Pedro Alves wrote:
> On Wednesday 27 April 2011 18:17:25, Ulrich Weigand wrote:
> > +  /* Stepping over a breakpoint while at the same time delivering a signal
> > +     has a problem: we cannot use displaced stepping, but we also cannot
> > +     use software single-stepping, because we do not know where execution
> > +     will continue if a signal handler is installed.
> > +
> > +     On the other hand, if there is a signal handler we'd have to step
> > +     over it anyway.  So what we do instead is to install a step-resume
> > +     handler at the current address right away, deliver the signal without
> > +     stepping, and once we arrive back at the step-resume breakpoint, step
> > +     once more over the original breakpoint we wanted to step over.  */
> > +  if (oneproc && tp->suspend.stop_signal != TARGET_SIGNAL_0
> > +      && execution_direction != EXEC_REVERSE)
> > +    {
> > +      insert_step_resume_breakpoint_at_frame (get_current_frame ());
> > +      tp->step_after_step_resume_breakpoint = 1;
> > +      oneproc = 0;
> > +    }
> 
> This unfortunately somewhat breaks hardware-step archs:
> 
> (the below is a simple program that writes to 0, and has a
> SIGSEGV handler installed)
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000004008ca in main2 () at siginfo.c:104
> 104       *(int *)p = 0;
> (gdb) b
> Breakpoint 1 at 0x4008ca: file siginfo.c, line 104.
> (gdb) si

That's an interesting test case :-)

The problem is that if a step-resume breakpoint is installed,
handle_inferior_event will never expect hardware single-step
traps (unless a software watchpoint is also in effect), because
it assumes nobody ever uses a step-resume breakpoint and then
hardware single-steps as well (because currently_stepping
returns 0 in that case).

The simple way to fix the inconsistency would be to just add a
  step = 0;
line to the above if.  Of course this changes the behaviour for
hardware single-step platforms: they now would not step into
the signal handler in this case (just like software single-step
platforms don't).

On the one hand, this adds consistency: both types of platforms
behave the same.  (On software single-step platforms, it seems
we simply cannot step into the handler, because we can't find
it.)

On the other hand, in some sense this reduces functionality.
So one could try to treat the two platforms separately, and
have hardware single-step platforms step into the handler,
even while software single-step platforms don't.

[ This would probably mean to move support back into resume,
because we'd want to do that only if we actually use software
single-step for this particular step.  ]

Thoughts?  Which behaviour would you prefer?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]