Re: [PATCH 01/24] MIPS: Handle run-time reconfigurable FPR size

["Maciej W. Rozycki" <macro@imgtec.com>]

On Fri, 11 Nov 2016, Yao Qi wrote:

> > > >     This is implemented by retaining the raw register size for the FPRs at its
> > > >     native size (64-bits; this is required for remote packet offsets to work
> > > >     out correctly) and then truncating the cooked register size or not as
> > > >     required.  I have skipped `maintenance print registers' dumps here for
> > > >     brevity, the types flip between "double" and "float" as expected.
> > > >
> > > 
> > > If I understand you correctly, 64-bits are still transferred in remote protocol
> > > if FPRs are 32-bit.
> > 
> >  Nope.  In the FR=0 mode existing XML-described stubs present a file of 32 
> > 32-bit FPRs; this applies to MIPS32 targets only as so far we've had an 
> > assumption that MIPS32 <=> FR=0 and MIPS64 <=> FR=1.  I think switching 
> > the view at this time would be an undesireable complication, as it would 
> > be yet another variant we'd have to handle forever along with the new one.
> 
> Yeah, there are different variants.  Let me be specific, with this patch
> applied, on MIPS64, FR=0, how many bits needed for each FPR in 'g' packet?
> I ask this question for this sentence "This is implemented by retaining the
> raw register size for the FPRs at its native size (64-bits; this is required for
> remote packet offsets to work out correctly) and then truncating the cooked
> register size or not as required." in Bhushan's mail.
> IIUC, with this patch applied, on MIPS64, FR=0, FPR is 32-bit, but 64-bit
> space is used in 'g' packet.  No?

 Pre-XML stubs have a uniform register width so with a MIPS64 debuggee 
FPRs will be 64-bit whether FR=1 or FR=0; this patch cannot and does not 
attempt to change this, so in that case FPRs need to be explicitly 
truncated at the cooked level, which is arranged by this patch in 
`mips_register_type'.

 XML-described stubs are enforced by this patch to match `g' packet space 
with the actual FPR width, however no XML-described stub is currently 
known to support FR tracking.

 NB all this only applies to bare-metal stubs rather than our `gdbserver' 
as MIPS64/FR=0 is not a supported Linux execution model.

> >  FWIW I think the FR=0 mode should have been chosen to present the FPR 
> > file as 16 64-bit FPRs instead, with the cooked register view used to 
> > access register halves if required, but then I think a further 
> > complication would arise with non-XML-described stubs.
> > 
> > > >      The change also supports both XML and non-XML targets, but currently
> > > >     bare-iron targets for which this update has any significant meaning do not
> > > >     really support XML.  Any XML target is supposed to always provide an FPU
> > > >     description that matches the current setting of CP0.Status.FR, the new
> > > >     code verifies this is always the case and rejects the description as
> > > >     invalid otherwise.
> > > 
> > > How do I understand "Any XML target is supposed to always provide
> > > an FPU description that matches the current setting of CP0.Status.FR"?
> > > I don't see how it is done in current GDB/GDBserver.
> > 
> >  I do hope the last patch which adds `gdbserver' features en masse, which 
> > I didn't get to to looking through yet, has it (although I think the 
> > individual features should be included along with corresponding base 
> > target and native support instead).
> 
> Oh, it must be this patch
> https://sourceware.org/ml/gdb-patches/2016-06/msg00511.html

 Correct.

> > > "reconfigure FPRs" is a target description change to me, instead of a
> > > regcache change.
> > 
> >  The regcache change is partly historic, because parts of the series 
> > (dating back to 2005) were implemented even before we had XML 
> > descriptions, and an FR transition is also supposed to work with 
> > non-XML-described MIPS64 bare-metal targets (where the FPR file is 
> > presented as 32 64-bit FPRs regardless of the FR setting).  I do agree a 
> > target description should take precedence where available, and certainly 
> > with Linux targets where you cannot get a MIPS64 FR=0 configuration or a 
> > non-XML-described MIPS32 FR=1 configuration).
> > 
> >  What do you propose if we don't have a target description though?  We 
> > can't handle MIPS32 FR=1, because stubs won't transfer the upper halves of 
> > FPRs, but we can handle MIPS64 FR=0, because we can simply ignore the 
> > irrelevant upper halves.
> 
> Why stubs doesn't transfer the upper bits of PFRs in case of MIPS32 FR=1?
> because of keeping backward compatibility?  Does
> register_remote_g_packet_guess help?

 Pre-XML stubs have a uniform register width matching the architecture, 
and then a fixed register layout as defined by the enum in mips-tdep.h.  
Consequently there is simply no room there for the upper halves of 
MIPS32/FR=1 FPRs, so no legacy stub ever gives access to them, because all 
registers transferred are 32-bit.  Using `register_remote_g_packet_guess' 
won't help with such missing data.

 With an XML-described stub we can of course supply whole FPRs however we 
wish, although I think there's still value in keeping the MIPS32/FR=0 
packet format the same (i.e. as defined by mips-tdep.h) so that 
communication continues working with legacy pre-XML GDB clients.  Of 
course once we switch to MIPS32/FR=1, then communication will break, but 
pre-XML GDB clients don't support the cooked MIPS32/FR=1 register format 
anyway.

 Did I answer your questions?

  Maciej