This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.  


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]