From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29860 invoked by alias); 28 Mar 2011 16:50:40 -0000 Received: (qmail 29846 invoked by uid 22791); 28 Mar 2011 16:50:36 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 28 Mar 2011 16:50:28 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id A26472BAF90; Mon, 28 Mar 2011 12:50:27 -0400 (EDT) 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 B9VAS7nterEN; Mon, 28 Mar 2011 12:50:27 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 5ADE62BAF8E; Mon, 28 Mar 2011 12:50:26 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id DAED4145869; Mon, 28 Mar 2011 09:50:22 -0700 (PDT) Date: Mon, 28 Mar 2011 18:05:00 -0000 From: Joel Brobecker To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: [patch] ada testsuite: False FAILs with gcc debug info Message-ID: <20110328165022.GB3670@adacore.com> References: <20110327081139.GA30398@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110327081139.GA30398@host1.jankratochvil.net> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2011-03/txt/msg01132.txt.bz2 > with installed and matching debug infos there flip some gdb.ada/ testsuite > results PASS->FAIL: Yeah - I wasn't expecting anyone to run the testsuite using a runtime that has debugging info. It introduces other issues as well (we worked around some of these issues for the sake of people working on the compiler). It's not easy for you to flip runtimes, so we can try accomodating... Just a thought: Perhaps it might be easier to flip runtimes if you provide the runtime with debug info as a second runtime. There is a way to do this, and then the user controls which one he wants using --RTS= (only when the default one is not the one he wants). > (gdb) print String_Var (1 .. 3) = "Hel" > -$1 = true > -(gdb) PASS: gdb.ada/str_ref_cmp.exp: print String_Var (1 .. 3) = "Hel" > +$1 = false > +(gdb) FAIL: gdb.ada/str_ref_cmp.exp: print String_Var (1 .. 3) = "Hel" > as even just > (gdb) print "a"="a" > starts giving `false' with debug info installed, the BINOP_EQUAL > operator resolves to: ada__strings__maps__Oeq (Ada.Strings.Maps) as > its type matches in ada_resolve_function. I do not understand the Ada > scoping to fix it, filed PR for KFAIL. This is incorrect, but I cannot reproduce (we should be able to get the same behavior by recompiling the program with "-f -a", which tells gnatmake to recompile everything, including runtime files). In this case, the lookup is "wild", because the entity name is not qualified using the package name. Regardless of that, the scoping rules we use to match is: - If there is a local symbol, use that and disregard any global symbol that might have matched otherwise; - If no match, then we move to file-static, I think; - And finally, we look for globals; The match is incorrect as far as I can tell, because the only "=" function defined in this package is the one for type Character_Set: function "=" (Left, Right : Character_Set) return Boolean; And type Character_Set does not match type String: type Character_Set_Internal is array (Character) of Boolean; pragma Pack (Character_Set_Internal); type Character_Set is new Character_Set_Internal; Type string is implicitly defined as: type String is array (Positive range <>) of Character; pragma Pack (String); I think the debugging info must be incorrect. That being said, we noticed a side-effect of this kind a while ago, except I can't find it in my notes anymore. It was valid matching at the time, except that the user-define "=" did not have the usual semantics, and thus was yielding surprising results. > gdb/testsuite/ > 2011-03-27 Jan Kratochvil > > * gdb.ada/arrayparam.exp (print first after function call): Use > explicit package name. Add a comment > (print lasta after function call): Rename ... > (print last after function call): ... it and use explicit package > name. > (print length after function call): Use explicit package name. > * gdb.ada/str_ref_cmp.exp (operator = works for strings): New test. > * gdb.ada/sym_print_name.exp: Change `i' to `integervar'. > (multiple matches for symbol i): Rename ... > (multiple matches for symbol integervar): ... it. > * gdb.ada/sym_print_name/foo.adb (Foo): Change `I' to `IntegerVar'. > * gdb.ada/sym_print_name/pck.ads (Pck): Likewise. This is OK. Just one minor comment: `IntegerVar' is not very Ada-ish. Normally, one would use `Integer_Var' instead. However, thinking about it, I think it's good, because it reduces further the chances of this entity name being used in the compiler runtime, thus causing an extra unexpected match. So, let's keep it that way. -- Joel