This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v1] Intel(R) MPX - Bound violation handling.
- From: Pedro Alves <palves at redhat dot com>
- To: "Tedeschi, Walfred" <walfred dot tedeschi at intel dot com>, "'Joel Brobecker'" <brobecker at adacore dot com>
- Cc: "'gdb-patches at sourceware dot org'" <gdb-patches at sourceware dot org>
- Date: Wed, 16 Dec 2015 16:52:54 +0000
- Subject: Re: [PATCH v1] Intel(R) MPX - Bound violation handling.
- Authentication-results: sourceware.org; auth=none
- References: <1445864086-4831-1-git-send-email-walfred dot tedeschi at intel dot com> <1445864086-4831-4-git-send-email-walfred dot tedeschi at intel dot com> <20151119000134 dot GB7958 at adacore dot com> <AC542571535E904D8E8ADAE745D60B1944505D29 at IRSMSX104 dot ger dot corp dot intel dot com> <566F0E37 dot 8090905 at redhat dot com> <AC542571535E904D8E8ADAE745D60B194450629D at IRSMSX104 dot ger dot corp dot intel dot com> <AC542571535E904D8E8ADAE745D60B1944506C80 at IRSMSX104 dot ger dot corp dot intel dot com>
On 12/16/2015 03:19 PM, Tedeschi, Walfred wrote:
> Pedro,
>
> We have found an interesting fact, changing the order the observer_notify_signal_recieved from about line 8170 to just before
> Observer_notify_normal_stop. Allows the evaluation of the siginfo without the stop.
That's because we're about to present a stop to the user, so we
mark the threads as stopped in between:
/* Let the user/frontend see the threads as stopped. */
do_cleanups (old_chain);
But there's another observer_notify_signal_received
call that is done while threads are still marked running. Here
when we print the signal, but don't stop:
/* Notify observers the signal has "handle print" set. Note we
returned early above if stopping; normal_stop handles the
printing in that case. */
if (signal_print[ecs->event_thread->suspend.stop_signal])
{
/* The signal table tells us to print about this signal. */
target_terminal_ours_for_output ();
observer_notify_signal_received (ecs->event_thread->suspend.stop_signal);
target_terminal_inferior ();
}
Should gdb print the extra info in that case?
In any case, for the normal_stop case, I think you'd want to move
the observers call to just after the do_cleanups call shown above.
At least, put it before the stop hook handling. If something sets the
target running in the stop hook, then you'd lose stopped_by_random_signal.
> Looking at the code I could not see anything could harm there.
This may change output order, both CLI and MI. Please actually
try using the resulting gdb to intercept a signal, and compare it
with an unpatched gdb. Also, running the testsuite wouldn't be
a bad idea...
>
> What do you think? Is moving that code a possibility?
Thanks,
Pedro Alves