This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Allocation of dwarf2_frame_state_reg_info
- From: Christopher SMITH <chris dot smith at st dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gdb at sourceware dot org, Sean MCGOOGAN <sean dot mcgoogan at st dot com>
- Date: Wed, 22 Mar 2006 15:48:46 +0000
- Subject: Re: Allocation of dwarf2_frame_state_reg_info
- References: <4416EC57.2000107@st.com> <20060321142041.GB15578@nevyn.them.org>
Hi Daniel!
Thanks for your reply.
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.
Sorry, I put that badly. What I was trying to say was that
dwarf2_frame_state.reg wasn't initialised, not the whole dwarf2_frame_state.
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?
Oops - no. :-( I was originally looking at the sh linux gdb, which is
still based on gdb 6.3 and so doesn't check initial.num_regs. I did
actually check that the code I was interested in, dwarf2_frame_cache()
etc., hadn't changed but I missed that bit. My apologies - of course,
this fixes the problem.
Thanks for your help!
Many thanks,
Chris
--
Chris Smith, STS Software Engineer
STMicroelectronics (R&D) Ltd.
1000 Aztec West, Almondsbury, Bristol BS32 4SQ
Phone: +44 1454 462358