From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29120 invoked by alias); 18 Mar 2011 18:56:24 -0000 Received: (qmail 28883 invoked by uid 22791); 18 Mar 2011 18:56:23 -0000 X-SWARE-Spam-Status: No, hits=-1.9 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; Fri, 18 Mar 2011 18:56:19 +0000 Received: (qmail 32018 invoked from network); 18 Mar 2011 18:56:17 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Mar 2011 18:56:17 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: graceful unwind termination when we'd need unavailable/uncollect memory or registers to unwind further Date: Fri, 18 Mar 2011 20:21:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-27-generic; KDE/4.6.1; x86_64; ; ) References: <201102221834.42413.pedro@codesourcery.com> In-Reply-To: <201102221834.42413.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103181856.13372.pedro@codesourcery.com> X-IsSubscribed: yes 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: 2011-03/txt/msg00932.txt.bz2 I've checked this one in as well. On Tuesday 22 February 2011 18:34:42, Pedro Alves wrote: > This patch applies on top of the "unavailable regs/locals" > series, starting at: > . > > This teaches GDB about terminating unwinding gracefully if > unwind further we would need registers/memory that haven't > been collected. > > Here's the result: > > (gdb) bt > #0 begin (a=) at ../../../src/gdb/testsuite/gdb.trace/unavailable.cc:182 > #1 0x00000000004008ad in main (argc=1, argv=0x7fff0e22cf28, envp=0x7fff0e22cf38) > at ../../../src/gdb/testsuite/gdb.trace/unavailable.cc:210 > #2 in ?? () > Backtrace stopped: Not enough registers or memory available to unwind further > > I think I've implemented this differently in about 10 > different ways. This is the design that I ended up with and > that I think is best. > > - when we sniff unwinders trying to find a matching unwinder, > we catch NOT_AVAILABLE_ERRORS. If the PC is unavailable, > it is impossible to determine if a given non-prologue parser unwinder > would have been the best unwinder or not. By catching > NOT_AVAILABLE_ERRORS, we don't have too touch many sniffers. > When sniffing, they just read whatever minimum data they > require to determine they're the correct unwinder. If > any of that is unavailable, we'll hit an exception. So what > this means is that sniffer code does not try to check if a > given _required_ value is available --- it just goes ahead and > reads it. > > - adds a new frame_unwind method, to make it possible for an unwinder > to tell the core frame code that it can't unwind further. The > concept here, is that if we are able to tell a given unwinder > would be the best unwinder, select it, even if actually trying to > unwind from it wouldn't work due to unavailable data. E.g., if > all we have available is the PC, we'll be able to tell that we > have dwarf unwind info for that frame. But if we then find out > that we don't have enough registers/memory to compute the CFA, we know > we aren't going to be able to unwind. We _don't_ fallback to > prologue parsing in such cases, since if we couldn't unwind with > the precise unwind info missing, prologue parsing is surely not > going to be able to unwind correctly. > > - this new method incidently allows cleanly reporting to the core > frame machinery when a frame is the outermost, without resorting > to hacks in the frame_id, which opens the door to fixing a > corner case with stepping through the outermost frame when there's > no debug info. I won't be implementing that, it just paves the way. > > - the prologue parsers then need to be made aware that they may trip > on necessary registers (e.g., PC / SP / FP) unavailable to unwine, > and that they should return that they can't unwind further in > the new frame_unwind method in that case. I've taught the x86 > and x64_64 unwinders, but not all others. I did do the mechanical > work of adjusting all of them to the new interface, so that > --enable-targets=all still builds, and so that they continue working > as today. Theaching other prologue unwinders how to terminate > gracefully with UNWIND_UNAVAILABLE is only interesting when a > corresponding target supports tracepoints on that architecture, so > it can be enabled on a case by case basis. -- Pedro Alves