This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC 2/3] use reinsert breakpoint for vCont;s


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]