Re: [PATCH] MIPS: Handle the DSP registers for bare metal

["Maciej W. Rozycki" <macro at linux-mips dot org>]

On Mon, 5 Jan 2015, Pedro Alves wrote:

> >  Register probing Yao mentioned is still needed, because in this fixed 
> > packet format the whole set of architecturally defined register slots is 
> > exchanged with the RSP stub, e.g. 8 * 32 = 256 CP0 registers, 8 * 32 = 256 
> > CP2 registers, etc. (as documented by the change to mips-tdep.h proposed), 
> > even if some are not present, e.g. not all CP0 register slots have already 
> > been allocated in the architecture so far and the vast majority of them is 
> > optional.
> 
> That's orthogonal.
> 
> > 
> >  The information on which registers are present and which are not will not 
> > be supplied by the target and has to be determined by gradual discovery, 
> > that is poking at registers as they are determined to be present, i.e. 
> > first CP0.PRId that is always there, then CP0.Config0 if present, then 
> > CP0.Config1 if present, and so on.  Gaps will be present in the packets 
> > exchanged for the absent registers as with the ACX registers discussed 
> > previously.
> 
> > 
> >  And if we were to define built-in target descriptions for the possible 
> > variants of present register sets, then, as noted by Yao, we hit the issue 
> > of having to make some 2^50 templates (slightly fewer actually, as there 
> 
> That'd be silly of course, but it's also not what I meant.  The built-in
> description is used for the case of a legacy stubs that does not report a
> target description, and those stubs you say use a fixed register layout.
> So we're talking about _one_ built-in target description that describes
> that fixed register layout.

 Addressing the two parts quoted -- do you mean to have a built-in target 
description that optional registers can be further excluded from if not 
actually present, analogously to what the patches proposed do without 
creating this artificial target description?

 Yao, I think it would make sense if you posted the other change I've been 
referring to for a reference, so that Pedro and other people have a chance 
to know what I am talking about.

> > are some dependencies between the presence of some registers, e.g. you 
> > can't have a processor that has a CP0.Config2 register, but does not have 
> > CP0.Config1, the reverse is allowed; similarly a CPU can't have the ACX 
> > register when it does not have CP0.Config3) which is of course beyond 
> > technical capabilities as e.g. a 32-bit host will have fewer bytes of 
> > addressable memory even.
> 
> >  NB `mips_register_g_packet_guesses' is not necessarily relevant here as 
> > there may be registers accessible through the stub via the p/P packets 
> > only and not included in the g/G packet layout for performance reasons 
> 
> If existing/legacy stubs are doing that in practice, then we can
> make gdb pick the fallback description (in case in target doesn't
> provide one) depending on selected osabi.

 They do.  We might be able to make an educated guess from a `g' packet 
anyway, it's not like there is much choice here.  Using the osabi has the 
corner-case drawback of forcing the user to set it manually where no 
executable image of code to debug is available (e.g. debugging ROM 
firmware).  Besides, I believe the osabi is tangential to the debug stub 
being used.

> > (the packet may be shorter than the maximum defined) as to transfer all 
> > the registers through a JTAG link every time the target is stopped may be 
> > exceedingly slow, especially when single-stepping.
> 
> For the single-stepping case, the fix should be to include
> all the registers GDB needs to compute whether the step finished
> directly in the expedite stop reply, though.

 Registers have more recently been already included in the expedite stop 
reply, IIRC they include $pc, $sp, $fp and $s1 (the latter being the 
MIPS16 frame pointer).  That may not cover all the corner cases though, 
e.g. $s2 is needed if single-stepping stops in some MIPS16 thunks, that 
are not worth the performance regression sending extra registers in the 
expedite reply would cause for the general case.

 Finally, in most cases, such as accessing program variables whose storage 
has been optimised to registers, it's the GPR and maybe the FPR register 
set that is ever used.  So the contents of the `g'/`G' packets are really 
a compromise -- performance when accessing all registers is traded for 
performance when accessing the most frequently used ones.

 This is because the `p'/`P' packets have a higher overhead as they 
transfer individual registers, requiring a JTAG probe to do the whole 
dance for the target to switch modes for a single register access.  
Whereas the `g'/`G' packets let a JTAG probe do a bulk transfer and 
therefore do the dance with the target only once.

 By avoiding including infrequently needed registers we're talking of up 
to dozens of seconds to save here per single `g'/`G' packet here.  But 
then a command like:

(gdb) info registers

can take these dozens of seconds instead.

 So this compromise will have to be retained somehow even if a proper 
target description is supplied by an RSP stub.  Using such a description 
will have the advantage of giving access to registers that were not 
included in the fixed format, e.g. shadow register sets.

  Maciej