From: "Tedeschi, Walfred" <walfred.tedeschi@intel.com>
To: 'Pedro Alves' <palves@redhat.com>,
'Joel Brobecker' <brobecker@adacore.com>
Cc: "'gdb-patches@sourceware.org'" <gdb-patches@sourceware.org>
Subject: RE: [PATCH v1] Intel(R) MPX - Bound violation handling.
Date: Wed, 16 Dec 2015 15:21:00 -0000 [thread overview]
Message-ID: <AC542571535E904D8E8ADAE745D60B1944506C80@IRSMSX104.ger.corp.intel.com> (raw)
In-Reply-To: <AC542571535E904D8E8ADAE745D60B194450629D@IRSMSX104.ger.corp.intel.com>
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.
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,
-Fred
-----Original Message-----
From: Tedeschi, Walfred
Sent: Tuesday, December 15, 2015 11:59 AM
To: Pedro Alves; Joel Brobecker
Cc: gdb-patches@sourceware.org
Subject: RE: [PATCH v1] Intel(R) MPX - Bound violation handling.
Pedro,
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!
Best regards,
-Fred
-----Original Message-----
From: Pedro Alves [mailto:palves@redhat.com]
Sent: Monday, December 14, 2015 7:45 PM
To: Tedeschi, Walfred; Joel Brobecker
Cc: gdb-patches@sourceware.org
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?
Thanks,
Pedro Alves
>
> 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
next prev parent reply other threads:[~2015-12-16 15:21 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-26 15:09 [PATCH obv] Changing compiler flags for MPX tests Walfred Tedeschi
2015-10-26 16:10 ` [PATCH v1] Intel(R) MPX registers to the DWARF enumeration Walfred Tedeschi
2015-12-06 16:35 ` Joel Brobecker
2015-12-06 17:42 ` H.J. Lu
2015-12-07 8:29 ` Tedeschi, Walfred
2015-10-26 16:11 ` [PATCH v1] Synchronize siginfo type described in GDB with the kernel and glibc ones Walfred Tedeschi
2015-11-18 23:01 ` Joel Brobecker
2015-11-19 9:52 ` Tedeschi, Walfred
2015-11-19 13:27 ` Pedro Alves
2015-11-19 16:41 ` Tedeschi, Walfred
2015-11-19 17:07 ` Pedro Alves
2015-12-01 10:08 ` Tedeschi, Walfred
2015-12-01 12:08 ` Pedro Alves
2015-10-26 16:22 ` [PATCH v1] ABI changes for Intel(R) MPX Walfred Tedeschi
2015-10-26 19:07 ` Eli Zaretskii
2015-10-27 17:21 ` Tedeschi, Walfred
2015-12-06 16:16 ` Joel Brobecker
2015-10-26 16:25 ` [PATCH obv] Fix non stopping breakpoint on newer compilers Walfred Tedeschi
2015-11-04 14:42 ` Joel Brobecker
2015-10-26 16:26 ` [PATCH v1] Intel(R) MPX - Bound violation handling Walfred Tedeschi
2015-11-04 14:55 ` Joel Brobecker
2015-11-05 10:04 ` Tedeschi, Walfred
2015-11-19 0:01 ` Joel Brobecker
2015-12-14 17:43 ` Tedeschi, Walfred
2015-12-14 18:45 ` Pedro Alves
2015-12-15 11:01 ` Tedeschi, Walfred
2015-12-16 15:21 ` Tedeschi, Walfred [this message]
2015-12-16 16:52 ` Pedro Alves
2015-12-17 17:31 ` Tedeschi, Walfred
2015-12-21 17:23 ` Pedro Alves
2015-11-04 14:42 ` [PATCH obv] Changing compiler flags for MPX tests Joel Brobecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AC542571535E904D8E8ADAE745D60B1944506C80@IRSMSX104.ger.corp.intel.com \
--to=walfred.tedeschi@intel.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox