From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13468 invoked by alias); 21 Oct 2010 20:29:43 -0000 Received: (qmail 13458 invoked by uid 22791); 21 Oct 2010 20:29:42 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,TW_XA,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate7.de.ibm.com (HELO mtagate7.de.ibm.com) (195.212.17.167) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 21 Oct 2010 20:29:37 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate7.de.ibm.com (8.13.1/8.13.1) with ESMTP id o9LKTYXv021112 for ; Thu, 21 Oct 2010 20:29:34 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 o9LKTYqR2773186 for ; Thu, 21 Oct 2010 22:29:34 +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 o9LKTXKh013406 for ; Thu, 21 Oct 2010 22:29:34 +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 o9LKTWpN013394; Thu, 21 Oct 2010 22:29:32 +0200 Message-Id: <201010212029.o9LKTWpN013394@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 21 Oct 2010 22:29:32 +0200 Subject: Re: [rfc/rfa] Use ARM exception tables as GDB unwinder To: dan@codesourcery.com (Daniel Jacobowitz) Date: Thu, 21 Oct 2010 20:29:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, rearnsha@arm.com, matthew.gretton-dann@arm.com In-Reply-To: <20101021184229.GR8337@caradoc.them.org> from "Daniel Jacobowitz" at Oct 21, 2010 02:42:30 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/msg00340.txt.bz2 Dan Jacobowitz wrote: > On Thu, Oct 21, 2010 at 08:26:09PM +0200, Ulrich Weigand wrote: > > 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? > > Yes, it's true that this requires names. Fortunately, in the usual > case they are in the dynamic symbol table. So, I think you'll have > the names - or do we not see dynamic symbols here? Hmm, I was confused by readelf apparently being unable to resolve them in the case of libstdc++: Unwind table index '.ARM.exidx' at offset 0x95768 contains 1433 entries: 0x44704: 0x1 [cantunwind] 0x4478c: 0x80aab0b0 Compact model 0 0xaa pop {r4, r5, r6r14} 0xb0 finish 0xb0 finish 0x44804: 0x1 [cantunwind] 0x44938: @0x8fec0 Personality routine: 0x43264 0x44990: @0x8fedc Personality routine: 0x43264 0x44b00: 0x1 [cantunwind] But in fact 0x43264 is the address of the PLT entry pointing to this jump slot: 000a4480 000d7516 R_ARM_JUMP_SLOT 00084e25 __gxx_personality_v0 So we should certainly be able to resolve that in GDB. > > 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. > > This should work... the problem with r7 was that it's the hard frame > pointer for Thumb (even Thumb-2 - although it shouldn't be, most > likely, it's a wasteful choice). So we couldn't mark it as > clobbered. Does GCC not mark r7 as saved on the stack for the ARM > code? It should know perfectly well that r7 is not unchanged. Right, for C code there should be no problem. The problems I've been seeing all come from *assembler* source files using the DO_CALL macro. This gets CFI correct, but doesn't create any unwind records ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com