[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gdb
Subject:    Re: Last week: i686-pc-linux-gnu 'gdb.server' testsuite regressions
From:       Thomas Schwinge <thomas () codesourcery ! com>
Date:       2019-04-20 9:30:38
Message-ID: 87r29x6n29.fsf () euler ! schwinge ! homeip ! net
[Download RAW message or body]


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

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]