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

[Tom Tromey <tromey@redhat.com>]

>>>>> "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.

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.

Tom

diff --git a/gdb/ax-gdb.c b/gdb/ax-gdb.c
index 2908431..d1736e1 100644
--- a/gdb/ax-gdb.c
+++ b/gdb/ax-gdb.c
@@ -2044,14 +2044,13 @@ gen_expr (struct expression *exp, union exp_element **pc,
 
 	(*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;
       }