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