From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2846 invoked by alias); 9 Sep 2014 17:57:06 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 2833 invoked by uid 89); 9 Sep 2014 17:57:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 09 Sep 2014 17:57:03 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1XRPf2-0005Km-Bw from Maciej_Rozycki@mentor.com ; Tue, 09 Sep 2014 10:57:00 -0700 Received: from localhost (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 9 Sep 2014 18:56:58 +0100 Date: Tue, 09 Sep 2014 17:57:00 -0000 From: "Maciej W. Rozycki" To: James Hogan CC: Subject: Re: Adding MIPS registers (was Re: [PATCH v2] Reset errno before PTRACE_PEEKUSER for MIPS DSP_CONTROL) In-Reply-To: <540F2ECD.5080604@imgtec.com> Message-ID: References: <1409608120-23991-1-git-send-email-james.hogan@imgtec.com> <20140903125111.GF12084@jhogan-linux.le.imgtec.org> <540F2ECD.5080604@imgtec.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2014-09/txt/msg00033.txt.bz2 James, > > BTW, I've had some FR=1 stuff ongoing too, though regrettably stalled > > recently, see: > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=7518 > > http://sourceware.org/ml/gdb-patches/2012-06/msg00201.html > > > > -- based on an old patch from MIPS Technologies that wasn't quite there, > > but still was a good starting point. Bare iron only of course as there > > was no FR=1 Linux ABI up until recently. It will be interesting to see > > how the two pieces compare. Or actually it may make sense if I push my > > piece first, there was just some concern about regcache that remained > > unresolved, so I'll see if I can reintegrate that change against current > > trunk, retest and repost. > > Yes, that's what I've based my work on, but with some changes since it > needs to support FRE=1 too. Hmm, I think this stuff would be best made incrementally anyway. We have a bug to fix here and a new feature. I'd rather kept changes to address them separate. > I've added a number of new MIPS registers, but I'm keen to get guidance > about gdbserver ABI issues. Perhaps you or somebody else could comment. > > The main register changes are: > * the MIPS32 fp registers are sometimes extended to 64-bits, at least > when FR=1 (at the moment I've made gdbserver extend to 64-bits whenever > FIR.F64=1, so that the register format cannot change during use). One issue here is FR can now be changed at the run time, with the UFR feature, so the register set presented will have to change dynamically, according to that setting even for Linux targets. I have addressed this to some extent for bare iron, but with Linux that means `gdbserver' changes as well (as you noted). I think raw registers should reflect precisely the state of hardware and all the mapping based on FR should be done for cooked registers only. > * expose CP0 Config5 as a new register (contains the FRE bit, only > really relevant when FR=1) I smell ABI problems here (think core files and maybe signal frames), what is this bit for and why was it added to CP0.Config5 rather than CP0.Status? Is this stuff publicly documented anywhere? -- I don't see it in documentation I have handy, not even for rev. 6 of the architecture, let alone 5. > * (separately) expose the rest of the MSA vector registers as new > registers (raw register excludes the low 64-bits which alias the double > FP registers, pseudo register concatenates raw fp/vector register together). Hmm, offhand I think it would be cleaner done the other way round -- expose raw 128-bit or 256-bit MSA registers as applicable and let the cooked layer map parts to legacy FP or MSA registers as appropriate. For non-MSA cores keep exposing FP registers as usually. Do you have a specific reason why you did it like you did? > Currently I've done this by adding whole new target descriptions: > mips-fpu64-dsp-linux (mips-dsp-linux with 64-bit fp and config5) > mips-fpu64-linux (mips-linux with 64-bit fp and config5) > mips-msa-linux (64-bit fp registers, config5, vector registers) > mips64-msa-linux > > and carefully appending Config5 to the following target descriptions (is > that a valid approach, adding registers to the end?): > mips64-dsp-linux > mips64-linux That doesn't matter I believe, the description has to be interpreted as a whole by GDB anyway. Registers that don't have a special interpretation in GDB will simply be passed through and available by their names in the usual contexts. That is at least how this stuff is meant to be working I'm told. Shouldn't e.g. mips-linux have a variant with CP0.Config5 too? Note that inevitably you'll be able to change FR from GDB now too, just by poking at it, e.g.: (gdb) set $sr ^= 1 << 26 The ptrace(2) code in the kernel needs to recognise CP0.Config5.UFR being set and allow r/w access to CP0.Status.FR with PTRACE_POKEUSER or PTRACE_SETREGS, just as with the CTC1 moves to CP1.UFR and CP1.UNFR, and in response to that you need to switch the target description to the new register layout instantaneously. Same with e.g. single-stepping over these instructions. > With a GDB & target that supports XML I believe all should be well. > However with a MIPS32 remote which supports FR=1 (i.e. when FIR.F64=1), > AFAICT GDB without XML target description support has no (simple) way to > tell whether the remote is actually providing 32-bit or 64-bit fp registers. IMO you don't have to be concerned with stone-age versions of GDB, our intent is to support old remote stubs with current GDB (stubs are not always easy to upgrade and sometimes not really possible, if built into firmware for example), but not the other way round. If you've got modern `gdbserver', then just use GDB you've built along it. > So, for MIPS do we care about GDB being built without XML support (at > least for gdbserver)? I.e. creation of whole new target descriptions > that a non-xml gdb won't recognise. No, as far as I'm concerned. BTW, while making such changes you need to verify the correct operation of native GDB too. Maciej