From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64759 invoked by alias); 16 Dec 2018 16:23:39 -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 64739 invoked by uid 89); 16 Dec 2018 16:23:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=malloc, act X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 16 Dec 2018 16:23:35 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id EE1DB1E4C2; Sun, 16 Dec 2018 11:23:33 -0500 (EST) Subject: Re: [PATCH] gdb: Allow struct fields named double To: Andrew Burgess , gdb-patches@sourceware.org Cc: jimw@sifive.com, palmer@sifive.com, jhb@FreeBSD.org References: <20181215232414.10883-1-andrew.burgess@embecosm.com> From: Simon Marchi Message-ID: <98105817-ba16-27f9-5bcb-7a6e7555f87b@simark.ca> Date: Sun, 16 Dec 2018 16:23:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <20181215232414.10883-1-andrew.burgess@embecosm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-12/txt/msg00184.txt.bz2 On 2018-12-15 6:24 p.m., Andrew Burgess wrote: > The patch below fixes an issue with the current was floating point is > handled on RISC-V. We currently model 64-bit floating point as a > union with fields 'double' and 'float'. The problem is that having a > field named 'double' isn't currently valid in GDB (though float is fine). > > The easiest solution might be to change the field names... but the > patch below instead extends the C parser to allow double as a field > name. > > I'd be interested in hearing feedback on the below, > > Thanks, > Andrew > > --- > > The 64-bit RISC-V target currently models the floating point registers > as having the following type: > > union riscv_double > { > builtin_type_ieee_single float; > builtin_type_ieee_double double; > } > > Notice the choice of names for the fields of this struct, possibly not > ideal choices, as these are not valid field names in C. However, this > type is only ever defined within GDB (or in the target description), > and no restriction seems to exist on the field names in that case. > > The problem though is that currently: > > (gdb) info registers $ft0 > ft0 {float = 0, double = 0} (raw 0x0000000000000000) > (gdb) p $ft0.float > $1 = 0 > (gdb) p $ft0.double > A syntax error in expression, near `double'. > > We can access the 'float' field, but not the 'double' field. This is > because the string 'double' is handled differently to the string > 'float' in c-exp.y. > > In both cases the string '$ft0' is parsed as a VARIABLE expression. > > In the 'float' case, the string 'float' becomes a generic NAME token > in 'lex_one_token', which then allows the rule "exp '.' name" to match > and the field name lookup to occur. > > The 'double' case is different. In order to allow parsing of the type > string 'long double', the 'double' string becomes the token > DOUBLE_KEYWORD. At this point there's no rule to match "exp '.' > DOUBLE_KEYWORD", so we can never lookup the field named 'double'. > > We could rename the fields for RISC-V, and maybe that would be the > best solution. However, its not hard to allow for fields named > 'double', which is what this patch does. > > A new case is added to the 'name' rule to match the DOUBLE_KEYWORD, > and create a suitable 'struct stoken'. With this done the "exp '.' > name" pattern can now match, and we can lookup the double field. > > With this patch in place I now see this behaviour: > > (gdb) info registers $ft0 > ft0 {float = 0, double = 0} (raw 0x0000000000000000) > (gdb) p $ft0.float > $1 = 0 > (gdb) p $ft0.double > $2 = 0 > > This change was tested on x86-64 GNU/Linux with no regressions. > > gdb/ChangeLog: > > * c-exp.y (name): Allow DOUBLE_KEYWORD to act as a name. > (typename_stoken): New function. This looks reasonable to me, from the user point of view there is not reason why x.double would be different from x.float. With the same logic, we should also allow x.int, x.short, etc. But I'm fine with doing it on an as-needed basis. This LGTM, with one thing below you might want to change. I'm far from an expert in parsers though, so please give others ~1 week to comment, and push then if you don't receive additional feedback. > --- > gdb/ChangeLog | 5 +++++ > gdb/c-exp.y | 17 +++++++++++++++++ > 2 files changed, 22 insertions(+) > > diff --git a/gdb/c-exp.y b/gdb/c-exp.y > index bfc78415b22..8d805cbde3d 100644 > --- a/gdb/c-exp.y > +++ b/gdb/c-exp.y > @@ -113,6 +113,7 @@ static int type_aggregate_p (struct type *); > static int parse_number (struct parser_state *par_state, > const char *, int, int, YYSTYPE *); > static struct stoken operator_stoken (const char *); > +static struct stoken typename_stoken (const char *); > static void check_parameter_typelist (VEC (type_ptr) *); > static void write_destructor_name (struct parser_state *par_state, > struct stoken); > @@ -1642,6 +1643,7 @@ name : NAME { $$ = $1.stoken; } > | TYPENAME { $$ = $1.stoken; } > | NAME_OR_INT { $$ = $1.stoken; } > | UNKNOWN_CPP_NAME { $$ = $1.stoken; } > + | DOUBLE_KEYWORD { $$ = typename_stoken ("double"); } > | oper { $$ = $1; } > ; > > @@ -1707,6 +1709,21 @@ operator_stoken (const char *op) > return st; > }; > > +/* Returns a stoken of the type named TYPE. */ > + > +static struct stoken > +typename_stoken (const char *type) > +{ > + struct stoken st = { NULL, 0 }; > + char *buf = xstrdup (type); > + st.ptr = buf; > + st.length = strlen (type); > + > + /* The toplevel (c_parse) will free the memory allocated here. */ > + make_cleanup (free, buf); > + return st; > +}; Unlike operator_stoken, I don't think we need to malloc anything here, we could return { "double", strlen ("double") }. At this point, we might not need a dedicated function. Simon