Re: MIPS: Handle the DSP registers

[Daniel Jacobowitz <drow@false.org>]

On Thu, Mar 27, 2008 at 05:13:03PM +0000, Maciej W. Rozycki wrote:
>  As far as I know it both YAMON and the SDE library debugging stub both 
> provide access to cp0 registers.  I may not have time to check whether 
> they use the problematic packets, but with the code shuffle above (1) this 
> becomes a non-issue for this lone change.

Great.  So we can figure out what register layout they need and
provide it explicitly.

> > Does the MDI patch rely on passing "1" to the new function?  If not,
> > please just use regcache_invalidate.  Speaking about good engineering
> 
>  Well, it passes "-1", so it is reasonable and not exactly the same as 
> regcache_invalidate().

Hmm, that is more reasonable.  That meaning is documented in a
comment, but not used anywhere else in present GDB, though, and none
of the callers of regcache_valid_p expect it - so I'd be dubious of it
actually working!  If we want it to work there's going to be an
ugly audit involved.

May I ask you to save this function for later, and return to it along
with the MDI patch?  I will look at that as soon as I can find a
moment, it's next after this one.

> > Then an N32 GDB is not going to be able to read these registers unless
> > we create a regset for them, FYI.  ptrace takes and returns longs on
> > n32, not long longs.  I experimented with using long long, but it was
> > a terrible mess.
> 
>  Hmm, I have had a peek at the kernel and it looks like PTRACE_POKEUSR and 
> PTRACE_PEEKUSR requests are completely broken for n32; it's just that we 
> have a way around it for GP/FP registers...

Yes, pretty much.  Other platforms know how to fetch larger than
word-sized registers using these functions but they do it by using
register offsets in a hypothetical "struct user" as arguments, instead
of indexes.  The fact that we pass 30 and 31 to get $30 and $31 really
messes things up when you want the other half of $30.

>  Well, certainly fixing ptrace() to work with DSP registers one way or 
> another for n32 can wait until we have a relevant piece of silicon and 
> I'll sort out the numbering issue as referred to above (1).  Please let me 
> know whether there is anything else you have had in mind and I'll send a 
> new version of the patch shortly.

Nope, I'm otherwise happy.  Thanks for your patience.

-- 
Daniel Jacobowitz
CodeSourcery