From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22960 invoked by alias); 2 Jan 2007 11:30:25 -0000 Received: (qmail 22949 invoked by uid 22791); 2 Jan 2007 11:30:24 -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 11:30:18 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id CBAE648CCBF for ; Tue, 2 Jan 2007 06:30:16 -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 17452-01-2 for ; Tue, 2 Jan 2007 06:30:16 -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 5D49548CC27 for ; Tue, 2 Jan 2007 06:30:15 -0500 (EST) Received: by takamaka.act-europe.fr (Postfix, from userid 1000) id EADC634C099; Tue, 2 Jan 2007 15:31:02 +0400 (RET) Date: Tue, 02 Jan 2007 11:30:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: [RFA] fix gdb.ada/null_record.exp Message-ID: <20070102113102.GJ17211@adacore.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="XMCwj5IQnwKtuyBG" Content-Disposition: inline User-Agent: Mutt/1.4.2.2i 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-01/txt/msg00047.txt.bz2 --XMCwj5IQnwKtuyBG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 1899 Hello, Daniel reported that null_record.exp was failing. The test was failing on my side as well, although not the same way (I was so intent on finding out what the cause was that I didn't pay enough attention to what Daniel posted - sorry). Here is what I observed: ptype empty type = (gdb) FAIL: gdb.ada/null_record.exp: ptype on null record The output is not a surprise when you look at what ada_evaluate_subexp returns for OP_TYPE expressions: case OP_TYPE: /* The value is not supposed to be used. This is here to make it easier to accommodate expressions that contain types. */ (*pos) += 2; if (noside == EVAL_SKIP) goto nosideret; else if (noside == EVAL_AVOID_SIDE_EFFECTS) !!!-> return allocate_value (builtin_type_void); else error (_("Attempt to use a type name as an expression")); The reason this was good enough is that, in GDB 6.4 (we are still using this as our baseline), ptype_command was not doing a full evaluation of the expression to get the type description. Rather, it used a short-cut: static struct type * ptype_eval (struct expression *exp) { if (exp->elts[0].opcode == OP_TYPE) { return (exp->elts[1].type); } else [...] } This was changed since then to call evaluate_type (expr) instead, Knowing this, I discovered that calling ptype on probably any type name would return this "" type. I reproduced this with a non- null record too, for instance. The proposed fix is attached: 2007-01-02 Joel Brobecker * ada-lang.c (ada_evaluate_subexp) [OP_TYPE]: Return a value with the appropriate type rather than a bogus void type. Tested on x86-linux, no regression. Fixes the null_record.exp on my side. OK to apply? Thanks, -- Joel --XMCwj5IQnwKtuyBG Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ada-lang.c.diff" Content-length: 628 Index: ada-lang.c =================================================================== RCS file: /cvs/src/src/gdb/ada-lang.c,v retrieving revision 1.85 diff -u -p -r1.85 ada-lang.c --- ada-lang.c 1 Dec 2006 00:32:29 -0000 1.85 +++ ada-lang.c 2 Jan 2007 10:52:36 -0000 @@ -8576,7 +8576,7 @@ ada_evaluate_subexp (struct type *expect if (noside == EVAL_SKIP) goto nosideret; else if (noside == EVAL_AVOID_SIDE_EFFECTS) - return allocate_value (builtin_type_void); + return allocate_value (exp->elts[pc + 1].type); else error (_("Attempt to use a type name as an expression")); --XMCwj5IQnwKtuyBG--