long long considered harmful?

long long considered harmful?

[Kris Warkentin]

Below is a clipping from our debug.h header which defines the register
structures for QNX Neutrino.  I've been in conversation with Mark Kettenis
about our gdb submission and it looks like portability issues in this header
are one of the few remaining stumbling blocks, at least from his
perspective.  I guess that conceivably some older systems might not be able
to deal with a 64 bit int type.  The question I want to ask is, "how do I
deal with this in a portable way?"

I don't believe that any of these structures are ever manipulated in any way
other than to read/write bytes of data into and out of them.  Would it be
best just to define any long long members as arrays of char?  It doesn't
seem very pretty but it would certainly do the trick.

ie. "char u64[8]" instead of "long long u64" is fine but "char gpr_hi[32 *
8]" instead of "long long gpr_hi[32]" seems a bit nasty.

comments?

Kris

>>>>>>>>>>>>>debug.h clip<<<<<<<<<<<<<<<<<<<<<
typedef union
{
  unsigned long long u64;
  double f;
} mipsfloat;

typedef struct mips_cpu_registers
{
  unsigned regs[74];
  unsigned long long regs_alignment;
} MIPS_CPU_REGISTERS;

typedef struct mips_fpu_registers
{
  mipsfloat fpr[32];
  unsigned fpcr31;
} MIPS_FPU_REGISTERS;

typedef struct mips_alt_registers
{
  union
  {
    struct mips_tx79
    {
      unsigned long long gpr_hi[32];
      unsigned long long lo1;
      unsigned long long hi1;
      unsigned sa;
    } tx79;
  } un;
} MIPS_ALT_REGISTERS;

#ifdef __BIGREGS__
typedef unsigned long long ppcint;
#else
typedef unsigned ppcint;
#endif

typedef union
{
  unsigned long long u64;
  double f;
} ppcfloat;

typedef union
{
  unsigned long long u64[2];
  unsigned u32[4];
  unsigned char u8[16];
  float f32[4];
} ppcvmx;

typedef struct ppc_cpu_registers
{
  ppcint gpr[32];
  ppcint ctr;
  ppcint lr;
  ppcint msr;
  ppcint iar;
  unsigned cr;
  unsigned xer;
  unsigned ear;   /* Not present on all chips.  */
  unsigned mq;   /* Only on the 601.  */
  unsigned vrsave;  /* On Altivec CPU's, SPR256.  */
} PPC_CPU_REGISTERS;

typedef struct ppc_fpu_registers
{
  ppcfloat fpr[32];
  unsigned fpscr;
  unsigned fpscr_val;
  /* Load/store of fpscr is done through fprs, the real value is in [32,63]
of a fpr.
     Fpscr is the address for lfd, stfd. fpscr_val is the real value of
fpscr.  */
} PPC_FPU_REGISTERS;

typedef struct ppc_vmx_registers
{
  ppcvmx vmxr[32];
  ppcvmx vscr;
} PPC_VMX_REGISTERS;

typedef struct ppc_alt_registers
{
  PPC_VMX_REGISTERS vmx;
} PPC_ALT_REGISTERS;

Re: long long considered harmful?

[Daniel Jacobowitz]

On Tue, Apr 22, 2003 at 01:39:53PM -0400, Kris Warkentin wrote:
> Below is a clipping from our debug.h header which defines the register
> structures for QNX Neutrino.  I've been in conversation with Mark Kettenis
> about our gdb submission and it looks like portability issues in this header
> are one of the few remaining stumbling blocks, at least from his
> perspective.  I guess that conceivably some older systems might not be able
> to deal with a 64 bit int type.  The question I want to ask is, "how do I
> deal with this in a portable way?"
> 
> I don't believe that any of these structures are ever manipulated in any way
> other than to read/write bytes of data into and out of them.  Would it be
> best just to define any long long members as arrays of char?  It doesn't
> seem very pretty but it would certainly do the trick.
> 
> ie. "char u64[8]" instead of "long long u64" is fine but "char gpr_hi[32 *
> 8]" instead of "long long gpr_hi[32]" seems a bit nasty.
> 
> comments?

Several things come to my eye as problems here:

