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>
- Cc: "'gdb-patches at sourceware dot org'" <gdb-patches at sourceware dot org>
- Date: Wed, 16 Dec 2015 15:19:40 +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>
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.
Looking at the code I could not see anything could harm there.
What do you think? Is moving that code a possibility?
Thanks and regards,
From: Tedeschi, Walfred
Sent: Tuesday, December 15, 2015 11:59 AM
To: Pedro Alves; Joel Brobecker
Subject: RE: [PATCH v1] Intel(R) MPX - Bound violation handling.
It comes from the infrun.c (validate_siginfo_access) .
The requirement is not running is not fulfilled. Also in the case that we execute a lookup_interval and ask for value_contents we trigger the same code.
What would be the suggestion here:
Additional function to be used internally in infrun or add a flag.
Thanks a lot for your comments and insights!
From: Pedro Alves [mailto:email@example.com]
Sent: Monday, December 14, 2015 7:45 PM
To: Tedeschi, Walfred; Joel Brobecker
Subject: Re: [PATCH v1] Intel(R) MPX - Bound violation handling.
On 12/14/2015 05:43 PM, Tedeschi, Walfred wrote:
> Joel and Pedro,
> Thanks a lot for your feedback!
> I Could address most of the comments in here.
> An important one is still missing, namely this one:
>> + long si_code;
>> + struct regcache *regcache = get_current_regcache ();
>> + struct gdbarch *gdbarch = get_regcache_arch (regcache);
>> + set_running (user_visible_resume_ptid (1), 0);
> This is the part that _really_ concerns me, not necessary because I think it's wrong (although, it is a big red flag for me), but because I don't understand why it's needed, and how it will affect things.
> (From Joel)
>> + si_code = parse_and_eval_long ("$_siginfo.si_code\n");
> During the debugging time I understood that inferior was stopped. Gdb is that was in the process to determine in which state the inferior was.
> In this sense I set the flag at this point to allow for the evaluation.
Where is the error thrown that required brute-forcing set_running away?
Can we try to find some other way to handle this? E.g., use something a bit lower level than parse_and_eval_long that bypasses the error? E.g., start from lookup_internalvar and then use type/value manipulation routines?
> I also looked in gdb for error handling while performing evaluations but did not find anything.
> I am considering that the way to proceed is to use TRY and CATCH blocks. Would you recommend that?
> Thanks and regards,
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