From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25198 invoked by alias); 10 Jun 2013 15:39:22 -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 25165 invoked by uid 89); 10 Jun 2013 15:39:17 -0000 X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_MED,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,TW_EG,TW_TD autolearn=ham version=3.3.1 Received: from e06smtp14.uk.ibm.com (HELO e06smtp14.uk.ibm.com) (195.75.94.110) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 10 Jun 2013 15:39:16 +0000 Received: from /spool/local by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 10 Jun 2013 16:32:19 +0100 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp14.uk.ibm.com (192.168.101.144) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 10 Jun 2013 16:32:17 +0100 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 778EC17D805C for ; Mon, 10 Jun 2013 16:40:31 +0100 (BST) Received: from d06av08.portsmouth.uk.ibm.com (d06av08.portsmouth.uk.ibm.com [9.149.37.249]) by b06cxnps4076.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r5AFd0b847841522 for ; Mon, 10 Jun 2013 15:39:00 GMT Received: from d06av08.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id r5AFdA9T004977 for ; Mon, 10 Jun 2013 09:39:10 -0600 Received: from br87z6lw.de.ibm.com (dyn-9-152-212-143.boeblingen.de.ibm.com [9.152.212.143]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id r5AFd9vI004960; Mon, 10 Jun 2013 09:39:10 -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> <87d2rxu6r0.fsf@br87z6lw.de.ibm.com> <51B22D43.9080304@redhat.com> Date: Mon, 10 Jun 2013 16:59:00 -0000 In-Reply-To: <51B22D43.9080304@redhat.com> (Pedro Alves's message of "Fri, 07 Jun 2013 19:58:11 +0100") Message-ID: <877gi2t1pd.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: 13061015-1948-0000-0000-00000562D992 X-SW-Source: 2013-06/txt/msg00230.txt.bz2 Pedro Alves writes: > On 06/07/2013 07:15 PM, Andreas Arnez wrote: >> Pedro Alves writes: >>> 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. > > Okay. How are the TDB registers presented to the user (info > all-registers, etc) in the current patchset when the target supports > them, but the inferior is presently interrupted outside a transaction, > with live debugging? (screenshot, please! :-)) (gdb) info all-reg pswm 0x705200180000000 505845723963588608 pswa 0x8000060a 2147485194 --- /snip/ --- tdb0 *value not available* tac *value not available* tct *value not available* atia *value not available* tr0 *value not available* tr1 *value not available* tr2 *value not available* tr3 *value not available* tr4 *value not available* tr5 *value not available* tr6 *value not available* tr7 *value not available* tr8 *value not available* tr9 *value not available* tr10 *value not available* tr11 *value not available* tr12 *value not available* tr13 *value not available* tr14 *value not available* tr15 *value not available* pc 0x8000060a 0x8000060a cc 0x2 2 When there's no TDB for the current inferior's state, "value not available" is the closest representation I could find in the current regcache design. Or maybe there is a better way? My assumption was that this representation is even acceptable when the inferior runs on a target without transactional-execution support, because there's really no difference between a program that *never uses* transactions and a program that *can not* use transactions. But I can certainly take a shot at an alternate version of the patch which introduces new target descriptions "s390x-linux64v2-tx" and "s390-linux64v2-tx" and selects one of those if the hardware supports transactions. That's what's being proposed, right? > The new org.gnu.gdb.s390.tdb target feature needs to be documented, > btw. OK, will do that in my updated patch. > TDB support should be mentioned in NEWS too. Will do. > With xi:include, that's really pretty manageable. Please do take a > look at ppc_linux_read_description and at features/rs6000/, for > example, though there are several others in the tree. The x86 port > has a complex selection of proper description/register set too, given > xsave. Did you want to hint at anything specific? Or just how to add a new tdesc in general (and select it)?