From: Andrew Burgess <andrew.burgess@embecosm.com>
To: gdb-patches@sourceware.org
Cc: Tom Tromey <tom@tromey.com>, Simon Marchi <simark@simark.ca>,
jimw@sifive.com, jhb@FreeBSD.org, palmer@sifive.com,
Andrew Burgess <andrew.burgess@embecosm.com>
Subject: [PATCHv2 4/4] gdb: Allow struct fields named double
Date: Tue, 18 Dec 2018 22:40:00 -0000 [thread overview]
Message-ID: <41fdb503cf18c86986aaf70dd2387c42f52502ee.1545172667.git.andrew.burgess@embecosm.com> (raw)
In-Reply-To: <cover.1545172667.git.andrew.burgess@embecosm.com>
In-Reply-To: <cover.1545172667.git.andrew.burgess@embecosm.com>
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.
---
gdb/ChangeLog | 7 ++
gdb/c-exp.y | 25 +++-
gdb/testsuite/ChangeLog | 5 +
gdb/testsuite/gdb.dwarf2/dw2-unusual-field-names.c | 32 +++++
.../gdb.dwarf2/dw2-unusual-field-names.exp | 132 +++++++++++++++++++++
5 files changed, 200 insertions(+), 1 deletion(-)
create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-unusual-field-names.c
create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-unusual-field-names.exp
diff --git a/gdb/c-exp.y b/gdb/c-exp.y
index b6b57c8c4d4..44e8eeadd7a 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);
@@ -1643,9 +1644,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; }
@@ -1718,6 +1731,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
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-unusual-field-names.c b/gdb/testsuite/gdb.dwarf2/dw2-unusual-field-names.c
new file mode 100644
index 00000000000..091e475fb3f
--- /dev/null
+++ b/gdb/testsuite/gdb.dwarf2/dw2-unusual-field-names.c
@@ -0,0 +1,32 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+ Copyright 2018 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+struct foo
+{
+ int field;
+};
+
+struct foo obj = { 0 };
+
+struct foo *ptr = &obj;
+
+int
+main (void)
+{
+ return obj.field;
+}
+
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-unusual-field-names.exp b/gdb/testsuite/gdb.dwarf2/dw2-unusual-field-names.exp
new file mode 100644
index 00000000000..6443acee249
--- /dev/null
+++ b/gdb/testsuite/gdb.dwarf2/dw2-unusual-field-names.exp
@@ -0,0 +1,132 @@
+# Copyright 2018 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+# Test that GDB can support accesing fields of a structure if the
+# fields have non-standard names. Specifically, if the names are
+# reserved C type names like 'double', 'float', 'int', etc.
+#
+# We don't expect to that such structures should be seen in real C
+# code, but in some cases GDB will generate artificial structures, and
+# in some cases, these type names are the obvious choice for field
+# names.
+#
+# One specific example is RISC-V, the 64-bit floating point registers
+# are represented as a structure with the field names 'float' and
+# 'double'.
+
+load_lib dwarf.exp
+
+# This test can only be run on targets which support DWARF-2 and use
+# gas.
+if {![dwarf2_support]} {
+ return 0
+}
+
+standard_testfile dw2-unusual-field-names.c dw2-unusual-field-names.S
+set asm_file [standard_output_file $srcfile2]
+
+# We need to know the size of integer and address types in order to
+# write some of the debugging info we'd like to generate.
+#
+# For that, we ask GDB by debugging our test program. Any program
+# would do, but since we already have one specifically for this
+# testcase, might as well use that.
+if [prepare_for_testing "failed to prepare" ${testfile} ${srcfile}] {
+ return -1
+}
+set int_size [get_sizeof "int" -1]
+
+# Rebuild the test binary with the single field within the structure
+# renamed to FIELD_NAME, then test that we can access the field
+# through '.' and through '->'.
+proc run_test { field_name } {
+ global asm_file testfile srcfile subdir srcdir
+ global int_size
+
+ Dwarf::assemble $asm_file {
+ global srcdir subdir srcfile
+ global field_name int_size
+
+ cu {} {
+ DW_TAG_compile_unit {
+ {DW_AT_language @DW_LANG_C}
+ {DW_AT_name dw2-unusual-field-names.c}
+ {DW_AT_comp_dir /tmp}
+ } {
+ declare_labels itype ptype stype
+
+ itype: DW_TAG_base_type {
+ {DW_AT_byte_size $int_size DW_FORM_sdata}
+ {DW_AT_encoding @DW_ATE_signed}
+ {DW_AT_name int}
+ }
+
+ stype: DW_TAG_structure_type {
+ {DW_AT_name "foo"}
+ {DW_AT_byte_size $int_size DW_FORM_sdata}
+ } {
+ member {
+ {name $field_name}
+ {type :$itype}
+ {data_member_location 0 data1}
+ }
+ }
+
+ ptype: DW_TAG_pointer_type {
+ {DW_AT_type :$stype}
+ }
+
+ DW_TAG_variable {
+ {DW_AT_name obj}
+ {DW_AT_type :$stype}
+ {DW_AT_location {
+ DW_OP_addr [gdb_target_symbol obj]
+ } SPECIAL_expr}
+ {external 1 flag}
+ }
+
+ DW_TAG_variable {
+ {DW_AT_name ptr}
+ {DW_AT_type :$ptype}
+ {DW_AT_location {
+ DW_OP_addr [gdb_target_symbol ptr]
+ } SPECIAL_expr}
+ {external 1 flag}
+ }
+ }
+ }
+ }
+
+ if { [prepare_for_testing "failed to prepare" ${testfile} \
+ [list $srcfile $asm_file] {nodebug}] } {
+ return -1
+ }
+
+ if ![runto_main] {
+ return -1
+ }
+
+ gdb_test "p obj.$field_name" " = 0" \
+ "access a field named '$field_name' directly"
+
+ gdb_test "p ptr->$field_name" " = 0" \
+ "access a field named '$field_name' through a pointer"
+
+ gdb_exit
+}
+
+foreach field_name { double float char byte long int short unsigned signed } {
+ run_test $field_name
+}
--
2.14.5
next prev parent reply other threads:[~2018-12-18 22:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-15 23:25 [PATCH] " Andrew Burgess
2018-12-16 16:23 ` Simon Marchi
2018-12-16 16:42 ` Tom Tromey
2018-12-18 22:40 ` [PATCHv2 2/4] gdb: Resolve 49 reduce/reduce conflicts in c-exp.y Andrew Burgess
2018-12-21 16:37 ` Tom Tromey
2018-12-18 22:40 ` Andrew Burgess [this message]
2018-12-21 17:19 ` [PATCHv2 4/4] gdb: Allow struct fields named double Tom Tromey
2018-12-18 22:40 ` [PATCHv2 1/4] gdb: Extend the comments in c-exp.y Andrew Burgess
2018-12-21 15:44 ` Tom Tromey
2018-12-18 22:40 ` [PATCHv2 3/4] gdb: Add new parser rule for structure field names Andrew Burgess
2018-12-21 16:38 ` Tom Tromey
2018-12-18 22:40 ` [PATCHv2 0/4] gdb: Allow struct fields named double Andrew Burgess
2018-12-24 17:30 ` Andrew Burgess
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41fdb503cf18c86986aaf70dd2387c42f52502ee.1545172667.git.andrew.burgess@embecosm.com \
--to=andrew.burgess@embecosm.com \
--cc=gdb-patches@sourceware.org \
--cc=jhb@FreeBSD.org \
--cc=jimw@sifive.com \
--cc=palmer@sifive.com \
--cc=simark@simark.ca \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox