Re: [PATCH v1] Intel(R) MPX - Bound violation handling.

Pedro Alves
2015-12-16T16:52:59Z

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