Re: [PATCH 0/9 V3] Use reinsert breakpoint for vCont;s

[Antoine Tremblay <antoine.tremblay@ericsson.com>]

Yao Qi writes:

> Here is the V3 of this patch series, V2 can be found
> https://sourceware.org/ml/gdb-patches/2016-06/msg00029.html
> some preparatory patches in V2 are already pushed in.  Patches
> 1 - 5 and 9 are already approved in V2 review.
>
> This patch series is to address the review comments
> https://sourceware.org/ml/gdb-patches/2016-06/msg00305.html
>
>> Hmm, seeing that we need to handle installing the breakpoints in
>> both places, I wonder about making linux_resume just handle
>> setting up the last resume kind and queue signals, and then
>> end up calling proceed_all_lwps.  If that works, I suspect it
>> would simplify things a good deal.
>
> I do something slightly differently in V3.  In my
> "V2 Use reinsert breakpoint for vCont;s", I install reinsert breakpoints
> for needed lwps in two places, linux_resume and proceed_all_lwps, which
> isn't ideal.
>
> After the chat with Pedro, we don't need to stop all threads when inserting
> reinsert breakpoint, so we can move the breakpoint installation further
> down to linux_resume_one_thread and proceed_one_lwp.

I'm following up on random SIGILL/SIGSEGV when using software single stepping/
range stepping with GDBServer on ARM.

And I can't see why we don't need to stop all threads when inserting
reinsert breakpoint.

Since linux_resume will call:

find_inferior (&all_threads, linux_resume_one_thread,
  &leave_all_stopped);

This will start one thread after the other. So for example if thread 3
has a single step breakpoint to install this will start thread 1, then
thread 2 and just modify the program's memory to install reinsert
breakpoints on thread 3 with thread 1 and 2 running.

Thus leading to thread 1 or 2 executing invalid memory, thus the SIGILL
random problems...

Could either of you elaborate on this chat ? (I could not find any
reference in the mail archives...)

Thanks,
Antoine