From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15506 invoked by alias); 3 Oct 2007 21:36:28 -0000 Received: (qmail 15498 invoked by uid 22791); 3 Oct 2007 21:36:27 -0000 X-Spam-Check-By: sourceware.org Received: from mu-out-0910.google.com (HELO mu-out-0910.google.com) (209.85.134.189) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 03 Oct 2007 21:36:24 +0000 Received: by mu-out-0910.google.com with SMTP id g7so5747279muf for ; Wed, 03 Oct 2007 14:36:19 -0700 (PDT) Received: by 10.82.171.16 with SMTP id t16mr6156951bue.1191447378799; Wed, 03 Oct 2007 14:36:18 -0700 (PDT) Received: from ?78.130.32.227? ( [78.130.32.227]) by mx.google.com with ESMTPS id h7sm5577441nfh.2007.10.03.14.36.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Oct 2007 14:36:17 -0700 (PDT) Message-ID: <47040AD9.6000900@portugalmail.pt> Date: Wed, 03 Oct 2007 21:36:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Joel Brobecker , Pierre Muller , 'Pedro Alves' , gdb-patches@sourceware.org Subject: Re: [RFC] Stabs parsing regression from GDB 6.6 to GDB 6.6.90 References: <46F486B4.6050900@portugalmail.pt> <46F56F04.6070601@portugalmail.pt> <46F707C3.1090105@portugalmail.pt> <006101c7fe8b$70d5af70$52810e50$@u-strasbg.fr> <4053daab0709240321n40d7e3e0vc0f7d5567e990785@mail.gmail.com> <006701c7feae$fbb75850$f32608f0$@u-strasbg.fr> <46F8C1C8.7080608@portugalmail.pt> <46F9A061.2020909@portugalmail.pt> <001b01c805b5$ce7f0730$6b7d1590$@u-strasbg.fr> <20071003184156.GC4305@adacore.com> <20071003185126.GA1976@caradoc.them.org> In-Reply-To: <20071003185126.GA1976@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-10/txt/msg00040.txt.bz2 Daniel Jacobowitz wrote: > On Wed, Oct 03, 2007 at 11:41:56AM -0700, Joel Brobecker wrote: >>> I definitively think that this patch should go both into >>> head and branch, but it needs approval from someone else... >> Unless someone like Elena who knows this code very well says it's safe, >> I would prefer if the patch didn't get applied to the branch. I'm a bit >> concerned about it given the few iterations that you both had to go >> through in order to get it to that point. It just shows that it is >> not obvious. > That's because the original code to read signed octals was never triggered from day 1. I suspect it was due to a bad/incomplete merge from whatever tree it came from, and a testcase that doesn't really trigger it. > I think it's a bad idea to ship a release of GDB with a new bug that > we know about, which wasn't present in the previous release. > Another option is to revert this on the branch: 2007-08-04 Michael Snyder * stabsread.c (read_huge_number): Attempt to compute value before values that it depends on. Since nobody complained until then (except for Coverity). The signed octal parsing was dead code Before Michail's Patch (BMP), and is broken after it. BMP, the basic types happened to be recorded with the correct bit sizes, but ADA ranges that have a negative edge (-50, 50) would be misrecorded . That was what the original code attempted to fix, but I don't really know where it makes a difference. Perhaps a print command which sets a value whose type is covered by a range, with an out-of-range value, will trigger a warning: print var = -51 warning: -51 is out of range for type x [-50, 50]. If gdb doesn't do it yet, it could be useful anyway. What I know of ADA is what one can learn from a 10 minutes HOWTO reading. > I read through the patch. It seems fine to me, though I am mostly > trusting Pedro, Pierre, and their test cases. >