From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15150 invoked by alias); 11 Mar 2004 14:09:40 -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 15100 invoked from network); 11 Mar 2004 14:09:37 -0000 Received: from unknown (HELO miranda.se.axis.com) (212.209.10.220) by sources.redhat.com with SMTP; 11 Mar 2004 14:09:37 -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 i2BE928u017742; Thu, 11 Mar 2004 15:09:02 +0100 Message-ID: <405072FE.1010403@axis.com> Date: Thu, 11 Mar 2004 14: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> In-Reply-To: <20040310165905.GA4291@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03.o/txt/msg00266.txt Message-ID: <20040311140900.bFpZYXDjVvLXIHMoLA6DAjEBBS5VsUliKM9KPKKl4V4@z> Daniel Jacobowitz wrote: > > Well, it sounds like the return address is being unwound incorrectly. > You may want to take a look at the CFI data by hand, and then compare > with dwarf2_frame_prev_register. I can't quite imagine how you'd get > the one-instruction-early behavior, though :) (The "one-instruction-early" description of the breakpoint setting was incorrect - that breakpoint was actually the "break main" breakpoint. Thanks for noticing.) The test program is just: void foo(void) {} int main () { foo(); return 0; } Here's what happens when I do "next" over the call to foo(): dwarf2_frame_prev_register gets called for register 15 (PC). The switch on cache->reg[regnum].how leads to DWARF2_FRAME_REG_SAVED_REG, where cache->reg[regnum].loc.reg says the PC is located in register 16, so we unwind register 16 from the next frame, which is definitely wrong (register 16 is a 8-bit zero register). Changing 16 to 27 (SRP, where the PC is saved) makes "next" work in this simple case. I did a readelf -w on the binary (below), and looked at the .debug_frame-section (hoping that's what you meant by "look at the CFI data by hand"), and though my understanding of this is limited I get the impression that the dwarf2 CFI for CRIS is wrong (but that the dwarf2 frame unwinder does the right thing). "Return address column" says 16, and for main (where the SRP is pushed on the stack) it says "DW_CFA_offset: r16 at cfa-4". I checked section 6.4.1 in the dwarf2 standard, but I couldn't confirm my suspicions since some of the fields mentioned weren't present in the readelf output (return_address_register for example). 00000010 0000000c ffffffff CIE Version: 1 Augmentation: "" Code alignment factor: 1 Data alignment factor: -1 Return address column: 16 DW_CFA_def_cfa: r14 ofs 0 00000020 00000014 00000010 FDE cie=00000010 pc=000802e4..000802f0 DW_CFA_advance_loc: 0 to 000802e4 DW_CFA_def_cfa: r8 ofs 4 DW_CFA_offset: r8 at cfa-4 DW_CFA_nop DW_CFA_nop 00000038 00000014 00000010 FDE cie=00000010 pc=000802f0..0008030a DW_CFA_advance_loc: 0 to 000802f0 DW_CFA_def_cfa: r8 ofs 8 DW_CFA_offset: r16 at cfa-4 DW_CFA_offset: r8 at cfa-8 -- Orjan Friberg Axis Communications