From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128549 invoked by alias); 10 Mar 2015 15:46:06 -0000 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 Received: (qmail 128514 invoked by uid 89); 10 Mar 2015 15:46:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 10 Mar 2015 15:46:03 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2AFjKam028003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 10 Mar 2015 11:45:20 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2AFjHdm027773; Tue, 10 Mar 2015 11:45:19 -0400 Message-ID: <54FF118D.9010301@redhat.com> Date: Tue, 10 Mar 2015 15:46:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Andy Wingo CC: gdb-patches@sourceware.org, asmundak@google.com Subject: Re: [PATCH v2] Add Guile frame unwinder interface References: <87oao7wi66.fsf@igalia.com> <87zj7msbly.fsf@igalia.com> <54FDBF21.4090400@redhat.com> <87pp8iq9wc.fsf@igalia.com> In-Reply-To: <87pp8iq9wc.fsf@igalia.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-03/txt/msg00250.txt.bz2 On 03/09/2015 06:54 PM, Andy Wingo wrote: > Hi, > > On Mon 09 Mar 2015 16:41, Pedro Alves writes: > >> On 03/09/2015 10:34 AM, Andy Wingo wrote: >>> +@var{register} names a register, and should be a string, for example >>> +@samp{rip}. @var{value} is the register value, as a @value{GDBN} >>> +value. Alternately, passing @code{#f} as the value will mark the >>> +register as unavailable. >> >> From a glimpse over the code, I think this actually marks it as >> "" (optimized out), right? That would be the correct >> thing to do. Marking a register as "" is also possible, >> but it is a different thing -- it means the value exists, but gdb >> couln't get to it, because e.g., the core file is trimmed, or the >> ptrace interface is missing access to some registers. >> >> That said, you may want to consider how you'd expand the API >> to allow marking registers as unavailable. > > I didn't realize that "unavailable" and "not saved" were different > things, thanks for the pointer. I guess given that the default is a > "not saved" result, I can just document this default state, and that > ephemeral-frame-add-saved-value! adds a value. We remove the #f case. I wonder whether that's the best default though. That forces the unwinder to always handle all registers, even random i/o registers, etc the machine may happen to have/expose? An alternative would be assume the register is found unmodified in this_frame. You'd need a ephemeral-frame-mark-not-saved! then, of course. > > If we need to support other states like "unavailable", we can add other > API like ephemeral-frame-mark-unavailable! or similar. Yeah. Note that GDB can mark _parts_ of registers not saved or unavailable, down to the bit level (mark_value_bits_optimized_out / mark_value_bits_unavailable). Thanks, Pedro Alves