From patchwork Mon Apr 4 21:28:33 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Don Breazeal X-Patchwork-Id: 11626 Received: (qmail 35083 invoked by alias); 4 Apr 2016 21:28:46 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 35063 invoked by uid 89); 4 Apr 2016 21:28:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=visual, recognizes X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 04 Apr 2016 21:28:36 +0000 Received: from svr-orw-fem-05.mgc.mentorg.com ([147.34.97.43]) by relay1.mentorg.com with esmtp id 1anC30-00035Z-Cc from Don_Breazeal@mentor.com ; Mon, 04 Apr 2016 14:28:34 -0700 Received: from build4-lucid-cs (147.34.91.1) by svr-orw-fem-05.mgc.mentorg.com (147.34.97.43) with Microsoft SMTP Server id 14.3.224.2; Mon, 4 Apr 2016 14:28:34 -0700 Received: by build4-lucid-cs (Postfix, from userid 1905) id BC5F941282; Mon, 4 Apr 2016 14:28:33 -0700 (PDT) From: Don Breazeal To: , Subject: Re: [PATCH] Eliminate -var-create error for optzd ptr to struct Date: Mon, 4 Apr 2016 14:28:33 -0700 Message-ID: <1459805313-6418-1-git-send-email-donb@codesourcery.com> In-Reply-To: <86a8lgrq3f.fsf@gmail.com> MIME-Version: 1.0 X-IsSubscribed: yes Hi Yao, On 4/4/2016 10:16 AM, Don Breazeal wrote: > On 4/4/2016 3:41 AM, Yao Qi wrote: >> Don Breazeal writes: >> >>> Note that we if value_optimized_out throws an error we just assume >>> the value is not optimized out. We let value_rtti_indirect_type >>> handle any errors, and don't try to duplicate its error handling. >> >> I am wondering why does value_optimized_out have to throw an error? >> Can't we catch the error in value_optimized_out thrown by >> value_fetch_lazy? >> >> I am not very sure on this idea, but I searched the archive, and didn't >> find anything say we can't do that. >> > I looked briefly at all the call sites for value_optimized_out. It > looks like if value_optimized_out were to just return 'false' when it > got a memory error, the result in most cases would be that a subsequent > memory read would throw an error. It might be that this could prevent a > scenario similar to the -var-create error elsewhere in GDB, but there > wasn't anything obvious in my quick scan. > > I'll change the patch accordingly and run the testsuite. Also note that in my scan of value_optimized_out call sites, I didn't notice anywhere that it was explicitly wrapped in a TRY/CATCH block. I made the changes described above, ran the testsuite on x86_64 Linux (no regressions), and updated the patch description and ChangeLog. The updated patch follows below. Thanks --Don ---- This patch eliminates an error thrown when accessing the value of a pointer to a structure where the pointer has been optimized out and 'set print object' is 'on'. The error shows up as the rather ugly value of the pointer variable in Eclipse. If 'set print object' is 'on', GDB tries to determine the actual (derived) type of the object rather than the declared type, which requires dereferencing the pointer, which in this cases throws an error because the pointer has been optimized out. The fix is to simply ignore the 'print object on' setting for pointers or references to structures when they have been optimized out. This means we just get the declared type instead of the actual type, because in this case that's the best that we can do. To implement the fix, value_optimized_out was modified so that it no longer throws an error when it fails to fetch the specified value. Instead, it just returns 'false'. If we can't definitively say that the value is optimized out, then we assume it is not. Note that this affects other parts of GDB that call value_optimized_out; however, visual inspection of the code shows that in all of those cases an error occurring in value_optimized_out will likely recur in a subsequent attempt to access memory, and the error will be thrown there. Meanwhile this change will prevent other scenarios similar to the one that's fixed here. I'm working on setting things in motion for a patch to Eclipse that recognizes optimized-out pointer-to-struct in this scenario and prevents any subsequent attempt to dereference it from that end. Tested on bare-metal powerpc board with Linux x86 host and Linux native x86_64. gdb/ChangeLog: 2016-04-04 Don Breazeal * value.c (value_actual_type): Don't try to get rtti type of the value if it has been optimized out. (value_optimized_out): Return zero if a memory access error occurs. --- gdb/value.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/gdb/value.c b/gdb/value.c index 8268b08..90ae193 100644 --- a/gdb/value.c +++ b/gdb/value.c @@ -1205,7 +1205,8 @@ value_actual_type (struct value *value, int resolve_simple_types, if ((TYPE_CODE (result) == TYPE_CODE_PTR || TYPE_CODE (result) == TYPE_CODE_REF) && TYPE_CODE (check_typedef (TYPE_TARGET_TYPE (result))) - == TYPE_CODE_STRUCT) + == TYPE_CODE_STRUCT + && !value_optimized_out (value)) { struct type *real_type; @@ -1433,7 +1434,18 @@ value_optimized_out (struct value *value) /* We can only know if a value is optimized out once we have tried to fetch it. */ if (VEC_empty (range_s, value->optimized_out) && value->lazy) - value_fetch_lazy (value); + { + TRY + { + value_fetch_lazy (value); + } + CATCH (ex, RETURN_MASK_ERROR) + { + /* If we get an error, assume the value is not optimized out. */ + return 0; + } + END_CATCH + } return !VEC_empty (range_s, value->optimized_out); }