From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31203 invoked by alias); 12 Mar 2004 12:00:34 -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 31189 invoked from network); 12 Mar 2004 12:00:31 -0000 Received: from unknown (HELO miranda.se.axis.com) (193.13.178.2) by sources.redhat.com with SMTP; 12 Mar 2004 12:00:31 -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 i2CBxQ8u018424; Fri, 12 Mar 2004 12:59:26 +0100 Message-ID: <4051A61E.3030907@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: Andrew Cagney CC: Daniel Jacobowitz , 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> <40509C21.1040906@gnu.org> In-Reply-To: <40509C21.1040906@gnu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00280.txt.bz2 Andrew Cagney wrote: > > Does this: > > /* NOTE: cagney/2003-09-05: CFI should specify the disposition > of all debug info registers. If it doesn't, complain (but > not too loudly). It turns out that GCC assumes that an > unspecified register implies "same value" when CFI (draft > 7) specifies nothing at all. Such a register could equally > be interpreted as "undefined". Also note that this check > isn't sufficient; it only checks that all registers in the > range [0 .. max column] are specified, and won't detect > problems when a debug info register falls outside of the > table. We need a way of iterating through all the valid > DWARF2 register numbers. */ > if (fs->regs.reg[column].how == DWARF2_FRAME_REG_UNSPECIFIED) > complaint (&symfile_complaints, > "Incomplete CFI data; unspecified registers at 0x%s", > paddr (fs->pc)); > else > cache->reg[regnum] = fs->regs.reg[column]; > > sound like your problem? It's possible to specify initial values of > such registers with: I do get that complaint, and it seems a lot of registers are set to DWARF2_FRAME_REG_UNSPECIFIED. > /* Set the architecture-specific register state initialization > function for GDBARCH to INIT_REG. */ > > extern void dwarf2_frame_set_init_reg (struct gdbarch *gdbarch, > void (*init_reg) (struct gdbarch > *, int, > struct > dwarf2_frame_state_reg *)); Thanks for the tip, I hadn't seen that. Reading the s390 implementation of dwarf2_frame_init_reg I get the impression that that information should have been there from the beginning (emitted by gcc that is) since it seems to be ABI/calling convention related. But I'll try and implement something similar. -- Orjan Friberg Axis Communications From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31203 invoked by alias); 12 Mar 2004 12:00:34 -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 31189 invoked from network); 12 Mar 2004 12:00:31 -0000 Received: from unknown (HELO miranda.se.axis.com) (193.13.178.2) by sources.redhat.com with SMTP; 12 Mar 2004 12:00:31 -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 i2CBxQ8u018424; Fri, 12 Mar 2004 12:59:26 +0100 Message-ID: <4051A61E.3030907@axis.com> Date: Fri, 12 Mar 2004 12:00: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: Andrew Cagney CC: Daniel Jacobowitz , 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> <40509C21.1040906@gnu.org> In-Reply-To: <40509C21.1040906@gnu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03.o/txt/msg00280.txt Message-ID: <20040312120000.wwbi2DiYNXjrYwtGSmsy095zEgz7iBewxbBq0UOTFw0@z> Andrew Cagney wrote: > > Does this: > > /* NOTE: cagney/2003-09-05: CFI should specify the disposition > of all debug info registers. If it doesn't, complain (but > not too loudly). It turns out that GCC assumes that an > unspecified register implies "same value" when CFI (draft > 7) specifies nothing at all. Such a register could equally > be interpreted as "undefined". Also note that this check > isn't sufficient; it only checks that all registers in the > range [0 .. max column] are specified, and won't detect > problems when a debug info register falls outside of the > table. We need a way of iterating through all the valid > DWARF2 register numbers. */ > if (fs->regs.reg[column].how == DWARF2_FRAME_REG_UNSPECIFIED) > complaint (&symfile_complaints, > "Incomplete CFI data; unspecified registers at 0x%s", > paddr (fs->pc)); > else > cache->reg[regnum] = fs->regs.reg[column]; > > sound like your problem? It's possible to specify initial values of > such registers with: I do get that complaint, and it seems a lot of registers are set to DWARF2_FRAME_REG_UNSPECIFIED. > /* Set the architecture-specific register state initialization > function for GDBARCH to INIT_REG. */ > > extern void dwarf2_frame_set_init_reg (struct gdbarch *gdbarch, > void (*init_reg) (struct gdbarch > *, int, > struct > dwarf2_frame_state_reg *)); Thanks for the tip, I hadn't seen that. Reading the s390 implementation of dwarf2_frame_init_reg I get the impression that that information should have been there from the beginning (emitted by gcc that is) since it seems to be ABI/calling convention related. But I'll try and implement something similar. -- Orjan Friberg Axis Communications