[RFA] W.I.P. AltiVec ppc registers support.
Andrew Cagney
ac131313@cygnus.com
Wed Nov 21 04:10:00 GMT 2001
>> >
>> >
>> >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;
>
>>
>> Hmm, Kevin did have good reason to be concerned. That is wrong.
>> Mechanisms similar to shlib et.al. should be used.
>
>
> What is wrong with it?
>
> I agree that it is messy, but it is completely correct. I know of no
> platform with 8-bit bytes stupid enough to do this any way other than
> the way I intend.
Several things come to mind: the __attribute() - there are alignment
independant functions for packing/unpacking/copying stuff; the
__unint128_t is is a name in system space.
The shlib code does this by describing the actual layout using a very
thin interface (like how remote.c unpacks the g-packet) so host issues
aren't a problem (but yes, it would be a suprise to find one that didn't
have 8 bit chars).
The other way of doing this is more like C++ where it creates a ``struct
type'' to describe the structure exactly how the target sees it.
enjoy,
Andrew
More information about the Gdb-patches
mailing list