Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro_alves@portugalmail.pt>
To: Pierre Muller <muller@ics.u-strasbg.fr>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC] Stabs parsing regression from GDB 6.6 to GDB 6.6.90
Date: Tue, 25 Sep 2007 08:09:00 -0000	[thread overview]
Message-ID: <46F8C1C8.7080608@portugalmail.pt> (raw)
In-Reply-To: <006701c7feae$fbb75850$f32608f0$@u-strasbg.fr>

[-- Attachment #1: Type: text/plain, Size: 902 bytes --]

Pierre Muller wrote:
> 
>>>   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...
>   For good behaving compilers, probably not,
> but it never hurts to be on the sure size and to be able
> to report if some input is malformed.
> 
>   I would really appreciate that report an error
> whenever the number cannot be parsed correctly.
> 
>>>   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 ...
>>

Updated patch attached, as per your comments.

Regtested on i386-pc-cygwin, C/C++.

Cheers,
Pedro Alves

[-- Attachment #2: read_huge_number2.diff --]
[-- Type: text/x-diff, Size: 5233 bytes --]

2007-09-25  Pedro Alves  <pedro_alves@portugalmail.pt>

	* stabsread.c (read_huge_number): Fix handling of octal
	representation when the bit width is known.
	(read_range_type): Record unsigned integral types with their size,
	when the type size is known.

---
 gdb/stabsread.c |   96 +++++++++++++++++++++++++++++++++++++++-----------------
 1 file changed, 67 insertions(+), 29 deletions(-)

Index: src/gdb/stabsread.c
===================================================================
--- src.orig/gdb/stabsread.c	2007-09-24 01:38:14.000000000 +0100
+++ src/gdb/stabsread.c	2007-09-24 23:03:50.000000000 +0100
@@ -3704,14 +3704,14 @@ read_huge_number (char **pp, int end, in
   char *p = *pp;
   int sign = 1;
   int sign_bit;
+  int saw_first = 0;
   long n = 0;
-  long sn = 0;
   int radix = 10;
   char overflow = 0;
   int nbits = 0;
   int c;
   long upper_limit;
-  int twos_complement_representation;
+  int twos_complement_representation = 0;
 
   if (*p == '-')
     {
@@ -3727,7 +3727,37 @@ read_huge_number (char **pp, int end, in
       p++;
     }
 
-  twos_complement_representation = radix == 8 && twos_complement_bits > 0;
+  /* Skip extra zeros.  */
+  while (*p == '0')
+    p++;
+
+  if (sign > 0 && radix == 8 && twos_complement_bits > 0)
+    {
+      /* Octal, possibly signed.  Check if we have enough chars for a
+	 negative number.  */
+
+      size_t len;
+      char *p1 = p;
+      while ((c = *p1) >= '0' && c < '8')
+	p1++;
+
+      len = p1 - p;
+      if (len > twos_complement_bits / 3
+	  || (twos_complement_bits % 3 == 0 && len == twos_complement_bits / 3))
+	{
+	  /* Ok, we have enough characters for a signed value, check
+	     for signness by testing if the sign bit is set.  */
+	  sign_bit = (twos_complement_bits % 3 + 2) % 3;
+	  c = *p - '0';
+	  if (c & (1 << sign_bit))
+	    {
+	      /* Definitily signed.  */
+	      twos_complement_representation = 1;
+	      sign = -1;
+	    }
+	}
+    }
+
   upper_limit = LONG_MAX / radix;
 
   while ((c = *p++) >= '0' && c < ('0' + radix))
@@ -3736,23 +3766,19 @@ read_huge_number (char **pp, int end, in
         {
           if (twos_complement_representation)
             {
-              /* Octal, signed, twos complement representation. In this case,
-                 sn is the signed value, n is the corresponding absolute
-                 value. signed_bit is the position of the sign bit in the
-                 first three bits.  */
-              if (sn == 0)
-                {
-                  sign_bit = (twos_complement_bits % 3 + 2) % 3;
-                  sn = c - '0' - ((2 * (c - '0')) | (2 << sign_bit));
-                }
+	      /* Octal, signed, twos complement representation. In
+		 this case, n is the corresponding absolute value.  */
+	      if (!saw_first)
+		{
+		  long sn = c - '0' - ((2 * (c - '0')) | (2 << sign_bit));
+		  n = -sn;
+		  saw_first = 1;
+		}
               else
                 {
-                  sn *= radix;
-                  sn += c - '0';
+                  n *= radix;
+                  n += sign * (c - '0');
                 }
-
-              if (sn < 0)
-                n = -sn;
             }
           else
             {
@@ -3796,6 +3822,15 @@ read_huge_number (char **pp, int end, in
   else
     --p;
 
+  if (radix == 8 && twos_complement_bits > 0 && nbits > twos_complement_bits)
+    {
+      /* We were supposed to parse a number with maximum
+	 TWOS_COMPLEMENT_BITS bits, but something went wrong.  */
+      if (bits != NULL)
+	*bits = -1;
+      return 0;
+    }
+
   *pp = p;
   if (overflow)
     {
@@ -3809,8 +3844,9 @@ read_huge_number (char **pp, int end, in
 	}
 
       /* -0x7f is the same as 0x80.  So deal with it by adding one to
-         the number of bits.  */
-      if (sign == -1)
+         the number of bits.  Two's complement represention octals
+         can't have a '-' in front.  */
+      if (sign == -1 && !twos_complement_representation)
 	++nbits;
       if (bits)
 	*bits = nbits;
@@ -3819,10 +3855,7 @@ read_huge_number (char **pp, int end, in
     {
       if (bits)
 	*bits = 0;
-      if (twos_complement_representation)
-        return sn;
-      else
-        return n * sign;
+      return n * sign;
     }
   /* It's *BITS which has the interesting information.  */
   return 0;
@@ -3947,15 +3980,20 @@ read_range_type (char **pp, int typenums
 	return float_type;
     }
 
-  /* If the upper bound is -1, it must really be an unsigned int.  */
+  /* If the upper bound is -1, it must really be an unsigned integral.  */
 
   else if (n2 == 0 && n3 == -1)
     {
-      /* It is unsigned int or unsigned long.  */
-      /* GCC 2.3.3 uses this for long long too, but that is just a GDB 3.5
-         compatibility hack.  */
-      return init_type (TYPE_CODE_INT, 
-			gdbarch_int_bit (current_gdbarch) / TARGET_CHAR_BIT,
+      int bits = type_size;
+      if (bits <= 0)
+	{
+	  /* We don't know its size.  It is unsigned int or unsigned
+	     long.  GCC 2.3.3 uses this for long long too, but that is
+	     just a GDB 3.5 compatibility hack.  */
+	  bits = gdbarch_int_bit (current_gdbarch);
+	}
+
+      return init_type (TYPE_CODE_INT, bits / TARGET_CHAR_BIT,
 			TYPE_FLAG_UNSIGNED, NULL, objfile);
     }
 

[-- Attachment #3: read_huge_number.s --]
[-- Type: text/plain, Size: 1930 bytes --]

	.stabs	"read_huge_number.s",100,0,0,Ltext0
	.text
Ltext0:
	.stabs	"gcc2_compiled.",60,0,0,0

	.stabs  "t30:t(0,30)=@s8;r(0,30);02000;0077;",128,0,0,0
	
	.stabs	"u8:t(0,22)=r(0,22);00;0377;",128,0,0,0

	.stabs	"long long unsigned int:t(0,7)=@s64;r(0,7);0000000000000;01777777777777777777777;",128,0,0,0
	.stabs	"int:t(0,1)=r(0,1);-2147483648;2147483647;",128,0,0,0
	.stabs	"char:t(0,2)=r(0,2);0;127;",128,0,0,0
	.stabs	"long int:t(0,3)=r(0,3);-2147483648;2147483647;",128,0,0,0
	.stabs	"unsigned int:t(0,4)=r(0,4);0000000000000;0037777777777;",128,0,0,0
	.stabs	"long unsigned int:t(0,5)=r(0,5);0000000000000;0037777777777;",128,0,0,0
	.stabs	"long long int:t(0,6)=@s64;r(0,6);01000000000000000000000;0777777777777777777777;",128,0,0,0
	.stabs	"long long unsigned int:t(0,7)=@s64;r(0,7);0000000000000;01777777777777777777777;",128,0,0,0
	.stabs	"short int:t(0,8)=@s16;r(0,8);-32768;32767;",128,0,0,0
	.stabs	"short unsigned int:t(0,9)=@s16;r(0,9);0;65535;",128,0,0,0
	.stabs	"signed char:t(0,10)=@s8;r(0,10);-128;127;",128,0,0,0
	.stabs	"unsigned char:t(0,11)=@s8;r(0,11);0;255;",128,0,0,0
	.stabs	"float:t(0,12)=r(0,1);4;0;",128,0,0,0
	.stabs	"double:t(0,13)=r(0,1);8;0;",128,0,0,0
	.stabs	"long double:t(0,14)=r(0,1);12;0;",128,0,0,0
	.stabs	"complex int:t(0,15)=s8real:(0,1),0,32;imag:(0,1),32,32;;",128,0,0,0
	.stabs	"complex float:t(0,16)=R3;8;0;",128,0,0,0
	.stabs	"complex double:t(0,17)=R3;16;0;",128,0,0,0
	.stabs	"complex long double:t(0,18)=R3;24;0;",128,0,0,0
	.stabs	"void:t(0,19)=(0,19)",128,0,0,0
	.stabs	"__builtin_va_list:t(0,20)=*(0,2)",128,0,0,0
	.stabs	"_Bool:t(0,21)=@s8;-16",128,0,0,0

	.stabs	"s8:t(0,22)=@s8;r(0,22);0200;0177;",128,0,0,0
	.stabs	"s800:t(0,23)=@s64;r(0,23);01777777777777777776340;0000000001440;",128,0,0,0
	
	.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

	.text
	.stabs	"main:F(0,1)",36,0,5,_main
.globl _main
_main:

  reply	other threads:[~2007-09-25  8:09 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <000e01c7fb9b$22e600f0$68b202d0$@u-strasbg.fr>
2007-09-21  8:01 ` Pierre Muller
2007-09-22  3:07   ` Pedro Alves
2007-09-22  4:20     ` Joel Brobecker
2007-09-22 10:17       ` Pedro Alves
2007-09-22 19:39     ` Pedro Alves
2007-09-22 22:58       ` Joel Brobecker
2007-09-22 23:08         ` Daniel Jacobowitz
2007-09-23  1:17           ` Joel Brobecker
2007-09-23 10:17             ` Pedro Alves
2007-09-23 11:39           ` Pedro Alves
2007-09-23 12:42             ` Daniel Jacobowitz
2007-09-23 13:57               ` Pedro Alves
2007-09-24  0:43       ` Pedro Alves
2007-09-24  9:15         ` Pierre Muller
2007-09-24 10:21           ` Pedro Alves
2007-09-24 13:30             ` Pierre Muller
2007-09-25  8:09               ` Pedro Alves [this message]
2007-09-25 23:58                 ` Pedro Alves
2007-10-03 12:06                   ` Pierre Muller
2007-10-03 16:43                     ` Jim Blandy
2007-10-03 18:44                     ` Joel Brobecker
2007-10-03 18:51                       ` Daniel Jacobowitz
2007-10-03 19:07                         ` Joel Brobecker
2007-10-03 21:36                         ` Pedro Alves
2007-10-03 21:40                           ` Daniel Jacobowitz
2007-10-05  9:59                             ` Pedro Alves
2007-10-08 23:26                               ` Pedro Alves
2007-10-09  9:10                                 ` Pierre Muller
2007-10-09 11:39                                   ` Pedro Alves
2007-09-23  1:06     ` Joel Brobecker
2007-09-24  6:57     ` Pierre Muller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46F8C1C8.7080608@portugalmail.pt \
    --to=pedro_alves@portugalmail.pt \
    --cc=gdb-patches@sourceware.org \
    --cc=muller@ics.u-strasbg.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox