Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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 0/4] gdb: Allow struct fields named double
Date: Tue, 18 Dec 2018 22:40:00 -0000	[thread overview]
Message-ID: <cover.1545172667.git.andrew.burgess@embecosm.com> (raw)
In-Reply-To: <87tvjd4e54.fsf@tromey.com>

Simon, Tom,

Thanks for the feedback.

* Tom Tromey <tom@tromey.com> [2018-12-16 09:42:15 -0700]:

> >>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:
> 
> Simon> This looks reasonable to me, from the user point of view there is not reason
> Simon> why x.double would be different from x.float.  With the same logic, we should
> Simon> also allow x.int, x.short, etc.  But I'm fine with doing it on an as-needed basis.
> 
> See also https://sourceware.org/bugzilla/show_bug.cgi?id=13368

The new patch series includes a patch that extends some of the
comments in order to hopefully address this bug.

> 
> Simon> This LGTM, with one thing below you might want to change.  I'm far from an expert
> Simon> in parsers though, so please give others ~1 week to comment, and push then if you
> Simon> don't receive additional feedback.
> 
> I think the main possible issue is if this introduces a new parser conflict.
> Taking a glance at the uses of "name" in the grammar, though, it seems
> safe enough.

I took a better look at how the YACC step of the compile works, and it
turns out that parser conflicts are not fatal to the build, and my
change had introduced a new conflict.

The new patch series addresses this by focusing my change specifically
on structure field names, so I want to be able to parse:
'object.double', but I don't expect to be able to parse an object
named 'double'.  I also extended my patch to cover other types like
'int', 'short', etc.

As penance I've included a patch that tweaks how pointers are parsed
that resolves 49 reduce/reduce conflicts.

After this series there's still 42 shift/reduce conflicts, and 4
reduce/reduce conflicts in the C parser, but patch #4, the one I
really care about, doesn't introduce any new conflicts.

Tested on X86-64 GNU/Linux.

Thanks,
Andrew

---

Andrew Burgess (4):
  gdb: Extend the comments in c-exp.y
  gdb: Resolve 49 reduce/reduce conflicts in c-exp.y
  gdb: Add new parser rule for structure field names
  gdb: Allow struct fields named double

 gdb/ChangeLog                                      |  24 ++++
 gdb/c-exp.y                                        |  73 +++++++++---
 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, 248 insertions(+), 18 deletions(-)
 create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-unusual-field-names.c
 create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-unusual-field-names.exp

-- 
2.14.5


  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 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     ` Andrew Burgess [this message]
2018-12-24 17:30       ` [PATCHv2 0/4] gdb: Allow struct fields named double Andrew Burgess
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     ` [PATCHv2 4/4] gdb: Allow struct fields named double Andrew Burgess
2018-12-21 17:19       ` Tom Tromey

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=cover.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