From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14572 invoked by alias); 17 Apr 2008 01:02:58 -0000 Received: (qmail 14556 invoked by uid 22791); 17 Apr 2008 01:02:56 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 17 Apr 2008 01:02:37 +0000 Received: from zps18.corp.google.com (zps18.corp.google.com [172.25.146.18]) by smtp-out.google.com with ESMTP id m3H12PVs027834 for ; Thu, 17 Apr 2008 02:02:25 +0100 Received: from wa-out-1112.google.com (wagm34.prod.google.com [10.114.214.34]) by zps18.corp.google.com with ESMTP id m3H0vrWs009974 for ; Wed, 16 Apr 2008 18:02:24 -0700 Received: by wa-out-1112.google.com with SMTP id m34so4351287wag.9 for ; Wed, 16 Apr 2008 18:02:24 -0700 (PDT) Received: by 10.114.109.1 with SMTP id h1mr769957wac.35.1208394144452; Wed, 16 Apr 2008 18:02:24 -0700 (PDT) Received: by 10.115.107.18 with HTTP; Wed, 16 Apr 2008 18:02:24 -0700 (PDT) Message-ID: Date: Thu, 17 Apr 2008 10:10:00 -0000 From: "Doug Evans" To: gdb@sourceware.org, ppluzhnikov@google.com Subject: Re: determining whether page 0 (or low addresses in general) is executable In-Reply-To: <20080416193346.GA25227@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080416192047.984F91C75AD@localhost> <20080416193346.GA25227@caradoc.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-04/txt/msg00165.txt.bz2 On Wed, Apr 16, 2008 at 12:33 PM, Daniel Jacobowitz wrote: > On Wed, Apr 16, 2008 at 12:20:47PM -0700, Doug Evans wrote: > > Hi. We're trying to come up with a workaround for an apparent gcc/linker issue > > where debug info can be left behind that messes up backtraces. > > The erroneous debug info shouldn't be generated, but gdb could do a better > > job when faced with it. > > Not much better; I would suggest effort be spent on the > linker/compiler limitations, instead. For instance moving debug info > into comdat sections. Hopefully that'll get done too of course. > I thought GNU ld only had this problem for .debug_info and already > edited out discarded FDEs from .debug_frame / .eh_frame. Are you > using GNU ld or gold? Maybe the linker only edits .eh_frame. Actually the problem occurs with both gld and gold. The linker does explicitly handle .eh_frame, and I'm told the debug info doesn't go into comdat on purpose (complexity issues I gather). > > > > *************** dwarf2_frame_find_fde (CORE_ADDR *pc) > > @@ -1585,6 +1608,13 @@ > > > > while (fde) > > { > > + if (fde->initial_location + offset == 0 > > + && !is_zero_page_executable ()) > > + { > > + /* Ignore this FDE -- linker bug. */ > > + fde = fde->next; > > + continue; > > + } > > > > See has_section_at_zero in dwarf2read.c. It's just the same hack. Ah. Thanks.