Re: long long considered harmful?

[Daniel Jacobowitz <drow@mvista.com>]

On Wed, Apr 23, 2003 at 09:39:13AM -0400, Kris Warkentin wrote:
> > > 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

If you want to get at it, then it _is_ a host vs. target issue.

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

If it's not portable, I'd really strongly prefer it not go in at all
until it is.  I went through this exact thing making core dumps work in
a cross environment; someone wanted to use them from a 64-bit Solaris
host.

It's just as easy to do it right, really.  Look at this:

typedef char qnx_reg64[8];
static void regset_fetch (int endian, unsigned first, unsigned last, qnx_reg64 *data)
{
  for (; first <= last; first++)
    {
      if (endian)
	supply_register (first, (char *) &data[0][4]);
      else
	supply_register (first, (char *) data);
      data++;
    }
}

Was that really so hard?  And it's a lot clearer.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer