From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12358 invoked by alias); 21 Jan 2013 16:04:54 -0000 Received: (qmail 12343 invoked by uid 22791); 21 Jan 2013 16:04:53 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 21 Jan 2013 16:04:42 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r0LG4dTl012456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Jan 2013 11:04:40 -0500 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r0LG4cJT031212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 21 Jan 2013 11:04:39 -0500 From: Tom Tromey To: Joel Brobecker Cc: gdb-patches@sourceware.org Subject: Re: RFC: fix PR c++/14999 References: <87mwwj38hm.fsf@fleche.redhat.com> <20130119155435.GA5215@adacore.com> Date: Mon, 21 Jan 2013 16:04:00 -0000 In-Reply-To: <20130119155435.GA5215@adacore.com> (Joel Brobecker's message of "Sat, 19 Jan 2013 19:54:35 +0400") Message-ID: <878v7m4j55.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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: 2013-01/txt/msg00475.txt.bz2 >>>>> "Joel" == Joel Brobecker writes: Joel> I looked at the PR, and it seems to me that the problem comes Joel> from the fact that the ax stack was missing the "reg 7" operation. Joel> I don't really understand the code well enough to be sure about Joel> my fix, in particular what the "loc" parameter is about, but Joel> the attached patch seems to restore the origin behavior while Joel> still keeping your new testcase happy. Can you try the appended instead? I am testing it here as well. I think calling ax_reg and setting kind==axs_lvalue_register is wrong, as it may result in a second ax_reg call if require_rvalue is called. Instead I think we should mimic what dwarf2eval does for the fbreg case, and only derferences lvalue_register values. Tom diff --git a/gdb/dwarf2loc.c b/gdb/dwarf2loc.c index 2282feb..3688425 100644 --- a/gdb/dwarf2loc.c +++ b/gdb/dwarf2loc.c @@ -2878,7 +2878,8 @@ dwarf2_compile_expr_to_ax (struct agent_expr *expr, struct axs_value *loc, op_ptr = safe_read_sleb128 (op_ptr, op_end, &offset); dwarf2_compile_expr_to_ax (expr, loc, arch, addr_size, datastart, datastart + datalen, per_cu); - require_rvalue (expr, loc); + if (loc->kind == axs_lvalue_register) + require_rvalue (expr, loc); if (offset != 0) {