> >>>>>>>>>>>>>debug.h clip<<<<<<<<<<<<<<<<<<<<<
> typedef union
> {
>   unsigned long long u64;
>   double f;
> } mipsfloat;

This is a target entity isn't it?  You've got no business using
"double" for a target float.  Use the gdb type mechanism instead.

> typedef struct mips_cpu_registers
> {
>   unsigned regs[74];
>   unsigned long long regs_alignment;
> } MIPS_CPU_REGISTERS;

What's the purpose of the alignment entry?  I doubt it does what you
want it to.

> #ifdef __BIGREGS__

Eh?

> typedef union
> {
>   unsigned long long u64[2];
>   unsigned u32[4];
>   unsigned char u8[16];
>   float f32[4];
> } ppcvmx;

As above.

I recommend something like 'typedef char qnx_reg64[8];'; then you can
still say 'qnx_reg64 gpr[32]' and get the right result.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: long long considered harmful?

[Kris Warkentin]

<disclaimer> I didn't write this stuff - it's taken from our system headers
and reflects the way that the kernel stores registers when you ask it to.
</disclaimer>

> > typedef union
> > {
> >   unsigned long long u64;
> >   double f;
> > } mipsfloat;
>
> This is a target entity isn't it?  You've got no business using
> "double" for a target float.  Use the gdb type mechanism instead.

Can you point to an example of how this is done?

> > typedef struct mips_cpu_registers
> > {
> >   unsigned regs[74];
> >   unsigned long long regs_alignment;
> > } MIPS_CPU_REGISTERS;
>
> What's the purpose of the alignment entry?  I doubt it does what you
> want it to.

I believe it's padding to handle whether we're dealing with a little or big
endian target.  I'll ask the kernel guys when I find them.  Regardless of
whether it does anything, the structure has to be the appropriate size for
the kernel to fill in.  "Mine is not to reason why, mine is just to do or
die."

> > #ifdef __BIGREGS__
>
> Eh?

Not sure about the origin of this.  It's in our powerpc stuff but there
doesn't ever seem to be a situation where it's defined.  It might be future
proofing but it probably doesn't belong here.  I'll most likely take it out
and if it ever comes up, fix it in the target backend.

> I recommend something like 'typedef char qnx_reg64[8];'; then you can
> still say 'qnx_reg64 gpr[32]' and get the right result.

Really?  I thought I knew C fairly well....I didn't think that was legal.
If so, it handles my ugliness issues.

cheers,

Kris

Re: long long considered harmful?

[Daniel Jacobowitz]

On Tue, Apr 22, 2003 at 02:08:54PM -0400, Kris Warkentin wrote:
> <disclaimer> I didn't write this stuff - it's taken from our system headers
> and reflects the way that the kernel stores registers when you ask it to.
> </disclaimer>
> 
> > > typedef union
> > > {
> > >   unsigned long long u64;
> > >   double f;
> > > } mipsfloat;
> >
> > This is a target entity isn't it?  You've got no business using
> > "double" for a target float.  Use the gdb type mechanism instead.
> 
> Can you point to an example of how this is done?

Check out floatformat_to_doublest.  You may not even need it if you
only pass the data to supply_register...

> > > typedef struct mips_cpu_registers {
> > >   unsigned regs[74];
> > >   unsigned long long regs_alignment;
> > > } MIPS_CPU_REGISTERS;
> >
> > What's the purpose of the alignment entry?  I doubt it does what you
> > want it to.
> 
> I believe it's padding to handle whether we're dealing with a little or big
> endian target.  I'll ask the kernel guys when I find them.  Regardless of
> whether it does anything, the structure has to be the appropriate size for
> the kernel to fill in.  "Mine is not to reason why, mine is just to do or
> die."

We're talking about code in the host now though, right?  You can not
rely on any structure alignment to match.  If any of these must match
target structures, you must use gdbarch and the type mechanism for
them.  See gnu-v3-abi.c for an example; or just define the offsets that
you need.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: long long considered harmful?

[Kris Warkentin]

> > > This is a target entity isn't it?  You've got no business using
> > > "double" for a target float.  Use the gdb type mechanism instead.
> >
> > Can you point to an example of how this is done?
>
> Check out floatformat_to_doublest.  You may not even need it if you
> only pass the data to supply_register...

