This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [unavailable values part 1, 16/17] don't merge almost but not quite adjacent memory ranges to collect
>>>>> "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;
}