From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15265 invoked by alias); 27 Jun 2008 15:37:27 -0000 Received: (qmail 15254 invoked by uid 22791); 27 Jun 2008 15:37:26 -0000 X-Spam-Check-By: sourceware.org Received: from snape.ecoscentric.com (HELO snape.ecoscentric.com) (212.13.207.199) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 27 Jun 2008 15:37:01 +0000 Received: from localhost (snape.ecoscentric.com [127.0.0.1]) by snape.ecoscentric.com (Postfix) with ESMTP id 07644DC8D08 for ; Fri, 27 Jun 2008 16:36:58 +0100 (BST) Received: from snape.ecoscentric.com ([127.0.0.1]) by localhost (snape.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rFlhDNYBMyP; Fri, 27 Jun 2008 16:36:57 +0100 (BST) Message-ID: <48650919.707@eCosCentric.com> Date: Fri, 27 Jun 2008 15:56:00 -0000 From: Jonathan Larmour User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Avoid potential crashes with --gc-sections and low addresses OpenPGP: id=A5FB74E6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 2008-06/txt/msg00499.txt.bz2 Hi, The attached patch deals with a problem that occurs with some embedded targets when the linker garbage collection feature of GNU ld (--gc-sections) is used. Linker gc can cause DWARF2 debug info for eliminated functions and frames to be retained in the binary, but with the location set to 0. This works most of the time. The problem occurs when there is retained valid code with a location close to 0, as can happen on an embedded target. In dwarf2_frame_find_fde we have: while (fde) { if (*pc >= fde->initial_location + offset && *pc < fde->initial_location + offset + fde->address_range) { *pc = fde->initial_location + offset; return fde; } fde = fde->next; } In most executables on other targets, eliminated code would not match this, but when there is code close to 0, the pc comparison test can succeed and match the debug information for the eliminated code because that code is within the address range. The simplest solution is to prevent these sorts of FDEs being loaded in the first place, by only incorporating FDEs with non-NULL initial locations, as per the attached patch. This also avoids using up memory and processing time for debug info we'll never use. The patch was in fact written by a colleague, but since it's a one-liner, I assume copyright assignments are superfluous under the "simple changes" rule. I do have check-in perms (it's been a while I know) if that helps. Jifl 2008-07-27 Bart Veer * dwarf2-frame.c (decode_frame_entry_1): Only add FDE if it has a valid location. -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ------["Si fractum non sit, noli id reficere"]------ Opinions==mine