From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10802 invoked by alias); 14 Nov 2013 19:37:45 -0000 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 Received: (qmail 10791 invoked by uid 89); 14 Nov 2013 19:37:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 14 Nov 2013 19:37:42 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rAEJbYHw018547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Nov 2013 14:37:34 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rAEJbW8L019653; Thu, 14 Nov 2013 14:37:33 -0500 Message-ID: <5285267C.7080004@redhat.com> Date: Thu, 14 Nov 2013 20:12:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joel Brobecker CC: gdb-patches@sourceware.org Subject: Re: [RFA] Fix DW_OP_GNU_regval_type with FP registers References: <1384434175-15561-1-git-send-email-brobecker@adacore.com> In-Reply-To: <1384434175-15561-1-git-send-email-brobecker@adacore.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-11/txt/msg00385.txt.bz2 On 11/14/2013 01:02 PM, Joel Brobecker wrote: > Hello, > > Consider the following code, compiled at -O2 on ppc-linux: > > procedure Increment (Val : in out Float; Msg : String); > > The implementation does not really matter in this case). In our example, > this function is being called from a function with Param_1 set to 99.0. > Trying to break inside that function, and running until reaching that > breakpoint yields: > > (gdb) b increment > Breakpoint 1 at 0x100014b4: file callee.adb, line 6. > (gdb) run > Starting program: /[...]/foo > > Breakpoint 1, callee.increment (val=99.0, val@entry=0.0, msg=...) > at callee.adb:6 > 6 if Val > 200.0 then > > The @entry value for parameter "val" is incorrect, it should be 99.0. > > The associated call-site parameter DIE looks like this: > > .uleb128 0xc # (DIE (0x115) DW_TAG_GNU_call_site_parameter) > .byte 0x2 # DW_AT_location > .byte 0x90 # DW_OP_regx > .uleb128 0x21 > .byte 0x3 # DW_AT_GNU_call_site_value > .byte 0xf5 # DW_OP_GNU_regval_type > .uleb128 0x3f > .uleb128 0x25 > > The DW_AT_GNU_call_site_value uses a DW_OP_GNU_regval_type > operation, referencing register 0x3f=63, which is $f31, > an 8-byte floating register. In that register, the value is > stored using the usual 8-byte float format: > > (gdb) info float > f31 99.0 (raw 0x4058c00000000000) > > The current code evaluating DW_OP_GNU_regval_type operations > currently is (dwarf2expr.c:execute_stack_op): > > result = (ctx->funcs->read_reg) (ctx->baton, reg); > result_val = value_from_ulongest (address_type, result); > result_val = value_from_contents (type, > value_contents_all (result_val)); > > What the ctx->funcs->read_reg function does is read the contents > of the register as if it contained an address. The rest of the code > continues that assumption, thinking it's OK to then use that to > create an address/ulongest struct value, which we then re-type > to the type specified by DW_OP_GNU_regval_type. > > We're getting 0.0 above because the read_reg implementations > end up treating the contents of the FP register as an integral, > reading only 4 out of the 8 bytes. > > Being a big-endian target, > we read the high-order ones, which gives us zero. > > This patch fixes the problem by introducing a new callback to > read the contents of a register as a given type, and then adjust > the handling of DW_OP_GNU_regval_type to use that new callback. I definitely agree with this. The patch looked fine to me. (Eliminating read_reg might be tricky, but I think it'd be nice if it were be renamed to something that implies "address", like read_addr_reg or some such.) -- Pedro Alves