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

["Tedeschi, Walfred" <walfred dot tedeschi at intel dot com>]

Pedro,

We have lost the print when not stopping, by doing that.
Idea was also to print in that case.
Any idea how we could also handle the other case?

For the stopping case all seems fine. Will run tests again to be sure.

Thanks and regards,
-Fred


-----Original Message-----
From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Pedro Alves
Sent: Wednesday, December 16, 2015 5:53 PM
To: Tedeschi, Walfred; 'Joel Brobecker'
Cc: 'gdb-patches@sourceware.org'
Subject: Re: [PATCH v1] Intel(R) MPX - Bound violation handling.

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

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928