From mboxrd@z Thu Jan  1 00:00:00 1970
From: Kevin Buettner <kevinb@redhat.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: Elena Zannoni <ezannoni@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: [RFA] W.I.P. AltiVec ppc registers support.
Date: Thu, 29 Nov 2001 15:15:00 -0000
Message-ID: <1011129231229.ZM19791@ocotillo.lan>
References: <15365.39495.801289.497931@krustylu.cygnus.com> <1011129183830.ZM18856@ocotillo.lan> <15366.44991.616576.411278@krustylu.cygnus.com> <1011129222000.ZM19585@ocotillo.lan> <20011129174621.B15429@nevyn.them.org> <drow@mvista.com>
X-SW-Source: 2001-11/msg00582.html
Message-ID: <20011129151500.KzpVN7JuhK-HbJLdfr1kBj6hdHPzo3xdC2-ZMD65Gig@z>

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