From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13577 invoked by alias); 24 Sep 2007 10:21:39 -0000 Received: (qmail 13567 invoked by uid 22791); 24 Sep 2007 10:21:38 -0000 X-Spam-Check-By: sourceware.org Received: from nf-out-0910.google.com (HELO nf-out-0910.google.com) (64.233.182.191) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 24 Sep 2007 10:21:33 +0000 Received: by nf-out-0910.google.com with SMTP id b11so1162260nfh for ; Mon, 24 Sep 2007 03:21:31 -0700 (PDT) Received: by 10.78.160.2 with SMTP id i2mr1241852hue.1190629290770; Mon, 24 Sep 2007 03:21:30 -0700 (PDT) Received: by 10.78.192.16 with HTTP; Mon, 24 Sep 2007 03:21:30 -0700 (PDT) Message-ID: <4053daab0709240321n40d7e3e0vc0f7d5567e990785@mail.gmail.com> Date: Mon, 24 Sep 2007 10:21:00 -0000 From: "Pedro Alves" To: "Pierre Muller" Subject: Re: [RFC] Stabs parsing regression from GDB 6.6 to GDB 6.6.90 Cc: gdb-patches@sourceware.org In-Reply-To: <006101c7fe8b$70d5af70$52810e50$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> <006101c7fe8b$70d5af70$52810e50$@u-strasbg.fr> X-Google-Sender-Auth: 0bd6f3d7d700a3f4 X-IsSubscribed: yes 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/msg00336.txt.bz2 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