aboutsummaryrefslogtreecommitdiff
path: root/gdb/c-exp.y
diff options
context:
space:
mode:
authorAndrew Burgess <andrew.burgess@embecosm.com>2018-12-13 18:25:25 +0000
committerAndrew Burgess <andrew.burgess@embecosm.com>2018-12-24 17:25:25 +0000
commit6f0ffe50c8f395ccb45ba9e801906b49d18c1af9 (patch)
tree4a459124e7622b93475e018952cc38cb6b6dbc24 /gdb/c-exp.y
parent0f5d3f636a606e307d8d8634415cc1e313a38273 (diff)
downloadgdb-6f0ffe50c8f395ccb45ba9e801906b49d18c1af9.zip
gdb-6f0ffe50c8f395ccb45ba9e801906b49d18c1af9.tar.gz
gdb-6f0ffe50c8f395ccb45ba9e801906b49d18c1af9.tar.bz2
gdb: Allow struct fields named double
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 'field_name' rule to match the DOUBLE_KEYWORD, and create a suitable 'struct stoken'. With this done the "exp '.' field_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 I've gone ahead and handled INT_KEYWORD, LONG, SHORT, SIGNED_KEYWORD, and UNSIGNED as well within field_name. I've added a new test for this functionality. This change was tested on x86-64 GNU/Linux with no regressions. gdb/ChangeLog: * c-exp.y (field_name): Allow DOUBLE_KEYWORD, INT_KEYWORD, LONG, SHORT, SIGNED_KEYWORD, and UNSIGNED tokens to act as a field names. (typename_stoken): New function. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-unusual-field-names.c: New file. * gdb.dwarf2/dw2-unusual-field-names.exp: New file.
Diffstat (limited to 'gdb/c-exp.y')
-rw-r--r--gdb/c-exp.y25
1 files changed, 24 insertions, 1 deletions
diff --git a/gdb/c-exp.y b/gdb/c-exp.y
index 98a0df3..996152d 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);
@@ -1645,9 +1646,21 @@ oper: OPERATOR NEW
}
;
-
+/* This rule exists in order to allow some tokens that would not normally
+ match the 'name' rule to appear as fields within a struct. The example
+ that initially motivated this was the RISC-V target which models the
+ floating point registers as a union with fields called 'float' and
+ 'double'. The 'float' string becomes a TYPENAME token and can appear
+ anywhere a 'name' can, however 'double' is its own token,
+ DOUBLE_KEYWORD, and doesn't match the 'name' rule.*/
field_name
: name
+ | DOUBLE_KEYWORD { $$ = typename_stoken ("double"); }
+ | INT_KEYWORD { $$ = typename_stoken ("int"); }
+ | LONG { $$ = typename_stoken ("long"); }
+ | SHORT { $$ = typename_stoken ("short"); }
+ | SIGNED_KEYWORD { $$ = typename_stoken ("signed"); }
+ | UNSIGNED { $$ = typename_stoken ("unsigned"); }
;
name : NAME { $$ = $1.stoken; }
@@ -1720,6 +1733,16 @@ 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 = { type, 0 };
+ st.length = strlen (type);
+ return st;
+};
+
/* Return true if the type is aggregate-like. */
static int