From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5477 invoked by alias); 2 Jan 2007 07:37:52 -0000 Received: (qmail 5469 invoked by uid 22791); 2 Jan 2007 07:37:51 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 02 Jan 2007 07:37:43 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id AE23448CDA9 for ; Tue, 2 Jan 2007 02:37:41 -0500 (EST) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 25220-01-6 for ; Tue, 2 Jan 2007 02:37:41 -0500 (EST) Received: from takamaka.act-europe.fr (AStDenis-105-1-58-225.w80-8.abo.wanadoo.fr [80.8.155.225]) by nile.gnat.com (Postfix) with ESMTP id 4A8A548CBCB for ; Tue, 2 Jan 2007 02:37:40 -0500 (EST) Received: by takamaka.act-europe.fr (Postfix, from userid 1000) id B9FA234C099; Tue, 2 Jan 2007 11:38:27 +0400 (RET) Date: Tue, 02 Jan 2007 07:37:00 -0000 From: Joel Brobecker To: gdb@sourceware.org Subject: Re: Ada testsuite failures Message-ID: <20070102073827.GB3434@adacore.com> References: <20061231194604.GA23919@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061231194604.GA23919@nevyn.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: 2007-01/txt/msg00008.txt.bz2 > Joel, I have seen Ada testsuite failures on GNU/Linux for about as long > as we've had tests. Do you know the status of these tests when run > against FSF releases of gnat, rather than the AdaCore version? I don't work at all with the FSF release of GCC, only with the AdaCore one. > I suspect it's inadequate debug info. I wouldn't be surprised. Recents versions of GCC are much better at not emitting debugging info for unused entity. This has caused us a lot of trouble when moving to GCC 4.1 for instance, because GNAT generates of lot of entities that appear unused from the compiler point of view, but are necessary for the debugger to work properly. We're getting back to the same project of getting rid of all these encoding in favor of standard DWARF. This is actually a very active project that we're working on right now, so hopefully the situation won't be as bad soon. I can ask that the local patches we maintain in our tree be submitted for inclusion if you think they'd be accepted. Our opinion was that they would probably be rejected as a step backward. > print e_one_two_three > $2 = (0 => 1, 2, 3) In this case, for instance, you are probably missing the debugging info for a type named: p__etable___XA. If you have a look at exp_dbug.ads in the compiler sources, this is what we call a parallel type which contains one field. The name of the field is the name of array index type. Not very elegant, but necessary in many cases when the platform does not support stabs. > print p_one_two_three > $4 = warning: could not find bounds information on packed array > can't unpack array > > (gdb) FAIL: gdb.ada/arrayidx.exp: print p_one_two_three, indexes off This case is probably the same sort of issue. I looked at the sources and it looks like GDB did not find the parallel type correspoinding to this array. The parallel type is computed by stripping the ___XP suffix in the type name (in this case, it looks like GDB failed to find type p__ptable. > ptype empty > type = function return int > (gdb) FAIL: gdb.ada/null_record.exp: ptype on null record Strangely, I just noticed that I have the same failure on my side. I will investigate. > $1 = warning: could not find bounds information on packed array > can't unpack array > > (gdb) FAIL: gdb.ada/packed_array.exp: print var This is probably the same as the packed array case above. -- Joel