This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Thu, Nov 29, 2001 at 04:45:27PM -0700, Kevin Buettner wrote:
> On Nov 29,  6:37pm, Daniel Jacobowitz wrote:
> > On Thu, Nov 29, 2001 at 04:12:29PM -0700, Kevin Buettner wrote:
> > > > 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.)
> > 
> > Nothing that abstracted.  I copy the necessary type definitions and
> > constants from target headers; they are "relatively" guaranteed never
> > to change.  It's a mess.
> How does the "cross" part of it work then?  Won't the sizes of the
> fundamental types, struct alignment, etc. change depending upon
> which host you compile it on?

How does it work?  Badly.

The types look like this right now:

+typedef unsigned char elf_greg_t[4];
+typedef unsigned char elf_fpreg_t[8];
+typedef struct {
+  unsigned char u[16];
+} __attribute((aligned(16))) __uint128_t;
+/* Altivec registers */
+typedef __uint128_t elf_vrreg_t;

Barring the GCC extension to get __uint128_t aligned, which I don't
actually need for anything, I can do what I need to with these; I use
explicitly target alignment.  No platform other than (IIRC) x86 is
broken enough to require the tdep to do computation on elf_greg_t's
while fetching them.

The current version also has a _ppc_pt_regs struct which contains only
unsigned longs; but the only thing it's doing there is providing struct
user, and the only thing that cares is the kernel_u_size function, and
the only reason that's there is because it was quicker at the time for
me to copy struct user than figure out the constant :)

Arrays of arrays of unsigned char have no alignment issues.

Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]