Re: long long considered harmful?

["Kris Warkentin" <kewarken@qnx.com>]

> > Pardon me, by overall structure, I mean the starting address of the
> > structure.  Having a 64 bit entry causes the compiler to align the
structure
> > on a 64 bit boundary.
>
> Whoever told you this is mistaken.  A long long member of a structure
> only has four byte alignment on i386-linux, for example.  That's
> mandated by the psABI.
>
> This is exactly one of those reasons why you can not use structures
> on the host to describe data on the target.

I'm not talking about host vs. target here.  These are the structures used
by our Mips and PowerPC kernels.  I believe the mips compiler will do the
alignment as mentioned above.  You are correct that you can't rely on it
being the same on host and target but this is not something that matters in
this case.  All that's important is that when the data comes over the wire,
we can get at it.  In this case, because of the awkward define (data below
is unsigned regs[74]), we wind up extracting the mips registers like so:

static void regset_fetch( int   endian, unsigned first, unsigned last,
unsigned *data )
{
 if( endian) data += 1; /* data in second word for big endian */
 for(; first <= last; ++first) {
  supply_register(first, (char *)data);
  data+=2;
 }
}

I know it's not 100% portable.  I personally don't really care as long as it
works on the hosts that we support.  The only reason I'm asking all this is
because I want to know what level of portability is required for the GDB
project to accept this patch.  I was trying to eliminate the long longs in a
relatively painless way and the char array seems to be not too bad.  Are you
really trying to tell me that gdb wouldn't blow up on a 32 bit char host as
it stands right now?  If you really feel that the only way for me to make
this acceptable is to just use a blob of memory and a table of offsets into
it, then that's what I'll do.  My mandate is to get our stuff accepted so I
don't really have a choice.  (I'd really rather not though. ;-)

cheers,

Kris