From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12488 invoked by alias); 12 Mar 2004 15:38:55 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 12478 invoked from network); 12 Mar 2004 15:38:53 -0000 Received: from unknown (HELO miranda.se.axis.com) (212.209.10.220) by sources.redhat.com with SMTP; 12 Mar 2004 15:38:53 -0000 Received: from axis.com (ironmaiden.se.axis.com [10.13.8.120]) by miranda.se.axis.com (8.12.9/8.12.9/Debian-5local0.1) with ESMTP id i2CFc78u023044; Fri, 12 Mar 2004 16:38:07 +0100 Message-ID: <4051D95F.3000704@axis.com> Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Orjan Friberg Organization: Axis Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb-patches@sources.redhat.com Subject: Re: [CRIS] dwarf2 frame sniffer problem? References: <404F481E.9060709@axis.com> <20040310165905.GA4291@nevyn.them.org> <405072FE.1010403@axis.com> <40508BD8.10802@axis.com> <20040311171139.GA17530@nevyn.them.org> <40518F6A.2080806@axis.com> In-Reply-To: <40518F6A.2080806@axis.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00283.txt.bz2 Orjan Friberg wrote: > Daniel Jacobowitz wrote: > >> >> The beauty of using the CFI data is that it _is_ supposed to work in >> the prologue. It sounds like the CFI is wrong. Could you post both >> assembly and CFI data for the same testcase? I don't know CRIS >> assembly but I imagine I can interpret it well enough to see what's >> going on. Out of curiosity, I had a look at the calls to execute_cfa_program (where the current state of the registers seems to be built from the dwarf2 information). The second call to execute_cfa_program is preceded by the comment: /* Then decode the insns in the FDE up to our target PC. */ When we get into execute_cfa_program we're stopped at the first instruction in foo, and the pc variable in execute_cfa_program is set to that value also. Nevertheless we parse *all* the information in that FDE: > 00000028 00000014 00000000 FDE cie=00000000 pc=00080080..00080096 > DW_CFA_advance_loc: 0 to 00080080 > DW_CFA_def_cfa: r8 ofs 8 > DW_CFA_offset: r16 at cfa-4 > DW_CFA_offset: r8 at cfa-8 So, not only do we incorrectly conclude that the SRP is located on the stack, but that the frame pointer (r8) is also (though neither of those have actually been pushed yet). Comparing with the example in Appendix 5 of the dwarf2 spec I get the impression that some DW_CFA_advance_loc are missing, but now is probably a good time for me to stop guessing ;-) . -- Orjan Friberg Axis Communications From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12488 invoked by alias); 12 Mar 2004 15:38:55 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 12478 invoked from network); 12 Mar 2004 15:38:53 -0000 Received: from unknown (HELO miranda.se.axis.com) (212.209.10.220) by sources.redhat.com with SMTP; 12 Mar 2004 15:38:53 -0000 Received: from axis.com (ironmaiden.se.axis.com [10.13.8.120]) by miranda.se.axis.com (8.12.9/8.12.9/Debian-5local0.1) with ESMTP id i2CFc78u023044; Fri, 12 Mar 2004 16:38:07 +0100 Message-ID: <4051D95F.3000704@axis.com> Date: Fri, 12 Mar 2004 15:38:00 -0000 From: Orjan Friberg Organization: Axis Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb-patches@sources.redhat.com Subject: Re: [CRIS] dwarf2 frame sniffer problem? References: <404F481E.9060709@axis.com> <20040310165905.GA4291@nevyn.them.org> <405072FE.1010403@axis.com> <40508BD8.10802@axis.com> <20040311171139.GA17530@nevyn.them.org> <40518F6A.2080806@axis.com> In-Reply-To: <40518F6A.2080806@axis.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03.o/txt/msg00283.txt Message-ID: <20040312153800.0qn5j672Xm6KadO9_RaRZRYlNJMlDwTFdldwa8bbSA8@z> Orjan Friberg wrote: > Daniel Jacobowitz wrote: > >> >> The beauty of using the CFI data is that it _is_ supposed to work in >> the prologue. It sounds like the CFI is wrong. Could you post both >> assembly and CFI data for the same testcase? I don't know CRIS >> assembly but I imagine I can interpret it well enough to see what's >> going on. Out of curiosity, I had a look at the calls to execute_cfa_program (where the current state of the registers seems to be built from the dwarf2 information). The second call to execute_cfa_program is preceded by the comment: /* Then decode the insns in the FDE up to our target PC. */ When we get into execute_cfa_program we're stopped at the first instruction in foo, and the pc variable in execute_cfa_program is set to that value also. Nevertheless we parse *all* the information in that FDE: > 00000028 00000014 00000000 FDE cie=00000000 pc=00080080..00080096 > DW_CFA_advance_loc: 0 to 00080080 > DW_CFA_def_cfa: r8 ofs 8 > DW_CFA_offset: r16 at cfa-4 > DW_CFA_offset: r8 at cfa-8 So, not only do we incorrectly conclude that the SRP is located on the stack, but that the frame pointer (r8) is also (though neither of those have actually been pushed yet). Comparing with the example in Appendix 5 of the dwarf2 spec I get the impression that some DW_CFA_advance_loc are missing, but now is probably a good time for me to stop guessing ;-) . -- Orjan Friberg Axis Communications