Re: [RFA] W.I.P. AltiVec ppc registers support.

[Kevin Buettner <kevinb@redhat.com>]

On Nov 29,  5:46pm, Daniel Jacobowitz wrote:

> > Hmm... I wonder if Linux/PPC even needs this function in core-aout.c.
> > Daniel J. is the expert on this stuff.  Daniel, doesn't Linux/PPC use
> > core-regset.c instead?
> 
> I'd like to kill our use of core-aout.c.  Linux/PPC never used a.out
> cores, but unfortunately core-aout.c defines register_addr () as a
> wrapper for REGISTER_U_ADDR.  The last time I tried to remove
> core-aout.c from a platform I got bitten.
> 
> I think, now that we are defining FETCH_INFERIOR_REGISTERS, we can do
> without it - infptrace was the only big consumer I see remaining.  So
> we might be OK without using core-aout.c at all now.

That's what I was hoping.  Maybe Elena could try it out and let us know?

> My still-unsubmitted cross-core patches for PowerPC remove
> core-regset.o also, and very unpleasantly turn ppc-linux-nat.c into a
> target-dependant rather than native-dependant file, so that we can grub
> through the gregsets by hand.  If you've got a better idea I'd love to
> hear it :) It will be made somewhat easier by the destruction of
> regmap[].

I haven't seen your patches, but I imagine you have a table of
constants or some such that represent offsets and sizes of members in
the regsets?  (I.e, something similar to what I did for SVR4 shared
library offsets.) If that's the approach, then the only real problem I
have with it is accurately generating (and maintaining) the tables. 
The SVR4 shared library tables are compact enough to easily generate
by hand.  The regset data is quite a lot larger and I would think
you'd want to generate this data through more automatic means.  (I.e,
via a program that you'd compile and and then run on the target.)

Kevin