Re: [unavailable values part 1, 16/17] don't merge almost but not quite adjacent memory ranges to collect

[Pedro Alves <pedro@codesourcery.com>]

On Wednesday 16 February 2011 16:49:26, Tom Tromey wrote:
> >>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:
> 
> Pedro> While writting the test in the patch below I tripped
> Pedro> on an internal error:
> >> collect {int [4]}globalarr2
> Pedro>  ../../src/gdb/ax-gdb.c:2053: internal-error: gen_expr: OP_MEMVAL operand isn't an rvalue???
> Pedro>  A problem internal to GDB has been detected,
> Pedro>  further debugging may prove unreliable.
> Pedro> ... bah.
> 
> I think that code is just confused.  Even the comment says so :-)
> 
> Could you try the appended?  I'm not totally sure about it; maybe for
> the axs_lvalue_memory case we should be calling gen_address_of.

Thanks!  Looks, works and test fine.

We get the same ax, whether we take the
address of the address expression or not:

 (gdb) maintenance agent {int [4]} globalarr3 
 Scope: 0x40091d
 Reg mask: 00
   0  const32 6299952
   5  const8 16
   7  trace
   8  end
 (gdb) maintenance agent {int [4]} &globalarr3
 Scope: 0x40091d
 Reg mask: 00
   0  const32 6299952
   5  const8 16
   7  trace
   8  end

Which is the same behavior of printing:

 (gdb) p {int [4]} &globalarr3
 $1 = {3, 2, 1, 0}
 (gdb) p {int [4]} globalarr3 
 $2 = {3, 2, 1, 0}

The ax also looks fine with registers ax values:

 (gdb) maintenance agent {int [4]} $rip
 Scope: 0x40091d
 Reg mask: 00 00 01
   0  reg 16
   3  zero_ext 64
   5  const8 16
   7  trace
   8  end

> I can't really test it here, since newer versions of GCC confuse AX
> generation :-(.  That is, I get this a lot when running collection.exp:
> 
> DWARF operator DW_OP_call_frame_cfa cannot be translated to an agent expression

> 
> This seems pretty important to fix.

Bummer.  Yeah.

I've added a simple testcase.  I didn't try cooking up
a variant for the axs_lval_register path.

I also wrote a ChangeLog entry.  Shall I go ahead and
commit this?

-- 
Pedro Alves

2011-02-16  Tom Tromey  <tromey@redhat.com>

	gdb/
	* ax-gdb.c.c (gen_expr) <UNOP_MEMVAL>: Handle value kinds other
	than axs_rvalue.

2011-02-16  Pedro Alves  <pedro@codesourcery.com>

	gdb/testsuite/
	* collection.c (globalarr3): New global.
	(main): Initialize it before collecting, and and clear it
	afterwards.
	* collection.exp (gdb_collect_globals_test): Test collecting with
	'{type} addr', where the addr expression is not an rvalue.

---
 gdb/ax-gdb.c                           |   15 +++++++--------
 gdb/testsuite/gdb.trace/collection.c   |    6 ++++++
 gdb/testsuite/gdb.trace/collection.exp |   11 ++++++++++-
 3 files changed, 23 insertions(+), 9 deletions(-)

Index: src/gdb/ax-gdb.c
===================================================================
--- src.orig/gdb/ax-gdb.c	2011-01-13 15:07:17.386075004 +0000
+++ src/gdb/ax-gdb.c	2011-02-16 17:05:25.816002008 +0000
@@ -2044,14 +2044,13 @@ gen_expr (struct expression *exp, union
 
 	(*pc) += 3;
 	gen_expr (exp, pc, ax, value);
-	/* I'm not sure I understand UNOP_MEMVAL entirely.  I think
-	   it's just a hack for dealing with minsyms; you take some
-	   integer constant, pretend it's the address of an lvalue of
-	   the given type, and dereference it.  */
-	if (value->kind != axs_rvalue)
-	  /* This would be weird.  */
-	  internal_error (__FILE__, __LINE__,
-			  _("gen_expr: OP_MEMVAL operand isn't an rvalue???"));
+
+	/* If we have an axs_rvalue or an axs_lvalue_memory, then we
+	   already have the right value on the stack.  For
+	   axs_lvalue_register, we must convert.  */
+	if (value->kind == axs_lvalue_register)
+	  require_rvalue (ax, value);
+
 	value->type = type;
 	value->kind = axs_lvalue_memory;
       }
Index: src/gdb/testsuite/gdb.trace/collection.c
===================================================================
--- src.orig/gdb/testsuite/gdb.trace/collection.c	2011-02-16 12:49:02.000000000 +0000
+++ src/gdb/testsuite/gdb.trace/collection.c	2011-02-16 17:41:25.426002003 +0000
@@ -27,6 +27,7 @@ test_struct  globalstruct;
 test_struct *globalp;
 int          globalarr[16];
 int          globalarr2[4];
+int          globalarr3[4];
 
 struct global_pieces {
   unsigned int a;
@@ -241,6 +242,9 @@ main (argc, argv, envp)
   for (i = 0; i < 4; i++)
     globalarr2[i] = i;
 
+  for (i = 0; i < 4; i++)
+    globalarr3[3 - i] = i;
+
   mystruct.memberc = 101;
   mystruct.memberi = 102;
   mystruct.memberf = 103.3;
@@ -289,6 +293,8 @@ main (argc, argv, envp)
     globalarr[i] = 0;
   for (i = 0; i < 4; i++)
     globalarr2[i] = 0;
+  for (i = 0; i < 4; i++)
+    globalarr3[i] = 0;
 
   end ();
   return 0;
Index: src/gdb/testsuite/gdb.trace/collection.exp
===================================================================
--- src.orig/gdb/testsuite/gdb.trace/collection.exp	2011-02-16 12:49:02.000000000 +0000
+++ src/gdb/testsuite/gdb.trace/collection.exp	2011-02-16 17:49:45.276001996 +0000
@@ -479,7 +479,8 @@ proc gdb_collect_globals_test { } {
 	    "collect globalc, globali, globalf, globald" "^$" \
 	    "collect globalstruct, globalp, globalarr" "^$" \
 	    "collect \{int \[4\]\}$globalarr2_addr" "^$" \
-	    "collect \{int \[2\]\}$globalarr2_addr" "^$"
+	    "collect \{int \[2\]\}$globalarr2_addr" "^$" \
+	    "collect \{int \[4\]\}globalarr3" "^$"
 
     # Begin the test.
     run_trace_experiment "globals" globals_test_func
@@ -530,6 +531,14 @@ proc gdb_collect_globals_test { } {
 	"\\$\[0-9\]+ = \\{0, 1, 2, 3\\}$cr" \
 	"collect globals: collected global array 2"
 
+    # GDB would internal error collecting UNOP_MEMVAL's whose address
+    # expression wasn't an rvalue (that's regtested in the
+    # corresponding 'collect' action above).  This just double checks
+    # we actually did collect what we wanted.
+    gdb_test "print globalarr3" \
+	"\\$\[0-9\]+ = \\{3, 2, 1, 0\\}$cr" \
+	"collect globals: collected global array 3"
+
     gdb_test "tfind none" \
 	    "#0  end .*" \
 	    "collect globals: cease trace debugging"