This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v1] Intel(R) MPX - Bound violation handling.
- From: Pedro Alves <palves at redhat dot com>
- To: "Tedeschi, Walfred" <walfred dot tedeschi at intel dot com>, Joel Brobecker <brobecker at adacore dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Mon, 21 Dec 2015 17:23:19 +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>
Hi Walfred,
(Please don't top post.)
On 12/15/2015 10:58 AM, Tedeschi, Walfred wrote:
> From: Pedro Alves [mailto:palves@redhat.com]
> On 12/14/2015 05:43 PM, Tedeschi, Walfred wrote:
>>> >> + 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?
>
> 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.
I gave this some thought, and ended up filling 2 PRs and a proposal forward:
[Bug breakpoints/19388] Access $_siginfo in breakpoint (catch signal) condition
https://sourceware.org/bugzilla/show_bug.cgi?id=19388
[Bug gdb/19389] GDB sometimes mistakenly allows accessing registers of running threads
https://sourceware.org/bugzilla/show_bug.cgi?id=19389
I think that to move forward we should change validate_siginfo_access to
check is_executing instead of is_running for now. I think it'll
fix your case (please give it a try). It's the same check that we do to
prevent accessing registers from a running thread. $_siginfo is
conceptually really no different from registers -- we could think of it as
just another register.
I sent a patch that does that here, along with testcase that justifies
it on its own, independently of MPX:
[PATCH] Fix PR19388: Can't access $_siginfo in breakpoint (catch signal) condition
https://sourceware.org/ml/gdb-patches/2015-12/msg00443.html
By making this change, $_siginfo will become exposed to PR19389 too,
just like registers, and we should definitely fix it, but that seems
like a lesser evil than not being able to get at the info at all.
Thanks,
Pedro Alves