From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84979 invoked by alias); 13 Jul 2018 16:38:38 -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 84969 invoked by uid 89); 13 Jul 2018 16:38:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 13 Jul 2018 16:38:36 +0000 Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6DGUVT1085698 for ; Fri, 13 Jul 2018 12:38:35 -0400 Received: from e06smtp04.uk.ibm.com (e06smtp04.uk.ibm.com [195.75.94.100]) by mx0b-001b2d01.pphosted.com with ESMTP id 2k6vmy0w21-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 13 Jul 2018 12:38:34 -0400 Received: from localhost by e06smtp04.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 13 Jul 2018 17:38:33 +0100 Received: from b06cxnps4076.portsmouth.uk.ibm.com (9.149.109.198) by e06smtp04.uk.ibm.com (192.168.101.134) 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 17:38:30 +0100 Received: from d06av22.portsmouth.uk.ibm.com (d06av22.portsmouth.uk.ibm.com [9.149.105.58]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w6DGcShp37617768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 13 Jul 2018 16:38:29 GMT Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 071B74C044; Fri, 13 Jul 2018 19:38:50 +0100 (BST) Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E620D4C040; Fri, 13 Jul 2018 19:38:49 +0100 (BST) Received: from oc3748833570.ibm.com (unknown [9.167.239.119]) by d06av22.portsmouth.uk.ibm.com (Postfix) with ESMTP; Fri, 13 Jul 2018 19:38:49 +0100 (BST) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id 5F9F3D80276; Fri, 13 Jul 2018 18:38:28 +0200 (CEST) Subject: Re: [PATCH 16/17] [PowerPC] Add support for EBB and PMU registers To: pedromfc@linux.ibm.com (Pedro Franco de Carvalho) Date: Fri, 13 Jul 2018 16:38:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, edjunior@gmail.com In-Reply-To: <20180713135226.2321-17-pedromfc@linux.ibm.com> from "Pedro Franco de Carvalho" at Jul 13, 2018 10:52:25 AM MIME-Version: 1.0 x-cbid: 18071316-0016-0000-0000-000001E68CB8 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18071316-0017-0000-0000-0000323B2A28 Message-Id: <20180713163828.5F9F3D80276@oc3748833570.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-SW-Source: 2018-07/txt/msg00420.txt.bz2 Pedro Franco de Carvalho wrote: > All three EBB registers are accessible. Only a subset of the PMU > registers can be accessed through ptrace. Because of this, the PMU > registers are enumerated indivitually in gdbarch_tdep, as opposed to > having a single "have_pmu" flag. This is intended to make it easier to > add additional PMU registers in the future, since checking a > "have_pmu" flag elsewhere in the code would no longer be correct. > > It's unclear if it makes sense to save and restore these registers > across function calls, since some of them can be modified > asynchronously. They are also not tracked in record-replay mode. Agreed, they should not be saved and restored. > Currently, the kernel can return ENODATA when ptrace is used to get > the EBB registers, unless a linux performance event that uses EBB is > open in the inferior. However, EBB registers are always saved and > restored by the kernel, but not the PMU registers, so the ENODATA > might have been meant for the PMU registers. For this reason GDB > handles ENODATA for both regsets. It would be good to clarify this with kernel people. > Like for the previous patches, configure.srv is updated here to avoid > breaking the build at this patch. Same comment as before. > > > > + > + > Adding these in the middle causes a bit of churn in the generated files. (It re-shuffles the gdbserver protocol register buffer instead of just adding to the end.) Now this *should* still all be compatible, but I guess it would be better to avoid the churn; either add this patch before the HTM patch, or else change the sequence in the XML file. > /* Hardware transactional memory registers. */ > - PPC_TFHAR_REGNUM = 175, > - PPC_TEXASR_REGNUM = 176, > - PPC_TFIAR_REGNUM = 177, > + PPC_TFHAR_REGNUM = 183, > + PPC_TEXASR_REGNUM = 184, > + PPC_TFIAR_REGNUM = 185, Similar comment to above, can we not avoid this renumbering churn? Also, I see you haven't got any test cases for this? Would these be difficult to add? Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com