Last week: i686-pc-linux-gnu 'gdb.server' testsuite regressions (was: Failures on Fedora-x86_64-m32, branch master)

Last week: i686-pc-linux-gnu 'gdb.server' testsuite regressions (was: Failures on Fedora-x86_64-m32, branch master)

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 6170 bytes --]

Hi!

I'd like to highlight the following <gdb-testers@sourceware.org> report:

On Thu, 11 Apr 2019 00:50:50 -0400, sergiodj+buildbot@sergiodj.net wrote:
> Buildslave:
> 	fedora-x86-64-4
> 
> Full Build URL:
> 	<http://gdb-build.sergiodj.net/builders/Fedora-x86_64-m32/builds/12207>
> 
> Commit(s) tested:
> 	9d1447e09d4aa673826039321163b5a684e8e043
> 
> Author(s) (in the same order as the commits):
> 	Sergio Durigan Junior <sergiodj@redhat.com>
> 
> Subject:
> 	Destroy allocated values when exiting GDB
> 
> Testsuite log (gdb.sum and gdb.log) URL(s):
> 	<http://gdb-build.sergiodj.net/results/Fedora-x86_64-m32/9d/9d1447e09d4aa673826039321163b5a684e8e043/>
> 
> *** Diff to previous build ***
> ============================
> PASS -> FAIL: gdb.server/abspath.exp: continue to main
> PASS -> FAIL: gdb.server/connect-without-multi-process.exp: multiprocess=auto: continue to main
> PASS -> FAIL: gdb.server/connect-without-multi-process.exp: multiprocess=off: continue to main
> PASS -> FAIL: gdb.server/ext-run.exp: kill
> PASS -> UNRESOLVED: gdb.server/ext-run.exp: load new file without any gdbserver inferior
> PASS -> FAIL: gdb.server/ext-wrapper.exp: kill
> PASS -> FAIL: gdb.server/reconnect-ctrl-c.exp: first: stop with control-c
> PASS -> FAIL: gdb.server/server-kill.exp: continue to breakpoint: after server_pid assignment
> PASS -> FAIL: gdb.server/server-run.exp: continue to main
> PASS -> FAIL: gdb.server/solib-list.exp: non-stop 1: sharedlibrary
> PASS -> FAIL: gdb.server/stop-reply-no-thread.exp: continue to main
> PASS -> FAIL: gdb.server/wrapper.exp: continue to marker
> PASS -> KFAIL: gdb.threads/process-dies-while-handling-bp.exp: non_stop=on: cond_bp_target=1: inferior 1 exited
> ============================
> 
> 
> *** Complete list of XFAILs for this builder ***
> 
> To obtain the list of XFAIL tests for this builder, go to:
> 
> 	<https://git.sergiodj.net/gdb-xfails.git/tree/xfails/Fedora-x86_64-m32/xfails/master/xfail?id=1e97744b>
> 
> You can also see a pretty-printed version of the list, with more information
> about each XFAIL, by going to:
> 
> 	<https://git.sergiodj.net/gdb-xfails.git/tree/xfails/Fedora-x86_64-m32/xfails/master/xfail.table?id=1e97744b>

