Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: Julian Brown <julian@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Displaced stepping (non-stop debugging) support for ARM Linux
Date: Wed, 21 Jan 2009 18:07:00 -0000	[thread overview]
Message-ID: <200901211808.32127.pedro@codesourcery.com> (raw)
In-Reply-To: <20090120221355.46ac23e6@rex.config>

Hi Julian,

On Tuesday 20 January 2009 22:13:55, Julian Brown wrote:
> As a side-effect of the lack of h/w single-stepping support, we've
> enabled displaced stepping in all cases, not just when stepping over
> breakpoints (a patch of Pedro Alves's, attached, but mangled by me to
> apply to mainline). I'm not sure if that's the most sensible approach
> (for displaced stepping, we only care about not *removing* breakpoints
> which might be hit by other threads. We can still add temporary
> breakpoints for the purpose of software single-stepping).

Right, you may end up with a temporary breakpoint over another breakpoint,
though.  It would be better to use the standard software
single-stepping (set temp break at next pc, continue, remove break) for
standard stepping requests, and use displaced stepping only for stepping
over breakpoints.  Unfortunately, you don't get that for free --- infrun.c
and friends don't know how to handle multiple simultaneous software
single-stepping requests, and that is required in non-stop mode.

On Tuesday 20 January 2009 22:13:55, Julian Brown wrote:
> 2008-11-19  Pedro Alves  <pedro@codesourcery.com>
> 
>     * infrun.c (displaced_step_fixup): If this is a software
>     single-stepping arch, don't tell the target to single-step.
>     (resume): If this is a software single-stepping arch, and
>     displaced-stepping is enabled, use it for all single-step
>     requests.  

By default, displaced stepping is only enabled in non-stop mode, so,
I'm fine with this being placed in the tree, as an incremental step.
This should not affect standard all-stop mode.  It is a step in the
right direction, IMO.

You'll need someone else to look over the ARM bits.  I wouldn't
mind at all if you added a general description of what you're doing
to arm-tdep.c, though.  Perhaps, even based on:

On Tuesday 20 January 2009 22:13:55, Julian Brown wrote:
> ARM support is relatively tricky compared to some other architectures,
> because there's no hardware single-stepping support. However we can
> fake it by making sure that displaced instructions don't modify control
> flow, and placing a software breakpoint after each displaced
> instruction. Also registers are rewritten to handle instructions which
> might read/write the PC. We must of course take care that the cleanup
> routine puts things back in the correct places.

-- 
Pedro Alves


  reply	other threads:[~2009-01-21 18:07 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-20 22:14 Julian Brown
2009-01-21 18:07 ` Pedro Alves [this message]
2009-02-02 20:01 ` Daniel Jacobowitz
2009-05-16 18:19   ` Julian Brown
2009-06-09 17:37     ` Daniel Jacobowitz
2009-06-10 14:58       ` Pedro Alves
2009-06-10 15:05         ` Daniel Jacobowitz
2009-07-15 19:16           ` Julian Brown
2009-07-24  2:17             ` Daniel Jacobowitz
2009-07-31 11:43             ` Julian Brown
2009-09-24 19:35               ` Ulrich Weigand
2009-09-27 21:47                 ` [rfc] Fix PowerPC displaced stepping regression Ulrich Weigand
2009-09-28 16:57                   ` Pedro Alves
2009-09-28 17:12                     ` Ulrich Weigand
2009-09-28 17:31                       ` Pedro Alves
2009-09-28 17:39                         ` Ulrich Weigand
2009-09-28 17:27                     ` Ulrich Weigand
2009-09-28 17:39                       ` Pedro Alves
2009-09-28 17:45                         ` Ulrich Weigand
2009-09-28 19:07                           ` Pedro Alves
2009-09-28 19:41                   ` Pedro Alves
2009-09-29  0:59                     ` Ulrich Weigand
2009-09-29  1:36                       ` Joel Brobecker
2009-09-29 12:54                         ` Ulrich Weigand

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=200901211808.32127.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=julian@codesourcery.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