Certain earlier versions of GDB have (possibly distro) derived issues
when running against multiarch guests. Also given the problem of
clashing ports it is preferable to use socket comms rather than TCP
ports for testing.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 configure | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 11f5878a59..f6347382e9 100755
--- a/configure
+++ b/configure
@@ -6721,8 +6721,11 @@ if test "$plugins" = "yes" ; then
     fi
 fi
 
-if test -n "$gdb_bin" ; then
-    echo "HAVE_GDB_BIN=$gdb_bin" >> $config_host_mak
+if test -n "$gdb_bin"; then
+    gdb_version=$($gdb_bin --version | head -n 1)
+    if version_ge ${gdb_version##* } 8.3.1; then
+        echo "HAVE_GDB_BIN=$gdb_bin" >> $config_host_mak
+    fi
 fi
 
 if test "$secret_keyring" = "yes" ; then
-- 
2.20.1

On Mon, 14 Dec 2020 at 15:36, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> Certain earlier versions of GDB have (possibly distro) derived issues
> when running against multiarch guests. Also given the problem of
> clashing ports it is preferable to use socket comms rather than TCP
> ports for testing.

What's a "multiarch guest" ?

Incidentally I think the problem I have been running into
with the Ubuntu gdb 8.1 is that it doesn't support registers
larger than 64 bytes, and if AArch64 QEMU is emulating SVE
then it tries to expose registers bigger than that to the
gdbstub.

thanks
-- PMM

Peter Maydell <peter.maydell@linaro.org> writes:

> On Mon, 14 Dec 2020 at 15:36, Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>> Certain earlier versions of GDB have (possibly distro) derived issues
>> when running against multiarch guests. Also given the problem of
>> clashing ports it is preferable to use socket comms rather than TCP
>> ports for testing.
>
> What's a "multiarch guest" ?

I guess non-native guest would be another way of saying it. There is
some hoop jumping to deal with the fact that some arches package up a
fully featured multiarch aware gdb and some package up the multiarch one
as a separate gdb-multiarch package.

> Incidentally I think the problem I have been running into
> with the Ubuntu gdb 8.1 is that it doesn't support registers
> larger than 64 bytes, and if AArch64 QEMU is emulating SVE
> then it tries to expose registers bigger than that to the
> gdbstub.

So this is a missing patch from Ubuntu's gdb?

We could just peg the sha1 test to cortex-a57 - your are likely not
getting the SVE tests running unless you have the compilers to build
them (or using docker).

>
> thanks
> -- PMM


-- 
Alex Bennée

On Mon, 14 Dec 2020 at 17:08, Alex Bennée <alex.bennee@linaro.org> wrote:
>
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > On Mon, 14 Dec 2020 at 15:36, Alex Bennée <alex.bennee@linaro.org> wrote:
> >>
> >> Certain earlier versions of GDB have (possibly distro) derived issues
> >> when running against multiarch guests. Also given the problem of
> >> clashing ports it is preferable to use socket comms rather than TCP
> >> ports for testing.
> >
> > What's a "multiarch guest" ?
>
> I guess non-native guest would be another way of saying it. There is
> some hoop jumping to deal with the fact that some arches package up a
> fully featured multiarch aware gdb and some package up the multiarch one
> as a separate gdb-multiarch package.
>
> > Incidentally I think the problem I have been running into
> > with the Ubuntu gdb 8.1 is that it doesn't support registers
> > larger than 64 bytes, and if AArch64 QEMU is emulating SVE
> > then it tries to expose registers bigger than that to the
> > gdbstub.
>
> So this is a missing patch from Ubuntu's gdb?

No, upstream 8.1 doesn't handle this either and crashes too.
I'm a bit surprised we haven't had user complaints, since
gdb+QEMU would have previously worked and then started to
crash gdb when we put in the SVE registers.

> We could just peg the sha1 test to cortex-a57 - your are likely not
> getting the SVE tests running unless you have the compilers to build
> them (or using docker).

Yeah, forcing a non-SVE CPU should allow the test to work with this gdb.

thanks
-- PMM