From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7303 invoked by alias); 22 Sep 2007 03:07:55 -0000 Received: (qmail 7293 invoked by uid 22791); 22 Sep 2007 03:07:54 -0000 X-Spam-Check-By: sourceware.org Received: from ug-out-1314.google.com (HELO ug-out-1314.google.com) (66.249.92.170) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 22 Sep 2007 03:07:50 +0000 Received: by ug-out-1314.google.com with SMTP id o2so695022uge for ; Fri, 21 Sep 2007 20:07:47 -0700 (PDT) Received: by 10.67.20.11 with SMTP id x11mr5099495ugi.1190430466456; Fri, 21 Sep 2007 20:07:46 -0700 (PDT) Received: from ?62.169.92.224? ( [62.169.92.224]) by mx.google.com with ESMTPS id 7sm2773639nfv.2007.09.21.20.07.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 21 Sep 2007 20:07:42 -0700 (PDT) Message-ID: <46F486B4.6050900@portugalmail.pt> Date: Sat, 22 Sep 2007 03:07: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: Pierre Muller CC: gdb-patches@sourceware.org Subject: Re: [RFC] Stabs parsing regression from GDB 6.6 to GDB 6.6.90 References: <000e01c7fb9b$22e600f0$68b202d0$@u-strasbg.fr> <000601c7fc25$98110430$c8330c90$@u-strasbg.fr> In-Reply-To: <000601c7fc25$98110430$c8330c90$@u-strasbg.fr> Content-Type: multipart/mixed; boundary="------------050704040704020001030502" 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/msg00288.txt.bz2 This is a multi-part message in MIME format. --------------050704040704020001030502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 2191 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: /* 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 :( ) What about the attached? Isn't it simpler? We get passed the max number of bits the number we're parsing can hold in TWOS_COMPLEMENT_BITS. Just parse the number as unsigned, if it overflows, it doesn't matter, we just account for the bits. If it doesn't overflow (host has a big long), and TWOS_COMPLEMENT_BITS < sizeof (long) * HOST_CHAR_BIT and number is signed according to TWOS_COMPLEMENT_BITS - 1 bit being set, sign extend the number into a long. Just tested that it also fixes the problem. I'll give it a testsuite spin for C/C++ on Cygwin tomorrow, but the testcase that suposedly tests this is in ADA, which I don't have a setup for... Cheers, Pedro Alves --------------050704040704020001030502 Content-Type: text/x-diff; name="stabsread.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="stabsread.c.diff" Content-length: 2477 2007-09-22 Pedro Alves * stabsread.c (read_huge_number): Remove special parsing of octal two's complement representation. If just parsed a negative number in octal two's complement representation, sign extend the result to a long. Index: stabsread.c =================================================================== RCS file: /cvs/src/src/gdb/stabsread.c,v retrieving revision 1.95 diff -u -p -r1.95 stabsread.c --- stabsread.c 10 Aug 2007 22:08:22 -0000 1.95 +++ stabsread.c 22 Sep 2007 02:28:15 -0000 @@ -3737,32 +3737,9 @@ read_huge_number (char **pp, int end, in { if (n <= upper_limit) { - 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)); - } - else - { - sn *= radix; - sn += c - '0'; - } - - if (sn < 0) - n = -sn; - } - else - { - /* unsigned representation */ - n *= radix; - n += c - '0'; /* FIXME this overflows anyway */ - } + /* unsigned representation */ + n *= radix; + n += c - '0'; /* FIXME this overflows anyway */ } else overflow = 1; @@ -3823,7 +3800,25 @@ read_huge_number (char **pp, int end, in if (bits) *bits = 0; if (twos_complement_representation) - return sn; + { + if (nbits == twos_complement_bits) + { + /* N is signed. TWOS_COMPLEMENT_BITS may be less than + what fits in a long. Since we can't assume a host + with two's complement long, extract the module value + of N, and multiply it with -1. + + eg: with TWOS_COMPLEMENT_BITS == 16, and sizeof long == 32, + 0x00008111 => 0xffff7eef => 0x00007eef => 0xffff8111. */ + + unsigned long l = (unsigned long) n; + l = ~l + 1; + l &= (1L << twos_complement_bits) - 1; + l *= -1; + n = l; + } + return n; + } else return n * sign; } --------------050704040704020001030502--