This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Allocation of dwarf2_frame_state_reg_info


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]