[RFA] W.I.P. AltiVec ppc registers support.
Kevin Buettner
kevinb@redhat.com
Tue Nov 20 09:07:00 GMT 2001
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
More information about the Gdb-patches
mailing list