From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17843 invoked by alias); 19 Nov 2015 16:41:02 -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 17826 invoked by uid 89); 19 Nov 2015 16:41:02 -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: mga01.intel.com Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Nov 2015 16:40:59 +0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 19 Nov 2015 08:40:27 -0800 X-ExtLoop1: 1 Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66]) by fmsmga002.fm.intel.com with ESMTP; 19 Nov 2015 08:40:26 -0800 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.138]) by IRSMSX152.ger.corp.intel.com ([169.254.6.143]) with mapi id 14.03.0248.002; Thu, 19 Nov 2015 16:40:25 +0000 From: "Tedeschi, Walfred" To: Pedro Alves , Joel Brobecker , "Yao Qi (yao@codesourcery.com)" CC: "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 16:41: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> <564DCE42.5060000@redhat.com> In-Reply-To: <564DCE42.5060000@redhat.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/msg00405.txt.bz2 Pedro, If I understood you right you are in favour of keeping the siginfo as globa= l one? In case this is correct, I will start working on the code you pointed out. What I could see from the glibc code the structure is reset via memset. Thanks a lot for your feedback!=20 Muito obrigado! Best regards, -Fred -----Original Message----- From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-owner@sourceware= .org] On Behalf Of Pedro Alves Sent: Thursday, November 19, 2015 2:28 PM To: Tedeschi, Walfred; Joel Brobecker; Yao Qi (yao@c= odesourcery.com) Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v1] Synchronize siginfo type described in GDB with the = kernel and glibc ones. On 11/19/2015 09:51 AM, Tedeschi, Walfred wrote: > I understood from the kernel and glibc patches that the kernel is=20 > generic (all architectures) and the glibc is added for Intel only. IIRC, not all architectures in the kernel use /include/uapi/asm-generic/sig= info.h, and some have their own custom siginfo.h. Those should have a cust= om gdbarch_get_siginfo_type hook in gdb as well, but nobody has ever bother= ed to fix that this far, supposedly because the siginfo tests in the testsu= ite don't depend in bits of the siginfo objects that might differ on such a= rchitectures. It does look a bit odd to me to expose these new fields on all architecture= s, given that this is Intel/x86-only. But it doesn't _really_ hurt, other = than potentially being a little bit confusing. >=20=20 > Finally I think it is also better to describe a bit what happens with the= new fields in the kernel side. >=20 > In case we have a bound violation, the kernel does a disassemble of=20 > the current 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 va= lid if the sigcode is 3. >=20 > 1. Make a mechanism to determine which siginfo version to be used dependi= ng from the system being debugged. > I am not sure if there is such a mechanism in GDB already or how error=20 > prune it would be to be able to detect pre presence of these fields=20 > from the kernel side and glibc (in the case of the glibc also taking into= account the architecture). As alluded to above, the 'get_siginfo_type' method can be set different for= each gdbarch. So x86, arm, etc. each can tailor the siginfo type to their needs by instal= ling a different hook. In fact, it's what we did prior to 5cd867b414fe, ex= cept that before that commit, all archs were actually installing the same h= ook. Checking the kernel version would be more complicated, considering remote d= ebugging. We could have gdbserver probe for support for the feature, and t= hen report it in qSupported at connection time, for example, or even have t= he server fully describe the layout of the object (similar to how it can de= scribe register types, which you used in gdb/features/i386/64bit-mpx.xml), = though I don't think either would be warranted here. The siginfo object's layout and size is ABI, the kernel can't change it. E= ven though new fields have been added to the end of struct _sigfault, the _= sigfault field itself is part of a union, which is padded to SI_PAD_SIZE by= tes. That is, this change did not change the siginfo object's size. Since= we're only supposed to interpret the contents of the new elements when si_= code is 3 and the kernel never set si_code to 3 before, the change is also = fully backwards compatible. >=20 > 2. Set the field _low and _upper to 0 in case the sigcode is not 3. I'd just leave them be. You always have to know how to interpret the sigin= fo object's elements, and know which enum field to look at between siginfo.= _sifields.{_kill|_timer|_sigchld|etc.}, depending on si_code and si_signo. = Doesn't the kernel of glibc already always memset the whole object before = filling in the valid bits, BTW? Lastly, I think you missed tweaking amd64_linux_siginfo_fixup & co in order= to correctly convert these fields when debugging 32-bit and x32 programs o= n a 64-bit kernel. Likewise the gdbserver equivalents. Thanks, Pedro Alves 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