[PATCH] Fix for thread debugging in the presence of software single step

[PATCH] Fix for thread debugging in the presence of software single step

[Nitin Gupta]

Following patch fixes for thread debugging in the presence of software 
single step:
  Only allow one thread to single-step if SOFTWARE_SINGLE_STEP_P ()

If it looks OK,  Could someone please check it in?

Index: gdb-6.5/gdb/infrun.c
===================================================================
--- gdb-6.5.orig/gdb/infrun.c
+++ gdb-6.5/gdb/infrun.c
@@ -618,10 +618,11 @@
        }

       if ((scheduler_mode == schedlock_on)
-         || (scheduler_mode == schedlock_step
-             && (step || singlestep_breakpoints_inserted_p)))
+         || (scheduler_mode == schedlock_step && step)
+         || singlestep_breakpoints_inserted_p)
        {
          /* User-settable 'scheduler' mode requires solo thread resume. */
+         /* Software single-step doesn't work right with multiple 
threads.  */
          resume_ptid = inferior_ptid;
        }

Re: [PATCH] Fix for thread debugging in the presence of software single step

[Daniel Jacobowitz]

On Tue, Nov 28, 2006 at 10:41:59AM -0800, Nitin Gupta wrote:
> Following patch fixes for thread debugging in the presence of software 
> single step:
>  Only allow one thread to single-step if SOFTWARE_SINGLE_STEP_P ()

Patches go to the gdb-patches list, and should include a changelog
entry, please.  What does this fix?  I know some work's been done on
software single step plus threads.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH] Fix for thread debugging in the presence of software single step

[Ulrich Weigand]

Daniel Jacobowitz wrote:
> On Tue, Nov 28, 2006 at 10:41:59AM -0800, Nitin Gupta wrote:
> > Following patch fixes for thread debugging in the presence of software 
> > single step:
> >  Only allow one thread to single-step if SOFTWARE_SINGLE_STEP_P ()
> 
> Patches go to the gdb-patches list, and should include a changelog
> entry, please.  What does this fix?  I know some work's been done on
> software single step plus threads.

This is an interesting coincidence since we've been struggling with
software single-step vs. threads issues in the Cell BE combined debugger
over the last couple of weeks as well ;-)

One problem we found is the following: if in addition to using software
single-step, the platform also requires a non-zero decr_pc_after_break,
things go wrong.  In particular, if  -while single-stepping-  *another*
thread hits a breakpoint, or some other event occurs, it may happen that
the single-stepped thread runs onto the single-step breakpoint, but
GDB never performs the PC adjustment.  This leads to instructions simply
being skipped in the inferior.

The code in infrun.c only ever adjusts the PC for the current thread
(which may be the other thread that was not single-stepped), and while
there is code in linux-nat.c (cancel_breakpoints_callback) that does
the PC adjustment for the non-current threads, this routine only
handles regular breakpoints, not single-step breakpoints.

I've fixed this in our local build by basically adding to the

  if (lp->status != 0
      && WIFSTOPPED (lp->status) && WSTOPSIG (lp->status) == SIGTRAP
      && breakpoint_inserted_here_p (read_pc_pid (lp->ptid) -
                                     DECR_PC_AFTER_BREAK))
    {

condition a check whether a *software single-step* breakpoint is
inserted at the PC location.  However, this required adding a new
function to breakpoint.c since there is currently no way to actually
query that information ...

Bye,
Ulrich

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