From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20926 invoked by alias); 24 Sep 2007 06:57:45 -0000 Received: (qmail 20918 invoked by uid 22791); 24 Sep 2007 06:57:44 -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 06:57:42 +0000 Received: from ICSMULLER (laocoon.u-strasbg.fr [130.79.112.72]) by ics.u-strasbg.fr (Postfix) with ESMTP id 6292118701F; Mon, 24 Sep 2007 09:02:36 +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> In-Reply-To: <46F486B4.6050900@portugalmail.pt> Subject: RE: [RFC] Stabs parsing regression from GDB 6.6 to GDB 6.6.90 Date: Mon, 24 Sep 2007 06:57:00 -0000 Message-ID: <005d01c7fe78$309525c0$91bf7140$@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/msg00334.txt.bz2 > -----Original Message----- > From: Pedro Alves [mailto:alves.ped@gmail.com] On Behalf Of Pedro Alves > Sent: Saturday, September 22, 2007 5:06 AM > To: Pierre Muller > Cc: gdb-patches@sourceware.org > Subject: Re: [RFC] Stabs parsing regression from GDB 6.6 to GDB 6.6.90 > > Hi, > > This afects Cygwin badly, as it still uses stabs by default. > I've seen this problem here, but thought it was caused by a few gcc > changes I was making ... > > Pierre Muller wrote: > > As I was unable to understand the current implementation of the > > twos_complement_representation > > I can't really see how it was supposed to work either. > Parsing 000000000 is broken currently. > > > I rewrote it almost completely. > > You are only counting the bits. This function should return the parsed > number if it fits in a long: My idea was to clear the sign bit and let the normal code handle the parsing of the value, but I completely forgot that two complement notation is not the same as the multiplication by -1. So I should probably have let the sign bit and parse it as an unsigned integer. > /* If TWOS_COMPLEMENT_BITS is set to a strictly positive value and if > the number is represented in an octal representation, assume that > it is represented in a 2's complement representation with a size > of > TWOS_COMPLEMENT_BITS. > > If the number fits in a long, set *BITS to 0 and return the value. > If not, set *BITS to be the number of bits in the number and > return 0. > > If encounter garbage, set *BITS to -1 and return 0. */ > > > > The code now checks that the most significant bit of the whole > octal > > representation of the huge number that is being parsed is exactly at > > the bit position given by the twos_complement_bits parameter. > > > > > The attached patch (against 6.6.90 source) fixes the problem that I > > describe in the previous email. I get no complaint for the 'unsigned > > long long' type compiled with '-gstabs+' option. > > > > Thanks for pointing in the right direction! > > (Forgive me for counter patching, but I had started on this > here too yesterday :( ) As nobody reacted on my first email, I thought that nobody cared. I am glad you propose a new patch. As you already proposed a second one, I will try to comment on that one directly. Thanks Pierre Muller