From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15721 invoked by alias); 19 Nov 2015 17:07:13 -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 15710 invoked by uid 89); 19 Nov 2015 17:07:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 19 Nov 2015 17:07:12 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id AD10AC0BFBA1; Thu, 19 Nov 2015 17:07:10 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tAJH78h2028923; Thu, 19 Nov 2015 12:07:09 -0500 Message-ID: <564E01BC.4030402@redhat.com> Date: Thu, 19 Nov 2015 17:07:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Tedeschi, Walfred" , 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. 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: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-11/txt/msg00406.txt.bz2 On 11/19/2015 04:40 PM, Tedeschi, Walfred wrote: > Pedro, > > If I understood you right you are in favour of keeping the siginfo as global one? > In case this is correct, I will start working on the code you pointed out. I favor not querying whether the running x86 kernel supports the extra field. But I wouldn't say I'm in favor of exposing the field in all targets -- more like, if it's hard and we really want to be lazy, I see no real big harm in making the change affect all archs, though I'd mildly prefer making the change be x86-specific, like glibc did. I actually think it'd be simple. IIRC, Yao already suggested how to do it without much changes. Simply rename the existing linux_get_siginfo_type function, and add a new parameter that allows saying "I want field X". Then the x86 version can install a siginfo type with the field, while other ports not. e.g., enum linux_siginfo_extra_field_values { LINUX_SIGINFO_FIELD_ADDR_BND = 1, ... }; DEF_ENUM_FLAGS_TYPE (enum linux_siginfo_extra_field_values, linux_siginfo_extra_fields); static struct type * linux_get_siginfo_type_with_fields (struct gdbarch *gdbarch, linux_siginfo_extra_fields extra_fields) { ... if ((extra_fields & LINUX_SIGINFO_FIELD_ADDR_BND) != 0) { ... } } static struct type * linux_get_siginfo_type (struct gdbarch *gdbarch) { return linux_get_siginfo_type_with_fields (gdbarch, 0); } x86: x86_linux_get_siginfo_type_with_fields (struct gdbarch *gdbarch, linux_siginfo_extra_fields extra_fields) { return linux_get_siginfo_type_with_fields (gdbarch, LINUX_SIGINFO_FIELD_ADDR_BND); } ... set_gdbarch_get_siginfo_type (gdbarch, x86_linux_get_siginfo_type_with_fields); ... > > What I could see from the glibc code the structure is reset via memset. Actually, gdb reads the siginfo object out of the kernel directly, so whatever glibc does has no bearing here. The question is whether the kernel really shows garbage in those fields when si_code is not 3, or whether it always pre-fills the siginfo objects (including the padding) with zeroes. > > Thanks a lot for your feedback! > Muito obrigado! You're welcome. De nada. ;-) Thanks, Pedro Alves