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

[Andrew Cagney]

>> 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;

Hmm, Kevin did have good reason to be concerned.  That is wrong. 
Mechanisms similar to shlib et.al. should be used.

BTW, where did this buffer layout come from?
	Andrew


> 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.
> 
> 
>