In
d970ee2bae1925bb9265d37adef0b92e2678d666..02e902e1a1ec7b74125f329b3faef1992efb6d51
(that is, basically, last week) I'm too seeing a good number of
'gdb.server' testsuite regressions in native i686-pc-linux-gnu testing:

    Running [...]/gdb/testsuite/gdb.server/abspath.exp ...
    {+FAIL: gdb.server/abspath.exp: continue to main+}
    Running [...]/gdb/testsuite/gdb.server/connect-stopped-target.exp ...
    Running [...]/gdb/testsuite/gdb.server/connect-with-no-symbol-file.exp ...
    Running [...]/gdb/testsuite/gdb.server/connect-without-multi-process.exp ...
    {+FAIL: gdb.server/connect-without-multi-process.exp: multiprocess=off: continue to main+}
    {+FAIL: gdb.server/connect-without-multi-process.exp: multiprocess=auto: continue to main+}
    Running [...]/gdb/testsuite/gdb.server/ext-attach.exp ...
    Running [...]/gdb/testsuite/gdb.server/ext-restart.exp ...
    {+FAIL: gdb.server/ext-restart.exp: run to main+}
    {+FAIL: gdb.server/ext-restart.exp: restart: run to main+}
    Running [...]/gdb/testsuite/gdb.server/ext-run.exp ...
    {+FAIL: gdb.server/ext-run.exp: continue to main+}
    Running [...]/gdb/testsuite/gdb.server/ext-wrapper.exp ...
    {+FAIL: gdb.server/ext-wrapper.exp: run to marker+}
    {+FAIL: gdb.server/ext-wrapper.exp: print d+}
    {+FAIL: gdb.server/ext-wrapper.exp: restart: run to marker+}
    {+FAIL: gdb.server/ext-wrapper.exp: restart: print d+}
    Running [...]/gdb/testsuite/gdb.server/extended-remote-restart.exp ...
    Running [...]/gdb/testsuite/gdb.server/file-transfer.exp ...
    Running [...]/gdb/testsuite/gdb.server/no-thread-db.exp ...
    {+FAIL: gdb.server/no-thread-db.exp: continue to breakpoint: after tls assignment+}
    Running [...]/gdb/testsuite/gdb.server/non-existing-program.exp ...
    Running [...]/gdb/testsuite/gdb.server/reconnect-ctrl-c.exp ...
    {+FAIL: gdb.server/reconnect-ctrl-c.exp: first: stop with control-c+}
    {+FAIL: gdb.server/reconnect-ctrl-c.exp: second: stop with control-c+}
    Running [...]/gdb/testsuite/gdb.server/run-without-local-binary.exp ...
    {+FAIL: gdb.server/run-without-local-binary.exp: run test program until the end+}
    Running [...]/gdb/testsuite/gdb.server/server-connect.exp ...
    Running [...]/gdb/testsuite/gdb.server/server-exec-info.exp ...
    Running [...]/gdb/testsuite/gdb.server/server-kill.exp ...
    {+FAIL: gdb.server/server-kill.exp: continue to breakpoint: after server_pid assignment+}
    {+FAIL: gdb.server/server-kill.exp: tstatus+}
    Running [...]/gdb/testsuite/gdb.server/server-mon.exp ...
    Running [...]/gdb/testsuite/gdb.server/server-run.exp ...
    {+FAIL: gdb.server/server-run.exp: continue to main+}
    Running [...]/gdb/testsuite/gdb.server/solib-list.exp ...
    {+FAIL: gdb.server/solib-list.exp: non-stop 0: continue+}
    {+FAIL: gdb.server/solib-list.exp: non-stop 0: p libvar+}
    {+FAIL: gdb.server/solib-list.exp: non-stop 1: continue+}
    {+FAIL: gdb.server/solib-list.exp: non-stop 1: p libvar+}
    Running [...]/gdb/testsuite/gdb.server/stop-reply-no-thread.exp ...
    {+FAIL: gdb.server/stop-reply-no-thread.exp: continue to main+}
    {+Running [...]/gdb/testsuite/gdb.server/sysroot.exp ...+}
    {+FAIL: gdb.server/sysroot.exp: sysroot=local: continue to main+}
    {+FAIL: gdb.server/sysroot.exp: sysroot=local: continue to printf+}
    {+FAIL: gdb.server/sysroot.exp: sysroot=remote: continue to main+}
    {+FAIL: gdb.server/sysroot.exp: sysroot=remote: continue to printf+}
    Running [...]/gdb/testsuite/gdb.server/unittest.exp ...
    Running [...]/gdb/testsuite/gdb.server/wrapper.exp ...
    {+FAIL: gdb.server/wrapper.exp: continue to marker+}
    {+FAIL: gdb.server/wrapper.exp: print d+}

These generally seem to be because the "Program received signal SIGSEGV,
Segmentation fault".  Not any further bisected, or analyzed.


Grüße
 Thomas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: Last week: i686-pc-linux-gnu 'gdb.server' testsuite regressions

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 5154 bytes --]

Hi!

