public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Yao Qi <qiyaoltc@gmail.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 4/8] Force to insert software single step breakpoint
Date: Thu, 17 Mar 2016 12:40:00 -0000	[thread overview]
Message-ID: <56EAA5A4.5040601@redhat.com> (raw)
In-Reply-To: <86egbay78l.fsf@gmail.com>

On 03/16/2016 11:47 AM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
> 
>> Hmm, I think we might need to do something else.
>>
>> If you put a breakpoint there, then the instruction under
>> the breakpoint won't execute at all.
> 
> That is intended, because if the instruction is executed, it can't be
> stopped.
> 
>>
>> If it's a conditional branch, and the condition is false,
>> we will fail to ever advance past the instruction.
>>
>> Similarly if the branch instruction happens to have important
>> side effects (flags? counters?).
> 
> We can switch to displaced stepping if we find the instruction may
> branch to itself.  Say, we can change gdbarch software_single_step to
> return a vector of dest addresses of current pc and caller inserts
> software single step breakpoints to these dest addresses.  If any
> element of vector equals to the current pc, switch to displaced
> stepping if supported.  What do you think?

That's not possible on the gdbserver side, however.

Maybe what we need to do is firmly declare (and add comments in that
direction) that the arch's get_next_pcs implementation must always evaluate 
the condition of conditional branches, and not put a breakpoint at the
branch destination if the condition is false, thus ensuring forward progress.
The ARM implementation does this, though I haven't checked whether all the
branch instructions are covered.  Some other archs don't, and always put
a break at the branch destination, like e.g., moxie_software_single_step.

If we find some instruction where that is still not be sufficient,
due to side effects, then maybe gdb and gdbserver could first
try emulating the instruction's side effects manually.  And only
if that doesn't work, then try displaced stepping.  We could leave
that for later, until we find a need.

WDYT?

Thanks,
Pedro Alves

  reply	other threads:[~2016-03-17 12:40 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-04 10:44 [PATCH 0/8] Step over instruction branches to itself Yao Qi
2016-03-04 10:44 ` [PATCH 2/8] Check LWP_SIGNAL_CAN_BE_DELIVERED for enqueue/dequeue pending signals Yao Qi
2016-03-11 10:55   ` Pedro Alves
2016-03-17  8:40     ` Yao Qi
2016-03-17 11:07       ` Pedro Alves
2016-03-18 14:36         ` Yao Qi
2016-03-16 17:02   ` Luis Machado
2016-03-04 10:44 ` [PATCH 6/8] [GDBserver] Don't error in reinsert_raw_breakpoint if bp->inserted Yao Qi
2016-03-04 10:44 ` [PATCH 1/8] Set signal to 0 after enqueue_pending_signal Yao Qi
2016-03-11 10:53   ` Pedro Alves
2016-03-18 14:36     ` Yao Qi
2016-03-04 10:44 ` [PATCH 3/8] Deliver signal in hardware single step Yao Qi
2016-03-11 11:05   ` Pedro Alves
2016-03-11 11:09     ` Pedro Alves
2016-03-11 11:37       ` Pedro Alves
2016-03-16 10:47         ` Yao Qi
2016-03-17 12:12           ` Pedro Alves
2016-03-04 10:44 ` [PATCH 4/8] Force to insert software single step breakpoint Yao Qi
2016-03-11 11:49   ` Pedro Alves
2016-03-16 11:47     ` Yao Qi
2016-03-17 12:40       ` Pedro Alves [this message]
2016-03-18 14:25         ` Yao Qi
2016-03-18 15:03           ` Pedro Alves
2016-03-04 10:44 ` [PATCH 7/8] Resume the inferior with signal rather than stepping over Yao Qi
2016-03-11 12:04   ` Pedro Alves
2016-03-21  9:40     ` Yao Qi
2016-03-04 10:45 ` [PATCH 8/8] New test case gdb.base/branch-to-self.exp Yao Qi
2016-03-04 10:45 ` [PATCH 5/8] Insert breakpoint even when the raw breakpoint is found Yao Qi
2016-03-11 11:54   ` Pedro Alves

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=56EAA5A4.5040601@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=qiyaoltc@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).