Re: MIPS: Handle the DSP registers

Daniel Jacobowitz
2008-03-27T17:46:32Z

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