Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Christopher Philip SMITH <chris.smith@st.com>
To: gdb@sourceware.org
Cc: Sean MCGOOGAN <sean.mcgoogan@st.com>
Subject: Allocation of dwarf2_frame_state_reg_info
Date: Tue, 14 Mar 2006 17:21:00 -0000	[thread overview]
Message-ID: <4416EC57.2000107@st.com> (raw)

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


             reply	other threads:[~2006-03-14 16:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-14 17:21 Christopher Philip SMITH [this message]
2006-03-22 15:50 ` Daniel Jacobowitz
2006-03-22 22:01   ` Christopher SMITH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4416EC57.2000107@st.com \
    --to=chris.smith@st.com \
    --cc=gdb@sourceware.org \
    --cc=sean.mcgoogan@st.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox