This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [RFC] Stabs parsing regression from GDB 6.6 to GDB 6.6.90

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

	* 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: [] On
> Behalf Of Pierre Muller
> Sent: Thursday, September 20, 2007 5:30 PM
> To:
> 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 %lu\r\n",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;",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;0777777777777777777777;"
> ,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

Attachment: stabsread.patch
Description: Binary data

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]