From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8788 invoked by alias); 14 Mar 2006 16:16:39 -0000 Received: (qmail 8777 invoked by uid 22791); 14 Mar 2006 16:16:38 -0000 X-Spam-Check-By: sourceware.org Received: from fra-del-01.spheriq.net (HELO fra-del-01.spheriq.net) (195.46.51.97) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 14 Mar 2006 16:16:35 +0000 Received: from fra-out-03.spheriq.net (fra-out-03.spheriq.net [195.46.51.131]) by fra-del-01.spheriq.net with ESMTP id k2EGGToa019414 for ; Tue, 14 Mar 2006 16:16:29 GMT Received: from fra-cus-01.spheriq.net (fra-cus-01.spheriq.net [195.46.51.37]) by fra-out-03.spheriq.net with ESMTP id k2EGGS0R002098 for ; Tue, 14 Mar 2006 16:16:28 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by fra-cus-01.spheriq.net with ESMTP id k2EGGRB2022449 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 14 Mar 2006 16:16:27 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id BC0F8DA44 for ; Tue, 14 Mar 2006 16:16:26 +0000 (GMT) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 3FF0847496 for ; Tue, 14 Mar 2006 16:20:19 +0000 (GMT) Received: from [164.129.14.54] (crecy.bri.st.com [164.129.14.54]) by mail1.bri.st.com (MOS 3.5.8-GR) with ESMTP id CHI87649 (AUTH smithc); Tue, 14 Mar 2006 16:16:23 GMT Message-ID: <4416EC57.2000107@st.com> Date: Tue, 14 Mar 2006 17:21:00 -0000 From: Christopher Philip SMITH User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319 MIME-Version: 1.0 To: gdb@sourceware.org Cc: Sean MCGOOGAN Subject: Allocation of dwarf2_frame_state_reg_info Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-O-Spoofed: Not Scanned X-O-General-Status: No X-O-Spam1-Status: Not Scanned X-O-Spam2-Status: Not Scanned X-O-URL-Status: Not Scanned X-O-Virus1-Status: No X-O-Virus2-Status: Not Scanned X-O-Virus3-Status: No X-O-Virus4-Status: No X-O-Virus5-Status: Not Scanned X-O-Image-Status: Not Scanned X-O-Attach-Status: Not Scanned X-SpheriQ-Ver: 4.2.01 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00065.txt.bz2 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