Exactly.  All we do is throw the bits around to supply register.  I'm just
looking for a way to make the structures the right size without being
completely ugly.

> > I believe it's padding to handle whether we're dealing with a little or
big
> > endian target.  I'll ask the kernel guys when I find them.  Regardless
of
> > whether it does anything, the structure has to be the appropriate size
for
> > the kernel to fill in.  "Mine is not to reason why, mine is just to do
or
> > die."
>
> We're talking about code in the host now though, right?  You can not
> rely on any structure alignment to match.  If any of these must match
> target structures, you must use gdbarch and the type mechanism for
> them.  See gnu-v3-abi.c for an example; or just define the offsets that
> you need.

Well, at the moment, the only host we build gdb for is i386 and Sparc
(Neutrino, Solaris and Win32) but conceivably we might want to build a gdb
for Neutrino on ppc or mips or some such.  Once again, as far as gdb is
concerned, none of it really matters because this is just data coming over
the wire (or from a system call) and all it needs to know is which offset
into the structure to call supply_register on.

Do  you think it will be sufficient just to get rid of the long longs?

cheers,

Kris

Re: long long considered harmful?

[Kris Warkentin]

Found some answers:

> > typedef struct mips_cpu_registers
> > {
> >   unsigned regs[74];
> >   unsigned long long regs_alignment;
> > } MIPS_CPU_REGISTERS;
>
> What's the purpose of the alignment entry?  I doubt it does what you
> want it to.

I was more or less correct on this one.  Apparently this was not even
defined by us but by one of our very large chip vendors who shall remain
nameless.  Rather than the nicer solution of just defining an array of 64
bit regs, they did this which necessitates some nastiness when dealing with
different endians.  The alignment field ensures that the overall structure
is 64 bit aligned which is a handy thing to be on mips.

> > #ifdef __BIGREGS__
>
> Eh?

I was correct.  This is future proofing and currently unnecessary.  I'll
remove it.

cheers,

Kris

Re: long long considered harmful?

[Kris Warkentin]

> > > typedef struct mips_cpu_registers
> > > {
> > >   unsigned regs[74];
> > >   unsigned long long regs_alignment;
> > > } MIPS_CPU_REGISTERS;
> >
> > What's the purpose of the alignment entry?  I doubt it does what you
> > want it to.
>
> I was more or less correct on this one.  Apparently this was not even
> defined by us but by one of our very large chip vendors who shall remain
> nameless.  Rather than the nicer solution of just defining an array of 64
> bit regs, they did this which necessitates some nastiness when dealing
with
> different endians.  The alignment field ensures that the overall structure
> is 64 bit aligned which is a handy thing to be on mips.

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.

cheers,

Kris

Re: long long considered harmful?

[Daniel Jacobowitz]

On Tue, Apr 22, 2003 at 03:25:21PM -0400, Kris Warkentin wrote:
> > > > typedef struct mips_cpu_registers
> > > > {
> > > >   unsigned regs[74];
> > > >   unsigned long long regs_alignment;
> > > > } MIPS_CPU_REGISTERS;
> > >
> > > What's the purpose of the alignment entry?  I doubt it does what you
> > > want it to.
> >
> > I was more or less correct on this one.  Apparently this was not even
> > defined by us but by one of our very large chip vendors who shall remain
> > nameless.  Rather than the nicer solution of just defining an array of 64
> > bit regs, they did this which necessitates some nastiness when dealing
> with
> > different endians.  The alignment field ensures that the overall structure
> > is 64 bit aligned which is a handy thing to be on mips.
> 
> 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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: long long considered harmful?

[Daniel Jacobowitz]

On Tue, Apr 22, 2003 at 02:41:51PM -0400, Kris Warkentin wrote:
> > > > This is a target entity isn't it?  You've got no business using
> > > > "double" for a target float.  Use the gdb type mechanism instead.
> > >
> > > Can you point to an example of how this is done?
> >
> > Check out floatformat_to_doublest.  You may not even need it if you
> > only pass the data to supply_register...
> 
> Exactly.  All we do is throw the bits around to supply register.  I'm just
> looking for a way to make the structures the right size without being
> completely ugly.

