From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17568 invoked by alias); 20 Dec 2007 20:23:48 -0000 Received: (qmail 17559 invoked by uid 22791); 20 Dec 2007 20:23:47 -0000 X-Spam-Check-By: sourceware.org Received: from igw1.br.ibm.com (HELO igw1.br.ibm.com) (32.104.18.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 20 Dec 2007 20:23:36 +0000 Received: from mailhub1.br.ibm.com (mailhub1 [9.18.232.109]) by igw1.br.ibm.com (Postfix) with ESMTP id A7AC732C2E7 for ; Thu, 20 Dec 2007 18:03:53 -0200 (BRDT) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by mailhub1.br.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id lBKKNVDj3494060 for ; Thu, 20 Dec 2007 18:23:33 -0200 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id lBKKNUC1018634 for ; Thu, 20 Dec 2007 18:23:30 -0200 Received: from [9.8.0.176] ([9.8.0.176]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id lBKKNT90016654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 Dec 2007 18:23:30 -0200 Subject: [PATCH] Fix DW_CFA_restore_extended parsing From: Luis Machado Reply-To: luisgpm@linux.vnet.ibm.com To: gdb-patches@sourceware.org Content-Type: multipart/mixed; boundary="=-laNOclkjc6bkTA3/Kn5E" Date: Thu, 20 Dec 2007 20:25:00 -0000 Message-Id: <1198182171.9817.22.camel@gargoyle> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-12/txt/msg00354.txt.bz2 --=-laNOclkjc6bkTA3/Kn5E Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 883 Hi folks, There appears to be a flaw during the execution of this instruction (DW_CFA_restore_extended). Most of the time the registers are implicitly defined to use an "unspecified" rule due to the lack of information (or due to space optimization strategies) in the CIE's initial instructions. Different from DW_CFA_restore, DW_CFA_restore_extended doesn't check if the register rule in the current dwarf frame set's list of initialized registers is valid prior to assigning the rule to it, so it might just grab junk and fail eventually. This is hard to reproduce as the extended restore instruction doesn't show up very often, and you have to be lucky to grab the "wrong" kind of junk for the rule, leading GDB to an internal error. This simple patch fixes the issue. Any thoughts? Ok to commit? Best regards, -- Luis Machado Software Engineer IBM Linux Technology Center --=-laNOclkjc6bkTA3/Kn5E Content-Disposition: attachment; filename=dwarf-fde-parse.diff Content-Type: text/x-patch; name=dwarf-fde-parse.diff; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-length: 1059 2007-12-20 Luis Machado * dwarf2-frame.c (execute_cfa_program): Check if a register's rule is explicitly defined in the CIE before assignment, else force the default rule. Index: gdb/dwarf2-frame.c =================================================================== --- gdb.orig/dwarf2-frame.c 2007-10-21 12:33:37.000000000 -0700 +++ gdb/dwarf2-frame.c 2007-12-20 11:19:56.000000000 -0800 @@ -382,7 +382,14 @@ insn_ptr = read_uleb128 (insn_ptr, insn_end, ®); reg = dwarf2_frame_adjust_regnum (gdbarch, reg, eh_frame_p); dwarf2_frame_state_alloc_regs (&fs->regs, reg + 1); - fs->regs.reg[reg] = fs->initial.reg[reg]; + + /* Check if this register was explicitly initialized in the + CIE initial instructions. If not, default the rule to + UNSPECIFIED. */ + if (reg < fs->initial.num_regs) + fs->regs.reg[reg] = fs->initial.reg[reg]; + else + fs->regs.reg[reg].how = DWARF2_FRAME_REG_UNSPECIFIED; break; case DW_CFA_undefined: --=-laNOclkjc6bkTA3/Kn5E--