Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: drow@false.org (Daniel Jacobowitz)
Cc: ngupta@mvista.com (Nitin Gupta),
	gdb@sourceware.org,         jimb@codesourcery.com (Jim Blandy),
	rob.quill@gmail.com (Rob Quill)
Subject: Re: [PATCH] Fix for thread debugging in the presence of software single  step
Date: Tue, 28 Nov 2006 19:01:00 -0000	[thread overview]
Message-ID: <200611281901.kASJ1cld016839@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <20061128184749.GA26707@nevyn.them.org> from "Daniel Jacobowitz" at Nov 28, 2006 01:47:49 PM

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


      reply	other threads:[~2006-11-28 19:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-28 18:42 Nitin Gupta
2006-11-28 18:47 ` Daniel Jacobowitz
2006-11-28 19:01   ` Ulrich Weigand [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200611281901.kASJ1cld016839@d12av02.megacenter.de.ibm.com \
    --to=uweigand@de.ibm.com \
    --cc=drow@false.org \
    --cc=gdb@sourceware.org \
    --cc=jimb@codesourcery.com \
    --cc=ngupta@mvista.com \
    --cc=rob.quill@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox