On openSUSE Tumbleweed with target board unix/-m32, I run into:
...
PASS: gdb.mi/mi-var-block.exp: step at do_block_test 2
Expecting: ^(-var-update \*[^M
]+)?(\^done,changelist=\[{name="foo",in_scope="true",type_changed="false",has_more="0"},
{name="cb",in_scope="true",type_changed="false",has_more="0"}\][^M
]+[(]gdb[)] ^M
[ ]*)
-var-update *^M
^done,changelist=[{name="foo",in_scope="true",type_changed="false",has_more="0"}]^M
(gdb) ^M
FAIL: gdb.mi/mi-var-block.exp: update all vars: cb foo changed (unexpected output)
...
The problem is that the test-case attempts to detect a change in the cb
variable caused by this initialization:
...
void
do_block_tests ()
{
int cb = 12;
...
but that only works if the stack location happens to be unequal to 12 before
the initialization.
Fix this by first initializing to 0, and then changing the value to 12:
...
- int cb = 12;
+ int cb = 0;
+ cb = 12;
...
and detecting that change.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29195
mi_runto do_block_tests
+# step to "cb = 12;"
+mi_step_to "do_block_tests" "" "var-cmd.c" \
+ [gdb_get_line_number "cb = 12;"] \
+ "step at do_block_test 0"
+
# Test: c_variable-3.2
# Desc: create cb and foo
mi_create_varobj "cb" "cb" "create local variable cb"
void
do_block_tests ()
{
- int cb = 12;
+ int cb = 0;
+ cb = 12;
{
int foo;