This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[PATCHv4 0/5] Fix -var-update for registers in frames 1 and up
- From: Andrew Burgess <andrew dot burgess at embecosm dot com>
- To: gdb-patches at sourceware dot org
- Cc: donb at codesourcery dot com, Andrew Burgess <andrew dot burgess at embecosm dot com>
- Date: Thu, 19 Oct 2017 14:27:04 +0100
- Subject: [PATCHv4 0/5] Fix -var-update for registers in frames 1 and up
- Authentication-results: sourceware.org; auth=none
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