From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23934 invoked by alias); 21 Oct 2010 18:26:27 -0000 Received: (qmail 23907 invoked by uid 22791); 21 Oct 2010 18:26:19 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate5.de.ibm.com (HELO mtagate5.de.ibm.com) (195.212.17.165) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 21 Oct 2010 18:26:13 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.1/8.13.1) with ESMTP id o9LIQAaW008964 for ; Thu, 21 Oct 2010 18:26:10 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o9LIQAlm3469440 for ; Thu, 21 Oct 2010 20:26:10 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o9LIQAds012168 for ; Thu, 21 Oct 2010 20:26:10 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id o9LIQ9P5012162; Thu, 21 Oct 2010 20:26:09 +0200 Message-Id: <201010211826.o9LIQ9P5012162@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 21 Oct 2010 20:26:09 +0200 Subject: Re: [rfc/rfa] Use ARM exception tables as GDB unwinder To: dan@codesourcery.com (Daniel Jacobowitz) Date: Thu, 21 Oct 2010 18:26:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, rearnsha@arm.com, matthew.gretton-dann@arm.com In-Reply-To: <20101021160155.GP8337@caradoc.them.org> from "Daniel Jacobowitz" at Oct 21, 2010 12:01:56 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2010-10/txt/msg00338.txt.bz2 Dan Jacobowitz wrote: > On Thu, Oct 21, 2010 at 05:50:51PM +0200, Ulrich Weigand wrote: > > 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: [snip] > 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. Hmm, the Ubuntu glibc image I'm using was built with 2.20.51.20100908-0ubuntu1 which should be recent enough ... I'm re-running a glibc build from source to try and debug what the linker is doing here. > > 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. One issue with this just occurred to me: comparing personality routines by *name* relies on symbol information being present. Since we're doing the whole ARM unwinder support primarily to better cope with the case where symbol information is absent, this may be counter-productive ... Is there some other way to recognize those particular unwinders? Another, related topic: Running the GDB testsuite on a system without debug/symbol info, I'm still seeing failures in unwinding from interrupted system calls. This is because the assembler code to do the syscall clobbers r7 without generating appropriate unwind records, and thus unwinding fails somewhere higher up the stack. Now, this is exactly the problem you fixed by moving the actual syscall into a separate routine __libc_do_syscall. However, this routine is only called from C code built for -mthumb. C code built for -marm, as well as code originally in (ARM) assembler, will continue to use inline sequences clobbering r7. Note that even in a glibc built completely for Thumb, there still will be some instances of the latter, e.g. the automatically generated system call stubs (like the one for "kill") as well as certain routines provided fully in assembler (like "vfork"). Unfortunately, if these are called from Thumb code higher up the stack, the fact that those routines clobber r7 (even as they themselves are ARM), still breaks unwinding ... Any thoughts how to fix this? Should those calls also use an out-of-line syscall helper? Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com