[PATCH 0/2] Fix two DWARF expression regressions

[PATCH 0/2] Fix two DWARF expression regressions

[Tom Tromey]

The recent changes to the DWARF expression evaluator caused a couple
of minor regressions with the AdaCore internal test suite.  (I think
these should also be visible with gdb's own test suite, when using a
suitable target, but I did not try this.)

These two patches fix the bugs.  Let me know what you think.

Tom

[PATCH 1/2] Fix Ada regression due to DWARF expression series

[Tom Tromey]

Commit 0579205aec4 ("Simplify dwarf_expr_context class interface")
caused a regression in the internal AdaCore test suite.  I didn't try
to reproduce this with the GDB test suite, but the test is identical
to gdb.dwarf2/dynarr-ptr.exp.

The problem is that this change:

 	case DW_OP_push_object_address:
 	  /* Return the address of the object we are currently observing.  */
-	  if (this->data_view.data () == nullptr
-	      && this->obj_address == 0)
+	  if (this->m_addr_info == nullptr)

... slightly changes the logic here.  In particular, it's possible for
the caller to pass in a non-NULL m_addr_info, but one that looks like:

    (top) p *this.m_addr_info
    $15 = {
      type = 0x29b7a70,
      valaddr = {
	m_array = 0x0,
	m_size = 0
      },
      addr = 0,
      next = 0x0
    }

In this case, an additional check is needed.  With the current code,
what happens instead is that the computation computes an incorrect
address -- but one that does not fail in read_memory, due to the
precise memory map of the embedded target in question.

This patch restores the old logic.
---
 gdb/dwarf2/expr.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gdb/dwarf2/expr.c b/gdb/dwarf2/expr.c
index cc1a72d7cd1..85088e9a07a 100644
--- a/gdb/dwarf2/expr.c
+++ b/gdb/dwarf2/expr.c
@@ -2338,7 +2338,9 @@ dwarf_expr_context::execute_stack_op (const gdb_byte *op_ptr,
 
 	case DW_OP_push_object_address:
 	  /* Return the address of the object we are currently observing.  */
-	  if (this->m_addr_info == nullptr)
+	  if (this->m_addr_info == nullptr
+	      || (this->m_addr_info->valaddr.data () == nullptr
+		  && this->m_addr_info->addr == 0))
 	    error (_("Location address is not set."));
 
 	  result_val
-- 
2.26.3

[PATCH 2/2] Fix register regression in DWARF evaluator

[Tom Tromey]

On an internal test case, using an arm-elf target, commit ba5bc3e5a92
("Make DWARF evaluator return a single struct value") causes a
regression.  (It doesn't happen for any of the other cross targets
that I test when importing upstream gdb.)

I don't know if there's an upstream gdb test case showing the same
problem... I can only really run native tests with dejagnu AFAIK.

The failure manifests like this:

    Breakpoint 1, file_1.export_1 (param_1=<error reading variable: Unable to access DWARF register number 64>, str=...) at [...]/file_1.adb:5

Whereas when it works it looks like:

    Breakpoint 1, file_1.export_1 (param_1=99.0, str=...) at [...]/file_1.adb:5

The difference is that the new code uses the passed-in gdbarch,
whereas the old code used the frame's gdbarch, when handling
DWARF_VALUE_REGISTER.

This patch restores the use of the frame's arch.
---
 gdb/dwarf2/expr.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gdb/dwarf2/expr.c b/gdb/dwarf2/expr.c
index 85088e9a07a..0e62de22aff 100644
--- a/gdb/dwarf2/expr.c
+++ b/gdb/dwarf2/expr.c
@@ -927,9 +927,11 @@ dwarf_expr_context::fetch_result (struct type *type, struct type *subobj_type,
 	{
 	case DWARF_VALUE_REGISTER:
 	  {
+	    gdbarch *f_arch = get_frame_arch (this->m_frame);
 	    int dwarf_regnum
 	      = longest_to_int (value_as_long (this->fetch (0)));
-	    int gdb_regnum = dwarf_reg_to_regnum_or_error (arch, dwarf_regnum);
+	    int gdb_regnum = dwarf_reg_to_regnum_or_error (f_arch,
+							   dwarf_regnum);
 
 	    if (subobj_offset != 0)
 	      error (_("cannot use offset on synthetic pointer to register"));
-- 
2.26.3