From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7120 invoked by alias); 5 Feb 2018 06:20:49 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 7103 invoked by uid 89); 5 Feb 2018 06:20:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-19.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*c:alternative X-HELO: mail-wm0-f48.google.com Received: from mail-wm0-f48.google.com (HELO mail-wm0-f48.google.com) (74.125.82.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 05 Feb 2018 06:20:45 +0000 Received: by mail-wm0-f48.google.com with SMTP id i186so23697589wmi.4 for ; Sun, 04 Feb 2018 22:20:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q84WWwthhwawDzPyxD+3q5dXUafMCF0Qy30J682St0U=; b=KpehxWSFCoBH5xE23LHHQ1mUW5bfltBZEZ1xlAOqOAJqWNYmJjLkCX1KlvH4WlD7HO hDh+NWIKCeKqMyitFK1xJYmakMKSRyWjwy+9wQRiOTpWpV5rMsmVIhsNXsRyXq9d09hS AByIJMqJLZZrMAi1Lgrf/s3isbxmw2Jx/Op6A4YMSUGclWNn4hZkpoqwJRlet/ObgQGF GQ6JX72F1K4DuoTldK4XdYWxAM31AaojFlJNlvcQnSERB8E9lopXbtnoU+voRX3gMoCX vaRPvVX8S/mqm/0+OR6w2/qtAa5h4rvikpzYwkwvpiluxWOkR/RmlDx9qWy6RltVGTEx ZbiA== X-Gm-Message-State: AKwxytfCbQHudbMH4l+hd47NteKoFGWGMi1BDglaud36H4YvDZK4jXQY t16iJkYoBhs9BtS8T9LCX2Yq57M/65fWfuetJ7k= X-Google-Smtp-Source: AH8x225XL+lWeglAyMVAY6o48qxM7TEDHpLLcbLl212F+xmkw52dd6lZLD4pZNg8B9PrbucA12erl8I6SYqHzR9j5as= X-Received: by 10.28.45.74 with SMTP id t71mr34083636wmt.90.1517811643133; Sun, 04 Feb 2018 22:20:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.122.19 with HTTP; Sun, 4 Feb 2018 22:20:42 -0800 (PST) In-Reply-To: References: From: Roman Popov Date: Mon, 05 Feb 2018 06:20:00 -0000 Message-ID: Subject: Re: GDB returns wrong type when traversing optimized-out Fields To: Simon Marchi Cc: gdb@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00023.txt.bz2 Thanks Simon, Your patch solves the issue for all of my clients! -Roman 2018-02-04 21:39 GMT-08:00 Simon Marchi : > On 2018-02-04 11:06 PM, Roman Popov wrote: > > I apologize for code typo in previous email. Here is correct code sample: > > > > template > > struct TRAITS { > > static const unsigned val1 = v1; > > static const unsigned val2 = v2; > > }; > > template < class TRAITS > > > struct foo { > > static const unsigned x1 = TRAITS::val1; > > static const unsigned x2 = TRAITS::val2; > > }; > > > > int main () { > > foo> f1; > > // SET BREAKPOINT HERE > > return 0; > > } > > > > -Roman > > > > > > 2018-02-04 20:02 GMT-08:00 Roman Popov : > > > >> Hi all, > >> I've encountered strange GDB behavior when requesting a value of > >> optimized-away field. > >> Instead of returning None or raising exception, GDB returns an > >> optimizied-out value of wrong type. > >> > >> Here is a small reproducer *optimize_out.cpp*: > >> > >> template > >> struct TRAITS { > >> static const unsigned val1 = v1; > >> static const unsigned val2 = v2; > >> }; > >> template < class TRAITS > > >> struct foo { > >> static const unsigned x1 = TRAITS::v1; > >> static const unsigned x2 = TRAITS::v2; > >> }; > >> > >> int main () { > >> foo> f1; > >> // SET BREAKPOINT HERE > >> return 0; > >> } > >> > >> # Using g++ 7.3 > >> $ g++ -g optimize_out.cpp > >> > >> # Using gdb 8.1 > >> $ gdb a.out > >> > >> (gdb) break optimize_out.cpp:14 > >> (gdb) r > >> (gdb) p f1 > >> $1 = {static x1 = , static x2 = } > >> > >> Ok, looks good. Now traverse fields: > >> > >> (gdb) python > >>> f1 = gdb.parse_and_eval("f1") > >>> for field in f1.type.fields(): > >>> print ("field name: ", field.name, "field type: ", field.type) > >>> field_val = f1[field] > >>> print ("optout?: ",field_val.is_optimized_out, "type: > >> ",field_val.type) > >>> end > >> field name: x1 field type: const unsigned int > >> optout?: True type: foo > > >> field name: x2 field type: const unsigned int > >> optout?: True type: foo > > >> > >> > >> > >> So type we get is foo >, not unsigned int. > >> > >> Looks like GDB-MI has same behavior. At least this code sample totatlly > >> confuses GDB GUI I use. > >> > >> Thanks, > >> Roman > >> > > Hi Roman, > > It just seems to be that we return a value with the type of the structure > instead of the type of the field in an error path somewhere. It causes > these weird behaviors in the CLI too: > > (gdb) p f1 > $1 = {static x1 = , static x2 = } > (gdb) p f1.x1 > $2 = > (gdb) ptype f1.x1 > type = struct foo > [with TRAITS = TRAITS<1, 2>] { > static const unsigned int x1; > static const unsigned int x2; > } > (gdb) ptype f1.x1.x1 > type = struct foo > [with TRAITS = TRAITS<1, 2>] { > static const unsigned int x1; > static const unsigned int x2; > } > (gdb) p f1.x1.x1.x1.x1 > $3 = > > Can you try the patch below? I did not run the testsuite on it. > > > From ef7f73557e291ed2d8bc7f175765bdbb91e2c817 Mon Sep 17 00:00:00 2001 > From: Simon Marchi > Date: Mon, 5 Feb 2018 00:34:08 -0500 > Subject: [PATCH] Return right type in value_static_field > > --- > gdb/value.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/gdb/value.c b/gdb/value.c > index 9a144fb7fb..063f57129a 100644 > --- a/gdb/value.c > +++ b/gdb/value.c > @@ -2978,7 +2978,10 @@ value_static_field (struct type *type, int fieldno) > = lookup_minimal_symbol (phys_name, NULL, NULL); > > if (!msym.minsym) > - return allocate_optimized_out_value (type); > + { > + struct type *field_type = TYPE_FIELD_TYPE (type, fieldno); > + return allocate_optimized_out_value (field_type); > + } > else > { > retval = value_at_lazy (TYPE_FIELD_TYPE (type, fieldno), > -- > 2.16.1 > > >