On Tue, 16 Apr 2019 11:56:21 +0200, I wrote:
> I'd like to highlight the following <gdb-testers@sourceware.org> report:
> 
> On Thu, 11 Apr 2019 00:50:50 -0400, sergiodj+buildbot@sergiodj.net wrote:
> > Buildslave:
> > 	fedora-x86-64-4
> > 
> > Full Build URL:
> > 	<http://gdb-build.sergiodj.net/builders/Fedora-x86_64-m32/builds/12207>
> > 
> > Commit(s) tested:
> > 	9d1447e09d4aa673826039321163b5a684e8e043
> > 
> > Author(s) (in the same order as the commits):
> > 	Sergio Durigan Junior <sergiodj@redhat.com>
> > 
> > Subject:
> > 	Destroy allocated values when exiting GDB

This one doesn't seem to be related, in fact.

> In
> d970ee2bae1925bb9265d37adef0b92e2678d666..02e902e1a1ec7b74125f329b3faef1992efb6d51
> (that is, basically, last week) I'm too seeing a good number of
> 'gdb.server' testsuite regressions in native i686-pc-linux-gnu testing:

These i686-pc-linux-gnu gdbserver regressions are caused by the commit
3f52fdbcb599f76b4838020721ca6c9f1cc28f84 "Fix amd64->i386 linux syscall
restart problem" changes to 'gdb/gdbserver/linux-x86-low.c'.  (The
'gdb/amd64-linux-nat.c' changes are not relevant in this
i686-pc-linux-gnu configuration -- do they need to be replicated to the
corresponding i686 GDB file, or do the gdbserver changes need to be
conditionalized on something?)

For reference:

>     Running [...]/gdb/testsuite/gdb.server/abspath.exp ...
>     {+FAIL: gdb.server/abspath.exp: continue to main+}
>     Running [...]/gdb/testsuite/gdb.server/connect-stopped-target.exp ...
>     Running [...]/gdb/testsuite/gdb.server/connect-with-no-symbol-file.exp ...
>     Running [...]/gdb/testsuite/gdb.server/connect-without-multi-process.exp ...
>     {+FAIL: gdb.server/connect-without-multi-process.exp: multiprocess=off: continue to main+}
>     {+FAIL: gdb.server/connect-without-multi-process.exp: multiprocess=auto: continue to main+}
>     Running [...]/gdb/testsuite/gdb.server/ext-attach.exp ...
>     Running [...]/gdb/testsuite/gdb.server/ext-restart.exp ...
>     {+FAIL: gdb.server/ext-restart.exp: run to main+}
>     {+FAIL: gdb.server/ext-restart.exp: restart: run to main+}
>     Running [...]/gdb/testsuite/gdb.server/ext-run.exp ...
>     {+FAIL: gdb.server/ext-run.exp: continue to main+}
>     Running [...]/gdb/testsuite/gdb.server/ext-wrapper.exp ...
>     {+FAIL: gdb.server/ext-wrapper.exp: run to marker+}
>     {+FAIL: gdb.server/ext-wrapper.exp: print d+}
>     {+FAIL: gdb.server/ext-wrapper.exp: restart: run to marker+}
>     {+FAIL: gdb.server/ext-wrapper.exp: restart: print d+}
>     Running [...]/gdb/testsuite/gdb.server/extended-remote-restart.exp ...
>     Running [...]/gdb/testsuite/gdb.server/file-transfer.exp ...
>     Running [...]/gdb/testsuite/gdb.server/no-thread-db.exp ...
>     {+FAIL: gdb.server/no-thread-db.exp: continue to breakpoint: after tls assignment+}
>     Running [...]/gdb/testsuite/gdb.server/non-existing-program.exp ...
>     Running [...]/gdb/testsuite/gdb.server/reconnect-ctrl-c.exp ...
>     {+FAIL: gdb.server/reconnect-ctrl-c.exp: first: stop with control-c+}
>     {+FAIL: gdb.server/reconnect-ctrl-c.exp: second: stop with control-c+}
>     Running [...]/gdb/testsuite/gdb.server/run-without-local-binary.exp ...
>     {+FAIL: gdb.server/run-without-local-binary.exp: run test program until the end+}
>     Running [...]/gdb/testsuite/gdb.server/server-connect.exp ...
>     Running [...]/gdb/testsuite/gdb.server/server-exec-info.exp ...
>     Running [...]/gdb/testsuite/gdb.server/server-kill.exp ...
>     {+FAIL: gdb.server/server-kill.exp: continue to breakpoint: after server_pid assignment+}
>     {+FAIL: gdb.server/server-kill.exp: tstatus+}
>     Running [...]/gdb/testsuite/gdb.server/server-mon.exp ...
>     Running [...]/gdb/testsuite/gdb.server/server-run.exp ...
>     {+FAIL: gdb.server/server-run.exp: continue to main+}
>     Running [...]/gdb/testsuite/gdb.server/solib-list.exp ...
>     {+FAIL: gdb.server/solib-list.exp: non-stop 0: continue+}
>     {+FAIL: gdb.server/solib-list.exp: non-stop 0: p libvar+}
>     {+FAIL: gdb.server/solib-list.exp: non-stop 1: continue+}
>     {+FAIL: gdb.server/solib-list.exp: non-stop 1: p libvar+}
>     Running [...]/gdb/testsuite/gdb.server/stop-reply-no-thread.exp ...
>     {+FAIL: gdb.server/stop-reply-no-thread.exp: continue to main+}
>     {+Running [...]/gdb/testsuite/gdb.server/sysroot.exp ...+}
>     {+FAIL: gdb.server/sysroot.exp: sysroot=local: continue to main+}
>     {+FAIL: gdb.server/sysroot.exp: sysroot=local: continue to printf+}
>     {+FAIL: gdb.server/sysroot.exp: sysroot=remote: continue to main+}
>     {+FAIL: gdb.server/sysroot.exp: sysroot=remote: continue to printf+}
>     Running [...]/gdb/testsuite/gdb.server/unittest.exp ...
>     Running [...]/gdb/testsuite/gdb.server/wrapper.exp ...
>     {+FAIL: gdb.server/wrapper.exp: continue to marker+}
>     {+FAIL: gdb.server/wrapper.exp: print d+}
> 
> These generally seem to be because the "Program received signal SIGSEGV,
> Segmentation fault".  Not any further bisected, or analyzed.


