public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Burgess <andrew.burgess@embecosm.com>
To: gdb-patches@sourceware.org
Cc: donb@codesourcery.com,	Andrew Burgess <andrew.burgess@embecosm.com>
Subject: [PATCHv4 0/5] Fix -var-update for registers in frames 1 and up
Date: Thu, 19 Oct 2017 13:27:00 -0000	[thread overview]
Message-ID: <cover.1508418720.git.andrew.burgess@embecosm.com> (raw)

This patch revives a patch series that was first discussed here:

  https://sourceware.org/ml/gdb-patches/2016-06/msg00145.html

with v3 being posted here:

  https://sourceware.org/ml/gdb-patches/2016-10/msg00069.html

On reflection I worried that the approach taken in patch v3 might not
cover all the cases, specifically, it would only spot cases where the
register was the first operand in the expression.  So something like
this would not get the correct results:

  (gdb) -var-create - * "(void*) $sp"

The more I thought about it, the more I wanted to revisit this
suggestion:

  https://sourceware.org/ml/gdb-patches/2016-06/msg00159.html

In this patch I extend the expression parser to log the innermost
block when parsing a register expression, however, Don pointed out at
the time, that this causes some test failures, as in some cases we
don't want to log the innermost block for registers.

The solution I'm proposing is to make the expression parser smarter,
or rather, the innermost block tracking aspect of the expression
parser.

Previously the innermost block was a simple global pointer, which we
set to NULL before parsing an expression, and read out afterwards.
Now, the innermost block is an object, we reset the object before
parsing an expression, and tell the object which types of innermost
block we care about.  During expression parsing all blocks are
mentioned to the innermost block object, and it takes care of
remembering the correct, innermost block.  After the expression parse
we query the innermost block object to find the correct answer.

There's also a very related fix thrown in at the end of the series, in
patch #5.

There are new tests added, and results updated in the few places where
things need to change, which is mainly as a result of the fix in patch #5.

Tested on x86-64 Linux native and with native-gdbserver, no regressions.

Thanks,
Andrew

---

Andrew Burgess (5):
  gdb: Remove duplicate declaration of a function
  gdb: New API for tracking innermost block
  gdb: PR mi/20395: Fix -var-update for registers in frames 1 and up
  gdb: Remove out of date comment
  gdb: Don't store a thread-id for floating varobj

 gdb/ChangeLog                               |  54 ++++++++
 gdb/ada-exp.y                               |   6 +-
 gdb/ada-lang.c                              |   8 +-
 gdb/breakpoint.c                            |  12 +-
 gdb/c-exp.y                                 |  20 +--
 gdb/d-exp.y                                 |  11 +-
 gdb/expression.h                            |   5 -
 gdb/f-exp.y                                 |   7 +-
 gdb/go-exp.y                                |   7 +-
 gdb/m2-exp.y                                |  14 +--
 gdb/objfiles.c                              |   2 +-
 gdb/p-exp.y                                 |  12 +-
 gdb/parse.c                                 |  18 ++-
 gdb/parser-defs.h                           |  54 +++++++-
 gdb/printcmd.c                              |   8 +-
 gdb/rust-exp.y                              |   8 +-
 gdb/symfile.c                               |   2 +-
 gdb/testsuite/ChangeLog                     |  14 +++
 gdb/testsuite/gdb.mi/basics.c               |   2 +
 gdb/testsuite/gdb.mi/mi-frame-regs.exp      | 187 ++++++++++++++++++++++++++++
 gdb/testsuite/gdb.mi/mi-var-create-rtti.exp |   5 +-
 gdb/testsuite/gdb.python/py-mi.exp          |  12 +-
 gdb/varobj.c                                |  10 +-
 23 files changed, 372 insertions(+), 106 deletions(-)
 create mode 100644 gdb/testsuite/gdb.mi/mi-frame-regs.exp

-- 
2.12.2

             reply	other threads:[~2017-10-19 13:27 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-19 13:27 Andrew Burgess [this message]
2017-10-19 13:27 ` [PATCHv4 1/5] gdb: Remove duplicate declaration of a function Andrew Burgess
2017-11-12 16:00   ` Simon Marchi
2017-10-19 13:27 ` [PATCHv4 4/5] gdb: Remove out of date comment Andrew Burgess
2017-11-12 20:57   ` Simon Marchi
2017-10-19 13:27 ` [PATCHv4 5/5] gdb: Don't store a thread-id for floating varobj Andrew Burgess
2017-11-12 21:00   ` Simon Marchi
2017-10-19 13:27 ` [PATCHv4 2/5] gdb: New API for tracking innermost block Andrew Burgess
2017-11-12 16:26   ` Simon Marchi
2017-10-19 13:27 ` [PATCHv4 3/5] gdb: PR mi/20395: Fix -var-update for registers in frames 1 and up Andrew Burgess
2017-11-12 20:49   ` Simon Marchi
2018-01-02 15:31 ` [PATCHv5 0/5] " Andrew Burgess
2018-01-20 21:34   ` [PATCHv6 3/5] gdb: PR mi/20395: " Andrew Burgess
2018-01-21  0:45     ` Pedro Alves
2018-01-20 21:34   ` [PATCHv6 2/5] gdb: New API for tracking innermost block Andrew Burgess
2018-01-20 21:34   ` [PATCHv6 5/5] gdb: Don't store a thread-id for floating varobj Andrew Burgess
2018-01-20 21:34   ` [PATCHv6 1/5] gdb: Remove duplicate declaration of global innermost_block Andrew Burgess
2018-01-20 21:34   ` [PATCHv6 4/5] gdb: Remove out of date comment Andrew Burgess
2018-01-20 21:34   ` [PATCHv6 0/5] Fix -var-update for registers in frames 1 and up Andrew Burgess
2018-01-02 15:32 ` [PATCHv5 2/5] gdb: New API for tracking innermost block Andrew Burgess
2018-01-02 15:32 ` [PATCHv5 1/5] gdb: Remove duplicate declaration of global innermost_block Andrew Burgess
2018-01-02 15:32 ` [PATCHv5 4/5] gdb: Remove out of date comment Andrew Burgess
2018-01-02 15:32 ` [PATCHv5 3/5] gdb: PR mi/20395: Fix -var-update for registers in frames 1 and up Andrew Burgess
2018-01-16 16:34   ` Pedro Alves
2018-01-02 15:32 ` [PATCHv5 5/5] gdb: Don't store a thread-id for floating varobj 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=cover.1508418720.git.andrew.burgess@embecosm.com \
    --to=andrew.burgess@embecosm.com \
    --cc=donb@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).