public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Antoine Tremblay <antoine.tremblay@ericsson.com>
To: Antoine Tremblay <antoine.tremblay@ericsson.com>
Cc: Yao Qi <qiyaoltc@gmail.com>, <gdb-patches@sourceware.org>
Subject: Re: [RFC 2/3] use reinsert breakpoint for vCont;s
Date: Fri, 13 May 2016 12:12:00 -0000	[thread overview]
Message-ID: <wwokeg9617ij.fsf@ericsson.com> (raw)
In-Reply-To: <wwokfutnl86k.fsf@ericsson.com>


Antoine Tremblay writes:

> Yao Qi writes:
>
>> Yao Qi <qiyaoltc@gmail.com> writes:
>>
>>> +
>>> +      if (!step_over_finished && !can_hardware_single_step ())
>>> +	{
>>> +	  /* If the thread resumed by resume_step hits the reinsert
>>> +	     breakpoint, delete the reinsert breakpoint for it.  */
>>> +	  if (current_thread->last_resume_kind == resume_step)
>>> +	    delete_reinsert_breakpoints (current_thread);
>>> +	  else
>>> +	    {
>>> +	      /* If the thread resumed by other kind, like
>>> +		 resume_continue, hits the breakpoint (either
>>> +		 reinsert breakpoint or GDB breakpoint), delete
>>> +		 all reinsert breakpoints if it hits non-reinsert
>>> +		 breakpoints, otherwise, leave reinsert breakpoint there
>>> +		 and step over it.  */
>>> +	      if (non_reinsert_breakpoint_inserted_here (event_child->stop_pc))
>>> +		delete_reinsert_breakpoints (NULL);
>>> +	    }
>>> +	}
>>>      }
>>>    else
>>>      {
>>>        /* We have some other signal, possibly a step-over dance was in
>>>  	 progress, and it should be cancelled too.  */
>>>        step_over_finished = finish_step_over (event_child);
>>> +
>>> +      if (!step_over_finished && !can_hardware_single_step ())
>>> +	delete_reinsert_breakpoints (NULL);
>>>      }
>>>  
>>>    /* We have all the data we need.  Either report the event to GDB, or
>>> @@ -3568,6 +3590,8 @@ linux_wait_1 (ptid_t ptid,
>>>  
>>>    /* Alright, we're going to report a stop.  */
>>>  
>>> +  delete_reinsert_breakpoints (NULL);
>>> +
>>
>> The SIGILL is caused by removing these reinsert breakpoints when threads
>> are still running.  I adjust the code removing reinsert breakpoints when
>> threads stop, the SIGILL goes away.
>
> I think the insertion of the breakpoints may also be unsafe in non-stop
> mode, since correct me if am wrong but in linux_resume we can't assume
> that all threads are stopped and thus when we call single_step from:
> linux_resume->linux_resume_one_lwp->single_step another thread could
> hit the memory we're writing to.
>
> We should stop all threads before the breakpoint insertion like done in
> start_step_over.
>

Note that on second though, I think it's best to just call
prepare/done_to_access_memory on every aceess and not have to worry
about this. I'm trying this out now.

And then it's easy to just select what were we want to remove the
breakpoint like this patch does.

  reply	other threads:[~2016-05-13 12:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-06 10:32 [RFC 0/3] Use " Yao Qi
2016-05-06 10:32 ` [RFC 1/3] make reinsert breakpoint thread specific Yao Qi
2016-05-06 10:32 ` [RFC 2/3] use reinsert breakpoint for vCont;s Yao Qi
2016-05-11 10:41   ` Yao Qi
2016-05-12 13:25     ` Antoine Tremblay
2016-05-13 12:12       ` Antoine Tremblay [this message]
2016-05-12 14:03     ` Antoine Tremblay
2016-05-12 16:38       ` Yao Qi
2016-05-06 10:32 ` [PATCH 3/3] [GDBserver] Support vCont s and S actions with software single step Yao Qi
2016-05-09 15:17 ` [RFC 0/3] Use reinsert breakpoint for vCont;s Antoine Tremblay
2016-05-10 13:29   ` Antoine Tremblay
2016-05-11  8:35     ` Yao Qi
2016-05-11 12:08       ` Antoine Tremblay
2016-05-17 14:08 ` Antoine Tremblay
2016-05-18  7:50   ` Yao Qi
2016-05-18 11:50     ` 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=wwokeg9617ij.fsf@ericsson.com \
    --to=antoine.tremblay@ericsson.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).