Stabs parsing regression from GDB 6.6 to GDB 6.6.90

  There is a new problem that 
appears in 6.6.90 and was not present in 
6.6 related to the gcc
-gstabs+ option.

  If I compile the following tiny source
and try to get the type of the variable u,
I get an error, because
gdb is not able to handle the extended 
stabs generated with -gstabs+ option
(if you only use -gstabs, it works OK).

>>>Source file:
unsigned long long u;

int
main ()
{
  u = 15;
  printf("Value of u is %lurn",u);
  return 0;
}
>>>End of source file

>>> Compilation
gcc -gstabs+ -o testll testll.c

>>> Launch gdb

gdb6690 ./testll
and
type 'ptyp u'

and you will receive an error...

The error is caused by:
        .stabs  "long long unsigned
int:t(0,7)=s64;r(0,7);0000000000000;01777777777777777777777;&quo
t;,128,0,0,0
(With -gstabs, you don't get the 's64;' part
which means that the size is 64 bits wide).

Note that this is parsed without generating errors:
       .stabs  "long long
int:t(0,6)=s64;r(0,6);01000000000000000000000;077777777777777777
7777;",128,
0,0,0

I added Michael Snyder in CC
because it is the only name that
I found associated with a recent change in read_huge_number
stabsread.c function. It seems that
his change changed the position
of the assignment of the variable
twos_complement_representation,
that was set in earlier version before
radix could be changed to 8 because of a leading '0'.


  Thus in 6.6 gdb, twos_complement_representation is 
always equal to zero and the problem appears
now because it is now set correctly. It seems 
that the code for twos_complement_representation
is not working properly for 13 '0' as in 'long long unsigned
int' type
above.
But I am unable to understand the code correctly.

  Michael, could you please confirm my problem and 
tell us if the 

Pierre Muller
Pascal language code maintainer

  As I was unable to understand the current implementation
of
the twos_complement_representation
I rewrote it almost completely.
  The code now checks that the most significant
bit of the whole octal representation of the huge number
that is being parsed is exactly at the bit position given
by
the twos_complement_bits parameter.

  The attached patch (against 6.6.90 source)
fixes the problem that I describe in the previous
email. I get no complaint for the 'unsigned long long' type
compiled with '-gstabs+' option.

ChangeLog entry:

2007-0921  Pierre Muller <mulleris.u-strasbg.fr>

	* stabsread.c (read_huge_number): fix the parsing
	of octal representation when twos_complement_bits 
	value is set.

  I am sorry, but I am again unable to check
if there are no regressions.
 

Pierre Muller

> -----Original Message-----
> From: gdb-ownersourceware.org [mailto:gdb-ownersourceware.org] On
> Behalf Of Pierre Muller
> Sent: Thursday, September 20, 2007 5:30 PM
> To: gdbsourceware.org
> Cc: 'Michael Snyder'
> Subject: [RFC] Stabs parsing regression from GDB 6.6 to
GDB 6.6.90
> 
>   There is a new problem that
> appears in 6.6.90 and was not present in
> 6.6 related to the gcc
> -gstabs+ option.
> 
>   If I compile the following tiny source
> and try to get the type of the variable u,
> I get an error, because
> gdb is not able to handle the extended
> stabs generated with -gstabs+ option
> (if you only use -gstabs, it works OK).
> 
> >>>Source file:
> unsigned long long u;
> 
> int
> main ()
> {
>   u = 15;
>   printf("Value of u is %lurn",u);
>   return 0;
> }
> >>>End of source file
> 
> >>> Compilation
> gcc -gstabs+ -o testll testll.c
> 
> >>> Launch gdb
> 
> gdb6690 ./testll
> and
> type 'ptyp u'
> 
> and you will receive an error...
> 
> The error is caused by:
>         .stabs  "long long unsigned
> int:t(0,7)=s64;r(0,7);0000000000000;01777777777777777777777;&quo
t;,128,0,0,
> 0
> (With -gstabs, you don't get the 's64;'
part
> which means that the size is 64 bits wide).
> 
> Note that this is parsed without generating errors:
>        .stabs  "long long
> int:t(0,6)=s64;r(0,6);01000000000000000000000;077777777777777777
7777;"
> ,128,
> 0,0,0
> 
> I added Michael Snyder in CC
> because it is the only name that
> I found associated with a recent change in
read_huge_number
> stabsread.c function. It seems that
> his change changed the position
> of the assignment of the variable
> twos_complement_representation,
> that was set in earlier version before
> radix could be changed to 8 because of a leading '0'.
> 
> 
>   Thus in 6.6 gdb, twos_complement_representation is
> always equal to zero and the problem appears
> now because it is now set correctly. It seems
> that the code for twos_complement_representation
> is not working properly for 13 '0' as in 'long long
unsigned int' type
> above.
> But I am unable to understand the code correctly.
> 
>   Michael, could you please confirm my problem and
> tell us if the
> 
> Pierre Muller
> Pascal language code maintainer
>