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
next 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