From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11439 invoked by alias); 17 Jul 2015 15:41:04 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 11381 invoked by uid 89); 17 Jul 2015 15:41:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f42.google.com Received: from mail-pa0-f42.google.com (HELO mail-pa0-f42.google.com) (209.85.220.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 17 Jul 2015 15:41:00 +0000 Received: by pactm7 with SMTP id tm7so63092514pac.2 for ; Fri, 17 Jul 2015 08:40:59 -0700 (PDT) X-Received: by 10.70.65.38 with SMTP id u6mr30222356pds.99.1437147659127; Fri, 17 Jul 2015 08:40:59 -0700 (PDT) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id xf2sm11664925pab.25.2015.07.17.08.40.56 (version=TLS1_2 cipher=AES128-SHA256 bits=128/128); Fri, 17 Jul 2015 08:40:58 -0700 (PDT) From: Yao Qi To: "Tedeschi\, Walfred" Cc: "Joel Brobecker \(brobecker\@adacore.com\)" , "Yao Qi \(qiyaoltc\@gmail.com\)" , "Pedro Alves \(palves\@redhat.com\)" , "gdb\@sourceware.org" Subject: Re: New siginfo type in kernel how to make gdb back compatible. References: Date: Fri, 17 Jul 2015 15:41:00 -0000 In-Reply-To: (Walfred Tedeschi's message of "Fri, 17 Jul 2015 12:35:09 +0000") Message-ID: <86mvyuiygx.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg00029.txt.bz2 "Tedeschi, Walfred" writes: > GDB should be nevertheless back compatible, i.e. capable of displaying th= e siginfo for applications running on systems having older glibc. > > In case this is desirable and I do think it is. > > How should we think about resolving that in terms of the siginfo type red= efined inside of GDB? GDB creates a type for "struct siginfo" in linux-tdep.c:linux_get_siginfo_type, and it should work well on both old kernel and new kernel, because the new fields are added the end of _sigfault. If you want to show these new added fields $_siginfo, then, I am not very sure. How are these two fields used? Are they only used when MPX is enabled in linux kernel? If so probably we can overwrite the default linux one (linux_get_siginfo_type) with a new one (linux_get_siginfo_type_1, for example) if i386_mpx_enabled is true. linux_get_siginfo_type_1 returns the type with new fields, and we call set_gdbarch_get_siginfo_type in i386_linux_init_abi like this, if (i386_mpx_enabled) set_gdbarch_get_siginfo_type (gdbarch, linux_get_siginfo_type_1); --=20 Yao (=E9=BD=90=E5=B0=A7)