[binutils-gdb] gdb: Guard against undefined behaviour in mi-vla-fortran.exp

[sergiodj+buildbot at redhat dot com]

*** TEST RESULTS FOR COMMIT 37a8db1a336ce78a46bf7f303e47e17b2a1bf694 ***

Author: Andrew Burgess <andrew.burgess@embecosm.com>
Branch: master
Commit: 37a8db1a336ce78a46bf7f303e47e17b2a1bf694

gdb: Guard against undefined behaviour in mi-vla-fortran.exp

The test gdb.mi/mi-vla-fortran.exp reveals an issue with the DWARF
generated by gfortran.

In the test a pointer variable 'pvla2' is created:
    real, pointer :: pvla2 (:, :)

Initially this variable will be unassociated, so something like this:
    l = associated(pvla2)

should return false.

In the test gdb stops at a point _before_ pvla2 is associated with
anything, and we then try to print pvla2, the expectation is that gdb
should reply <not associated>.

The problem is that the data the DWARF directs gdb to read (to identify
if the variable is associated or not) is not initialised until the first
time pvla2 is accessed.

As a result gdb ends up reading uninitialised memory, sometimes this
uninitialised memory indicates the variable is associated (when it's
not).  This first mistake can lead to a cascade of errors, reading
uninitialised memory, with the result that gdb builds an invalid type to
associate with the variable pvla2.

In some cases, this invalid type can be very large, which when we try to
print pvla2 causes gdb to allocate a large amount of memory.

A recent commit added a new gdb variable 'max-value-size', which
prevents gdb from allocating values of extreme size.  As a result
directly trying to print pvla2 will now now error rather than allocate a
large amount of memory.

However, some of the later tests create a varobj for pvla2, and then
ask for the children of that varobj to be displayed.  In the case where
an invalid type has been computed for pvla2 then the number of children
can be wrong, and very big, in which case trying to display all of these
children can cause gdb to consume an excessive amount of memory.

This commit first detects if printing pvla2 triggers the max-value-size
error, if it does then we avoid all the follow on tests relating to the
unassociated pvla2, which avoids the second error printing the varobj
children.

gdb/testsuite/ChangeLog:

	* gdb.mi/mi-vla-fortran.exp: Add XFAIL for accessing unassociated
	pointer.  Don't perform further tests on the unassociated pointer
	if the first test fails.