This is the mail archive of the
mailing list for the GDB project.
RE: [PATCH v1] Intel(R) MPX - Bound violation handling.
- From: "Tedeschi, Walfred" <walfred dot tedeschi at intel dot com>
- To: Pedro Alves <palves at redhat dot com>, "Joel Brobecker (brobecker at adacore dot com)" <brobecker at adacore dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Thu, 17 Dec 2015 17:31:07 +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> <567196E6 dot 9040602 at redhat dot com>
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,
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Pedro Alves
Sent: Wednesday, December 16, 2015 5:53 PM
To: Tedeschi, Walfred; 'Joel Brobecker'
Subject: Re: [PATCH v1] Intel(R) MPX - Bound violation handling.
On 12/16/2015 03:19 PM, Tedeschi, Walfred wrote:
> 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. */
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. */
/* The signal table tells us to print about this signal. */
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?
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