From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26132 invoked by alias); 17 Jul 2008 21:49:14 -0000 Received: (qmail 26121 invoked by uid 22791); 17 Jul 2008 21:49:12 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 17 Jul 2008 21:48:56 +0000 Received: from zps36.corp.google.com (zps36.corp.google.com [172.25.146.36]) by smtp-out.google.com with ESMTP id m6HLmhU9016239 for ; Thu, 17 Jul 2008 22:48:43 +0100 Received: from localhost (elbrus.corp.google.com [172.18.116.17]) by zps36.corp.google.com with ESMTP id m6HLmdH1025750; Thu, 17 Jul 2008 14:48:39 -0700 Received: by localhost (Postfix, from userid 74925) id 6AE253A67B6; Thu, 17 Jul 2008 14:48:39 -0700 (PDT) To: gdb-patches@sourceware.org Subject: [RFC] [patch] 'p->x' vs. 'p.x' and 'print object on' Message-Id: <20080717214839.6AE253A67B6@localhost> Date: Thu, 17 Jul 2008 21:49:00 -0000 From: ppluzhnikov@google.com (Paul Pluzhnikov) 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: 2008-07/txt/msg00353.txt.bz2 Greetings, Long time GDB users are somewhat used to 'p->x' and 'p.x' meaning the same thing. But, as test case below demonstrates, they don't mean the same thing when 'set print object on' is in effect. I believe it is desirable to make the behavior consistent -- either always accept 'p.x' when 'p->x' was meant, or always insist on correct form (which is what VisualStudio does). Attached patch fixes the problem for field access (but not for mem-function access -- that goes through different path), and eliminates some redundant code. Comments? Test case demonstrating the problem: --- cut --- struct Foo { int x; Foo() : x(1) { } virtual ~Foo() { } }; struct Bar : public Foo { Bar() : y(2), z(3) { } int y, z; }; int fn(Foo *f) { return f->x; } int main() { Bar b; return fn(&b); } --- cut --- (gdb) b fn Breakpoint 1 at 0x4002e0: file print-obj.cc, line 14. (gdb) r Breakpoint 1, fn (f=0x7fffffffe690) at print-obj.cc:14 14 return f->x; (gdb) p f $1 = (Foo *) 0x7fffffffe690 (gdb) set print object on (gdb) p f $2 = (Bar *) 0x7fffffffe690 (gdb) p f->z # works $3 = 3 (gdb) p f.z # doesn't work -- bug in gdb There is no member or method named z. # For members of 'Foo' it works either way: (gdb) p f->x $4 = 1 (gdb) p f.x $5 = 1 Thanks, -- Paul Pluzhnikov 2008-07-17 Paul Pluzhnikov * eval.c (evaluate_subexp_standard): Treat 'p.x' and 'p->x' the same. Index: eval.c =================================================================== RCS file: /cvs/src/src/gdb/eval.c,v retrieving revision 1.85 diff -u -p -u -r1.85 eval.c --- eval.c 6 Jun 2008 20:58:08 -0000 1.85 +++ eval.c 17 Jul 2008 21:32:49 -0000 @@ -1374,23 +1374,6 @@ evaluate_subexp_standard (struct type *e return value_literal_complex (arg1, arg2, builtin_type_f_complex_s16); case STRUCTOP_STRUCT: - tem = longest_to_int (exp->elts[pc + 1].longconst); - (*pos) += 3 + BYTES_TO_EXP_ELEM (tem + 1); - arg1 = evaluate_subexp (NULL_TYPE, exp, pos, noside); - if (noside == EVAL_SKIP) - goto nosideret; - if (noside == EVAL_AVOID_SIDE_EFFECTS) - return value_zero (lookup_struct_elt_type (value_type (arg1), - &exp->elts[pc + 2].string, - 0), - lval_memory); - else - { - struct value *temp = arg1; - return value_struct_elt (&temp, NULL, &exp->elts[pc + 2].string, - NULL, "structure"); - } - case STRUCTOP_PTR: tem = longest_to_int (exp->elts[pc + 1].longconst); (*pos) += 3 + BYTES_TO_EXP_ELEM (tem + 1); @@ -1430,8 +1413,10 @@ evaluate_subexp_standard (struct type *e else { struct value *temp = arg1; + char *const name = + (op == STRUCTOP_STRUCT) ? "structure" : "structure pointer"; return value_struct_elt (&temp, NULL, &exp->elts[pc + 2].string, - NULL, "structure pointer"); + NULL, name); } case STRUCTOP_MEMBER: