From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25959 invoked by alias); 21 Mar 2006 14:20:48 -0000 Received: (qmail 25949 invoked by uid 22791); 21 Mar 2006 14:20:47 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Tue, 21 Mar 2006 14:20:45 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FLhj0-0006PK-O3; Tue, 21 Mar 2006 09:20:42 -0500 Date: Wed, 22 Mar 2006 15:50:00 -0000 From: Daniel Jacobowitz To: Christopher Philip SMITH Cc: gdb@sourceware.org, Sean MCGOOGAN Subject: Re: Allocation of dwarf2_frame_state_reg_info Message-ID: <20060321142041.GB15578@nevyn.them.org> Mail-Followup-To: Christopher Philip SMITH , gdb@sourceware.org, Sean MCGOOGAN References: <4416EC57.2000107@st.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4416EC57.2000107@st.com> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00152.txt.bz2 On Tue, Mar 14, 2006 at 04:16:23PM +0000, Christopher Philip SMITH wrote: > In dwarf2-frame.c:dwarf2_frame_cache(), the two > dwarf2_frame_state_reg_infos, fs->regs and fs->initial, seem to be > allocated by calls to dwarf2_frame_state_alloc_regs() in only some cases > of execute_cfa_program(). In the case of the function above, none of the > cases exercised while going through the CIE result in an allocation, > which has the effect back in dwarf2_frame_cache() of leaving fs->initial > unallocated, and so uninitialised. Well, it's not entirely uninitialized, is it? At least it was memset to zeroes. > Later, when processing the FDE, a > DW_CFA_restore is encountered which reads from fs->initial and causes > the error... dwarf2_frame_state_alloc_regs (&fs->regs, reg + 1); if (reg < fs->initial.num_regs) fs->regs.reg[reg] = fs->initial.reg[reg]; else fs->regs.reg[reg].how = DWARF2_FRAME_REG_UNSPECIFIED; Are we looking at the same version of GDB here? > My question is, what is the reasoning behind only allocating the > dwarf2_frame_state_reg_infos in execute_cfa_program()? It seems that if > both fs->regs and fs->initial were allocated with the dwarf2_frame_state > at the beginning of dwarf2_frame_cache(), then all the registers would > be set as "undefined" unless explicitly changed when processing the > DWARF (standard behaviour?) and the uninitialised read could never > happen? Is it only a case of avoiding unnecessary allocation, or is > there something more subtle going on here? The problem is that we have no idea how many columns there are. -- Daniel Jacobowitz CodeSourcery