Allocation of dwarf2_frame_state_reg_info

Allocation of dwarf2_frame_state_reg_info

[Christopher Philip SMITH]

Hi,

While working with the sh Linux toolchain, I'm seeing an unusual code 
path in the dwarf2 stack unwinding which causes gdb to do an 
uninitialised read while backtracing. This generates a gdb internal error.

The DWARF for the frame in question is:

00002874 00000010 00000000 CIE
   Version:               1
   Augmentation:          "zR"
   Code alignment factor: 1
   Data alignment factor: -4
   Return address column: 17
   Augmentation data:     1b

   DW_CFA_def_cfa: r15 ofs 0

00003b64 00000034 000012f4 FDE cie=00002874 pc=000b2e80..000b2f3c
   DW_CFA_advance_loc: 48 to 000b2eb0
   DW_CFA_def_cfa_offset: 4
   DW_CFA_offset: r17 at cfa-4
   DW_CFA_advance_loc: 8 to 000b2eb8
   DW_CFA_def_cfa_offset: 20
   DW_CFA_offset: r4 at cfa-20
   DW_CFA_offset: r5 at cfa-16
   DW_CFA_offset: r6 at cfa-12
   DW_CFA_advance_loc: 24 to 000b2ed0
   DW_CFA_def_cfa_offset: 4
   DW_CFA_advance_loc: 2 to 000b2ed2
   DW_CFA_def_cfa_offset: 0
   DW_CFA_restore: r17
   DW_CFA_advance_loc: 26 to 000b2eec
   DW_CFA_def_cfa_offset: 4
   DW_CFA_offset: r17 at cfa-4
   DW_CFA_advance_loc: 2 to 000b2eee
   DW_CFA_def_cfa_offset: 8
   DW_CFA_offset: r0 at cfa-8
   DW_CFA_advance_loc: 16 to 000b2efe
   DW_CFA_def_cfa_offset: 4
   DW_CFA_restore: r0
   DW_CFA_advance_loc: 2 to 000b2f00
   DW_CFA_def_cfa_offset: 0
   DW_CFA_restore: r17

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. Later, when processing the FDE, a 
DW_CFA_restore is encountered which reads from fs->initial and causes 
the error...

My understanding is that gdb relies on the fact that registers not 
mentioned in the CIE will be represented as undefined because they will 
not have changed since they were memsetted to 0 just after allocation.

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?

Incidentally, I appreciate that it's quite possible that the DWARF being 
processed is wrong (although once I initialise those structures it's 
good enough to produce a valid backtrace!), but is there still some 
value in avoiding the possibility of these uninitialised reads?

Any light anybody could shed on this would be greatly appreciated!

Many thanks,


Chris
-- 
Chris Smith, STS Software Engineer
STMicroelectronics (R&D) Ltd.
1000 Aztec West, Almondsbury, Bristol BS32 4SQ
Phone: +44 1454 462358

Re: Allocation of dwarf2_frame_state_reg_info

[Daniel Jacobowitz]

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

Re: Allocation of dwarf2_frame_state_reg_info

[Christopher SMITH]

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