Re: [RFA v2 16/17] Convert dwarf_expr_context_funcs to methods

Pedro Alves
2016-10-28T13:36:07Z

On 10/20/2016 10:48 PM, Tom Tromey wrote:
> Pedro> Should we remove the parens throughout?
>
> Tom> I made this change.
>
> Here's the updated version of this patch.
> It also fixes some "CTX" comments.

Unfortunately, this caused regressions:

https://sourceware.org/ml/gdb-testers/2016-q4/msg01382.html

*** Diff to previous build ***
============================
PASS -> FAIL: gdb.arch/amd64-entry-value.exp: entry_reference: bt
PASS -> FAIL: gdb.arch/amd64-entry-value.exp: entry_reference: p regparam
PASS -> FAIL: gdb.arch/amd64-entry-value.exp: entry_reference: p regparam@entry
PASS -> FAIL: gdb.arch/amd64-entry-value.exp: entry_reference: p &regparam@entry
PASS -> FAIL: gdb.arch/amd64-entry-value.exp: tailcall: bt
PASS -> FAIL: gdb.arch/amd64-entry-value.exp: tailcall: p i
PASS -> FAIL: gdb.arch/amd64-entry-value.exp: tailcall: p i@entry
PASS -> FAIL: gdb.arch/amd64-entry-value.exp: tailcall: p j
PASS -> FAIL: gdb.arch/amd64-entry-value.exp: tailcall: p j@entry
PASS -> FAIL: gdb.arch/amd64-entry-value.exp: ambiguous: bt
PASS -> FAIL: gdb.arch/amd64-entry-value.exp: self: bt
PASS -> FAIL: gdb.arch/amd64-tailcall-noret.exp: bt
PASS -> FAIL: gdb.dwarf2/dw2-op-call.exp: p arraycallnoloc
PASS -> FAIL: gdb.dwarf2/typeddwarf.exp: check value of w at typeddwarf.c:29
PASS -> FAIL: gdb.dwarf2/typeddwarf.exp: check value of x at typeddwarf.c:29
PASS -> FAIL: gdb.dwarf2/typeddwarf.exp: check value of y at typeddwarf.c:29
PASS -> FAIL: gdb.dwarf2/typeddwarf.exp: check value of w at typeddwarf.c:53
PASS -> FAIL: gdb.dwarf2/typeddwarf.exp: check value of x at typeddwarf.c:53
PASS -> FAIL: gdb.dwarf2/typeddwarf.exp: check value of y at typeddwarf.c:53
============================

I've confirmed that going back to the commit before
192ca6d8eac4 ("Convert dwarf_expr_context_funcs to methods"),
the FAILs disappear.

Comparing before/after logs, I see:

~~~
-#0 reference (regparam=@0x7fffffffd344: 21, regparam@entry=@0x7fffffffd344: 1, nodataparam=@0x60202c: 22, r3=r3@entry=3, r4=r4@entry=4, r5=r5@entry=5, r6=r6@entry=6, stackparam1=@0x7fffffffd348: 31, stackparam2=@0x7fffffffd34c: 32) at gdb.arch/amd64-entry-value.cc:155
+#0 reference (regparam=@0x7fffffffcf14: 32767, regparam@entry=@0x7fffffffcf54: 1, nodataparam=@0x60202c: 22, r3=r3@entry=3, r4=r4@entry=4, r5=r5@entry=5, r6=r6@entry=6, stackparam1=@0x7fffffffcf58: 31, stackparam2=@0x7fffffffcf5c: 32) at gdb.arch/amd64-entry-value.cc:155
#1 0x00000000004005d0 in main () at gdb.arch/amd64-entry-value.cc:222
-(gdb) PASS: gdb.arch/amd64-entry-value.exp: entry_reference: bt
+(gdb) FAIL: gdb.arch/amd64-entry-value.exp: entry_reference: bt

-$14 = (int &) @0x7fffffffd344: 21
-(gdb) PASS: gdb.arch/amd64-entry-value.exp: entry_reference: p regparam
+$14 = (int &) @0x7fffffffcf14: 32767
+(gdb) FAIL: gdb.arch/amd64-entry-value.exp: entry_reference: p regparam
~~~

"32767" looks a lot like maybe some unitialized field in one of the classes.

~~~
-Breakpoint 2, d (i=71, i@entry=70, j=73.5, j@entry=72.5) at gdb.arch/amd64-entry-value.cc:34
+Breakpoint 2, d (i=<error reading variable: DWARF-2 expression error: Loop detected (257).>, j=<error reading variable: DWARF-2 expression error: Loop detected (257).>) at
~~~

Many instances of that loop error, actually.

~~~
-$26 = 1
-(gdb) PASS: gdb.dwarf2/typeddwarf.exp: check value of w at typeddwarf.c:53
+DW_OP_GNU_const_type has different sizes for type and data
+(gdb) FAIL: gdb.dwarf2/typeddwarf.exp: check value of w at typeddwarf.c:53
~~~

~~~
p arraycallnoloc
-Asked for position 0 of stack, stack only has 0 elements on it.
-(gdb) PASS: gdb.dwarf2/dw2-op-call.exp: p arraycallnoloc
-testcase /home/pedro/gdb/mygit/cxx-convertion/src/gdb/testsuite/gdb.dwarf2/dw2-op-call.exp completed in 1 seconds
+DW_OP_GNU_implicit_pointer is invalid in this context
+(gdb) FAIL: gdb.dwarf2/dw2-op-call.exp: p arraycallnoloc
+testcase /home/pedro/gdb/mygit/cxx-convertion/src/gdb/testsuite/gdb.dwarf2/dw2-op-call.exp completed in 0 seconds
~~~

Could you take a look? Maybe it'll be obvious to you what
the problem is.

Thanks,
Pedro Alves