This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: Adding MIPS registers (was Re: [PATCH v2] Reset errno before PTRACE_PEEKUSER for MIPS DSP_CONTROL)
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Paul Burton <Paul dot Burton at imgtec dot com>, James Hogan <James dot Hogan at imgtec dot com>
- Cc: "Maciej W. Rozycki" <macro at codesourcery dot com>, "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Wed, 10 Sep 2014 07:44:17 +0000
- Subject: RE: Adding MIPS registers (was Re: [PATCH v2] Reset errno before PTRACE_PEEKUSER for MIPS DSP_CONTROL)
- Authentication-results: sourceware.org; auth=none
- References: <1409608120-23991-1-git-send-email-james dot hogan at imgtec dot com> <alpine dot DEB dot 1 dot 10 dot 1409031340130 dot 27075 at tp dot orcam dot me dot uk> <20140903125111 dot GF12084 at jhogan-linux dot le dot imgtec dot org> <alpine dot DEB dot 1 dot 10 dot 1409031517450 dot 27075 at tp dot orcam dot me dot uk> <540F2ECD dot 5080604 at imgtec dot com> <alpine dot DEB dot 1 dot 10 dot 1409091808350 dot 27075 at tp dot orcam dot me dot uk> <20140909203922 dot GA27832 at jhogan-linux dot le dot imgtec dot org> <20140910064706 dot GS17248 at pburton-laptop>
> On Tue, Sep 09, 2014 at 09:39:22PM +0100, James Hogan wrote:
> > > with the UFR
> > > feature, so the register set presented will have to change dynamically,
> > > according to that setting even for Linux targets.
> >
> > I have a feeling that UFR is currently unlikely to be enabled in Linux,
> > due to subtleties with mode switches in multi-threaded processes
> > requiring kernel support. Matthew or Paul (on CC) can probably confirm
> > that.
>
> Correct, UFR (along with UFE) is currently not enabled by Linux, and I'm
> not aware of any need to deal with the pain involved in enabling it. There
> is a need to switch mode across a whole process, which will need to be met
> in some other way (the prctls in my internal branch, and hopefully the
> same once upstream).
We are quite a long way off topic from the original post but all this is
important for the bulk of James' further patches...
The O32 FR0/FR1 ABI documentation includes basic details of the new FRE
hardware mode and the corresponding new ABI extension FP64A:
https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking#7._Defining_O32_FP64A
A formal PRA document with FRE described is due within a week or so.
It also shows how the program loader is expected to behave:
https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking#10.4._Program_loader
And how mode switching is to be performed:
https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking#10.5.2._Setting_the_FPU_mode
I would like to propose that GDB is not able to change the FR or FRE bits
directly. These bits have to be handled with extreme caution and there is
no plan to support users changing them at arbitrary points either on bare
metal or user-land. The intention is that a program is provided with a
stable environment to run in where every loaded function (and region of
a function) can be executed in the current mode. When adding new code into
a process then a new hardware mode may be required but the change of mode
is performed atomically across all threads in a process. For bare-metal
there is almost no reason anyone will need a mode switch so that can be
disregarded entirely.
I'll reply about register layouts separately although that topic is mostly
subjective.
Thanks,
Matthew