From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6854 invoked by alias); 7 Jun 2013 18:16: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 6824 invoked by uid 89); 7 Jun 2013 18:15:55 -0000 X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_MED,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD autolearn=ham version=3.3.1 Received: from e06smtp10.uk.ibm.com (HELO e06smtp10.uk.ibm.com) (195.75.94.106) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 07 Jun 2013 18:15:54 +0000 Received: from /spool/local by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 7 Jun 2013 19:13:40 +0100 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp10.uk.ibm.com (192.168.101.140) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 7 Jun 2013 19:13:37 +0100 Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id D113B2190019 for ; Fri, 7 Jun 2013 19:19:03 +0100 (BST) Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps4075.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r57IFc9t37683432 for ; Fri, 7 Jun 2013 18:15:38 GMT Received: from d06av02.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id r57IFlRQ025425 for ; Fri, 7 Jun 2013 12:15:48 -0600 Received: from br87z6lw.de.ibm.com (dyn-9-152-212-143.boeblingen.de.ibm.com [9.152.212.143]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id r57IFk4s025415; Fri, 7 Jun 2013 12:15:47 -0600 From: Andreas Arnez To: Pedro Alves Cc: gdb-patches@sourceware.org, Ulrich Weigand Subject: Re: [RFA/RFT PATCH 0/3] Add TDB regset support References: <87fvwu5937.fsf@br87z6lw.de.ibm.com> <51B1F629.5070006@redhat.com> <87li6lud1m.fsf@br87z6lw.de.ibm.com> <51B20DFD.8040805@redhat.com> Date: Fri, 07 Jun 2013 18:16:00 -0000 In-Reply-To: <51B20DFD.8040805@redhat.com> (Pedro Alves's message of "Fri, 07 Jun 2013 17:44:45 +0100") Message-ID: <87d2rxu6r0.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: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13060718-4966-0000-0000-000005F65600 X-SW-Source: 2013-06/txt/msg00170.txt.bz2 Pedro Alves writes: > On 06/07/2013 04:59 PM, Andreas Arnez wrote: >> Pedro Alves writes: >> >>> Why isn't this exposed as a new target description that includes the >>> new register set? >> >> It would require extracting the hardware capabilities from the core >> file's auxiliary vector in order to distinguish between platforms with >> and without the transactional-execution facility. I guess it could be >> done, but I didn't consider it that important. > > You might not need to look at the auxv. Return the right tdesc > depending on presence of bfd sections. See ppc_linux_core_read_description. This doesn't work for the TDB, because the absence of the TDB register section doesn't mean that the core file target didn't support it. At least we'd break the gcore.exp test case. > If you connect a 7.6 GDB without this patch to a new GDBserver that > sends this extended regdat, I believe GDB will complain with > "Remote 'g' packet reply is too long", even if the target actually > doesn't support TDB. Hm, didn't realize that. But if the target does support TDB, we'd be in trouble either way, right? > You're extending the remote register buffer with an optional feature, > and in future when another alternative register set comes along that > replaces this one, we're in trouble, as we won't be able to tell > which is which (without ugly hacks). Well, the patch doesn't treat TDB as an optional feature, does it? In the future the TDB would always be included in the target description. Actually representing n optional register sets with different tdescs would require 2**n tdescs, right?