From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15227 invoked by alias); 23 Sep 2007 10:17:41 -0000 Received: (qmail 15215 invoked by uid 22791); 23 Sep 2007 10:17:41 -0000 X-Spam-Check-By: sourceware.org Received: from hu-out-0506.google.com (HELO hu-out-0506.google.com) (72.14.214.239) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 23 Sep 2007 10:17:37 +0000 Received: by hu-out-0506.google.com with SMTP id 22so453246hug for ; Sun, 23 Sep 2007 03:17:35 -0700 (PDT) Received: by 10.66.250.9 with SMTP id x9mr1964046ugh.1190542655008; Sun, 23 Sep 2007 03:17:35 -0700 (PDT) Received: from ?88.210.73.26? ( [88.210.73.26]) by mx.google.com with ESMTPS id d38sm2183840ugf.2007.09.23.03.17.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 23 Sep 2007 03:17:32 -0700 (PDT) Message-ID: <46F63D1C.2080409@portugalmail.pt> Date: Sun, 23 Sep 2007 10:17: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 CC: Pierre Muller , 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> <46F486B4.6050900@portugalmail.pt> <46F56F04.6070601@portugalmail.pt> <20070922225808.GD3963@adacore.com> <20070922230806.GA30487@caradoc.them.org> <20070923011723.GF3963@adacore.com> In-Reply-To: <20070923011723.GF3963@adacore.com> 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-09/txt/msg00324.txt.bz2 Joel Brobecker wrote: > > I was thinking that not having the error that was originially reported > would a good first step. If we could simply store the assembly file > produced by Pierre's example and then verify that "ptype u" works... > But now that I actually tried Pierre's example, I get no error at all, > even after having verified that I do get an @s64-etc stabs. I'm not sure > why... > Are you on an LP64 host? Changing this in read_huge_number: -upper_limit = LONG_MAX / radix; +upper_limit = 0x7fffffff / radix; ... will probably trigger it. Cheers, Pedro Alves