Re: Last week: i686-pc-linux-gnu 'gdb.server' testsuite regressions
Kevin Buettner <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
On Sat, 20 Apr 2019 11:30:38 +0200 Thomas Schwinge <[email protected]> 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.