If you want structures to be a particular size, you have to either
construct them using the type machinery or else just treat them as a
list of offsets and a size (all ints).  There's really nothing else
portable.  C'mon, I'll introduce you to a 32-bit-char host for fun and
see how you like it.

> Well, at the moment, the only host we build gdb for is i386 and Sparc
> (Neutrino, Solaris and Win32) but conceivably we might want to build a gdb
> for Neutrino on ppc or mips or some such.  Once again, as far as gdb is
> concerned, none of it really matters because this is just data coming over
> the wire (or from a system call) and all it needs to know is which offset
> into the structure to call supply_register on.

Record only the offsets, then.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: long long considered harmful?

[Kris Warkentin]

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

Re: long long considered harmful?

[Daniel Jacobowitz]

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

Re: long long considered harmful?

[Kris Warkentin]

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

Well, it's not really that hard.  I'm just being grumpy because it's snowing
outside and I really want to get this stuff committed one of these days.
I'd already done that to our i386 stuff both to remove the dependency on the
structure and to account for our weird ordering of registers.  See snippet
below:

Kris

/* Why 13?  Look in our debug.h header at the x86_cpu_registers structure
   and you'll see an 'exx' junk register that is just filler.  Don't ask
   me, ask the kernel guys.  */
#define NUM_GPREGS 13

/* Map a GDB register number to an offset in the reg structure.  */
static int regmap[] = {
  (7 * 4),   /* %eax */
  (6 * 4),   /* %ecx */
  (5 * 4),   /* %edx */
  (4 * 4),   /* %ebx */
  (11 * 4),   /* %esp */
  (2 * 4),   /* %epb */
  (1 * 4),   /* %esi */
  (0 * 4),   /* %edi */
  (8 * 4),   /* %eip */
  (10 * 4),   /* %eflags */
  (9 * 4),   /* %cs */
  (12 * 4),   /* %ss */
  (-1 * 4)   /* filler */
};

/* Perform mapping of gdb registers onto Neutrino registers.
   Actually works in reverse too which is why we make sure to
   return -1 if we're out of range.  */
int
gdb_to_os (int regno)
{
  return (regno >= 0 && regno < NUM_GPREGS) ? regmap[regno] >> 2 : -1;
}

void
nto_supply_gregset (char *gpregs)
{
  unsigned regno;

  for (regno = 0; regno < NUM_GPREGS - 1; regno++)
    {
      supply_register (regno, gpregs + regmap[regno]);
    }
}

Re: long long considered harmful?

[Kris Warkentin]

Inquiry:

All of our register structures in debug.h are unioned with basic arrays
guaranteed to be of sufficient size for storage.  Would it be acceptable to
leave the structures with all the registers in them so that others can look
and see how things are structured in Neutrino as long as the
<arch>-nto-tdep.c files do what I do below with the offsets?  That way
debug.h still matches our system headers but there is no code actually
relying on how the compiler organizes those structures.

Kris

> > Was that really so hard?  And it's a lot clearer.
>
> Well, it's not really that hard.  I'm just being grumpy because it's
snowing
> outside and I really want to get this stuff committed one of these days.
> I'd already done that to our i386 stuff both to remove the dependency on
the
> structure and to account for our weird ordering of registers.  See snippet
> below:
>
> Kris
>
> /* Why 13?  Look in our debug.h header at the x86_cpu_registers structure
>    and you'll see an 'exx' junk register that is just filler.  Don't ask
>    me, ask the kernel guys.  */
> #define NUM_GPREGS 13
>
> /* Map a GDB register number to an offset in the reg structure.  */
> static int regmap[] = {
>   (7 * 4),   /* %eax */
>   (6 * 4),   /* %ecx */
>   (5 * 4),   /* %edx */
>   (4 * 4),   /* %ebx */
>   (11 * 4),   /* %esp */
>   (2 * 4),   /* %epb */
>   (1 * 4),   /* %esi */
>   (0 * 4),   /* %edi */
>   (8 * 4),   /* %eip */
>   (10 * 4),   /* %eflags */
>   (9 * 4),   /* %cs */
>   (12 * 4),   /* %ss */
>   (-1 * 4)   /* filler */
> };
>
> /* Perform mapping of gdb registers onto Neutrino registers.
>    Actually works in reverse too which is why we make sure to
>    return -1 if we're out of range.  */
> int
> gdb_to_os (int regno)
> {
>   return (regno >= 0 && regno < NUM_GPREGS) ? regmap[regno] >> 2 : -1;
> }
>
> void
> nto_supply_gregset (char *gpregs)
> {
>   unsigned regno;
>
>   for (regno = 0; regno < NUM_GPREGS - 1; regno++)
>     {
>       supply_register (regno, gpregs + regmap[regno]);
>     }
> }
>
>
>

