From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 123039 invoked by alias); 12 Oct 2016 16:30: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 122967 invoked by uid 89); 12 Oct 2016 16:30:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=4.3 required=5.0 tests=BAYES_00,GARBLED_SUBJECT,RP_MATCHES_RCVD,SPF_PASS autolearn=no version=3.3.2 spammy=ccing, longs, exposing, variation X-HELO: mailapp01.imgtec.com Received: from mailapp02.imgtec.com (HELO mailapp01.imgtec.com) (217.156.133.132) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Oct 2016 16:30:06 +0000 Received: from HHMAIL03.hh.imgtec.org (unknown [10.44.0.21]) by Forcepoint Email with ESMTPS id C1319F0B7205D; Wed, 12 Oct 2016 17:29:59 +0100 (IST) Received: from HHMAIL01.hh.imgtec.org (10.100.10.19) by HHMAIL03.hh.imgtec.org (10.44.0.21) with Microsoft SMTP Server (TLS) id 14.3.294.0; Wed, 12 Oct 2016 17:30:03 +0100 Received: from [10.20.78.104] (10.20.78.104) by HHMAIL01.hh.imgtec.org (10.100.10.21) with Microsoft SMTP Server id 14.3.294.0; Wed, 12 Oct 2016 17:30:02 +0100 Date: Wed, 12 Oct 2016 16:30:00 -0000 From: "Maciej W. Rozycki" To: James Hogan CC: Bhushan Attarde , , Matthew Fortune , Andrew Bennett , Jaydeep Patil , Subject: Re: [PATCH 02/24] Add MIPS32 FPU64 GDB target descriptions In-Reply-To: <20161012135803.GT19354@jhogan-linux.le.imgtec.org> Message-ID: References: <1467038991-6600-1-git-send-email-bhushan.attarde@imgtec.com> <1467038991-6600-2-git-send-email-bhushan.attarde@imgtec.com> <20161012135803.GT19354@jhogan-linux.le.imgtec.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2016-10/txt/msg00324.txt.bz2 Hi James, Thanks for your input! Cc-ing linux-mips for the discussion about a ptrace(2) kernel API update; anyone interested in previous talk about this change please have a look at: and for the earlier messages. > > Hmm, has Linux kernel support for CP0.Config5 accesses gone upstream > > already? Can you give me an upstream commit ID and/or reference to the > > discussion where it has been approved if so? > > I don't think it did go upstream yet. Good! > > More importantly, what do we need CP0.Config5 access for in the first > > place? It looks to me like this bit is irrelevant to GDB as it does not > > affect the native (raw) register format. So the only use would be to let > > the user running a debugging session switch between the FRE and NFRE modes > > without the need to poke at CP1C.FRE or CP1C.NFRE registers with a CTC1 > > instruction, which by itself makes sense to me, but needs a further > > consideration. > > It allows the FRE bit to be read (I seem to remember this was the only > bit actually exposed through ptrace by the patch). Then I think it makes sense even more not to create this artificial API and use the CP1C.FRE/CP1C.NFRE registers instead which do correspond to what hardware presents to user software. Also with CP1C.UFR/CP1C.UNFR vs CP0.Status; while we want to retain the latter register in the view for historical reasons, it has always been read-only and I think it ought to remain such, with any writes to CP0.Status.FR executed via the former CP1C registers only. > FRE simply causes certain instructions (all single precision FP > arithmetic instructions and FP word loads/stores) to trap to the kernel > so that it can emulate a variation/subset of FR=0, so the debugger would > use it to decide how to decode the single precision FP registers based > on the double precision FP registers (iirc). I don't think there is any value in it for GDB, I think all 64-bit FP registers ought to remain being presented as doubles and pairs of singles regardless of the mode selected (and also possibly fixed-point longs and pairs of fixed-point words). We don't know what's emulated and what's not after all, and then the contents of FPRs are not interpreted by GDB itself anyhow except in user-supplied expressions or assignment requests, which for users' convenience I think should retain the maximum flexibility possible. So as I say it looks to me like the only, though obviously valid and wholeheartedly supported, use for CP1C.FRE/CP1C.NFRE would be for user's control of the execution environment. > > Additionally exposing CP0.Config5 may have security implications, > > especially as parts of the register have not been defined yet in the > > architectures and we'd have to force architecture maintainers somehow to > > ask us every time they intend to add a bit to this register to check if > > this has security implications and has to be avoided and/or explicitly > > handled in software. > > yes, as above it explicity only shows certain bits. I'm fine with the > api changing if necessary though since it isn't upstream. It sounds like a plan to me then -- any further questions or comments about the kernel API part, anyone? Maciej