From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39601 invoked by alias); 16 May 2016 20:08:10 -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 39571 invoked by uid 89); 16 May 2016 20:08:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=held X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 16 May 2016 20:07:58 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7944137E72; Mon, 16 May 2016 20:07:57 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-172.phx2.redhat.com [10.3.116.172]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4GK7uc5013811; Mon, 16 May 2016 16:07:56 -0400 Subject: Re: RFA: Generate normal DWARF DW_LOC descriptors for non integer mode pointers To: Nick Clifton , gcc-patches@gcc.gnu.org References: <87h9dyt7m3.fsf@redhat.com> Cc: gdb-patches@sourceware.org From: Jeff Law Message-ID: <1c7da1c8-c088-6c35-dbc8-bacebd4ad4d0@redhat.com> Date: Mon, 16 May 2016 20:08:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <87h9dyt7m3.fsf@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-05/txt/msg00252.txt.bz2 On 05/16/2016 08:12 AM, Nick Clifton wrote: > Hi Guys, > > Currently dwarf2out.c:mem_loc_descriptor() has some special case > code to handle the situation where an address is held in a register > whose mode is not of type MODE_INT. It generates a > DW_OP_GNU_regval_type expression which may later on be converted into > a frame pointer based expression. This is a problem for targets which > use a partial integer mode for their pointers (eg the msp430). In > such cases the conversion to a frame pointer based expression could > be wrong if the frame pointer is not being used. > > For example the GDB testfile gdb/testsuite/gdb.base/advance.c contains > this code fragment: > > int > main () > { > int result; > int b, c; > c = 5; > b = 3; /* advance this location */ > > func (c); /* stop here after leaving current frame */ > > which compiles to these instructions: > > suba #6, r1 > mov #5, 4(r1) > mov #3, 2(r1) > mov 4(r1), r12 > calla #0 ; > > (Note that only r1 - the stack pointer - is used. r4 - the frame > pointer - is not). > > The debug information produced for the "c" local variable looks like > this: > > Abbrev Number: 3 (DW_TAG_variable) > DW_AT_name : c > DW_AT_decl_file : 1 > DW_AT_decl_line : 40 > DW_AT_type : <0x37> > DW_AT_location : 5 byte block: f5 4 21 32 1c (DW_OP_GNU_regval_type: 4 (r4) <0x21>; DW_OP_lit2; DW_OP_minus) > > ie it says that "c" is stored in memory location "r4 - 2", which is > wrong since register r4 is not even used in this function. > > The patch below addresses this problem by allowing the normal, > register based descriptor to be produced when the mode is Pmode. > > With this patch applied the unexpected failure count in the GDB > testsuite for the MSP430's -mlarge multilib changes from 2253 to 367. > There are no regressions, for MSP430 or x86_64, and no changes to > the GCC testsuite results for either target. > > OK to apply ? > > Cheers > Nick > > gcc/ChangeLog > 2016-05-16 Nick Clifton > > * dwarf2out.c (mem_loc_descriptor): Convert REG based addresses > whose mode is Pmode into basereg descriptors even if Pmode is > not an integer mode. I'm not real familiar with dwarf, so if one of other maintainers steps in and says this is OK, then ignore my comments/questions. I may be missing something, but isn't it the transition to an FP relative address rather than a SP relative address that's the problem here? Where does that happen? Is it possible we've got the wrong DECL_RTL or somesuch? Jeff