From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12903 invoked by alias); 9 Sep 2014 16:46:15 -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 12890 invoked by uid 89); 9 Sep 2014 16:46:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 09 Sep 2014 16:46:11 +0000 Received: from KLMAIL01.kl.imgtec.org (unknown [192.168.5.35]) by Websense Email Security Gateway with ESMTPS id 3CA5ADBE2D7AB; Tue, 9 Sep 2014 17:46:03 +0100 (IST) Received: from LEMAIL01.le.imgtec.org (192.168.152.62) by KLMAIL01.kl.imgtec.org (192.168.5.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 9 Sep 2014 17:46:06 +0100 Received: from [192.168.154.101] (192.168.154.101) by LEMAIL01.le.imgtec.org (192.168.152.62) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 9 Sep 2014 17:46:05 +0100 Message-ID: <540F2ECD.5080604@imgtec.com> Date: Tue, 09 Sep 2014 16:46:00 -0000 From: James Hogan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Subject: Adding MIPS registers (was Re: [PATCH v2] Reset errno before PTRACE_PEEKUSER for MIPS DSP_CONTROL) References: <1409608120-23991-1-git-send-email-james.hogan@imgtec.com> <20140903125111.GF12084@jhogan-linux.le.imgtec.org> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00032.txt.bz2 Hi Maciej, On 03/09/14 22:21, Maciej W. Rozycki wrote: > On Wed, 3 Sep 2014, James Hogan wrote: >> This is my first GDB patch submitted upstream (although I have a pile of >> RFC patches for FR=1, FRE=1, MSA support I'm still getting into shape), >> so I don't have push access yet. Is it easy to arrange? > > 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. 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). * expose CP0 Config5 as a new register (contains the FRE bit, only really relevant when FR=1) * (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). 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 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. 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. Thanks James