Re: symtab/154: GDB truncates 64 bit enums.

[Kevin Nomura <nomura at netapp dot com>]

The following reply was made to PR symtab/154; it has been noted by GNATS.

From: Kevin Nomura <nomura@netapp.com>
To: gdb-gnats@sources.redhat.com
Cc:  
Subject: Re: symtab/154: GDB truncates 64 bit enums.
Date: Mon, 13 Sep 2004 15:10:40 -0700

 gdb 6.2 with gcc 3.4.1 still has problems with enum 
 values wider than an int.  gdb crashes can occur
 when stabsread.c:read_enum_type returns "error_type"
 
       n = read_huge_number (pp, ',', &nbits);
       if (nbits != 0)
 	return error_type (pp, objfile);
 
 which engenders a NULL type field in the symtab.
 Anyway this is an old problem report so I am sure
 you are aware of the symptoms.
 
 I have tinkered with working around this in 6.2 by
 expanding "ivalue" to a LONGEST in 
 symtab.h:struct general_symbol_info:
 
   union
   {
     /* The fact that this is a long not a LONGEST mainly limits the
        range of a LOC_CONST.  Since LOC_CONST_BYTES exists, I'm not
        sure that is a big deal.  */
     int  ivalue;    
 
 and expanding "bitpos" to a LONGEST in gdbtypes.h:struct main_type:
 
   struct field
   {
     union field_location
     {
       /* Position of this field, counting in bits from start of
 	 containing structure.
 	 For BITS_BIG_ENDIAN=1 targets, it is the bit offset to the MSB.
 	 For BITS_BIG_ENDIAN=0 targets, it is the bit offset to the LSB.
 	 For a range bound or enum value, this is the value itself. */
 
       LONGEST bitpos;
 
 and providing a version of stabsread.c:read_huge_number, which allows 
 64 bit integers, for read_enum_type to call.  gdb seems happy with this
 to a first approximation.  The segfault is gone, the values display
 properly with "p" and "ptype".
 
 However I've clearly tweaked some global data structures.  Warnings
 about typecasts of 64-bit ints to 32-bit pointers, and warnings about
 printfs being passed a 64-bit int to a %d format, pop out here and
 there, unrelated to enum code. 
 
 Is this the right approach, and a straightforward cleanup will address
 the warnings and be internally consistent?