From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119555 invoked by alias); 23 Oct 2018 18:42:24 -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 119541 invoked by uid 89); 23 Oct 2018 18:42:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,KHOP_DYNAMIC,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=filled 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; Tue, 23 Oct 2018 18:42:22 +0000 Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w9NIXiWM086766 for ; Tue, 23 Oct 2018 14:42:21 -0400 Received: from e11.ny.us.ibm.com (e11.ny.us.ibm.com [129.33.205.201]) by mx0a-001b2d01.pphosted.com with ESMTP id 2na6qf73sp-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 23 Oct 2018 14:42:20 -0400 Received: from localhost by e11.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 23 Oct 2018 14:42:20 -0400 Received: from b01cxnp23033.gho.pok.ibm.com (9.57.198.28) by e11.ny.us.ibm.com (146.89.104.198) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Tue, 23 Oct 2018 14:42:17 -0400 Received: from b01ledav005.gho.pok.ibm.com (b01ledav005.gho.pok.ibm.com [9.57.199.110]) by b01cxnp23033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w9NIgFd429229244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 23 Oct 2018 18:42:15 GMT Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 017C8AE066; Tue, 23 Oct 2018 18:42:15 +0000 (GMT) Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C7CCAAE060; Tue, 23 Oct 2018 18:42:14 +0000 (GMT) Received: from pedro.localdomain (unknown [9.18.235.38]) by b01ledav005.gho.pok.ibm.com (Postfix) with ESMTP; Tue, 23 Oct 2018 18:42:14 +0000 (GMT) Received: by pedro.localdomain (Postfix, from userid 1000) id 544E33C03FD; Tue, 23 Oct 2018 15:42:12 -0300 (-03) From: Pedro Franco de Carvalho To: Pedro Alves , gdb-patches@sourceware.org Cc: uweigand@de.ibm.com Subject: Re: [PATCH v5 00/12] GDB support for more powerpc registers on linux In-Reply-To: References: <20181022223242.7858-1-pedromfc@linux.ibm.com> Date: Tue, 23 Oct 2018 18:42:00 -0000 MIME-Version: 1.0 Content-Type: text/plain x-cbid: 18102318-2213-0000-0000-000003085604 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00009922; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000268; SDB=6.01106929; UDB=6.00573269; IPR=6.00887013; MB=3.00023875; MTD=3.00000008; XFM=3.00000015; UTC=2018-10-23 18:42:18 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18102318-2214-0000-0000-00005BFF3991 Message-Id: <878t2old2z.fsf@linux.vnet.ibm.com> X-IsSubscribed: yes X-SW-Source: 2018-10/txt/msg00517.txt.bz2 Pedro Alves writes: > I.e., what is the conclusion wrt to the differences in one of the note > sections generated by the kernel for a core file and the one generated > by GDB? Was that resolved? Will it be? Sorry, I really should have explained this better in the cover letter, and I forgot to update the commit message explaining the solution we picked for this issue. I discussed this with Ulrich and we came to the conclusion that it would be simpler to fill in the data for two of the registers that were different in the core file using other registers that are available to GDB, since they are not particularly useful as separate user-visible registers. This still leaves out some additional registers in this regset that GDB isn't aware of, which are most of the time 0. I will explain this in more detail below, but in this patch this is implemented with a different collect function used (ppc_linux_collect_core_cpgrregset) used by ppc_linux_iterate_over_regset_sections. To give you some background, the checkpointed registers are the values that are used to restore some of the regular registers to pre-transactional values in case a hardware transaction fails. This includes the GPRs, FPRs, vector registers and others. The kernel uses a pt_regs struct to hold the regular GPRs and various others registers. It also uses this struct to represent the equivalent checkpointed registers, and to generate the note section, except that only a subset of the registers in pt_regs is actually checkpointed by the processor. All of the registers that are actually checkpointed are visible to the GDB user and are correctly filled in the note section generated by GDB. This leaves out various other registers from pt_regs. One of these is the NIP (the pc), which the kernel fills in with the value of another register, TFHAR. Since TFHAR is in fact visible to GDB, GDB uses its value to fill in the corresponding slot in the core file. The "checkpointed" MSR (processor status register), is used by the kernel for some internal state tracking. We use the regular MSR to fill in the corresponding slot. These usually differ in some bits, and in certain conditions the checkpointed MSR from the kernel can be zero. The remaining registers in the checkpointed pt_regs are not filled in by the kernel and don't represent anything. They will only have non-zero values in a kernel-generated core file if someone explicitly sets them with ptrace before the process crashes. > As for the EBB/PMU patch, about gdbserver writing all registers in one go > before resuming the inferior, and the error would not being detected at the > time the user tries to write them, did you try making gdbserver flush > the regcache after handling 'G' and 'P' packets? From the previous > discussion, it sounded like that would work? I haven't tried this yet. I did think about this more and although it might work using 'P' packets, I'm not sure how to go about handling unavailable registers in general with the 'G' packet. The problem is that the server would need to somehow only flush these registers in response to 'P' packets, and ignore them when they come from 'G' packets. This is becasue if the client always uses 'G' packets to store any registers, including the ones that are always available, and the server flushes the regcache to detect errors, most 'G' packets would return in error because the inferior is usually not in a state in which the unavailable registers can be written. It's not clear that the 'xxxxx' encoding for unavailable registers can be used in 'G' packets, like it is for 'g' packets. The gdbserver stub doesn't handle this and assumes the 'G' packet contents will be properly encoded register values, it only uses this encoding when replying to 'g' packets. Maybe a solution is to prevent writing to these registers on the client side if the target is remote and print a warning (possibly through gdbarch_cannot_store_register). Thanks!! -- Pedro Franco de Carvalho