From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25444 invoked by alias); 21 Oct 2010 16:02:20 -0000 Received: (qmail 25413 invoked by uid 22791); 21 Oct 2010 16:02:18 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 21 Oct 2010 16:02:01 +0000 Received: (qmail 12075 invoked from network); 21 Oct 2010 16:01:59 -0000 Received: from unknown (HELO caradoc.them.org) (dan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 21 Oct 2010 16:01:59 -0000 Date: Thu, 21 Oct 2010 16:02:00 -0000 From: Daniel Jacobowitz To: Ulrich Weigand Cc: gdb-patches@sourceware.org, rearnsha@arm.com, matthew.gretton-dann@arm.com Subject: Re: [rfc/rfa] Use ARM exception tables as GDB unwinder Message-ID: <20101021160155.GP8337@caradoc.them.org> References: <20101020132657.GU8337@caradoc.them.org> <201010211550.o9LFopOt012436@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201010211550.o9LFopOt012436@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2010-10/txt/msg00337.txt.bz2 On Thu, Oct 21, 2010 at 05:50:51PM +0200, Ulrich Weigand wrote: > Hmm, I'm seeing many functions marked as can't-unwind in the Ubuntu > copy of glibc, so I was assuming this just means that for some reason > the unwind data couldn't be generated reliably enough to allow run-time > unwinding. However, for debugging purposes we still want to attempt to > show a backtrace, so I'm falling back to prologue parsing ... Oh, right - can't unwind can be generated by the compiler, or by the linker. It should cover all non-fexceptions code with can't-unwind markers. > Note the large gap between 0x15890 and 0x25a50, which contains many > functions, including "raise", for which the "pop {r7, r14}" instruction > certainly isn't correct. This caused test suite failures before I > added the check above. > > I understood the ARM standard to say that this was expected, because > for C or assembly routines, presence of an unwind entry is optional. > Is this not the case? No, this is not the case. The linker is supposed to fix it up: /* Scan .ARM.exidx tables, and create a list describing edits which should be made to those tables, such that: 1. Regions without unwind data are marked with EXIDX_CANTUNWIND entries. 2. Duplicate entries are merged together (EXIDX_CANTUNWIND, or unwind codes which have been inlined into the index). If MERGE_EXIDX_ENTRIES is false, duplicate entries are not merged. The edits are applied when the tables are written (in elf32_arm_write_section). */ If it's not doing that, we should figure out why - it can lead to crashes in libgcc, if the unwinder is invoked, rather than the correct failure to unwind. I think 2.19 didn't do this but 2.20 did. > Ah, I didn't see the readelf code (because I was looking at an old > checkout, I would appear). I can add those personality routines as well > (however, these are nowhere used in the glibc I'm looking at). Correct, they're only used with C cleanups or C++ exception throw/catch. -- Daniel Jacobowitz CodeSourcery