This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 0/9 V3] Use reinsert breakpoint for vCont;s
- From: Antoine Tremblay <antoine dot tremblay at ericsson dot com>
- To: Pedro Alves <palves at redhat dot com>, Yao Qi <qiyaoltc at gmail dot com>
- Cc: <gdb-patches at sourceware dot org>
- Date: Mon, 14 Nov 2016 14:10:32 -0500
- Subject: Re: [PATCH 0/9 V3] Use reinsert breakpoint for vCont;s
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=antoine dot tremblay at ericsson dot com;
- References: <1467295765-3457-1-git-send-email-yao.qi@linaro.org>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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