Grüße
 Thomas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: Last week: i686-pc-linux-gnu 'gdb.server' testsuite regressions

[Kevin Buettner]

On Sat, 20 Apr 2019 11:30:38 +0200
Thomas Schwinge <thomas@codesourcery.com> wrote:

> > In
> > d970ee2bae1925bb9265d37adef0b92e2678d666..02e902e1a1ec7b74125f329b3faef1992efb6d51
> > (that is, basically, last week) I'm too seeing a good number of
> > 'gdb.server' testsuite regressions in native i686-pc-linux-gnu testing:  
> 
> These i686-pc-linux-gnu gdbserver regressions are caused by the commit
> 3f52fdbcb599f76b4838020721ca6c9f1cc28f84 "Fix amd64->i386 linux syscall
> restart problem" changes to 'gdb/gdbserver/linux-x86-low.c'.

I did a i686-pc-linux-gnu build (though still on a 64-bit host), but
was unable to reproduce these regressions.  Do I need to do the build
on a 32-bit host?

> (The
> 'gdb/amd64-linux-nat.c' changes are not relevant in this
> i686-pc-linux-gnu configuration -- do they need to be replicated to the
> corresponding i686 GDB file, or do the gdbserver changes need to be
> conditionalized on something?)

The gdb/amd64-linux-nat.c changes don't need to be propogated to the
i686 configuration.  That change - and the corresponding change to
gdbserver/linux-86-low.c - only affect 64-bit hosts that are trying
to debug 32-bit code.

I guess I could wrap the code that I added with a
#ifdef __x86_64__ ... #endif, but I'd like to be able to reproduce
the problem first.

Kevin

