From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20514 invoked by alias); 21 Oct 2010 15:51:05 -0000 Received: (qmail 20505 invoked by uid 22791); 21 Oct 2010 15:51:04 -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 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 15:50:56 +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 o9LForP7016263 for ; Thu, 21 Oct 2010 15:50:53 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 o9LFor6C3469478 for ; Thu, 21 Oct 2010 17:50:53 +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 o9LFoqOc012454 for ; Thu, 21 Oct 2010 17:50:53 +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 o9LFopOt012436; Thu, 21 Oct 2010 17:50:51 +0200 Message-Id: <201010211550.o9LFopOt012436@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 21 Oct 2010 17:50:51 +0200 Subject: Re: [rfc/rfa] Use ARM exception tables as GDB unwinder To: dan@codesourcery.com (Daniel Jacobowitz) Date: Thu, 21 Oct 2010 15:51:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, rearnsha@arm.com, matthew.gretton-dann@arm.com In-Reply-To: <20101020132657.GU8337@caradoc.them.org> from "Daniel Jacobowitz" at Oct 20, 2010 09:26:57 AM 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/msg00336.txt.bz2 Dan Jacobowitz wrote: > On Wed, Oct 20, 2010 at 02:00:56AM +0200, Ulrich Weigand wrote: > > In addition, one minor change was necessary to the prologue unwinder: > > the this_id routine no longer uses get_frame_func to retrieve the > > function start address; instead, this value is stored in the cache. > > This allows the exception unwinder to provide this information from > > the exception table, instead of having to rely on symbol data. > > Like Matthew, I have some concern about this; unwind regions are not > 1:1 with functions. Not only will the linker combine identical > regions, but hand-written code (or, hypothetically, > -fnon-call-exceptions) can have multiple regions in a function. > But we can probably ignore the latter case; the former can be handled > by using whichever is larger, the symbol or exception region address. This is in effect what happens, because if the symbol is larger than the exception region address, I'm refusing to use the unwind record and fall back to prologue parsing (which will use the symbol). > > + /* See if we have an ARM exception table entry covering this address. */ > > + addr_in_block = get_frame_address_in_block (this_frame); > > + entry = arm_find_exidx_entry (addr_in_block, &func_exidx); > > + if (!entry) > > + return 0; > > I assume you're deliberately treating can't-unwind and no-information > the same. We use can't-unwind to mark _start, but it also shows up in > exception handling in some cases. 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 ... > > + /* The ARM exception index does not mark the *end* of the function > > + covered by the entry, and some functions will not have any entry. > > + Therefore, the entry we found above may not actually be correct > > + for this PC. As a sanity check, also try to determine the function > > + covering PC via the symbol table. If this finds a function start > > + address *closer* to PC than the one found via the exception table, > > + ignore the exception record, and fall back to prologue parsing. > > + > > + (Note that if we don't find a function via the symbol table, the > > + exception table may still be wrong. But in this case, prologue > > + parsing wouldn't work anyway, so we use the exception table and > > + hope for the best.) */ > > + if (find_pc_partial_function (addr_in_block, NULL, &func_symtab, NULL) > > + && func_symtab > func_exidx) > > + return 0; > > This doesn't go well with the discussion above about combined > exception regions... did you encounter this problem in practice? The > linker used to have this problem, but hasn't for a while (circa > 2009-05-05). Yes, I've definitely seen this in practice. In the Ubuntu glibc I have: Unwind table index '.ARM.exidx' at offset 0xe8448 contains 596 entries: 0x15470: 0x800b3fac Compact model 0 0x0b vsp = vsp + 48 0x3f vsp = vsp + 256 0xac pop {r4, r5, r6, r7, r8r14} 0x157ec: 0x80aab0b0 Compact model 0 0xaa pop {r4, r5, r6r14} 0xb0 finish 0xb0 finish 0x1584c: 0x8003a8b0 Compact model 0 0x03 vsp = vsp + 16 0xa8 pop {r4r14} 0xb0 finish 0x15890: 0x808408b0 Compact model 0 0x84 0x08 pop {r7, r14} 0xb0 finish 0x25a50: 0x808400b0 Compact model 0 0x84 0x00 pop {r14} 0xb0 finish 0x25a90: 0x80a8b0b0 Compact model 0 0xa8 pop {r4r14} 0xb0 finish 0xb0 finish 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? > The actual unwinder looks OK to me. If you want to handle C++ code > with exceptions (or C with cleanups), you'll need to check the name of > the referenced personality routine; it is __gxx_personality_v0 (et > cetera). Readelf has a sample of that. Code which doesn't throw or > catch uses the standard personality routines, as you've implemented. 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). Thanks for the review! Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com