From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24947 invoked by alias); 12 Jan 2015 14:30:57 -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 24933 invoked by uid 89); 12 Jan 2015 14:30:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e06smtp16.uk.ibm.com Received: from e06smtp16.uk.ibm.com (HELO e06smtp16.uk.ibm.com) (195.75.94.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 12 Jan 2015 14:30:53 +0000 Received: from /spool/local by e06smtp16.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 12 Jan 2015 14:30:50 -0000 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp16.uk.ibm.com (192.168.101.146) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 12 Jan 2015 14:30:46 -0000 Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 501822190045 for ; Mon, 12 Jan 2015 14:30:14 +0000 (GMT) Received: from d06av11.portsmouth.uk.ibm.com (d06av11.portsmouth.uk.ibm.com [9.149.37.252]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t0CEUkWW56229900 for ; Mon, 12 Jan 2015 14:30:46 GMT Received: from d06av11.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av11.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t0CEUjkt005807 for ; Mon, 12 Jan 2015 07:30:45 -0700 Received: from br87z6lw.de.ibm.com (sig-9-81-181-26.evts.de.ibm.com [9.81.181.26]) by d06av11.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id t0CEUiqm005774; Mon, 12 Jan 2015 07:30:44 -0700 From: Andreas Arnez To: Mark Kettenis Cc: palves@redhat.com, jan.kratochvil@redhat.com, gdb-patches@sourceware.org Subject: Re: [testsuite patch] for: [PATCH] [PR corefiles/17808] i386: Fix internal error when prstatus in core file is too big References: <874ms18cyz.fsf@br87z6lw.de.ibm.com> <20150108164327.GA29029@host2.jankratochvil.net> <87zj9s70bh.fsf@br87z6lw.de.ibm.com> <54B00160.5000309@redhat.com> <201501091659.t09GxO1q016197@glazunov.sibelius.xs4all.nl> <54B00D92.4050409@redhat.com> <201501091935.t09JZA6f017629@glazunov.sibelius.xs4all.nl> <54B035D8.6010003@redhat.com> <201501092030.t09KUAd8016363@glazunov.sibelius.xs4all.nl> Date: Mon, 12 Jan 2015 14:30:00 -0000 In-Reply-To: <201501092030.t09KUAd8016363@glazunov.sibelius.xs4all.nl> (Mark Kettenis's message of "Fri, 9 Jan 2015 21:30:10 +0100 (CET)") Message-ID: <87oaq46pgr.fsf@br87z6lw.de.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15011214-0025-0000-0000-000003546B2D X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00298.txt.bz2 On Fri, Jan 09 2015, Mark Kettenis wrote: >> Date: Fri, 09 Jan 2015 20:11:04 +0000 >> From: Pedro Alves >> >> ... >> I think we're saying the same thing, but what I'm calling "expected", >> you're calling "maximum". As in, consider the case where GDB >> about a regset section that is supposed to have size A. GDB is taught >> about this, with "minimum" == A, and "expected/maximum" == A. Later at >> some point, a new variant of the machine appears with more registers, and >> the regset is extended, to size B. A GDB that only knows about A encounters >> a core dump with B, and thus issues a warning (which suggests that either >> more info is available that gdb doesn't grok, or the core is broken), but still >> presents the A registers to the user. Later, someone teaches GDB about B >> registers, and at that point, "minimum" stays A, but "expected/maximum" is >> set to B. At some point, if the regset is extended further to C, a GDB >> that knows about A and B warns when it sees C. And on and on. I think >> we've already seen something like that with the x86 xsave regset? > > Yes, the x86 "FPU" register set certainly is an example I had in mind. > It all started when SSE was introduced. Right, the floating point register set has grown over time. The good thing is that x86 Linux platforms represent the different FPU regset versions with different target descriptions. (As determined from a core file with the core_read_description gdbarch method.) In this way the regset size passed to the iterator callback could match the "expected" size, not just the minimum. However, the size is currently not calculated at all for ".reg-xstate". I think this should be fixed, probably by using X86_XSTATE_SIZE.