> For reference:
> 
> >     Running [...]/gdb/testsuite/gdb.server/abspath.exp ...
> >     {+FAIL: gdb.server/abspath.exp: continue to main+}
> >     Running [...]/gdb/testsuite/gdb.server/connect-stopped-target.exp ...
> >     Running [...]/gdb/testsuite/gdb.server/connect-with-no-symbol-file.exp ...
> >     Running [...]/gdb/testsuite/gdb.server/connect-without-multi-process.exp ...
> >     {+FAIL: gdb.server/connect-without-multi-process.exp: multiprocess=off: continue to main+}
> >     {+FAIL: gdb.server/connect-without-multi-process.exp: multiprocess=auto: continue to main+}
> >     Running [...]/gdb/testsuite/gdb.server/ext-attach.exp ...
> >     Running [...]/gdb/testsuite/gdb.server/ext-restart.exp ...
> >     {+FAIL: gdb.server/ext-restart.exp: run to main+}
> >     {+FAIL: gdb.server/ext-restart.exp: restart: run to main+}
> >     Running [...]/gdb/testsuite/gdb.server/ext-run.exp ...
> >     {+FAIL: gdb.server/ext-run.exp: continue to main+}
> >     Running [...]/gdb/testsuite/gdb.server/ext-wrapper.exp ...
> >     {+FAIL: gdb.server/ext-wrapper.exp: run to marker+}
> >     {+FAIL: gdb.server/ext-wrapper.exp: print d+}
> >     {+FAIL: gdb.server/ext-wrapper.exp: restart: run to marker+}
> >     {+FAIL: gdb.server/ext-wrapper.exp: restart: print d+}
> >     Running [...]/gdb/testsuite/gdb.server/extended-remote-restart.exp ...
> >     Running [...]/gdb/testsuite/gdb.server/file-transfer.exp ...
> >     Running [...]/gdb/testsuite/gdb.server/no-thread-db.exp ...
> >     {+FAIL: gdb.server/no-thread-db.exp: continue to breakpoint: after tls assignment+}
> >     Running [...]/gdb/testsuite/gdb.server/non-existing-program.exp ...
> >     Running [...]/gdb/testsuite/gdb.server/reconnect-ctrl-c.exp ...
> >     {+FAIL: gdb.server/reconnect-ctrl-c.exp: first: stop with control-c+}
> >     {+FAIL: gdb.server/reconnect-ctrl-c.exp: second: stop with control-c+}
> >     Running [...]/gdb/testsuite/gdb.server/run-without-local-binary.exp ...
> >     {+FAIL: gdb.server/run-without-local-binary.exp: run test program until the end+}
> >     Running [...]/gdb/testsuite/gdb.server/server-connect.exp ...
> >     Running [...]/gdb/testsuite/gdb.server/server-exec-info.exp ...
> >     Running [...]/gdb/testsuite/gdb.server/server-kill.exp ...
> >     {+FAIL: gdb.server/server-kill.exp: continue to breakpoint: after server_pid assignment+}
> >     {+FAIL: gdb.server/server-kill.exp: tstatus+}
> >     Running [...]/gdb/testsuite/gdb.server/server-mon.exp ...
> >     Running [...]/gdb/testsuite/gdb.server/server-run.exp ...
> >     {+FAIL: gdb.server/server-run.exp: continue to main+}
> >     Running [...]/gdb/testsuite/gdb.server/solib-list.exp ...
> >     {+FAIL: gdb.server/solib-list.exp: non-stop 0: continue+}
> >     {+FAIL: gdb.server/solib-list.exp: non-stop 0: p libvar+}
> >     {+FAIL: gdb.server/solib-list.exp: non-stop 1: continue+}
> >     {+FAIL: gdb.server/solib-list.exp: non-stop 1: p libvar+}
> >     Running [...]/gdb/testsuite/gdb.server/stop-reply-no-thread.exp ...
> >     {+FAIL: gdb.server/stop-reply-no-thread.exp: continue to main+}
> >     {+Running [...]/gdb/testsuite/gdb.server/sysroot.exp ...+}
> >     {+FAIL: gdb.server/sysroot.exp: sysroot=local: continue to main+}
> >     {+FAIL: gdb.server/sysroot.exp: sysroot=local: continue to printf+}
> >     {+FAIL: gdb.server/sysroot.exp: sysroot=remote: continue to main+}
> >     {+FAIL: gdb.server/sysroot.exp: sysroot=remote: continue to printf+}
> >     Running [...]/gdb/testsuite/gdb.server/unittest.exp ...
> >     Running [...]/gdb/testsuite/gdb.server/wrapper.exp ...
> >     {+FAIL: gdb.server/wrapper.exp: continue to marker+}
> >     {+FAIL: gdb.server/wrapper.exp: print d+}
> > 
> > These generally seem to be because the "Program received signal SIGSEGV,
> > Segmentation fault".  Not any further bisected, or analyzed.  

