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

[Pedro Alves <palves@redhat.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