This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: [RFC] Stabs parsing regression from GDB 6.6 to GDB 6.6.90
Did you change the read_huge_number.s file manually?
It is as if there is an typing error for the
u16 type definition.
.stabs "s16:t(0,24)=@s16;r(0,24);0100000;077777;",128,0,0,0
.stabs "u16:t(0,25);r(0,25);0000000;0177777;",128,0,0,0
the ';' before 'r(0,25)' should be an equal sign, no?
One difference between my patch and yours is
that I think that your patch will mishandle
any octal number having more digits than needed,
because you are always considering that the
first char after the leading zero (to trigger octal notation)
contains the sign bit.
For instance, your patch does not complaint about this
.stabs "t30:t(0,30)=@s8;r(0,30);02000;0077;",128,0,0,0
but 02000 is -1024 and does not fit into a 8 bit memory.
I agree that there are normally no reasons to have more digits,
but more leading zeroes should not lead to an error in the parsing
and any bit set higher that this should trigger an error.
By the way, why is read_huge_number returning a 'long'?
It should be much better to return a LONGEST
LONGEST_MAX also exists, so switching
the type of that function to read_huge_number
would allow to get correct results much more often.
The main interest would be to really get the
real upper and lower bounds of range type
even if they do not fit into 'long' type.
These fields are currently put into
TYPE_FIELD_BITPOS which is a 'long' type
but this is in a union so adding one more field
on type 'LONGEST' and name 'bound',
adding a TYPE_FIELD_BOUND macro would be
easier to read but would increase the 'field_location'
element of the 'type' structure.
Another solution would be to
create a pointer to a 'LONGEST' value,
which would remove an increase of the general
'type' struct size.
Pierre Muller