From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8462 invoked by alias); 11 Jun 2013 10:43:44 -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 8423 invoked by uid 89); 11 Jun 2013 10:43:38 -0000 X-Spam-SWARE-Status: No, score=-7.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS,TW_EG,TW_TD autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 11 Jun 2013 10:43:37 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r5BAhVfu014041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Jun 2013 06:43:31 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r5BAhTBB023581; Tue, 11 Jun 2013 06:43:30 -0400 Message-ID: <51B6FF51.3080701@redhat.com> Date: Tue, 11 Jun 2013 10:48:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andreas Arnez 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> <877gi2t1pd.fsf@br87z6lw.de.ibm.com> In-Reply-To: <877gi2t1pd.fsf@br87z6lw.de.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-06/txt/msg00240.txt.bz2 On 06/10/2013 04:39 PM, Andreas Arnez wrote: > 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. It's close but not the same. If the machine doesn't have those registers, then they should not presented at all. > > 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? Right. We usually name the descriptions "CPU/PART-ABI/OS.xml", with cpu/part number being e.g., powerpc-750 for "PowerPC 750". but I have no idea about S/390 cpu names. E.g., when dsp registers get added to mips64-linux.xml, we get mips64-dsp-linux.xml. Maybe you should drop the v2 going forward (I think v1/v2 made sense since the additions were Linux specific, not a new machine), and make the new one "s390x-tx-linux64" or some other cpu name that'd make most sense. Or make that v3, dunno, up to you. >> 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? With > Actually representing n optional register sets with different tdescs > would require 2**n tdescs, right? you seemed to be worried by the explosion of the number of target descriptions. I was pointing out at an example in the tree where for the same general architecture family we have many target descriptions, one per each different machine with a different set of register sets, as an example of that not really being a problem. > Or just how to add a new tdesc in general (and select it)? That too. Thanks, -- Pedro Alves