From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33255 invoked by alias); 13 Jul 2018 18:16:43 -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 33160 invoked by uid 89); 13 Jul 2018 18:16:42 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=AMR, amr X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 13 Jul 2018 18:16:41 +0000 Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6DIEMlQ075751 for ; Fri, 13 Jul 2018 14:16:39 -0400 Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by mx0a-001b2d01.pphosted.com with ESMTP id 2k6xq0p4hw-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 13 Jul 2018 14:16:39 -0400 Received: from localhost by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 13 Jul 2018 12:16:38 -0600 Received: from b03cxnp07029.gho.boulder.ibm.com (9.17.130.16) by e36.co.us.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Fri, 13 Jul 2018 12:16:35 -0600 Received: from b03ledav005.gho.boulder.ibm.com (b03ledav005.gho.boulder.ibm.com [9.17.130.236]) by b03cxnp07029.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w6DIGWP67012712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 13 Jul 2018 11:16:32 -0700 Received: from b03ledav005.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C336ABE051; Fri, 13 Jul 2018 12:16:32 -0600 (MDT) Received: from b03ledav005.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 81AE6BE054; Fri, 13 Jul 2018 12:16:32 -0600 (MDT) Received: from pedro.localdomain (unknown [9.85.180.127]) by b03ledav005.gho.boulder.ibm.com (Postfix) with ESMTP; Fri, 13 Jul 2018 12:16:32 -0600 (MDT) Received: by pedro.localdomain (Postfix, from userid 1000) id B176F3C0472; Fri, 13 Jul 2018 15:16:29 -0300 (-03) From: Pedro Franco de Carvalho To: Ulrich Weigand Cc: gdb-patches@sourceware.org, edjunior@gmail.com Subject: Re: [PATCH 13/17] [PowerPC] Add support for HTM registers In-Reply-To: <20180713162433.9A714D80276@oc3748833570.ibm.com> References: <20180713162433.9A714D80276@oc3748833570.ibm.com> Date: Fri, 13 Jul 2018 18:16:00 -0000 MIME-Version: 1.0 Content-Type: text/plain x-cbid: 18071318-0020-0000-0000-00000E3D8EE5 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00009364; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000266; SDB=6.01060851; UDB=6.00544578; IPR=6.00838769; MB=3.00022133; MTD=3.00000008; XFM=3.00000015; UTC=2018-07-13 18:16:36 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18071318-0021-0000-0000-0000624553EA Message-Id: <87efg7j91e.fsf@linux.vnet.ibm.com> X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg00423.txt.bz2 Ulrich Weigand writes: > Pedro Franco de Carvalho wrote: > Well, this is weird. Either the kernel should be fixed to use the > smaller size as well, or else GDB should also generate the large > section (and zero out the second half). OK. One more thing about the checkpointed registers: Linux doesn't currently support AMR, but it is specified by the architecture to be checkpointed as well. If it is added in the future, its checkpointed version will either need to be a separate tdesc feature or rs6000_gdbarch_init will have to accept a org.gnu.gdb.power.htm feature with and without it. The tdep object might also need a separate field, since it won't be possible to rely on tdep->have_htm to know if a checkpointed amr is available in the gdbarch. This is different from the approach I took for the incomplete pmu registers, where I enumerated all the ones that are there in the tdep object. Doing this for all the htm registers would add a lot more fields. > I'm not sure I like this approach. The problem is only about > generating core files, right? Why don't we instead simply > change linux-tdep.c:linux_collect_regset_section_cb from > > buf = (char *) xmalloc (size); > regset->collect_regset (regset, data->regcache, -1, buf, size); > > to use xcalloc instead? This seems prudent anyway. (The same applies > to the similar code in fbsd-tdep.c.) > > Then we can probably even get rid of ppc_linux_collect_vrregset as well. Yes, this seems like a much simpler approach. > Hmm. The DFP and EFP pseudo registers are simply GDB views onto the > normal FP / VR register set. For completeness, shouldn't we also offer > similar views onto the checkpointed register set? OK. I had removed them thinking they weren't going to be used a lot, but I'll put them back in for completeness. > It looks a bit odd that we need to use variable numbers for > the vr0 / fp0 / vsr0 registers, but can hard-code the numbers > for the checkpointed register set. Why is this the case? There isn't a good reason, I probably just didn't change the way it was done for the regular registers. I will change them to use the hard-coded numbers for consistency (there is no tdep field for cvsr0_upper, cfp0 and cvr0). Thank you for the reviews! -- Pedro Franco de Carvalho