Re: Last week: i686-pc-linux-gnu 'gdb.server' testsuite regressions

[Kevin Buettner]

On Thu, 2 May 2019 19:59:29 -0700
Kevin Buettner <kevinb@redhat.com> wrote:

> On Sat, 20 Apr 2019 11:30:38 +0200
> Thomas Schwinge <thomas@codesourcery.com> wrote:
> 
> > > In
> > > d970ee2bae1925bb9265d37adef0b92e2678d666..02e902e1a1ec7b74125f329b3faef1992efb6d51
> > > (that is, basically, last week) I'm too seeing a good number of
> > > 'gdb.server' testsuite regressions in native i686-pc-linux-gnu testing:    
> > 
> > These i686-pc-linux-gnu gdbserver regressions are caused by the commit
> > 3f52fdbcb599f76b4838020721ca6c9f1cc28f84 "Fix amd64->i386 linux syscall
> > restart problem" changes to 'gdb/gdbserver/linux-x86-low.c'.  
> 
> I did a i686-pc-linux-gnu build (though still on a 64-bit host), but
> was unable to reproduce these regressions.  Do I need to do the build
> on a 32-bit host?

It seems that the answer is "yes".  Or maybe there's some additional
configuration that I needed to do when attempting to build on a 64-bit
host.

This is what I'm seeing in the log file for gdb.server/abspath.exp:

0xb7fd6130 in _start () from target:/lib/ld-linux.so.2
(gdb) break main
Breakpoint 1 at 0x8049169: file /ironwood1/sourceware-git/f30-i386-syscallrestart/bld/../../worktree-syscallrestart/gdb/testsuite/gdb.server/normal.c, line 23.
(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xb7fd6eaa in _dl_start () from target:/lib/ld-linux.so.2
(gdb) FAIL: gdb.server/abspath.exp: continue to main
Switching back to /mesquite2/sourceware-git/f30-i386-syscallrestart/bld/gdb/testsuite.
Remote debugging from host ::1, port 44692
monitor exit

Now that I've reproduced it, I'll try to figure out what's going on...

Kevin

Re: Last week: i686-pc-linux-gnu 'gdb.server' testsuite regressions

[Kevin Buettner]

On Thu, 2 May 2019 21:40:29 -0700
Kevin Buettner <kevinb@redhat.com> wrote:

> Program received signal SIGSEGV, Segmentation fault.
> 0xb7fd6eaa in _dl_start () from target:/lib/ld-linux.so.2
> (gdb) FAIL: gdb.server/abspath.exp: continue to main
> Switching back to /mesquite2/sourceware-git/f30-i386-syscallrestart/bld/gdb/testsuite.
> Remote debugging from host ::1, port 44692
> monitor exit
> 
> Now that I've reproduced it, I'll try to figure out what's going on...

It's here:

      *(int64_t *) ptr = *(int32_t *) ptr;

It's a mistake to attempt to sign extend a 32-bit value to 64-bits
when there's only a 32-bit container for that value.

I'm testing a patch which puts #ifdef __x86_64__ ... #endif
around the new code that I added.  I had thought that it was already
in one of these blocks, but it's not.

Thanks for the report and apologies for taking so long to get back
to you.  (Thanks to Sergio for pointing it out to me!)

Kevin

Re: Last week: i686-pc-linux-gnu 'gdb.server' testsuite regressions

[Kevin Buettner]

On Sat, 20 Apr 2019 11:30:38 +0200
Thomas Schwinge <thomas@codesourcery.com> wrote:

> > In
> > d970ee2bae1925bb9265d37adef0b92e2678d666..02e902e1a1ec7b74125f329b3faef1992efb6d51
> > (that is, basically, last week) I'm too seeing a good number of
> > 'gdb.server' testsuite regressions in native i686-pc-linux-gnu testing:  
> 
> These i686-pc-linux-gnu gdbserver regressions are caused by the commit
> 3f52fdbcb599f76b4838020721ca6c9f1cc28f84 "Fix amd64->i386 linux syscall
> restart problem" changes to 'gdb/gdbserver/linux-x86-low.c'.

This should be fixed now.  See:

https://www.sourceware.org/ml/gdb-patches/2019-05/msg00175.html

Thanks again for the report.

Kevin