Re: long long considered harmful?

[Daniel Jacobowitz]

I'd have to see exactly what you meant, but probably not.  These things
have to be an exact size, right?  Barring wackiness like the 32-bit
char platforms, which I shouldn't have brought into this.  So if you
run on a host with 64-bit "int", it will be wrong.

Not that we have any such hosts at the moment, but they're hardly
unreasonable in the next few years.  It's the principle that's really
the issue here, not any particular host.

On Wed, Apr 23, 2003 at 05:44:41PM -0400, Kris Warkentin wrote:
> Inquiry:
> 
> All of our register structures in debug.h are unioned with basic arrays
> guaranteed to be of sufficient size for storage.  Would it be acceptable to
> leave the structures with all the registers in them so that others can look
> and see how things are structured in Neutrino as long as the
> <arch>-nto-tdep.c files do what I do below with the offsets?  That way
> debug.h still matches our system headers but there is no code actually
> relying on how the compiler organizes those structures.
> 
> Kris
> 
> > > Was that really so hard?  And it's a lot clearer.
> >
> > Well, it's not really that hard.  I'm just being grumpy because it's
> snowing
> > outside and I really want to get this stuff committed one of these days.
> > I'd already done that to our i386 stuff both to remove the dependency on
> the
> > structure and to account for our weird ordering of registers.  See snippet
> > below:
> >
> > Kris
> >
> > /* Why 13?  Look in our debug.h header at the x86_cpu_registers structure
> >    and you'll see an 'exx' junk register that is just filler.  Don't ask
> >    me, ask the kernel guys.  */
> > #define NUM_GPREGS 13
> >
> > /* Map a GDB register number to an offset in the reg structure.  */
> > static int regmap[] = {
> >   (7 * 4),   /* %eax */
> >   (6 * 4),   /* %ecx */
> >   (5 * 4),   /* %edx */
> >   (4 * 4),   /* %ebx */
> >   (11 * 4),   /* %esp */
> >   (2 * 4),   /* %epb */
> >   (1 * 4),   /* %esi */
> >   (0 * 4),   /* %edi */
> >   (8 * 4),   /* %eip */
> >   (10 * 4),   /* %eflags */
> >   (9 * 4),   /* %cs */
> >   (12 * 4),   /* %ss */
> >   (-1 * 4)   /* filler */
> > };
> >
> > /* Perform mapping of gdb registers onto Neutrino registers.
> >    Actually works in reverse too which is why we make sure to
> >    return -1 if we're out of range.  */
> > int
> > gdb_to_os (int regno)
> > {
> >   return (regno >= 0 && regno < NUM_GPREGS) ? regmap[regno] >> 2 : -1;
> > }
> >
> > void
> > nto_supply_gregset (char *gpregs)
> > {
> >   unsigned regno;
> >
> >   for (regno = 0; regno < NUM_GPREGS - 1; regno++)
> >     {
> >       supply_register (regno, gpregs + regmap[regno]);
> >     }
> > }
> >
> >
> >
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: long long considered harmful?

[Kris Warkentin]

> I'd have to see exactly what you meant, but probably not.  These things
> have to be an exact size, right?  Barring wackiness like the 32-bit
> char platforms, which I shouldn't have brought into this.  So if you
> run on a host with 64-bit "int", it will be wrong.

It just has to be AT LEAST a certain size.  If I have:

typedef struct x86_cpu_registers
{
  unsigned edi, esi, ebp, exx, ebx, edx, ecx, eax;
  unsigned eip, cs, efl;
  unsigned esp, ss;
} X86_CPU_REGISTERS;

