gdb.ada/mi_var_access.exp

  GDB maintainers:

The following patch fixes two failures on PowerPC.  The test expects
the value of NUMCHILD to always be 1 but on PowerPC it is 2.  The other
issue is i the var-update test where there are additional values
printed that the test is not expecting.  The additional fields are
printed based on the value in VAROBJ_UPDATE_RESULT.TYPE_CHANGED.  On
PowerPC the value is true causing the additional fields to print.  On
X86-86 the field is false. 

The patch updates the test to accept a decimal for the value of
NUMCHILD and adds an alternate result string for the var-update test if
the additional fields are printed.

The patch has been tested on Power10 with no regression failures.  

Please let me know if this patch is acceptable for mainline.  Thnaks.

                             Carl 

------------------------------------------------

gdb.ada/mi_var_access.exp

The NUMCHILD value for the "A_String_Access" test differs for X86 and
PowerPC.  The patch substitutes $decimal instead of "1" to match the value
of NUMCHILD.

The test "-var-update A_String_Access" generates different output depending
on the value of VAROBJ_UPDATE_RESULT.TYPE_CHANGED.  If the value is true,
the strings "new_type" and "new_num_children" are printed along with their
values.

The VAROBJ_UPDATE_RESULT.TYPE_CHANGED value is true on PowerPC which
produces the output:

  Expecting: ^(-var-update A_String_Access[
  ]+)?(\^done,changelist=\[\{name="A_String_Access",in_scope="true",type_changed="false",has_more="0"\}\][
  ]+[(]gdb[)]
  [ ]*)
  -var-update A_String_Access
  ^done,changelist=[{name="A_String_Access",in_scope="true",type_changed="true",new_type="pck.string_access",new_num_children="1",has_more="0"}]
  (gdb)
  FAIL: gdb.ada/mi_var_access.exp: update at stop 2 (unexpected output)

The patch adds a second possible result string for the test
$re_varobj_update_result_type to match the case when type_changed is true.

Currently for the mi_var_access.exp test VAROBJ_UPDATE_RESULT.TYPE_CHANGED
is true on PowerPC and false on X86-64.

Fixes 2 failures on PowerPC.
---
 gdb/testsuite/gdb.ada/mi_var_access.exp | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)
  

>>>>> "Carl" == Carl Love via Gdb-patches <gdb-patches@sourceware.org> writes:

Carl> The following patch fixes two failures on PowerPC.  The test expects
Carl> the value of NUMCHILD to always be 1 but on PowerPC it is 2.

What is the extra child?
Seeing the MI output here might be informative.

Tom
  

Tom:
On Fri, 2023-08-11 at 09:38 -0600, Tom Tromey wrote:
> > > > > > "Carl" == Carl Love via Gdb-patches <
> > > > > > gdb-patches@sourceware.org> writes:
> 
> Carl> The following patch fixes two failures on PowerPC.  The test
> expects
> Carl> the value of NUMCHILD to always be 1 but on PowerPC it is 2.
> 
> What is the extra child?
> Seeing the MI output here might be informative.
> 
I see I have a typo above.  The test is expecting 1, but it is 0 on
PowerPC, not 2 as stated above.

(gdb) 
Expecting: ^(-var-create A_String_Access \* A_String_Access[^M
]+)?((\^done,name="A_String_Access",numchild="1",.*|\^error,msg="Value out of range.".*)[
]+[(]gdb[)] 
[ ]*)
-var-create A_String_Access * A_String_Access
^done,name="A_String_Access",numchild="0",value="0x0",type="pck.string_access",thread-id="1",has_more="0"
(gdb) 
FAIL: gdb.ada/mi_var_access.exp: Create varobj (unexpected output)


I have looked thru the log file for other places where numchild is
printed.  There is one other place which is after the second test
failure that the patch fixes.  In this case we get the expected value
of numchild:

(gdb) 
Expecting: ^(-var-update A_String_Access[
]+)?(\^done,changelist=\[\{name="A_String_Access",in_scope="true",type_changed="false",has_more="0"\}\][
]+[(]gdb[)] 
[ ]*)
-var-update A_String_Access
^done,changelist=[{name="A_String_Access",in_scope="true",type_changed="true",new_type="pck.string_access",new_num_children="1",has_more="0"}]
(gdb) 
FAIL: gdb.ada/mi_var_access.exp: update at stop 2 (unexpected output)

Expecting: ^(-var-list-children A_String_Access[]+)?(\^done,numchild="1",children=\[child=\{name="A_String_Access\.A_String_Access\.all",exp="A_String_Access\.all",numchild="3",type="array \(3 \.\. 5\) of character",thread-id="1"\}\],has_more="0"[
]+[(]gdb[)] 
[ ]*)
-var-list-children A_String_Access
^done,numchild="1",children=[child={name="A_String_Access.A_String_Access.all",exp="A_String_Access.all",numchild="3",type="array (3 .. 5) of character",thread-id="1"}],has_more="0"
(gdb) 
PASS: gdb.ada/mi_var_access.exp: list children at stop 2

In this case, the numchild value argrees with the expected output. 

                               Carl
  

>>>>> "Carl" == Carl Love <cel@us.ibm.com> writes:

Carl> I see I have a typo above.  The test is expecting 1, but it is 0 on
Carl> PowerPC, not 2 as stated above.

Carl> -var-create A_String_Access * A_String_Access
Carl> ^done,name="A_String_Access",numchild="0",value="0x0",type="pck.string_access",thread-id="1",has_more="0"

Ok, I see the problem.  The test is kind of bogus:

   A_String : String (3 .. 5) := "345"; -- STOP

... it stops at this line, but A_String may not be initialized here.

I think your patch is fine.
Approved-By: Tom Tromey <tom@tromey.com>

Tom