Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Yao Qi <qiyaoltc@gmail.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH 8/9] Use reinsert_breakpoint for vCont;s
Date: Fri, 01 Jul 2016 15:07:00 -0000	[thread overview]
Message-ID: <c9c52445-0d03-51fa-b4d4-cb94d1e74471@redhat.com> (raw)
In-Reply-To: <1467295765-3457-9-git-send-email-yao.qi@linaro.org>

On 06/30/2016 03:09 PM, Yao Qi wrote:
> V3: - install breakpoints in proceed_one_lwp, if the thread doesn't have
>     reinsert breakpoints installed yet,
>     - no longer stop all threads when installing breakpoints,
>     - delete reinsert breakpoints when GDBserver wants to report event,
> 
>> - Also, if in all-stop mode, if gdb does:
>>
>> vCont;s:1;c
>>
>> thus setting thread 1 stepping, and all others continuing,
>> and then some other thread but thread 1 hits a breakpoint,
>> what is removing the reinsert breakpoint of thread 1?
> 
> if thread 1 doesn't hit the reinsert breakpoint, we don't have to
> remove them, because GDB will send vCont;s:1 next time, and GDBserver

There's no guarantee GDB will send vCont;s:1 next time.
The user may do "continue" instead of "step".

> can only install reinsert breakpoints if they are not installed yet.

The user may even do "return + continue" or "jump", or an infcall,
all of which resume the thread at a different address from the address
the thread last stopped.  So there's no guarantee that the
reinsert breakpoint address makes any sense for the next step request,
or even that the next resume request is a step in the first place.

Basically the previous step request must be completely forgotten after
gdb has seen the thread stop.  In all-stop, gdb "sees "all threads
stopped on each and every event reported to gdb, for any thread.
A stop reply cancels any and all previous resume requests.

> if thread hits the reinsert breakpoint, but the event is not reported.
> It becomes pending, and GDBserver will delete the reinsert breakpoints
> next time when this pending event is reported back to GDB.

I don't follow.  I'm talking about the case where the thread does _not_
hit the reinsert breakpoint.  Instead some other thread hits some unrelated
event.

Thanks,
Pedro Alves


  reply	other threads:[~2016-07-01 15:07 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-30 14:09 [PATCH 0/9 V3] Use reinsert breakpoint " Yao Qi
2016-06-30 14:09 ` [PATCH 3/9] Refactor clone_all_breakpoints Yao Qi
2016-06-30 14:09 ` [PATCH 1/9] Pass breakpoint type in set_breakpoint_at Yao Qi
2016-06-30 14:09 ` [PATCH 9/9] Support vCont s and S actions with software single step Yao Qi
2016-06-30 14:09 ` [PATCH 7/9] Enqueue signal even when resuming threads Yao Qi
2016-07-01 15:06   ` Pedro Alves
2016-07-01 16:45     ` Yao Qi
2016-07-01 16:55       ` Pedro Alves
2016-07-01 17:01         ` Pedro Alves
2016-06-30 14:09 ` [PATCH 5/9] Switch current_thread to lwp's thread in install_software_single_step_breakpoints Yao Qi
2016-06-30 14:09 ` [PATCH 6/9] Use enqueue_pending_signal in linux_resume_one_thread Yao Qi
2016-06-30 14:09 ` [PATCH 8/9] Use reinsert_breakpoint for vCont;s Yao Qi
2016-07-01 15:07   ` Pedro Alves [this message]
2016-07-05  8:15     ` Yao Qi
2016-07-21  8:38       ` Yao Qi
2016-07-21 10:02       ` Pedro Alves
2016-06-30 14:09 ` [PATCH 4/9] Make reinsert_breakpoint thread specific Yao Qi
2016-06-30 14:09 ` [PATCH 2/9] Create sub classes of 'struct breakpoint' Yao Qi
2016-07-21 11:18 ` [PATCH 0/9 V3] Use reinsert breakpoint for vCont;s Yao Qi
2016-11-14 19:14 ` Antoine Tremblay
2016-11-21 12:08   ` Yao Qi
     [not found]     ` <wwok37ikrgmq.fsf@ericsson.com>
2016-11-23 19:03       ` Antoine Tremblay
2016-11-24 21:55       ` Yao Qi
2016-11-25 12:22         ` Antoine Tremblay
2016-11-25 13:13           ` Antoine Tremblay
2016-11-25 13:35             ` Antoine Tremblay
2016-11-25 13:44             ` Pedro Alves
2016-11-25 13:57               ` Antoine Tremblay
2016-11-25 14:28                 ` Antoine Tremblay

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=c9c52445-0d03-51fa-b4d4-cb94d1e74471@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