From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30673 invoked by alias); 24 Jan 2008 00:31:58 -0000 Received: (qmail 30618 invoked by uid 22791); 24 Jan 2008 00:31:38 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 24 Jan 2008 00:31:15 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 316D72A9649 for ; Wed, 23 Jan 2008 19:31:13 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 06RPsj+G6LRI for ; Wed, 23 Jan 2008 19:31:13 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id F0A0C2A961F for ; Wed, 23 Jan 2008 19:31:12 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id DB0AEE7ACB; Wed, 23 Jan 2008 16:31:10 -0800 (PST) Date: Thu, 24 Jan 2008 00:31:00 -0000 From: Joel Brobecker To: gdb@sourceware.org Subject: Re: FYI: Ada results on Debian/unstable Message-ID: <20080124003110.GF23576@adacore.com> References: <20080123131442.GA32621@caradoc.them.org> <20080123184710.GC23576@adacore.com> <20080123185325.GA20408@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080123185325.GA20408@caradoc.them.org> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00242.txt.bz2 > Nope. Just annoying to me, but now that I have a new baseline, it's > no big deal. Good to know that you can work with a baseline. I'm not sure there is much we can do to help. I looked at the GCC web pages, and even if we wanted to, I don't think that we'll be able to push any changes to the 4.1 branch. What I can say is that I'm regularly monitoring the Ada testcases by running them and making sure that none of them regress (but that's with the AdaCore compiler, though, as I very very rarely build my own compiler). I don't think that it's a big deal if you decide to always ignore failures inside gdb.ada. I think that Eric Botcazou and Olivier Hainque are particularly diligent at submitting GCC backend changes for AdaCore, and Arno Charlet should be taking care of all the front-end changes. So we should converge at some point. > (gdb) print r > $1 = (x => 1, y => 2, w => 3, h => 4) > (gdb) PASS: gdb.ada/interface.exp: print r > print s > /space/fsf/commit/src/gdb/utils.c:904: internal-error: virtual memory > exhausted: can't allocate 4294967423 bytes. > A problem internal to GDB has been detected, That could indeed be related to bad debugging info. -- Joel