From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20278 invoked by alias); 23 Feb 2011 22:26:31 -0000 Received: (qmail 20269 invoked by uid 22791); 23 Feb 2011 22:26:30 -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; Wed, 23 Feb 2011 22:26:24 +0000 Received: (qmail 2169 invoked from network); 23 Feb 2011 22:26:22 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 23 Feb 2011 22:26:22 -0000 From: Pedro Alves To: Mark Kettenis Subject: Re: [unavailable regs/locals, 0/11] Introduction Date: Wed, 23 Feb 2011 22:49:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-25-generic; KDE/4.6.0; x86_64; ; ) Cc: gdb-patches@sourceware.org References: <201102221327.22636.pedro@codesourcery.com> <201102221337.59184.pedro@codesourcery.com> <201102232142.p1NLgx86002352@glazunov.sibelius.xs4all.nl> In-Reply-To: <201102232142.p1NLgx86002352@glazunov.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201102232226.20634.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-02/txt/msg00666.txt.bz2 On Wednesday 23 February 2011 21:42:59, Mark Kettenis wrote: > > From: Pedro Alves > > Date: Tue, 22 Feb 2011 13:37:58 +0000 > > > > On Tuesday 22 February 2011 13:27:22, Pedro Alves wrote: > > > Tested on x86_64-linux, native and gdbserver. No > > > regressions, and the new tests pass cleanly. > > > > ... and it goes without saying: > > > > I'd appreciate comments and extra eyeballs on all of this. > > Pending objections, I'd like to commit after a reasonable wait. > > Pedro, I haven't looked very closely at the code yet, but I have a few > worries. The GCC debug information tends to underspecify the saved > registers in the unwind info. The unwinder code deals with > "unspecified"[1] registers by assuming they have the same value as in the > "inner" frame. How does your new code treat such "unspecified" > registers? > > [1] "unspecified" is different from "undefined" My changes related to unavailable register values, as in their register/memory 's contents not having been collected by a given tracepoint/traceframe. This is ortogonal from unspecified/undefined in debug info. There's sort of a run-time vs compile-time distinction. The unavailable-less I've been talking about is of the run-time kind. unspecified/undefined is of the compile-time kind. If the unwinder assumes an unspecified register has the same value as in the inner frame, it will continue to do so. Only when the register value is actually read from the stack or the register cache, is it determined to be unavailable/uncollected, and the struct value marked accordingly. In the unspecified case, if the register value is available in the next frame (because enough stack has been collected to cover the next frame, say), it'll be available in the this frame too. If it's unavailable in the next frame (because not enough stack had been collected to cover that particular register, that was saved last in the stack, say), it'll be unavailable in the this frame too. (If anything tries to get at an unavailable value's contents, and exception is thrown.) -- Pedro Alves