typedef union _debug_gregs
{
  ARM_CPU_REGISTERS arm;
  ...
  X86_CPU_REGISTERS x86;
  qnx_reg64 padding[1024];
} nto_gregset_t;

Then the padding guarantees a minimum size.  If I then calculate edi, esi,
etc.
using char offsets, the way the compiler creates the structure is completely
irrelevant.  The only reason for the structure is to maintain visible
compatability with our system headers.

I like your mips fix BTW.  I think that I'd rather have the test outside of
the
loop although it's probably not a huge gain.

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

cheers,

Kris

Re: long long considered harmful?

[Daniel Jacobowitz]

On Wed, Apr 23, 2003 at 06:09:40PM -0400, Kris Warkentin wrote:
> > I'd have to see exactly what you meant, but probably not.  These things
> > have to be an exact size, right?  Barring wackiness like the 32-bit
> > char platforms, which I shouldn't have brought into this.  So if you
> > run on a host with 64-bit "int", it will be wrong.
> 
> It just has to be AT LEAST a certain size.  If I have:
> 
> typedef struct x86_cpu_registers
> {
>   unsigned edi, esi, ebp, exx, ebx, edx, ecx, eax;
>   unsigned eip, cs, efl;
>   unsigned esp, ss;
> } X86_CPU_REGISTERS;
> 
> typedef union _debug_gregs
> {
>   ARM_CPU_REGISTERS arm;
>   ...
>   X86_CPU_REGISTERS x86;
>   qnx_reg64 padding[1024];
> } nto_gregset_t;
> 
> Then the padding guarantees a minimum size.  If I then calculate edi, esi,
> etc.
> using char offsets, the way the compiler creates the structure is completely
> irrelevant.  The only reason for the structure is to maintain visible
> compatability with our system headers.

At that point, the entire contents of this header (for GDB's purposes)
could be:
typedef union _debug_gregs
{
  qnx_reg64 padding[1024];
};

Right?

If so, honestly I don't see the point of including it in GDB at all.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: long long considered harmful?

[Kris Warkentin]

> At that point, the entire contents of this header (for GDB's purposes)
> could be:
> typedef union _debug_gregs
> {
>   qnx_reg64 padding[1024];
> };
>
> Right?
>
> If so, honestly I don't see the point of including it in GDB at all.

You're absolutely right.  Ultimately, if someone really wants to see how our
registers work, they can always go look at our system headers right?.
That's the problem with legacy code.  It's not always easy to see the wheat
for the chaff.  I think I'll get rid of all the register structures just as
you suggested.

cheers,

Kris

Re: long long considered harmful?

[Andrew Cagney]

>> Was that really so hard?  And it's a lot clearer.
> 
> 
> Well, it's not really that hard.  I'm just being grumpy because it's snowing
> outside and I really want to get this stuff committed one of these days.
> I'd already done that to our i386 stuff both to remove the dependency on the
> structure and to account for our weird ordering of registers.  See snippet
> below:

I thought snow was one of Canada's two main exports?

More seriously, a things-to-do-today item is to add to gdb (well 
immediatly remote.c) code that reads in a regformats file, and then uses 
that to unpack a raw target byte-ordered (or network ordered?) buffer.

Kris, that problem sounds very similar to what you're doing here.

Andrew

Re: long long considered harmful?

[Kris Warkentin]

> I thought snow was one of Canada's two main exports?

Yeah, but in April?  Ick.

> More seriously, a things-to-do-today item is to add to gdb (well
> immediatly remote.c) code that reads in a regformats file, and then uses
> that to unpack a raw target byte-ordered (or network ordered?) buffer.
>
> Kris, that problem sounds very similar to what you're doing here.

It is.  We already handle it fairly well in our pdebug protocol but I think
what you're talking about would be very handy.  We used to monkey around
with the data a lot more than I do now since gdb is pretty good at knowing
what the target is and dealing with the registers.  I think the place where
it would be really useful for us is in marshalling and unmarshalling our
pdebug stuff.  We could probably simplify a lot and remove some assumptions.

cheers,

Kris