From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12693 invoked by alias); 24 Sep 2007 09:15:33 -0000 Received: (qmail 12685 invoked by uid 22791); 24 Sep 2007 09:15:32 -0000 X-Spam-Check-By: sourceware.org Received: from ics.u-strasbg.fr (HELO ics.u-strasbg.fr) (130.79.112.250) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 24 Sep 2007 09:15:30 +0000 Received: from ICSMULLER (laocoon.u-strasbg.fr [130.79.112.72]) by ics.u-strasbg.fr (Postfix) with ESMTP id 555D1187020; Mon, 24 Sep 2007 11:20:24 +0200 (CEST) From: "Pierre Muller" To: "'Pedro Alves'" Cc: References: <000e01c7fb9b$22e600f0$68b202d0$@u-strasbg.fr> <000601c7fc25$98110430$c8330c90$@u-strasbg.fr> <46F486B4.6050900@portugalmail.pt> <46F56F04.6070601@portugalmail.pt> <46F707C3.1090105@portugalmail.pt> In-Reply-To: <46F707C3.1090105@portugalmail.pt> Subject: RE: [RFC] Stabs parsing regression from GDB 6.6 to GDB 6.6.90 Date: Mon, 24 Sep 2007 09:15:00 -0000 Message-ID: <006101c7fe8b$70d5af70$52810e50$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-09/txt/msg00335.txt.bz2 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