From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97646 invoked by alias); 19 Nov 2015 09:52:31 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 97633 invoked by uid 89); 19 Nov 2015 09:52:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mga02.intel.com Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Nov 2015 09:52:28 +0000 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 19 Nov 2015 01:52:04 -0800 X-ExtLoop1: 1 Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by orsmga002.jf.intel.com with ESMTP; 19 Nov 2015 01:52:03 -0800 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.138]) by IRSMSX103.ger.corp.intel.com ([169.254.3.13]) with mapi id 14.03.0248.002; Thu, 19 Nov 2015 09:51:18 +0000 From: "Tedeschi, Walfred" To: Joel Brobecker , "Yao Qi (yao@codesourcery.com)" CC: "palves@redhat.com" , "gdb-patches@sourceware.org" Subject: RE: [PATCH v1] Synchronize siginfo type described in GDB with the kernel and glibc ones. Date: Thu, 19 Nov 2015 09:52:00 -0000 Message-ID: References: <1445864086-4831-1-git-send-email-walfred.tedeschi@intel.com> <1445864086-4831-3-git-send-email-walfred.tedeschi@intel.com> <20151118230151.GA7958@adacore.com> In-Reply-To: <20151118230151.GA7958@adacore.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00382.txt.bz2 Joel and all, First of all, Thanks a lot for your review, on both patches! I had a discussion on the GDB list about this topic. Observation from Yao was that we could use this structure on new and old ke= rnels. https://sourceware.org/ml/gdb/2015-07/msg00029.html This was the reason why I wanted to keep it simple and avoid doing any king= of check. I understood from the kernel and glibc patches that the kernel is generic (= all architectures) and the=20 glibc is added for Intel only. =20 Finally I think it is also better to describe a bit what happens with the n= ew fields in the kernel side. In case we have a bound violation, the kernel does a disassemble of the cur= rent instruction, Reads the values of the operands of the compare bound instructions and set = the _low and _upper bound. At the same time it sets the sig_code to 3. I.e. Those fields are only vali= d if the sigcode is 3. 1. Make a mechanism to determine which siginfo version to be used depending= from the system being debugged. I am not sure if there is such a mechanism in GDB already or how error prun= e it would be to be able to detect pre presence of these fields from the kernel side and glibc = (in the case of the glibc also taking into account the architecture).=20 2. Set the field _low and _upper to 0 in case the sigcode is not 3. Any ideas or comments on that. Thanks and regards, -Fred -----Original Message----- From: Joel Brobecker [mailto:brobecker@adacore.com]=20 Sent: Thursday, November 19, 2015 12:02 AM To: Tedeschi, Walfred Cc: palves@redhat.com; gdb-patches@sourceware.org Subject: Re: [PATCH v1] Synchronize siginfo type described in GDB with the = kernel and glibc ones. > New kernel and glibc patches have introduced fields in the=20 > segmentation fault fields. >=20 > Kernel patch: > http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=3Dee1 > b58d36aa1b5a79eaba11f5c3633c88231da83 >=20 > Glibc patch: > http://repo.or.cz/w/glibc.git/commit/d4358b51c26a634eb885955aea06cad26 > af6f696 >=20 > 2015-07-21 Walfred Tedeschi >=20 > * linux-tdep.c (linux_get_siginfo_type): Add the _addr_bnd > structure to the siginfo. I would really like someone like Pedro to review this patch, as I am really= uncertain about the idea of extending our view of the structure without a = way of checking that you have kernel and glibc support for it. As far as I = can tell, this sets things up so as to ready undefined data, thus leading t= o undefined behavior. >=20 > --- > gdb/linux-tdep.c | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-) >=20 > diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c index=20 > 7c24eaa..de773ae 100644 > --- a/gdb/linux-tdep.c > +++ b/gdb/linux-tdep.c > @@ -248,10 +248,10 @@ static struct type * linux_get_siginfo_type=20 > (struct gdbarch *gdbarch) { > struct linux_gdbarch_data *linux_gdbarch_data; > - struct type *int_type, *uint_type, *long_type, *void_ptr_type; > + struct type *int_type, *uint_type, *long_type, *void_ptr_type,=20 > + *short_type; > struct type *uid_type, *pid_type; > struct type *sigval_type, *clock_type; > - struct type *siginfo_type, *sifields_type; > + struct type *siginfo_type, *sifields_type, *sigfault_bnd_fields; > struct type *type; >=20=20 > linux_gdbarch_data =3D get_linux_gdbarch_data (gdbarch); @@ -264,6=20 > +264,8 @@ linux_get_siginfo_type (struct gdbarch *gdbarch) > 1, "unsigned int"); > long_type =3D arch_integer_type (gdbarch, gdbarch_long_bit (gdbarch), > 0, "long"); > + short_type =3D arch_integer_type (gdbarch, gdbarch_long_bit (gdbarch), > + 0, "short"); > void_ptr_type =3D lookup_pointer_type (builtin_type=20 > (gdbarch)->builtin_void); >=20=20 > /* sival_t */ > @@ -339,6 +341,12 @@ linux_get_siginfo_type (struct gdbarch *gdbarch) > /* _sigfault */ > type =3D arch_composite_type (gdbarch, NULL, TYPE_CODE_STRUCT); > append_composite_type_field (type, "si_addr", void_ptr_type); > + append_composite_type_field (type, "_addr_lsb", short_type); > + > + sigfault_bnd_fields =3D arch_composite_type (gdbarch, NULL,=20 > + TYPE_CODE_STRUCT); append_composite_type_field=20 > + (sigfault_bnd_fields, "_lower", void_ptr_type);=20=20 > + append_composite_type_field (sigfault_bnd_fields, "_upper",=20 > + void_ptr_type); append_composite_type_field (type, "_addr_bnd",=20 > + sigfault_bnd_fields); > append_composite_type_field (sifields_type, "_sigfault", type); >=20=20 > /* _sigpoll */ > -- > 2.1.4 -- Joel 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