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

["Pedro Alves" <pedro_alves@portugalmail.pt>]

Pierre Muller wrote:
>   Did you change the read_huge_number.s file manually?

Yes.

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

Looks like so.  You sharp eyed :)

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

Right.  Does this really ever happen?  A check can be added then...
One can do it upfront like your patch does, or checking for
'n bits parsed' > size_type (is size_type > 0) after the parse loop should be
enough, I guess.

>   I agree that there are normally no reasons to have more digits,
> but more  leading zeroes should not lead to an error

They don't, AFAICS.

> ... in the parsing
> and any bit set higher that this should trigger an error.
>

OK ...

I didn't mention why I didn't take your approach, but followed what I
believe the
original code intended to do:
  - It changes the input string.  I don't believe that is correct.
Read only data
  comes to mind.
  - It parses 01777777777777777776340 as an overflow (doesn't it?)

Cheers,
Pedro Alves