From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19590 invoked by alias); 29 Nov 2013 20:20:52 -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 19577 invoked by uid 89); 29 Nov 2013 20:20:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_40,RDNS_NONE,SPF_HELO_PASS,SPF_PASS,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 29 Nov 2013 20:20:50 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rATKKgKE028944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Nov 2013 15:20:42 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rATKKfwZ032060; Fri, 29 Nov 2013 15:20:41 -0500 Message-ID: <5298F718.8060104@redhat.com> Date: Fri, 29 Nov 2013 22:31:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Andrew Burgess CC: "gdb-patches@sourceware.org" Subject: Re: [RFC 00/12] Merge value optimized_out and unavailable References: <5208D1DF.1090201@broadcom.com> In-Reply-To: <5208D1DF.1090201@broadcom.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-11/txt/msg00948.txt.bz2 On 08/12/2013 01:15 PM, Andrew Burgess wrote: > This patch set merges together how gdb handles values that are > optimized out and values that are unavailable. > > I think that in most cases gdb should not care why the contents of > a value are not fetch-able, it is only when we need to display > something to the user that we should have to figure out was this > optimized-out or unavailable? Kind of, but not quite. Going through the series, and thinking about it a lot, I'm not convinced the parts that handle unavailable and optimized out errors the same way are right. The frame machinery handles unavailable registers especially, with the _if_available wrappers, because it's possible to have a traceframe with no collected PC, or trimmed core file with no registers info, and consequently, a frame #0 with an PC / function. I'm not seeing how it's possible to end up with a frame_info that has an optimized out PC. If unwinding the PC results in a not saved PC, we use that as indication that we've reached the outermost frame, so we stop the backtrace before that could happen. So all the _if_available functions that _don't_ try to unwind the prev frame (which are most, except frame_unwind_caller_pc_if_available), shouldn't ever throw an optimized error for PC/function. Since frame_unwind_caller_pc_if_available is the only _if_available wrapper that unwinds, that's the case where the caller would need to likewise handle optimized out / not saved PCs. But then, after the series, "info frame", the only caller of frame_unwind_caller_pc_if_available, ends printing instead of , because these different errors passed through the same sieve hole: if (frame_unwind_caller_pc_if_available (fi, &caller_pc)) fputs_filtered (paddress (gdbarch, caller_pc), gdb_stdout); else fputs_filtered ("", gdb_stdout); (gdb) info frame Stack level 2, frame at 0x0: rip = 0x323d4f168d in clone (../sysdeps/unix/sysv/linux/x86_64/clone.S:115); saved rip Outermost frame: outermost caller of frame at 0x7ffff7fcafc0 source language asm. Arglist at 0x7ffff7fcafb8, args: Locals at 0x7ffff7fcafb8, Previous frame's sp is 0x7ffff7fcafc8 (gdb) Another place showing the issue with "merging" the errors is here: static CORE_ADDR frame_unwind_pc (struct frame_info *this_frame) { CORE_ADDR pc; if (!frame_unwind_pc_if_available (this_frame, &pc)) throw_error (NOT_AVAILABLE_ERROR, _("PC not available")); else return pc; } This throws the wrong error with the wrong string if frame_unwind_pc_if_available returned false due to OPTIMIZED_OUT_ERROR. So for that part of the series, I'd rather not go around and sprinkle the is_unavailable_error wrapper function wherever we use catch NOT_AVAILABLE_ERROR, but instead handle OPTIMIZED_OUT_ERROR as needed. I've posted a mini series that fixes the "info frame" case above: https://sourceware.org/ml/gdb-patches/2013-11/msg00943.html (I had actually tried to fix that before by making frame_unwind_caller_pc return struct value, and gave up as that grew quite messy quick. Making use of your new OPTIMIZED_OUT_ERROR ends up much simpler.) > After this patch set there will be a single unified interface to ask > if a value is available (either fully, partially, or for a range of > bit/bytes), this will answer in terms of both optimized out and > unavailable state. On terminology: I'd much rather not overload the "available/unavailable" words for this. It'll end up confusing, like "This value is not available, because it was unavailable? No, because it was optimized out.". Etc. Thanks, -- Pedro Alves