public inbox for gdb-testers@sourceware.org
help / color / mirror / Atom feed
* Failures on AIX-POWER7-plain, branch gdb-7.10-branch
[not found] <7366dec04e7aa6cf4a0c962ce6cc2bc13a63e3ea@kwanyin>
@ 2015-07-06 22:21 ` sergiodj+buildbot
2015-07-07 1:41 ` Failures on Fedora-s390x-m64, " sergiodj+buildbot
1 sibling, 0 replies; 34+ messages in thread
From: sergiodj+buildbot @ 2015-07-06 22:21 UTC (permalink / raw)
To: gdb-testers
Buildslave:
aix-power7-1
Full Build URL:
<http://gdb-build.sergiodj.net/builders/AIX-POWER7-plain/builds/92>
Commit(s) tested:
7366dec04e7aa6cf4a0c962ce6cc2bc13a63e3ea
Author(s) (in the same order as the commits):
Joel Brobecker <brobecker@adacore.com>
Testsuite log (gdb.sum and gdb.log) URL(s):
<http://gdb-build.sergiodj.net/cgit/AIX-POWER7-plain/.git/tree/?h=gdb-7.10-branch&id=397c940493c4fc55ddad1f629c84aa107f18a41d>
*** Regressions found ***
============================
new FAIL: gdb.threads/print-threads.exp: all threads ran once (fast) (total 4 threads ran)
new FAIL: gdb.threads/print-threads.exp: all threads ran once (slow with kill breakpoint) (total 4 threads ran)
PASS -> FAIL: gdb.threads/signal-command-multiple-signals-pending.exp: schedlock off: stop with SIGUSR1
PASS -> FAIL: gdb.threads/signal-command-multiple-signals-pending.exp: schedlock off: stop with SIGUSR2
new FAIL: gdb.threads/signal-command-multiple-signals-pending.exp: schedlock on: second signal: signal command queries (the program exited)
PASS -> FAIL: gdb.threads/signal-while-stepping-over-bp-other-thread.exp: continue to breakpoint: run to breakpoint in thread 3
PASS -> FAIL: gdb.threads/signal-while-stepping-over-bp-other-thread.exp: stepped thread under control
PASS -> FAIL: gdb.threads/stepi-random-signal.exp: continue to breakpoint: after pthread_kill
PASS -> FAIL: gdb.threads/tls.exp: continue to synch point
PASS -> FAIL: gdb.threads/tls.exp: continue to third thread
PASS -> FAIL: gdb.threads/tls.exp: third thread print me
new FAIL: gdb.threads/tls.exp: threads exited (the program exited)
============================
*** Regressions against the baseline ***
============================
new FAIL: gdb.cp/var-tag.exp: before start: c++: print E2
new FAIL: gdb.cp/var-tag.exp: before start: c++: print S2
new FAIL: gdb.cp/var-tag.exp: before start: c++: print U2
new FAIL: gdb.cp/var-tag.exp: before start: c++: ptype C
new FAIL: gdb.cp/var-tag.exp: before start: c++: ptype E
new FAIL: gdb.cp/var-tag.exp: before start: c++: ptype E2
new FAIL: gdb.cp/var-tag.exp: before start: c++: ptype EE
new FAIL: gdb.cp/var-tag.exp: before start: c++: ptype S2
new FAIL: gdb.cp/var-tag.exp: before start: c++: ptype U2
new FAIL: gdb.cp/var-tag.exp: before start: c++: ptype cc
new FAIL: gdb.cp/var-tag.exp: before start: c++: ptype ee
new FAIL: gdb.cp/var-tag.exp: before start: c: print E2
new FAIL: gdb.cp/var-tag.exp: before start: c: print S2
new FAIL: gdb.cp/var-tag.exp: before start: c: print U2
new FAIL: gdb.cp/var-tag.exp: before start: c: ptype C
new FAIL: gdb.cp/var-tag.exp: before start: c: ptype E
new FAIL: gdb.cp/var-tag.exp: before start: c: ptype E2
new FAIL: gdb.cp/var-tag.exp: before start: c: ptype EE
new FAIL: gdb.cp/var-tag.exp: before start: c: ptype S2
new FAIL: gdb.cp/var-tag.exp: before start: c: ptype U2
new FAIL: gdb.cp/var-tag.exp: before start: c: ptype cc
new FAIL: gdb.cp/var-tag.exp: before start: c: ptype ee
new FAIL: gdb.cp/var-tag.exp: in C::f: c++: print E
new FAIL: gdb.cp/var-tag.exp: in C::f: c++: print E2
new FAIL: gdb.cp/var-tag.exp: in C::f: c++: print S
new FAIL: gdb.cp/var-tag.exp: in C::f: c++: print S2
new FAIL: gdb.cp/var-tag.exp: in C::f: c++: print U
new FAIL: gdb.cp/var-tag.exp: in C::f: c++: print U2
new FAIL: gdb.cp/var-tag.exp: in C::f: c++: ptype C
new FAIL: gdb.cp/var-tag.exp: in C::f: c++: ptype E
new FAIL: gdb.cp/var-tag.exp: in C::f: c++: ptype E2
new FAIL: gdb.cp/var-tag.exp: in C::f: c++: ptype EE
new FAIL: gdb.cp/var-tag.exp: in C::f: c++: ptype S2
new FAIL: gdb.cp/var-tag.exp: in C::f: c++: ptype U2
new FAIL: gdb.cp/var-tag.exp: in C::f: c++: ptype cc
new FAIL: gdb.cp/var-tag.exp: in C::f: c++: ptype ee
new FAIL: gdb.cp/var-tag.exp: in C::f: c: print E
new FAIL: gdb.cp/var-tag.exp: in C::f: c: print E2
new FAIL: gdb.cp/var-tag.exp: in C::f: c: print S
new FAIL: gdb.cp/var-tag.exp: in C::f: c: print S2
new FAIL: gdb.cp/var-tag.exp: in C::f: c: print U
new FAIL: gdb.cp/var-tag.exp: in C::f: c: print U2
new FAIL: gdb.cp/var-tag.exp: in C::f: c: ptype C
new FAIL: gdb.cp/var-tag.exp: in C::f: c: ptype E
new FAIL: gdb.cp/var-tag.exp: in C::f: c: ptype E2
new FAIL: gdb.cp/var-tag.exp: in C::f: c: ptype EE
new FAIL: gdb.cp/var-tag.exp: in C::f: c: ptype S2
new FAIL: gdb.cp/var-tag.exp: in C::f: c: ptype U2
new FAIL: gdb.cp/var-tag.exp: in C::f: c: ptype cc
new FAIL: gdb.cp/var-tag.exp: in C::f: c: ptype ee
new FAIL: gdb.cp/var-tag.exp: in main: c++: print E
new FAIL: gdb.cp/var-tag.exp: in main: c++: print E2
new FAIL: gdb.cp/var-tag.exp: in main: c++: print S
new FAIL: gdb.cp/var-tag.exp: in main: c++: print S2
new FAIL: gdb.cp/var-tag.exp: in main: c++: print U
new FAIL: gdb.cp/var-tag.exp: in main: c++: print U2
new FAIL: gdb.cp/var-tag.exp: in main: c++: ptype C
new FAIL: gdb.cp/var-tag.exp: in main: c++: ptype E
new FAIL: gdb.cp/var-tag.exp: in main: c++: ptype E2
new FAIL: gdb.cp/var-tag.exp: in main: c++: ptype EE
new FAIL: gdb.cp/var-tag.exp: in main: c++: ptype S2
new FAIL: gdb.cp/var-tag.exp: in main: c++: ptype U2
new FAIL: gdb.cp/var-tag.exp: in main: c++: ptype cc
new FAIL: gdb.cp/var-tag.exp: in main: c++: ptype ee
new FAIL: gdb.cp/var-tag.exp: in main: c: print E
new FAIL: gdb.cp/var-tag.exp: in main: c: print E2
new FAIL: gdb.cp/var-tag.exp: in main: c: print S
new FAIL: gdb.cp/var-tag.exp: in main: c: print S2
new FAIL: gdb.cp/var-tag.exp: in main: c: print U
new FAIL: gdb.cp/var-tag.exp: in main: c: print U2
new FAIL: gdb.cp/var-tag.exp: in main: c: ptype C
new FAIL: gdb.cp/var-tag.exp: in main: c: ptype E
new FAIL: gdb.cp/var-tag.exp: in main: c: ptype E2
new FAIL: gdb.cp/var-tag.exp: in main: c: ptype EE
new FAIL: gdb.cp/var-tag.exp: in main: c: ptype S2
new FAIL: gdb.cp/var-tag.exp: in main: c: ptype U2
new FAIL: gdb.cp/var-tag.exp: in main: c: ptype cc
new FAIL: gdb.cp/var-tag.exp: in main: c: ptype ee
PASS -> FAIL: gdb.threads/hand-call-new-thread.exp: iter 1: p new_thread ()
new FAIL: gdb.threads/print-threads.exp: all threads ran once (fast) (total 4 threads ran)
PASS -> FAIL: gdb.threads/signal-command-multiple-signals-pending.exp: schedlock off: stop with SIGUSR1
PASS -> FAIL: gdb.threads/signal-command-multiple-signals-pending.exp: schedlock off: stop with SIGUSR2
new FAIL: gdb.threads/signal-command-multiple-signals-pending.exp: schedlock on: second signal: signal command queries (the program exited)
PASS -> FAIL: gdb.threads/signal-while-stepping-over-bp-other-thread.exp: continue to breakpoint: run to breakpoint in thread 3
PASS -> FAIL: gdb.threads/signal-while-stepping-over-bp-other-thread.exp: stepped thread under control
PASS -> FAIL: gdb.threads/stepi-random-signal.exp: continue to breakpoint: after pthread_kill
new FAIL: gdb.threads/thread-unwindonsignal.exp: continue until exit (the program is no longer running)
PASS -> FAIL: gdb.threads/tls.exp: continue to synch point
PASS -> FAIL: gdb.threads/tls.exp: continue to third thread
PASS -> FAIL: gdb.threads/tls.exp: third thread print me
new FAIL: gdb.threads/tls.exp: threads exited (the program exited)
============================
^ permalink raw reply [flat|nested] 34+ messages in thread
* Failures on Fedora-s390x-m64, branch gdb-7.10-branch
[not found] <7366dec04e7aa6cf4a0c962ce6cc2bc13a63e3ea@kwanyin>
2015-07-06 22:21 ` Failures on AIX-POWER7-plain, branch gdb-7.10-branch sergiodj+buildbot
@ 2015-07-07 1:41 ` sergiodj+buildbot
1 sibling, 0 replies; 34+ messages in thread
From: sergiodj+buildbot @ 2015-07-07 1:41 UTC (permalink / raw)
To: gdb-testers
Buildslave:
marist-fedora-s390x
Full Build URL:
<http://gdb-build.sergiodj.net/builders/Fedora-s390x-m64/builds/921>
Commit(s) tested:
7366dec04e7aa6cf4a0c962ce6cc2bc13a63e3ea
Author(s) (in the same order as the commits):
Joel Brobecker <brobecker@adacore.com>
Testsuite log (gdb.sum and gdb.log) URL(s):
<http://gdb-build.sergiodj.net/cgit/Fedora-s390x-m64/.git/tree/?h=gdb-7.10-branch&id=3d90f516fa7cff2d0eec215ed79513cb740fe54b>
*** Regressions found ***
============================
new FAIL: gdb.threads/thread-specific-bp.exp: non-stop: continue to end (timeout)
============================
*** Regressions against the baseline ***
============================
PASS -> FAIL: gdb.asm/asm-source.exp: bt 2 in foo2
PASS -> FAIL: gdb.asm/asm-source.exp: bt 3 in foo3
PASS -> FAIL: gdb.asm/asm-source.exp: bt ALL in foo2
PASS -> FAIL: gdb.asm/asm-source.exp: f at main
PASS -> FAIL: gdb.asm/asm-source.exp: f in foo2
new FAIL: gdb.asm/asm-source.exp: finish from foo3 (the program is no longer running)
PASS -> FAIL: gdb.asm/asm-source.exp: info line
PASS -> FAIL: gdb.asm/asm-source.exp: info source asmsrc2.s
PASS -> FAIL: gdb.asm/asm-source.exp: n in foo2
new FAIL: gdb.asm/asm-source.exp: next over foo3 (the program is no longer running)
PASS -> FAIL: gdb.asm/asm-source.exp: next over macro
PASS -> FAIL: gdb.asm/asm-source.exp: return from foo2
PASS -> FAIL: gdb.asm/asm-source.exp: step into foo2
new FAIL: gdb.base/gnu_vector.exp: finish shows vector return value
new FAIL: gdb.base/gnu_vector.exp: verify vector return value (the program exited)
PASS -> FAIL: gdb.base/siginfo-thread.exp: Extract si_errno
new FAIL: gdb.threads/thread-specific-bp.exp: non-stop: continue to end (timeout)
PASS -> FAIL: gdb.trace/mi-traceframe-changed.exp: tfile: -trace-find frame-number 0
PASS -> FAIL: gdb.trace/mi-traceframe-changed.exp: tfile: tfind 0 again
============================
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Fix '-data-read-memory-bytes' typo/assertion
@ 2016-02-11 15:36 sergiodj+buildbot
2016-02-11 16:13 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2016-02-11 15:36 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT 718b36fead887693158396b948d7f409b987c053 ***
Author: Don Breazeal <donb@codesourcery.com>
Branch: gdb-7.10-branch
Commit: 718b36fead887693158396b948d7f409b987c053
Fix '-data-read-memory-bytes' typo/assertion
Backported to the 7.10 branch per this thread:
https://www.sourceware.org/ml/gdb-patches/2016-02/msg00134.html
This patch fixes a typo in target.c:read_memory_robust, where
it calls read_whatever_is_readable with the function arguments
in the wrong order. Depending on the address being read, it
can cause an xmalloc with a huge size, resulting in an assertion
failure, or just read something other than what was requested.
The problem only arises when GDB is handling an MI
"-data-read-memory-bytes" request and the initial target_read returns
an error status. Note that read_memory_robust is only called from
the MI code.
gdb/ChangeLog:
* gdb/target.c (read_memory_robust): Call
read_whatever_is_readable with arguments in the correct order.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Failures on Fedora-s390x-m64, branch gdb-7.10-branch
2016-02-11 15:36 [binutils-gdb/gdb-7.10-branch] Fix '-data-read-memory-bytes' typo/assertion sergiodj+buildbot
@ 2016-02-11 16:13 ` sergiodj+buildbot
0 siblings, 0 replies; 34+ messages in thread
From: sergiodj+buildbot @ 2016-02-11 16:13 UTC (permalink / raw)
To: gdb-testers
Buildslave:
marist-fedora-s390x
Full Build URL:
<http://gdb-build.sergiodj.net/builders/Fedora-s390x-m64/builds/2574>
Commit(s) tested:
718b36fead887693158396b948d7f409b987c053
Author(s) (in the same order as the commits):
Don Breazeal <donb@codesourcery.com>
Subject:
Fix '-data-read-memory-bytes' typo/assertion
Testsuite log (gdb.sum and gdb.log) URL(s):
<http://gdb-build.sergiodj.net/cgit/Fedora-s390x-m64/.git/tree/?h=gdb-7.10-branch&id=2f02b17ab48a7c07ba1746cad801b66e919a5e60>
*** Regressions found ***
============================
new FAIL: gdb.arch/s390-multiarch.exp: create core file (31)
PASS -> FAIL: gdb.base/stap-probe.exp: without semaphore, optimized: set multi-location probe breakpoint (probe two)
PASS -> FAIL: gdb.base/stap-probe.exp: with semaphore, optimized: set multi-location probe breakpoint (probe two)
new FAIL: gdb.cp/no-dmgl-verbose.exp: setting breakpoint at 'f(std::string)'
PASS -> FAIL: gdb.cp/var-tag.exp: before start: c++: ptype E
PASS -> FAIL: gdb.cp/var-tag.exp: before start: c++: ptype ee
PASS -> FAIL: gdb.cp/var-tag.exp: before start: c++: ptype EE
PASS -> FAIL: gdb.cp/var-tag.exp: before start: c++: ptype E2
PASS -> FAIL: gdb.cp/var-tag.exp: in main: c++: ptype E
PASS -> FAIL: gdb.cp/var-tag.exp: in main: c++: ptype ee
PASS -> FAIL: gdb.cp/var-tag.exp: in main: c++: ptype EE
PASS -> FAIL: gdb.cp/var-tag.exp: in main: c++: ptype E2
PASS -> FAIL: gdb.cp/var-tag.exp: in C::f: c++: ptype E
PASS -> FAIL: gdb.cp/var-tag.exp: in C::f: c++: ptype ee
PASS -> FAIL: gdb.cp/var-tag.exp: in C::f: c++: ptype EE
PASS -> FAIL: gdb.cp/var-tag.exp: in C::f: c++: ptype E2
new FAIL: gdb.cp/vla-cxx.exp: continue to breakpoint: vlas_filled (the program exited)
PASS -> FAIL: gdb.cp/vla-cxx.exp: print vla
PASS -> FAIL: gdb.cp/vla-cxx.exp: print vlaref
PASS -> FAIL: gdb.cp/vla-cxx.exp: print vlaref2
PASS -> FAIL: gdb.cp/vla-cxx.exp: print c
PASS -> FAIL: gdb.fortran/library-module.exp: print var_i in lib
PASS -> FAIL: gdb.fortran/library-module.exp: print var_i in main
PASS -> FAIL: gdb.opt/inline-bt.exp: continue to bar (1)
PASS -> FAIL: gdb.opt/inline-bt.exp: backtrace from bar (1)
PASS -> FAIL: gdb.opt/inline-bt.exp: continue to bar (2)
PASS -> FAIL: gdb.opt/inline-bt.exp: backtrace from bar (2)
PASS -> FAIL: gdb.opt/inline-bt.exp: continue to bar (3)
PASS -> FAIL: gdb.opt/inline-bt.exp: backtrace from bar (3)
PASS -> FAIL: gdb.opt/inline-cmds.exp: continue to bar (1)
PASS -> FAIL: gdb.opt/inline-cmds.exp: backtrace from bar (1)
PASS -> FAIL: gdb.opt/inline-cmds.exp: continue to bar (2)
PASS -> FAIL: gdb.opt/inline-cmds.exp: backtrace from bar (2)
PASS -> FAIL: gdb.opt/inline-cmds.exp: continue to marker
PASS -> FAIL: gdb.opt/inline-cmds.exp: backtrace from marker
PASS -> FAIL: gdb.opt/inline-cmds.exp: step into finish marker
PASS -> FAIL: gdb.opt/inline-locals.exp: continue to bar (1)
PASS -> FAIL: gdb.opt/inline-locals.exp: continue to bar (2)
PASS -> FAIL: gdb.opt/inline-locals.exp: backtrace from bar (2)
PASS -> FAIL: gdb.opt/inline-locals.exp: continue to bar (3)
PASS -> FAIL: gdb.opt/inline-locals.exp: backtrace from bar (3)
PASS -> FAIL: gdb.threads/watchthreads.exp: threaded watch loop
PASS -> FAIL: gdb.threads/watchthreads.exp: combination of threaded watchpoints = 30
============================
*** Regressions against the baseline ***
============================
new FAIL: gdb.arch/s390-multiarch.exp: create core file (31)
new FAIL: gdb.base/gnu_vector.exp: finish shows vector return value
new FAIL: gdb.base/gnu_vector.exp: verify vector return value (the program exited)
PASS -> FAIL: gdb.base/stap-probe.exp: without semaphore, optimized: set multi-location probe breakpoint (probe two)
PASS -> FAIL: gdb.base/stap-probe.exp: with semaphore, optimized: set multi-location probe breakpoint (probe two)
new FAIL: gdb.cp/no-dmgl-verbose.exp: setting breakpoint at 'f(std::string)'
PASS -> FAIL: gdb.cp/var-tag.exp: before start: c++: ptype E
PASS -> FAIL: gdb.cp/var-tag.exp: before start: c++: ptype ee
PASS -> FAIL: gdb.cp/var-tag.exp: before start: c++: ptype EE
PASS -> FAIL: gdb.cp/var-tag.exp: before start: c++: ptype E2
PASS -> FAIL: gdb.cp/var-tag.exp: in main: c++: ptype E
PASS -> FAIL: gdb.cp/var-tag.exp: in main: c++: ptype ee
PASS -> FAIL: gdb.cp/var-tag.exp: in main: c++: ptype EE
PASS -> FAIL: gdb.cp/var-tag.exp: in main: c++: ptype E2
PASS -> FAIL: gdb.cp/var-tag.exp: in C::f: c++: ptype E
PASS -> FAIL: gdb.cp/var-tag.exp: in C::f: c++: ptype ee
PASS -> FAIL: gdb.cp/var-tag.exp: in C::f: c++: ptype EE
PASS -> FAIL: gdb.cp/var-tag.exp: in C::f: c++: ptype E2
new FAIL: gdb.cp/vla-cxx.exp: continue to breakpoint: vlas_filled (the program exited)
PASS -> FAIL: gdb.cp/vla-cxx.exp: print vla
PASS -> FAIL: gdb.cp/vla-cxx.exp: print vlaref
PASS -> FAIL: gdb.cp/vla-cxx.exp: print vlaref2
PASS -> FAIL: gdb.cp/vla-cxx.exp: print c
PASS -> FAIL: gdb.fortran/library-module.exp: print var_i in lib
PASS -> FAIL: gdb.fortran/library-module.exp: print var_i in main
PASS -> FAIL: gdb.opt/inline-bt.exp: continue to bar (1)
PASS -> FAIL: gdb.opt/inline-bt.exp: backtrace from bar (1)
PASS -> FAIL: gdb.opt/inline-bt.exp: continue to bar (2)
PASS -> FAIL: gdb.opt/inline-bt.exp: backtrace from bar (2)
PASS -> FAIL: gdb.opt/inline-bt.exp: continue to bar (3)
PASS -> FAIL: gdb.opt/inline-bt.exp: backtrace from bar (3)
PASS -> FAIL: gdb.opt/inline-cmds.exp: continue to bar (1)
PASS -> FAIL: gdb.opt/inline-cmds.exp: backtrace from bar (1)
PASS -> FAIL: gdb.opt/inline-cmds.exp: continue to bar (2)
PASS -> FAIL: gdb.opt/inline-cmds.exp: backtrace from bar (2)
PASS -> FAIL: gdb.opt/inline-cmds.exp: continue to marker
PASS -> FAIL: gdb.opt/inline-cmds.exp: backtrace from marker
PASS -> FAIL: gdb.opt/inline-cmds.exp: step into finish marker
PASS -> FAIL: gdb.opt/inline-locals.exp: continue to bar (1)
PASS -> FAIL: gdb.opt/inline-locals.exp: continue to bar (2)
PASS -> FAIL: gdb.opt/inline-locals.exp: backtrace from bar (2)
PASS -> FAIL: gdb.opt/inline-locals.exp: continue to bar (3)
PASS -> FAIL: gdb.opt/inline-locals.exp: backtrace from bar (3)
PASS -> FAIL: gdb.threads/watchthreads.exp: threaded watch loop
PASS -> FAIL: gdb.threads/watchthreads.exp: combination of threaded watchpoints = 30
PASS -> FAIL: gdb.trace/mi-traceframe-changed.exp: tfile: tfind 0 again
PASS -> FAIL: gdb.trace/mi-traceframe-changed.exp: tfile: -trace-find frame-number 0
============================
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Bump GDB version number to 7.10.1.DATE-cvs.
@ 2015-12-05 15:56 sergiodj+buildbot
2015-12-05 17:32 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-12-05 15:56 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT 40dfe024f929c4d2e27c9e3ef1809751b4fc1c55 ***
Author: Joel Brobecker <brobecker@adacore.com>
Branch: gdb-7.10-branch
Commit: 40dfe024f929c4d2e27c9e3ef1809751b4fc1c55
Bump GDB version number to 7.10.1.DATE-cvs.
gdb/ChangeLog:
* version.in: Set GDB version number to 7.10.1.DATE-cvs.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Failures on Fedora-s390x-m64, branch gdb-7.10-branch
2015-12-05 15:56 [binutils-gdb/gdb-7.10-branch] Bump GDB version number to 7.10.1.DATE-cvs sergiodj+buildbot
@ 2015-12-05 17:32 ` sergiodj+buildbot
0 siblings, 0 replies; 34+ messages in thread
From: sergiodj+buildbot @ 2015-12-05 17:32 UTC (permalink / raw)
To: gdb-testers
Buildslave:
marist-fedora-s390x
Full Build URL:
<http://gdb-build.sergiodj.net/builders/Fedora-s390x-m64/builds/2134>
Commit(s) tested:
40dfe024f929c4d2e27c9e3ef1809751b4fc1c55
Author(s) (in the same order as the commits):
Joel Brobecker <brobecker@adacore.com>
Subject:
Bump GDB version number to 7.10.1.DATE-cvs.
Testsuite log (gdb.sum and gdb.log) URL(s):
<http://gdb-build.sergiodj.net/cgit/Fedora-s390x-m64/.git/tree/?h=gdb-7.10-branch&id=784c41f3fd1811295050ab3726530a6ebceaee3b>
*** Regressions found ***
============================
PASS -> FAIL: gdb.base/siginfo-obj.exp: Extract si_errno
new FAIL: gdb.threads/thread-specific-bp.exp: non-stop: continue to end (timeout)
new FAIL: gdb.threads/watchpoint-fork.exp: child: singlethreaded: breakpoint after the second fork (timeout)
============================
*** Regressions against the baseline ***
============================
new FAIL: gdb.base/gnu_vector.exp: finish shows vector return value
new FAIL: gdb.base/gnu_vector.exp: verify vector return value (the program exited)
PASS -> FAIL: gdb.base/siginfo-obj.exp: Extract si_errno
new FAIL: gdb.threads/thread-specific-bp.exp: non-stop: continue to end (timeout)
new FAIL: gdb.threads/watchpoint-fork.exp: child: singlethreaded: breakpoint after the second fork (timeout)
PASS -> FAIL: gdb.trace/mi-traceframe-changed.exp: tfile: tfind 0 again
PASS -> FAIL: gdb.trace/mi-traceframe-changed.exp: tfile: -trace-find frame-number 0
============================
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Set GDB version number to 7.10.1.
@ 2015-12-05 15:33 sergiodj+buildbot
2015-12-05 16:27 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-12-05 15:33 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT c2bb526a220f4d79f698fca33ba57fe1f81aba9f ***
Author: Joel Brobecker <brobecker@adacore.com>
Branch: gdb-7.10-branch
Commit: c2bb526a220f4d79f698fca33ba57fe1f81aba9f
Set GDB version number to 7.10.1.
gdb/ChangeLog:
* version.in: Set GDB version number to 7.10.1.
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Fix regression by Do not skip prologue for asm (.S) files
@ 2015-12-02 9:47 sergiodj+buildbot
2015-12-02 10:11 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-12-02 9:47 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT 87a8c81ef09b8f86844924c71b2d886b58991c60 ***
Author: Yao Qi <yao.qi@linaro.org>
Branch: gdb-7.10-branch
Commit: 87a8c81ef09b8f86844924c71b2d886b58991c60
Fix regression by Do not skip prologue for asm (.S) files
Patch "Do not skip prologue for asm (.S) files" [1] changes GDB's
behaviour on which test gdb.arch/thumb-singlestep.exp depends, so
it causes the fail below:
(gdb) si^M
37 blx foo^M
(gdb) FAIL: gdb.arch/thumb-singlestep.exp: step into foo
the test assumes the program will stop at the instruction after "push"
but it doesn't. The fix to this fail is to do one more single step.
[1] https://sourceware.org/ml/gdb-patches/2015-06/msg00561.html
gdb/testsuite:
2015-12-02 Yao Qi <yao.qi@linaro.org>
* gdb.arch/thumb-singlestep.exp: Do one more single step.
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Fix several crashes of C++ demangler on fuzzed input.
@ 2015-11-28 21:54 sergiodj+buildbot
2015-11-28 23:12 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-11-28 21:54 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT fde0a3e5490d784da5450aedceae764f014e54de ***
Author: Mikhail Maltsev <maltsevm@gmail.com>
Branch: gdb-7.10-branch
Commit: fde0a3e5490d784da5450aedceae764f014e54de
Fix several crashes of C++ demangler on fuzzed input.
libiberty/
* cp-demangle.c (d_dump): Fix syntax error.
(d_identifier): Adjust type of len to match d_source_name.
(d_expression_1): Fix out-of-bounds access. Check code variable for
NULL before dereferencing it.
(d_find_pack): Do not recurse for FIXED_TYPE, DEFAULT_ARG and NUMBER.
(d_print_comp_inner): Add NULL pointer check.
* cp-demangle.h (d_peek_next_char): Define as inline function when
CHECK_DEMANGLER is defined.
(d_advance): Likewise.
* testsuite/demangle-expected: Add new testcases.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@225727 138bc75d-0d04-0410-961f-82ee72b054a4
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Adjust GDB to demangler API change
@ 2015-11-28 21:16 sergiodj+buildbot
2015-11-29 1:43 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-11-28 21:16 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT 9a2752c7f09d24865b33fedd9ac2585f3cbba3c3 ***
Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.10-branch
Commit: 9a2752c7f09d24865b33fedd9ac2585f3cbba3c3
Adjust GDB to demangler API change
Before commit 3a8724032abf, DEMANGLE_COMPONENT_CAST was used for both
casts and conversion operators. We now have
DEMANGLE_COMPONENT_CONVERSION for the latter.
gdb/ChangeLog:
2014-11-28 Pedro Alves <palves@redhat.com>
* cp-name-parser.y (conversion_op): Use
DEMANGLE_COMPONENT_CONVERSION instead of DEMANGLE_COMPONENT_CAST.
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] PR other/61321 - demangler crash on casts in template parameters
@ 2015-11-28 20:37 sergiodj+buildbot
2015-11-29 0:37 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-11-28 20:37 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT 49037e4a1249890812a8d4995c7592774e99c399 ***
Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.10-branch
Commit: 49037e4a1249890812a8d4995c7592774e99c399
PR other/61321 - demangler crash on casts in template parameters
The fix for bug 59195:
[C++ demangler handles conversion operator incorrectly]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59195
unfortunately makes the demangler crash due to infinite recursion, in
case of casts in template parameters.
For example, with:
template<int> struct A {};
template <typename Y> void function_temp(A<sizeof ((Y)(999))>) {}
template void function_temp<int>(A<sizeof (int)>);
The 'function_temp<int>' instantiation above mangles to:
_Z13function_tempIiEv1AIXszcvT_Li999EEE
The demangler parses this as:
typed name
template
name 'function_temp'
template argument list
builtin type int
function type
builtin type void
argument list
template (*)
name 'A'
template argument list
unary operator
operator sizeof
unary operator
cast
template parameter 0 (**)
literal
builtin type int
name '999'
And after the fix for 59195, due to:
static void
d_print_cast (struct d_print_info *dpi, int options,
const struct demangle_component *dc)
{
...
/* For a cast operator, we need the template parameters from
the enclosing template in scope for processing the type. */
if (dpi->current_template != NULL)
{
dpt.next = dpi->templates;
dpi->templates = &dpt;
dpt.template_decl = dpi->current_template;
}
when printing the template argument list of A (what should be "<sizeof
(int)>"), the template parameter 0 (that is, "T_", the '**' above) now
refers to the first parameter of the the template argument list of the
'A' template (the '*' above), exactly what we were already trying to
print. This leads to infinite recursion, and stack exaustion. The
template parameter 0 should actually refer to the first parameter of
the 'function_temp' template.
Where it reads "for the cast operator" in the comment in d_print_cast
(above), it's really talking about a conversion operator, like:
struct A { template <typename U> explicit operator U(); };
We don't want to inject the template parameters from the enclosing
template in scope when processing a cast _expression_, only when
handling a conversion operator.
The problem is that DEMANGLE_COMPONENT_CAST is currently ambiguous,
and means _both_ 'conversion operator' and 'cast expression'.
Fix this by adding a new DEMANGLE_COMPONENT_CONVERSION component type,
which does what DEMANGLE_COMPONENT_CAST does today, and making
DEMANGLE_COMPONENT_CAST just simply print its component subtree.
I think we could instead reuse DEMANGLE_COMPONENT_CAST and in
d_print_comp_inner still do:
@@ -5001,9 +5013,9 @@ d_print_comp_inner (struct d_print_info *dpi, int options,
d_print_comp (dpi, options, dc->u.s_extended_operator.name);
return;
case DEMANGLE_COMPONENT_CAST:
d_append_string (dpi, "operator ");
- d_print_cast (dpi, options, dc);
+ d_print_conversion (dpi, options, dc);
return;
leaving the unary cast case below calling d_print_cast, but seems to
me that spliting the component types makes it easier to reason about
the code.
g++'s testsuite actually generates three symbols that crash the
demangler in the same way. I've added those as tests in the demangler
testsuite as well.
And then this fixes PR other/61233 too, which happens to be a
demangler crash originally reported to GDB, at:
https://sourceware.org/bugzilla/show_bug.cgi?id=16957
Bootstrapped and regtested on x86_64 Fedora 20.
Also ran this through GDB's testsuite. GDB will require a small
update to use DEMANGLE_COMPONENT_CONVERSION in one place it's using
DEMANGLE_COMPONENT_CAST in its sources.
libiberty/
2015-11-27 Pedro Alves <palves@redhat.com>
PR other/61321
PR other/61233
* demangle.h (enum demangle_component_type)
<DEMANGLE_COMPONENT_CONVERSION>: New value.
* cp-demangle.c (d_demangle_callback, d_make_comp): Handle
DEMANGLE_COMPONENT_CONVERSION.
(is_ctor_dtor_or_conversion): Handle DEMANGLE_COMPONENT_CONVERSION
instead of DEMANGLE_COMPONENT_CAST.
(d_operator_name): Return a DEMANGLE_COMPONENT_CONVERSION
component if handling a conversion.
(d_count_templates_scopes, d_print_comp_inner): Handle
DEMANGLE_COMPONENT_CONVERSION.
(d_print_comp_inner): Handle DEMANGLE_COMPONENT_CONVERSION instead
of DEMANGLE_COMPONENT_CAST.
(d_print_cast): Rename as ...
(d_print_conversion): ... this. Adjust comments.
(d_print_cast): Rewrite - simply print the left subcomponent.
* cp-demint.c (cplus_demangle_fill_component): Handle
DEMANGLE_COMPONENT_CONVERSION.
* testsuite/demangle-expected: Add tests.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@231020 138bc75d-0d04-0410-961f-82ee72b054a4
^ permalink raw reply [flat|nested] 34+ messages in thread
* Failures on Fedora-s390x-m64, branch gdb-7.10-branch
2015-11-28 20:37 [binutils-gdb/gdb-7.10-branch] PR other/61321 - demangler crash on casts in template parameters sergiodj+buildbot
@ 2015-11-29 0:37 ` sergiodj+buildbot
0 siblings, 0 replies; 34+ messages in thread
From: sergiodj+buildbot @ 2015-11-29 0:37 UTC (permalink / raw)
To: gdb-testers
Buildslave:
marist-fedora-s390x
Full Build URL:
<http://gdb-build.sergiodj.net/builders/Fedora-s390x-m64/builds/2087>
Commit(s) tested:
49037e4a1249890812a8d4995c7592774e99c399
Author(s) (in the same order as the commits):
Pedro Alves <palves@redhat.com>
Subject:
PR other/61321 - demangler crash on casts in template parameters
Testsuite log (gdb.sum and gdb.log) URL(s):
<http://gdb-build.sergiodj.net/cgit/Fedora-s390x-m64/.git/tree/?h=gdb-7.10-branch&id=073ce089420711299dab19a16feeb330f3b4e644>
*** Regressions found ***
============================
new FAIL: gdb.cp/cpexprs.exp: list base::operator char* (GDB internal error)
new FAIL: gdb.cp/cpexprs.exp: list base::operator fluff* (GDB internal error)
new FAIL: gdb.cp/cpexprs.exp: list base::operator fluff** (GDB internal error)
new FAIL: gdb.cp/cpexprs.exp: list base::operator int (GDB internal error)
new FAIL: gdb.cp/cpexprs.exp: setting breakpoint at base::operator char* (GDB internal error)
PASS -> FAIL: gdb.cp/cpexprs.exp: continue to base::operator char*
new FAIL: gdb.cp/cpexprs.exp: setting breakpoint at base::operator fluff* (GDB internal error)
PASS -> FAIL: gdb.cp/cpexprs.exp: continue to base::operator fluff*
new FAIL: gdb.cp/cpexprs.exp: setting breakpoint at base::operator fluff** (GDB internal error)
PASS -> FAIL: gdb.cp/cpexprs.exp: continue to base::operator fluff**
new FAIL: gdb.cp/cpexprs.exp: setting breakpoint at base::operator int (GDB internal error)
PASS -> FAIL: gdb.cp/cpexprs.exp: continue to base::operator int
new FAIL: gdb.cp/cplusfuncs.exp: list foo::operator int* (GDB internal error)
PASS -> FAIL: gdb.threads/watchthreads.exp: threaded watch loop
PASS -> FAIL: gdb.threads/watchthreads.exp: combination of threaded watchpoints = 30
============================
*** Regressions against the baseline ***
============================
new FAIL: gdb.base/gnu_vector.exp: finish shows vector return value
new FAIL: gdb.base/gnu_vector.exp: verify vector return value (the program exited)
new FAIL: gdb.cp/cpexprs.exp: list base::operator char* (GDB internal error)
new FAIL: gdb.cp/cpexprs.exp: list base::operator fluff* (GDB internal error)
new FAIL: gdb.cp/cpexprs.exp: list base::operator fluff** (GDB internal error)
new FAIL: gdb.cp/cpexprs.exp: list base::operator int (GDB internal error)
new FAIL: gdb.cp/cpexprs.exp: setting breakpoint at base::operator char* (GDB internal error)
PASS -> FAIL: gdb.cp/cpexprs.exp: continue to base::operator char*
new FAIL: gdb.cp/cpexprs.exp: setting breakpoint at base::operator fluff* (GDB internal error)
PASS -> FAIL: gdb.cp/cpexprs.exp: continue to base::operator fluff*
new FAIL: gdb.cp/cpexprs.exp: setting breakpoint at base::operator fluff** (GDB internal error)
PASS -> FAIL: gdb.cp/cpexprs.exp: continue to base::operator fluff**
new FAIL: gdb.cp/cpexprs.exp: setting breakpoint at base::operator int (GDB internal error)
PASS -> FAIL: gdb.cp/cpexprs.exp: continue to base::operator int
new FAIL: gdb.cp/cplusfuncs.exp: list foo::operator int* (GDB internal error)
PASS -> FAIL: gdb.threads/watchthreads.exp: threaded watch loop
PASS -> FAIL: gdb.threads/watchthreads.exp: combination of threaded watchpoints = 30
PASS -> FAIL: gdb.trace/mi-traceframe-changed.exp: tfile: tfind 0 again
PASS -> FAIL: gdb.trace/mi-traceframe-changed.exp: tfile: -trace-find frame-number 0
============================
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Implement N4514, C++ Extensions for Transactional Memory.
@ 2015-11-28 20:05 sergiodj+buildbot
2015-11-29 0:10 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-11-28 20:05 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT d65faac094af199ce4f9c8c0bbd062f668979431 ***
Author: Jason Merrill <jason@redhat.com>
Branch: gdb-7.10-branch
Commit: d65faac094af199ce4f9c8c0bbd062f668979431
Implement N4514, C++ Extensions for Transactional Memory.
gcc/
* builtins.def (BUILT_IN_ABORT): Add transaction_pure attribute.
gcc/c-family/
* c-common.c (c_common_reswords): Add C++ TM TS keywords.
(c_common_attribute_table): Add transaction_safe_dynamic.
transaction_safe now affects type identity.
(handle_tm_attribute): Handle transaction_safe_dynamic.
* c-common.h (enum rid): Add RID_ATOMIC_NOEXCEPT,
RID_ATOMIC_CANCEL, RID_SYNCHRONIZED.
(OBJC_IS_CXX_KEYWORD): Add RID_SYNCHRONIZED.
(D_TRANSMEM): New.
* c-cppbuiltin.c (c_cpp_builtins): Define __cpp_transactional_memory.
* c-pretty-print.c (pp_c_attributes_display): Don't print
transaction_safe in C++.
gcc/c/
* c-parser.c (c_lex_one_token): Handle @synchronized.
* c-decl.c (match_builtin_function_types): A declaration of a built-in
can change whether the function is transaction_safe.
gcc/cp/
* cp-tree.h (struct cp_declarator): Add tx_qualifier field.
(BCS_NORMAL, BCS_TRANSACTION): New enumerators.
* lex.c (init_reswords): Limit TM kewords to -fgnu-tm.
* parser.c (cp_lexer_get_preprocessor_token): Fix @synchronized.
(make_call_declarator): Take tx_qualifier.
(cp_parser_tx_qualifier_opt): New.
(cp_parser_lambda_declarator_opt): Use it.
(cp_parser_direct_declarator): Likewise.
(cp_parser_statement): Handle atomic_noexcept, atomic_cancel.
(cp_parser_compound_statement): Change in_try parameter to bcs_flags.
(cp_parser_std_attribute): Map optimize_for_synchronized to
transaction_callable.
(cp_parser_transaction): Take the token. Handle atomic_noexcept.
* lambda.c (maybe_add_lambda_conv_op): Handle transaction-safety.
* call.c (enum conversion_kind): Add ck_tsafe.
(standard_conversion): Handle transaction-safety conversion.
(convert_like_real, resolve_address_of_overloaded_function): Likewise.
(check_methods): Diagnose transaction_safe_dynamic on non-virtual
function.
(look_for_tm_attr_overrides): Don't inherit transaction_safe_dynamic.
* cvt.c (tx_safe_fn_type_p, tx_unsafe_fn_variant)
(can_convert_tx_safety): New.
* typeck.c (composite_pointer_type): Handle transaction-safety.
* name-lookup.h (enum scope_kind): Add sk_transaction.
* name-lookup.c (begin_scope): Handle it.
* semantics.c (begin_compound_stmt): Pass it.
* decl.c (check_previous_goto_1): Check it.
(struct named_label_entry): Add in_transaction_scope.
(poplevel_named_label_1): Set it.
(check_goto): Check it.
(duplicate_decls): A specialization can be transaction_safe
independently of its template.
(grokdeclarator): Handle tx-qualifier.
* rtti.c (ptr_initializer): Handle transaction-safe.
* search.c (check_final_overrider): Check transaction_safe_dynamic.
Don't check transaction_safe.
* mangle.c (write_function_type): Mangle transaction_safe here.
(write_CV_qualifiers_for_type): Not here.
(write_type): Preserve transaction_safe when stripping attributes.
* error.c (dump_type_suffix): Print transaction_safe.
libiberty/
* cp-demangle.c (d_cv_qualifiers): Dx means transaction_safe.
(cplus_demangle_type): Let d_cv_qualifiers handle it.
(d_dump, d_make_comp, has_return_type, d_encoding)
(d_count_templates_scopes, d_print_comp_inner)
(d_print_mod_list, d_print_mod, d_print_function_type)
(is_ctor_or_dtor): Handle DEMANGLE_COMPONENT_TRANSACTION_SAFE.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@228462 138bc75d-0d04-0410-961f-82ee72b054a4
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Demangler: Fix constructor names with ABI tags
@ 2015-11-28 19:19 sergiodj+buildbot
2015-11-28 23:54 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-11-28 19:19 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT 99eda040d8214d2d691ba804d6354c99b6df5269 ***
Author: Ian Lance Taylor <iant@google.com>
Branch: gdb-7.10-branch
Commit: 99eda040d8214d2d691ba804d6354c99b6df5269
Demangler: Fix constructor names with ABI tags
The symbol _ZNSt8ios_base7failureB5cxx11C1EPKcRKSt10error_code, which
appears in libstdc++, was being demangled as
std::ios_base::failure[abi:cxx11]::cxx11(char const*, std::error_code const&)
That is clearly incorrect: std::ios_base::failure does not have a
method cxx11, and anyhow if you look closely at the mangled name you
will see that it is supposed to be a constructor. This patch fixes
the demangler to generate the correct demangling, namely
std::ios_base::failure[abi:cxx11]::failure(char const*, std::error_code const&)
Bootstrapped and ran libiberty and libstdc++-v3 tests on
x86_64-unknown-linux-gnu.
2015-08-15 Ian Lance Taylor <iant@google.com>
* cp-demangle.c (d_abi_tags): Preserve di->last_name across any
ABI tags.
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] PR remote/18965: vforkdone stop reply should indicate parent PID
@ 2015-09-15 18:09 sergiodj+buildbot
2015-09-15 19:39 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-09-15 18:09 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT 487bf2f7066948fffd3447a3c6dd83389a037e2d ***
Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.10-branch
Commit: 487bf2f7066948fffd3447a3c6dd83389a037e2d
PR remote/18965: vforkdone stop reply should indicate parent PID
The vforkdone stop reply misses indicating the thread ID of the vfork
parent which the event relates to:
@cindex vfork events, remote reply
@item vfork
The packet indicates that @code{vfork} was called, and @var{r}
is the thread ID of the new child process. Refer to
@ref{thread-id syntax} for the format of the @var{thread-id}
field. This packet is only applicable to targets that support
vfork events.
@cindex vforkdone events, remote reply
@item vforkdone
The packet indicates that a child process created by a vfork
has either called @code{exec} or terminated, so that the
address spaces of the parent and child process are no longer
shared. The @var{r} part is ignored. This packet is only
applicable to targets that support vforkdone events.
Unfortunately, this is not just a documentation issue. GDBserver
is really not specifying the thread ID. I noticed because
in non-stop mode, gdb complains:
[Thread 6089.6089] #1 stopped.
#0 0x0000003615a011f0 in ?? ()
0x0000003615a011f0 in ?? ()
(gdb) set debug remote 1
(gdb) c
Continuing.
Sending packet: $QPassSignals:e;10;14;17;1a;1b;1c;21;24;25;2c;4c;#5f...Packet received: OK
Sending packet: $vCont;c:p17c9.17c9#88...Packet received: OK
Notification received: Stop:T05vfork:p17ce.17ce;06:40d7ffffff7f0000;07:30d7ffffff7f0000;10:e4c9eb1536000000;thread:p17c9.17c9;core:2;
Sending packet: $vStopped#55...Packet received: OK
Sending packet: $D;17ce#af...Packet received: OK
Sending packet: $vCont;c:p17c9.17c9#88...Packet received: OK
Notification received: Stop:T05vforkdone:;
No process or thread specified in stop reply: T05vforkdone:;
(gdb)
This is not non-stop-mode-specific, however. Consider e.g., that in
all-stop, you may be debugging more than one process at the same time.
You continue, and both processes vfork. So when you next get a
T05vforkdone, there's no way to tell which of the parent processes is
done with the vfork.
Tests will be added later.
Tested on x86_64 Fedora 20.
gdb/gdbserver/ChangeLog:
2015-09-15 Pedro Alves <palves@redhat.com>
PR remote/18965
* remote-utils.c (prepare_resume_reply): Merge
TARGET_WAITKIND_VFORK_DONE switch case with the
TARGET_WAITKIND_FORKED case.
gdb/doc/ChangeLog:
2015-09-15 Pedro Alves <palves@redhat.com>
PR remote/18965
* gdb.texinfo (Stop Reply Packets): Explain that vforkdone's 'r'
part indicates the thread ID of the parent process.
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Set GDB version number to 7.10.
@ 2015-08-28 21:58 sergiodj+buildbot
2015-08-28 22:15 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-08-28 21:58 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT 80f340df6a00d139b198f80923d4c9faac01b2fc ***
Author: Joel Brobecker <brobecker@adacore.com>
Branch: gdb-7.10-branch
Commit: 80f340df6a00d139b198f80923d4c9faac01b2fc
Set GDB version number to 7.10.
gdb/ChangeLog:
* version.in: Set GDB version number to 7.10.
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] gdb/NEWS: Rename "Changes since GDB 7.9" into "Changes in GDB 7.10"
@ 2015-08-28 21:40 sergiodj+buildbot
2015-08-28 21:50 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-08-28 21:40 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT 3c2ae1bb39c2c60a7b1cd5ce75c9816fab45cea4 ***
Author: Joel Brobecker <brobecker@adacore.com>
Branch: gdb-7.10-branch
Commit: 3c2ae1bb39c2c60a7b1cd5ce75c9816fab45cea4
gdb/NEWS: Rename "Changes since GDB 7.9" into "Changes in GDB 7.10"
This is in preparation for the GDB 7.10 release.
gdb/ChangeLog:
* NEWS: Rename "Changes since GDB 7.9" into "Changes in GDB 7.10".
^ permalink raw reply [flat|nested] 34+ messages in thread
* Failures on Fedora-s390x-m64, branch gdb-7.10-branch
2015-08-28 21:40 [binutils-gdb/gdb-7.10-branch] gdb/NEWS: Rename "Changes since GDB 7.9" into "Changes in GDB 7.10" sergiodj+buildbot
@ 2015-08-28 21:50 ` sergiodj+buildbot
0 siblings, 0 replies; 34+ messages in thread
From: sergiodj+buildbot @ 2015-08-28 21:50 UTC (permalink / raw)
To: gdb-testers
Buildslave:
marist-fedora-s390x
Full Build URL:
<http://gdb-build.sergiodj.net/builders/Fedora-s390x-m64/builds/1433>
Commit(s) tested:
3c2ae1bb39c2c60a7b1cd5ce75c9816fab45cea4
Author(s) (in the same order as the commits):
Joel Brobecker <brobecker@adacore.com>
Subject:
gdb/NEWS: Rename "Changes since GDB 7.9" into "Changes in GDB 7.10"
Testsuite log (gdb.sum and gdb.log) URL(s):
<http://gdb-build.sergiodj.net/cgit/Fedora-s390x-m64/.git/tree/?h=gdb-7.10-branch&id=3983d42bb5c2fb1ca46cac1f81643e80c6a42a69>
*** Regressions found ***
============================
new FAIL: gdb.threads/watchpoint-fork.exp: child: multithreaded: watchpoint A after the second fork (timeout)
PASS -> FAIL: gdb.threads/watchpoint-fork.exp: child: multithreaded: watchpoint B after the second fork
new FAIL: gdb.threads/watchpoint-fork.exp: child: multithreaded: finish (the program is no longer running)
============================
*** Regressions against the baseline ***
============================
new FAIL: gdb.base/gnu_vector.exp: finish shows vector return value
new FAIL: gdb.base/gnu_vector.exp: verify vector return value (the program exited)
PASS -> FAIL: gdb.base/siginfo-obj.exp: Extract si_errno
new FAIL: gdb.threads/watchpoint-fork.exp: child: multithreaded: watchpoint A after the second fork (timeout)
PASS -> FAIL: gdb.threads/watchpoint-fork.exp: child: multithreaded: watchpoint B after the second fork
new FAIL: gdb.threads/watchpoint-fork.exp: child: multithreaded: finish (the program is no longer running)
PASS -> FAIL: gdb.trace/mi-traceframe-changed.exp: tfile: tfind 0 again
PASS -> FAIL: gdb.trace/mi-traceframe-changed.exp: tfile: -trace-find frame-number 0
============================
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] remote: allow aborting long operations (e.g., file transfers)
@ 2015-08-25 18:44 sergiodj+buildbot
2015-08-25 18:44 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-08-25 18:44 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT 026ca0231ae6dcc107ec496ed677bd1b00474a2f ***
Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.10-branch
Commit: 026ca0231ae6dcc107ec496ed677bd1b00474a2f
remote: allow aborting long operations (e.g., file transfers)
Currently, when remote debugging, if you type Ctrl-C just while the
target stopped for an internal event, and GDB is busy doing something
that takes a while (e.g., fetching chunks of a shared library off of
the target, with vFile, to process ELF headers and debug info), the
Ctrl-C is lost.
The patch hooks up the QUIT macro to a new target method that lets the
target react to the double-Ctrl-C before the event loop is reached,
which allows reacting to a double-Ctrl-C even when GDB is busy doing
some long operation and not waiting for a stop reply. That end result
is:
(gdb) c
Continuing.
^C
^C
Interrupted while waiting for the program.
Give up waiting? (y or n) y
Quit
(gdb) info threads
Id Target Id Frame
* 1 Thread 11673 0x00007ffff7deb240 in _dl_debug_state () from target:/lib64/ld-linux-x86-64.so.2
(gdb)
If, however, GDB is waiting for a stop reply (because the target has
been resumed, with e.g., vCont;c), but the target isn't responding, we
now get:
(gdb) c
Continuing.
^C
^C
The target is not responding to interrupt requests.
Stop debugging it? (y or n) y
Disconnected from target.
(gdb) info threads
No threads.
This offers to disconnect, because when we're waiting for a stop
reply, there's nothing else we can send the target other than an
interrupt request. And if that doesn't work, there's nothing else we
can do.
The Ctrl-C is presently lost because until we get to a user-visible
stop, the SIGINT handler that is installed is the one that forwards
the interrupt to the remote side, with the \003 "packet" [1]. But,
gdbserver ignores an interrupt request if the program is stopped.
Still, even if it didn't, the server can only report back a
stop-because-of-SIGINT when the program is next resumed. And it may
take a while to actually re-resume the target.
[1] - In the old sync days, the remote target would react to a
double-Ctrl-C by asking users whether they wanted to give up waiting
and disconnect. The code is still there, but it it isn't reacheable
on most hosts, which support serial connections in async mode
(probably only DJGPP doesn't). Even then, in sync mode, remote.c's
SIGINT handler is only installed while the target is resumed, and is
removed as soon as the target sends back a stop reply. That means
that a Ctrl-C just while GDB is processing an internal event can end
up with an odd "Quit" at the prompt instead of "Program stopped by
SIGINT". In contrast, in async mode, remote.c's SIGINT handler is set
up as long as target_terminal_inferior or
target_terminal_ours_for_output are in effect (IOW, until we get a
user-visible stop and call target_terminal_ours), so the user
shouldn't get back a spurious Quit. However, it's still desirable to
be able to interrupt a long-running GDB operation, if GDB takes a
while to re-resume the target or get back to the event loop.
Tested on x86_64 Fedora 20.
gdb/ChangeLog:
2015-08-24 Pedro Alves <palves@redhat.com>
PR gdb/18804
* defs.h (maybe_quit): Declare.
(QUIT): Now calls maybe_quit.
* event-loop.c (clear_async_signal_handler)
(async_signal_handler_is_marked): New functions.
* event-loop.h (async_signal_handler_is_marked)
(clear_async_signal_handler): New declarations.
* remote.c (remote_check_pending_interrupt): New function.
(interrupt_query): Use make_cleanup_restore_target_terminal. No
longer check whether the target is async. If waiting for a stop
reply, and a Ctrl-C as been sent to the target, offer to
disconnect, and throw TARGET_CLOSE_ERROR instead of a quit.
Otherwise do not disconnect and throw a quit.
(_initialize_remote): Install remote_check_pending_interrupt as
to_check_pending_interrupt.
* target.c (target_check_pending_interrupt): New function.
* target.h (struct target_ops) <to_check_pending_interrupt>: New
field.
(target_check_pending_interrupt): New declaration.
* utils.c (maybe_quit): New function.
* target-delegates.c: Regenerate.
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] signal_command: Leftover cleanup chain regression
@ 2015-08-25 17:11 sergiodj+buildbot
2015-08-25 19:40 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-08-25 17:11 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT 3ba0344e56ef739808615be5ca319f82c2a83855 ***
Author: Jan Kratochvil <jan.kratochvil@redhat.com>
Branch: gdb-7.10-branch
Commit: 3ba0344e56ef739808615be5ca319f82c2a83855
signal_command: Leftover cleanup chain regression
gdb/ChangeLog
2015-08-04 Jan Kratochvil <jan.kratochvil@redhat.com>
* infcmd.c (signal_command): Call do_cleanups for args_chain.
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Make remote file transfers interruptible
@ 2015-08-21 18:24 sergiodj+buildbot
2015-08-21 21:56 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-08-21 18:24 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT ecc06bd425d6fcbb994b7b4d1d6f3c6f705e0784 ***
Author: Gary Benson <gbenson@redhat.com>
Branch: gdb-7.10-branch
Commit: ecc06bd425d6fcbb994b7b4d1d6f3c6f705e0784
Make remote file transfers interruptible
This commit makes it possible to interrupt remote file transfers.
gdb/ChangeLog:
* gdb_bfd.c (gdb_bfd_iovec_fileio_pread): Add QUIT call.
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Warn when accessing binaries from remote targets
@ 2015-08-21 17:54 sergiodj+buildbot
2015-08-21 21:32 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-08-21 17:54 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT 290f582b49a81b7fa01fc430bad1a7f9af21c922 ***
Author: Gary Benson <gbenson@redhat.com>
Branch: gdb-7.10-branch
Commit: 290f582b49a81b7fa01fc430bad1a7f9af21c922
Warn when accessing binaries from remote targets
GDB provides no indicator of progress during file operations, and can
appear to have locked up during slow remote transfers. This commit
updates GDB to print a warning each time a file is accessed over RSP.
An additional message detailing how to avoid remote transfers is
printed for the first transfer only.
gdb/ChangeLog:
* target.h (struct target_ops) <to_fileio_open>: New argument
warn_if_slow. Update comment. All implementations updated.
(target_fileio_open_warn_if_slow): New declaration.
* target.c (target_fileio_open): Renamed as...
(target_fileio_open_1): ...this. New argument warn_if_slow.
Pass warn_if_slow to implementation. Update debug printing.
(target_fileio_open): New function.
(target_fileio_open_warn_if_slow): Likewise.
* gdb_bfd.c (gdb_bfd_iovec_fileio_open): Use new function
target_fileio_open_warn_if_slow.
gdb/testsuite/ChangeLog:
* gdb.trace/pending.exp: Cope with remote transfer warnings.
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Prelimit number of bytes to read in "vFile:pread:"
@ 2015-08-19 13:35 sergiodj+buildbot
2015-08-19 13:59 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-08-19 13:35 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT 5e83dd6fb19ba25a89e321a0eb1373b3d3fc3930 ***
Author: Gary Benson <gbenson@redhat.com>
Branch: gdb-7.10-branch
Commit: 5e83dd6fb19ba25a89e321a0eb1373b3d3fc3930
Prelimit number of bytes to read in "vFile:pread:"
While handling "vFile:pread:" packets, gdbserver would read the
number of bytes requested regardless of whether this would fit
into the reply packet. gdbserver would then return a packet's
worth of data and discard the remainder. When accessing large
binaries GDB (via BFD) routinely makes large "vFile:pread:"
requests, resulting in gdbserver allocating large unnecessary
buffers and reading some portions of the file many times over.
This commit causes gdbserver to limit the number of bytes to be
read to a sensible maximum prior to allocating buffers and reading
data.
gdb/gdbserver/ChangeLog:
* hostio.c (handle_pread): Do not attempt to read more data
than hostio_reply_with_data can fit in a packet.
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] PR record/18691: Fix fails in solib-precsave.exp
@ 2015-08-18 14:03 sergiodj+buildbot
2015-08-18 15:27 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-08-18 14:03 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT 37419df723ec96b600030970e0fe97aaa82fa2e1 ***
Author: Yao Qi <yao.qi@linaro.org>
Branch: gdb-7.10-branch
Commit: 37419df723ec96b600030970e0fe97aaa82fa2e1
PR record/18691: Fix fails in solib-precsave.exp
We see the following regressions in testing on x86_64-linux,
reverse-step^M
Cannot access memory at address 0x2aaaaaed26c0^M
(gdb) FAIL: gdb.reverse/solib-precsave.exp: reverse-step into solib function one
when GDB reverse step into a function, GDB wants to skip prologue so
it requests TARGET_OBJECT_CODE_MEMORY to read some code memory in
memory_xfer_partial_1. However in dcache_read_memory_partial, the object
becomes TARGET_OBJECT_MEMORY
return ops->to_xfer_partial (ops, TARGET_OBJECT_MEMORY, NULL,
myaddr, NULL, memaddr, len,
xfered_len);
in reverse debugging, ops->to_xfer_partial is record_full_core_xfer_partial
and it will return TARGET_XFER_E_IO because it can't find any records.
The test fails.
At this moment, the delegate relationship is like
dcache -> record-core -> core -> exec
and we want to GDB read memory across targets, which means if the
requested memory isn't found in record-core, GDB can read memory from
core, and exec even further if needed. I find raw_memory_xfer_partial
is exactly what I want.
gdb:
2015-08-18 Yao Qi <yao.qi@linaro.org>
PR record/18691
* dcache.c (dcache_read_memory_partial): Call
raw_memory_xfer_partial.
* target.c (raw_memory_xfer_partial): Make it non-static.
* target.h (raw_memory_xfer_partial): Declare.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Failures on Fedora-s390x-m64, branch gdb-7.10-branch
2015-08-18 14:03 [binutils-gdb/gdb-7.10-branch] PR record/18691: Fix fails in solib-precsave.exp sergiodj+buildbot
@ 2015-08-18 15:27 ` sergiodj+buildbot
0 siblings, 0 replies; 34+ messages in thread
From: sergiodj+buildbot @ 2015-08-18 15:27 UTC (permalink / raw)
To: gdb-testers
Buildslave:
marist-fedora-s390x
Full Build URL:
<http://gdb-build.sergiodj.net/builders/Fedora-s390x-m64/builds/1327>
Commit(s) tested:
37419df723ec96b600030970e0fe97aaa82fa2e1
Author(s) (in the same order as the commits):
Yao Qi <yao.qi@linaro.org>
Subject:
PR record/18691: Fix fails in solib-precsave.exp
Testsuite log (gdb.sum and gdb.log) URL(s):
<http://gdb-build.sergiodj.net/cgit/Fedora-s390x-m64/.git/tree/?h=gdb-7.10-branch&id=bf7d833fc9f88f90f456dd90c08ee0256048e413>
*** Regressions found ***
============================
PASS -> FAIL: gdb.base/siginfo-thread.exp: Extract si_errno
new FAIL: gdb.threads/clone-new-thread-event.exp: catch SIGUSR1 (the program exited)
PASS -> FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: only inferior 1 left
PASS -> FAIL: gdb.threads/watchthreads.exp: threaded watch loop
PASS -> FAIL: gdb.threads/watchthreads.exp: combination of threaded watchpoints = 30
============================
*** Regressions against the baseline ***
============================
new FAIL: gdb.base/gnu_vector.exp: finish shows vector return value
new FAIL: gdb.base/gnu_vector.exp: verify vector return value (the program exited)
PASS -> FAIL: gdb.base/siginfo-thread.exp: Extract si_errno
new FAIL: gdb.threads/clone-new-thread-event.exp: catch SIGUSR1 (the program exited)
PASS -> FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: only inferior 1 left
PASS -> FAIL: gdb.threads/watchthreads.exp: threaded watch loop
PASS -> FAIL: gdb.threads/watchthreads.exp: combination of threaded watchpoints = 30
PASS -> FAIL: gdb.trace/mi-traceframe-changed.exp: tfile: tfind 0 again
PASS -> FAIL: gdb.trace/mi-traceframe-changed.exp: tfile: -trace-find frame-number 0
============================
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] [amd64] Invalid return address after displaced stepping
@ 2015-08-13 19:13 sergiodj+buildbot
2015-08-13 20:09 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-08-13 19:13 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT 475f4248decaaa6fcd6fbed0b47dd541db640c3f ***
Author: Joel Brobecker <brobecker@adacore.com>
Branch: gdb-7.10-branch
Commit: 475f4248decaaa6fcd6fbed0b47dd541db640c3f
[amd64] Invalid return address after displaced stepping
Making all-stop run on top of non-stop caused a small regression
in behavior. This was observed on x86_64-linux. The attached testcase
is in C whereas the investigation was done with an Ada program,
but it's the same scenario, and using a C testcase allows wider testing.
Basically: I am debugging a single-threaded program, and currently
stopped inside a function provided by a shared-library, at a line
calling a subprogram provided by a second shared library, and trying
to "next" over that function call.
Before we changed the default all-stop behavior, we had:
7 Impl_Initialize; -- Stop here and try "next" over this line
(gdb) n
8 return 5; <<-- OK
But now, "next" just stops much earlier:
(gdb) n
0x00007ffff7bd8560 in impl.initialize@plt () from /[...]/lib/libpck.so
What happens is that next stops at a call instruction, which calls
the function's PLT, and GDB fails to notice that the inferior stepped
into a subroutine, and so decides that we're done. We can see another
symptom of the same issue by looking at the backtrace at the point
GDB stopped:
(gdb) bt
#0 0x00007ffff7bd8560 in impl.initialize@plt ()
from /[...]/lib/libpck.so
#1 0x00000000f7bd86f9 in ?? ()
#2 0x00007fffffffdf50 in ?? ()
#3 0x0000000000401893 in a () at /[...]/a.adb:7
Backtrace stopped: frame did not save the PC
With a functioning GDB, the backtrace looks like the following instead:
#0 0x00007ffff7bd8560 in impl.initialize@plt ()
from /[...]/lib/libpck.so
#1 0x00007ffff7bd86f9 in sub () at /[...]/pck.adb:7
#2 0x0000000000401893 in a () at /[...]/a.adb:7
Note how, for frame #1, the address looks quite similar, except
for the high-order bits not being set:
#1 0x00007ffff7bd86f9 in sub () at /[...]/pck.adb:7 <<<-- OK
#1 0x00000000f7bd86f9 in ?? () <<<-- WRONG
^^^^
||||
Wrong
Investigating this further led me to displaced stepping.
As we are "next"-ing from a location where a breakpoint is inserted,
we need to step out of it, and since we're on non-stop mode, we need
to do it using displaced stepping. And looking at
amd64-tdep.c:amd64_displaced_step_fixup, I found the code that handles
the return address:
regcache_cooked_read_unsigned (regs, AMD64_RSP_REGNUM, &rsp);
retaddr = read_memory_unsigned_integer (rsp, retaddr_len, byte_order);
retaddr = (retaddr - insn_offset) & 0xffffffffUL;
The mask used to compute retaddr looks wrong to me, keeping only
4 bytes instead of 8, and explains why the high order bits of
the backtrace are unset. What happens is that, after the displaced
stepping has completed, GDB restores that return address at the location
where the program expects it. But because the top half bits of
the address have been masked out, the return address is now invalid.
The incorrect behavior of the "next" command and the backtrace at
that location are the first symptoms of that. Another symptom is
that this actually alters the behavior of the program, where a "cont"
from there soon leads to a SEGV when the inferior tries to jump back
to that incorrect return address:
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x00000000f7bd86f9 in ?? ()
^^^^^^^^^^^^^^^^^^
This patch fixes the issue by using a mask that seems more appropriate
for this architecture.
gdb/ChangeLog:
* amd64-tdep.c (amd64_displaced_step_fixup): Fix the mask used to
compute RETADDR.
gdb/testsuite/ChangeLog:
* gdb.base/dso2dso-dso2.c, gdb.base/dso2dso-dso2.h,
gdb.base/dso2dso-dso1.c, gdb.base/dso2dso-dso1.h, gdb.base/dso2dso.c,
gdb.base/dso2dso.exp: New files.
Tested on x86_64-linux, no regression.
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] [regression] Do not read from catchpoint/watchpoint locations' addresses when checking for a permanent breakpoint
@ 2015-08-12 9:20 sergiodj+buildbot
2015-08-12 13:10 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-08-12 9:20 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT 835001623351330d49678d215d1338c0ce35c1f9 ***
Author: Luis Machado <lgustavo@codesourcery.com>
Branch: gdb-7.10-branch
Commit: 835001623351330d49678d215d1338c0ce35c1f9
[regression] Do not read from catchpoint/watchpoint locations' addresses when checking for a permanent breakpoint
While running bare-metal tests with GDB i noticed some failures in
gdb.base/break.exp, related to the use of the catch commands.
It turns out GDB tries to access memory address 0x0 whenever one tries
to insert a catchpoint, which should obviously not happen.
This was introduced with the changes for permanent breakpoints. In special,
bp_loc_is_permanent tries to check if there is a breakpoint inserted at
the same address as the current breakpoint's location's address. In the
case of catchpoints, this is 0x0.
(top-gdb) catch fork
Sending packet: $m0,1#fa...Packet received: E01
Catchpoint 4 (fork)
(top-gdb) catch vfork
Sending packet: $m0,1#fa...Packet received: E01
Catchpoint 5 (vfork)
It is not obvious to detect because this fails silently for Linux. For our
bare-metal testing, though, this fails with a clear error message from the
target about not being able to read such address.
The attached patch addresses this by bailing out of bp_loc_is_permanent (...)
if the location address is not meaningful. I also took the opportunity to
update the comment for breakpoint_address_is_meaningful, which mentioned
breakpoint addresses as opposed to their locations' addresses.
gdb/ChangeLog:
2015-08-11 Luis Machado <lgustavo@codesourcery.com>
* breakpoint.c (bp_loc_is_permanent): Return 0 when breakpoint
location address is not meaningful.
(breakpoint_address_is_meaningful): Update comment.
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] PR python/17136
@ 2015-08-06 17:47 sergiodj+buildbot
2015-08-06 18:39 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-08-06 17:47 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT 17d1595ac5371d06537bc57df86a9f7359e62127 ***
Author: Clem Dickey <clemd@acm.org>
Branch: gdb-7.10-branch
Commit: 17d1595ac5371d06537bc57df86a9f7359e62127
PR python/17136
gdb/ChangeLog:
* python/lib/gdb/command/type_printers.py (InfoTypePrinter): Fix typo.
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] gdbserver: Fix non-stop / fork / step-over issues
@ 2015-08-06 12:22 sergiodj+buildbot
2015-08-06 12:40 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-08-06 12:22 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT 3a3f16c0cf0fa5a555a688e119bb8b363a2e7d59 ***
Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.10-branch
Commit: 3a3f16c0cf0fa5a555a688e119bb8b363a2e7d59
gdbserver: Fix non-stop / fork / step-over issues
Ref: https://sourceware.org/ml/gdb-patches/2015-07/msg00868.html
This adds a test that has a multithreaded program have several threads
continuously fork, while another thread continuously steps over a
breakpoint.
This exposes several intertwined issues, which this patch addresses:
- When we're stopping and suspending threads, some thread may fork,
and we missed setting its suspend count to 1, like we do when a new
clone/thread is detected. When we next unsuspend threads, the fork
child's suspend count goes below 0, which is bogus and fails an
assertion.
- If a step-over is cancelled because a signal arrives, but then gdb
is not interested in the signal, we pass the signal straight back
to the inferior. However, we miss that we need to re-increment the
suspend counts of all other threads that had been paused for the
step-over. As a result, other threads indefinitely end up stuck
stopped.
- If a detach request comes in just while gdbserver is handling a
step-over (in the test at hand, this is GDB detaching the fork
child), gdbserver internal errors in stabilize_thread's helpers,
which assert that all thread's suspend counts are 0 (otherwise we
wouldn't be able to move threads out of the jump pads). The
suspend counts aren't 0 while a step-over is in progress, because
all threads but the one stepping past the breakpoint must remain
paused until the step-over finishes and the breakpoint can be
reinserted.
- Occasionally, we see "BAD - reinserting but not stepping." being
output (from within linux_resume_one_lwp_throw). That was because
GDB pokes memory while gdbserver is busy with a step-over, and that
suspends threads, and then re-resumes them with proceed_one_lwp,
which missed another reason to tell linux_resume_one_lwp that the
thread should be set back to stepping.
- In a couple places, we were resuming threads that are meant to be
suspended. E.g., when a vCont;c/s request for thread B comes in
just while gdbserver is stepping thread A past a breakpoint. The
resume for thread B must be deferred until the step-over finishes.
- The test runs with both "set detach-on-fork" on and off. When off,
it exercises the case of GDB detaching the fork child explicitly.
When on, it exercises the case of gdb resuming the child
explicitly. In the "off" case, gdb seems to exponentially become
slower as new inferiors are created. This is _very_ noticeable as
with only 100 inferiors gdb is crawling already, which makes the
test take quite a bit to run. For that reason, I've disabled the
"off" variant for now.
gdb/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* target/waitstatus.h (enum target_stop_reason)
<TARGET_STOPPED_BY_SINGLE_STEP>: New value.
gdb/gdbserver/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* linux-low.c (handle_extended_wait): Set the fork child's suspend
count if stopping and suspending threads.
(check_stopped_by_breakpoint): If stopped by trace, set the LWP's
stop reason to TARGET_STOPPED_BY_SINGLE_STEP.
(linux_detach): Complete an ongoing step-over.
(lwp_suspended_inc, lwp_suspended_decr): New functions. Use
throughout.
(resume_stopped_resumed_lwps): Don't resume a suspended thread.
(linux_wait_1): If passing a signal to the inferior after
finishing a step-over, unsuspend and re-resume all lwps. If we
see a single-step event but the thread should be continuing, don't
pass the trap to gdb.
(stuck_in_jump_pad_callback, move_out_of_jump_pad_callback): Use
internal_error instead of gdb_assert.
(enqueue_pending_signal): New function.
(check_ptrace_stopped_lwp_gone): Add debug output.
(start_step_over): Use internal_error instead of gdb_assert.
(complete_ongoing_step_over): New function.
(linux_resume_one_thread): Don't resume a suspended thread.
(proceed_one_lwp): If the LWP is stepping over a breakpoint, reset
it stepping.
gdb/testsuite/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* gdb.threads/forking-threads-plus-breakpoint.exp: New file.
* gdb.threads/forking-threads-plus-breakpoint.c: New file.
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Linux gdbserver confused when event randomization picks process exit event
@ 2015-08-06 11:58 sergiodj+buildbot
2015-08-06 12:13 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-08-06 11:58 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT 91da80b56eb52209fb8b366aca9519eb6e488397 ***
Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.10-branch
Commit: 91da80b56eb52209fb8b366aca9519eb6e488397
Linux gdbserver confused when event randomization picks process exit event
The tail end of linux_wait_1 isn't expecting that the select_event_lwp
machinery can pick a whole-process exit event to report to GDB. When
that happens, both gdb and gdbserver end up quite confused:
...
(gdb)
[Thread 24971.24971] #1 stopped.
0x0000003615a011f0 in ?? ()
c&
Continuing.
(gdb) [New Thread 24971.24981]
[New Thread 24983.24983]
[New Thread 24971.24982]
[Thread 24983.24983] #3 stopped.
0x0000003615ebc7cc in __libc_fork () at ../nptl/sysdeps/unix/sysv/linux/fork.c:130
130 pid = ARCH_FORK ();
[New Thread 24984.24984]
Error in re-setting breakpoint -16: PC register is not available
Error in re-setting breakpoint -17: PC register is not available
Error in re-setting breakpoint -18: PC register is not available
Error in re-setting breakpoint -19: PC register is not available
Error in re-setting breakpoint -24: PC register is not available
Error in re-setting breakpoint -25: PC register is not available
Error in re-setting breakpoint -26: PC register is not available
Error in re-setting breakpoint -27: PC register is not available
Error in re-setting breakpoint -28: PC register is not available
Error in re-setting breakpoint -29: PC register is not available
Error in re-setting breakpoint -30: PC register is not available
PC register is not available
(gdb)
gdb/gdbserver/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* linux-low.c (add_lwp): Set waitstatus to TARGET_WAITKIND_IGNORE.
(linux_thread_alive): Use lwp_is_marked_dead.
(extended_event_reported): Delete.
(linux_wait_1): Check if waitstatus is TARGET_WAITKIND_IGNORE
instead of extended_event_reported.
(mark_lwp_dead): Don't set the 'dead' flag. Store the waitstatus
as well.
(lwp_is_marked_dead): New function.
(lwp_running): Use lwp_is_marked_dead.
* linux-low.h: Delete 'dead' field, and update 'waitstatus's
comment.
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Check for asprintf and vasprintf during configure stage.
@ 2015-08-05 7:33 sergiodj+buildbot
2015-08-05 8:09 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-08-05 7:33 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT a03bd1099151e16a07b3a9b3846a28bdef1ba686 ***
Author: Iain Buclaw <ibuclaw@gdcproject.org>
Branch: gdb-7.10-branch
Commit: a03bd1099151e16a07b3a9b3846a28bdef1ba686
Check for asprintf and vasprintf during configure stage.
This should fix some build errors seen on AIX, MinGW, and possibly other
non-GNU systems too due to missing asprintf().
bfd/
* configure.in: Add asprintf and vasprintf to AC_CHECK_DECLS.
* config.in, configure: Regenerate.
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] PR threads/18600: Inferiors left around after fork+thread spawn
@ 2015-07-30 20:10 sergiodj+buildbot
2015-07-30 20:20 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-07-30 20:10 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT 7476be08b73fdfba4eb91d891b235d4cf2e70f3b ***
Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.10-branch
Commit: 7476be08b73fdfba4eb91d891b235d4cf2e70f3b
PR threads/18600: Inferiors left around after fork+thread spawn
The new gdb.threads/fork-plus-threads.exp test exposes one more
problem. When one types "info inferiors" after running the program,
one see's a couple inferior left still, while there should only be
inferior #1 left. E.g.:
(gdb) info inferiors
Num Description Executable
4 process 8393 /home/pedro/bugs/src/test
2 process 8388 /home/pedro/bugs/src/test
* 1 <null> /home/pedro/bugs/src/test
(gdb) info threads
Calling prune_inferiors() manually at this point (from a top gdb) does
not remove them, because they still have inf->pid != 0 (while they
shouldn't). This suggests that we never mourned those inferiors.
Enabling logs (master + previous patch) we see:
...
WL: waitpid Thread 0x7ffff7fc2740 (LWP 9513) received Trace/breakpoint trap (stopped)
WL: Handling extended status 0x03057f
LHEW: Got clone event from LWP 9513, new child is LWP 9579
[New Thread 0x7ffff37b8700 (LWP 9579)]
WL: waitpid Thread 0x7ffff7fc2740 (LWP 9508) received 0 (exited)
WL: Thread 0x7ffff7fc2740 (LWP 9508) exited.
^^^^^^^^
[Thread 0x7ffff7fc2740 (LWP 9508) exited]
WL: waitpid Thread 0x7ffff7fc2740 (LWP 9499) received 0 (exited)
WL: Thread 0x7ffff7fc2740 (LWP 9499) exited.
[Thread 0x7ffff7fc2740 (LWP 9499) exited]
RSRL: resuming stopped-resumed LWP Thread 0x7ffff37b8700 (LWP 9579) at 0x3615ef4ce1: step=0
...
(gdb) info inferiors
Num Description Executable
5 process 9508 /home/pedro/bugs/src/test
^^^^
4 process 9503 /home/pedro/bugs/src/test
3 process 9500 /home/pedro/bugs/src/test
2 process 9499 /home/pedro/bugs/src/test
* 1 <null> /home/pedro/bugs/src/test
(gdb)
...
Note the "Thread 0x7ffff7fc2740 (LWP 9508) exited." line.
That's this in wait_lwp:
/* Check if the thread has exited. */
if (WIFEXITED (status) || WIFSIGNALED (status))
{
thread_dead = 1;
if (debug_linux_nat)
fprintf_unfiltered (gdb_stdlog, "WL: %s exited.\n",
target_pid_to_str (lp->ptid));
}
}
That was the leader thread reporting an exit, meaning the whole
process is gone. So the problem is that this code doesn't understand
that an WIFEXITED status of the leader LWP should be reported to
infrun as process exit.
gdb/ChangeLog:
2015-07-30 Pedro Alves <palves@redhat.com>
PR threads/18600
* linux-nat.c (wait_lwp): Report to the core when thread group
leader exits.
gdb/testsuite/ChangeLog:
2015-07-30 Pedro Alves <palves@redhat.com>
PR threads/18600
* gdb.threads/fork-plus-threads.exp: Test that "info inferiors"
only shows inferior 1.
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] PR threads/18600: Threads left stopped after fork+thread spawn
@ 2015-07-30 19:38 sergiodj+buildbot
2015-07-30 19:51 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-07-30 19:38 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT b31f5e79aac67f61a684c3af281caebd2ac1eece ***
Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.10-branch
Commit: b31f5e79aac67f61a684c3af281caebd2ac1eece
PR threads/18600: Threads left stopped after fork+thread spawn
When a program forks and another process start threads while gdb is
handling the fork event, newly created threads are left stuck stopped
by gdb, even though gdb presents them as "running", to the user.
This can be seen with the test added by this patch. The test has the
inferior fork a certain number of times and waits for all children to
exit. Each fork child spawns a number of threads that do nothing and
joins them immediately. Normally, the program should run unimpeded
(from the point of view of the user) and exit very quickly. Without
this fix, it doesn't because of some threads left stopped by gdb, so
inferior 1 never exits.
The program triggers when a new clone thread is found while inside the
linux_stop_and_wait_all_lwps call in linux-thread-db.c:
linux_stop_and_wait_all_lwps ();
ALL_LWPS (lp)
if (ptid_get_pid (lp->ptid) == pid)
thread_from_lwp (lp->ptid);
linux_unstop_all_lwps ();
Within linux_stop_and_wait_all_lwps, we reach
linux_handle_extended_wait with the "stopping" parameter set to 1, and
because of that we don't mark the new lwp as resumed. As consequence,
the subsequent resume_stopped_resumed_lwps, called from
linux_unstop_all_lwps, never resumes the new LWP.
There's lots of cruft in linux_handle_extended_wait that no longer
makes sense. On systems with CLONE events support, we don't rely on
libthread_db for thread listing anymore, so the code that preserves
stop_requested and the handling of last_resume_kind is all dead.
So the fix is to remove all that, and simply always mark the new LWP
as resumed, so that resume_stopped_resumed_lwps re-resumes it.
gdb/ChangeLog:
2015-07-30 Pedro Alves <palves@redhat.com>
Simon Marchi <simon.marchi@ericsson.com>
PR threads/18600
* linux-nat.c (linux_handle_extended_wait): On CLONE event, always
mark the new thread as resumed. Remove STOPPING parameter.
(wait_lwp): Adjust call to linux_handle_extended_wait.
(linux_nat_filter_event): Adjust call to
linux_handle_extended_wait.
(resume_stopped_resumed_lwps): Add debug output.
gdb/testsuite/ChangeLog:
2015-07-30 Simon Marchi <simon.marchi@ericsson.com>
Pedro Alves <palves@redhat.com>
PR threads/18600
* gdb.threads/fork-plus-threads.c: New file.
* gdb.threads/fork-plus-threads.exp: New file.
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] gdbserver/Linux: internal error when killing a process that is already gone
@ 2015-07-14 10:30 sergiodj+buildbot
2015-07-14 10:46 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-07-14 10:30 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT 68988aba52a4c6355b03834f70bcebbd114be2cd ***
Author: Pedro Alves <palves@redhat.com>
Branch: gdb-7.10-branch
Commit: 68988aba52a4c6355b03834f70bcebbd114be2cd
gdbserver/Linux: internal error when killing a process that is already gone
If the process disappears (e.g., killed with "kill -9" from the shell)
while it was stopped under GDBserver's control, and the GDBserver
tries to kill it, GDBserver asserts:
(gdb) shell kill -9 23084
(gdb) kill
...
Killing process(es): 23084
/home/pedro/gdb/mygit/src/gdb/gdbserver/linux-low.c:972: A problem internal to GDBserver has been detected.
kill_wait_lwp: Assertion `res > 0' failed.
...
gdb/gdbserver/ChangeLog:
2015-07-14 Pedro Alves <palves@redhat.com>
* linux-low.c (kill_wait_lwp): Don't assert if waitpid fails.
Instead, ignore ECHILD, and throw an error for other errnos.
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] record: set stop_pc in "record goto" command
@ 2015-07-14 7:24 sergiodj+buildbot
2015-07-14 7:35 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-07-14 7:24 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT 0900c4cec7f75a00cccb3537d754c20f99096686 ***
Author: Markus Metzger <markus.t.metzger@intel.com>
Branch: gdb-7.10-branch
Commit: 0900c4cec7f75a00cccb3537d754c20f99096686
record: set stop_pc in "record goto" command
When navigating in the recorded execution trace via "record goto", we do not
set stop_pc. This may trigger an internal error in infrun.c when stepping
from that location. Set it.
(gdb) rec full
(gdb) c
Continuing.
Breakpoint 1, foo (void) at foo.c:42
42 x = y
(gdb) rn
foo (void)
at foo.c:41
41 y = x
(gdb) rec go end
Go forward to insn number 98724
at foo.c:42
42 x = y
(gdb) n
infrun.c:2382: internal-error: resume: Assertion `sig != GDB_SIGNAL_0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
This happens because there's a breakpoint at PC when the "next"
is issued, so that breapoint should be immediately stepped over.
That should have been detected/done by proceed, here:
if (addr == (CORE_ADDR) -1)
{
if (pc == stop_pc
&& breakpoint_here_p (aspace, pc) == ordinary_breakpoint_here
&& execution_direction != EXEC_REVERSE)
/* There is a breakpoint at the address we will resume at,
step one instruction before inserting breakpoints so that
we do not stop right away (and report a second hit at this
breakpoint).
Note, we don't do this in reverse, because we won't
actually be executing the breakpoint insn anyway.
We'll be (un-)executing the previous instruction. */
tp->stepping_over_breakpoint = 1;
But since stop_pc was stale, the pc == stop_pc check failed, and left the
breakpont at PC inserted.
gdb/
* record-btrace.c (record_btrace_goto_begin, record_btrace_goto_end)
record_btrace_goto): Move call to print_stack_frame ...
(record_btrace_set_replay): ... here. Set stop_pc.
* record-full.c (record_full_goto_entry): Set stop_pc.
testsuite/
* gdb.btrace/record_goto-step.exp: New.
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] Fix testsuite regression by: Do not skip prologue for asm (.S) files
@ 2015-07-10 13:58 sergiodj+buildbot
2015-07-10 15:33 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-07-10 13:58 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT 8746ea769d67bf186d582d892cf37da42bc95ea9 ***
Author: Jan Kratochvil <jan.kratochvil@redhat.com>
Branch: gdb-7.10-branch
Commit: 8746ea769d67bf186d582d892cf37da42bc95ea9
Fix testsuite regression by: Do not skip prologue for asm (.S) files
I have somehow missed gdb.asm/asm-source.exp PASS->FAIL even on x86_64.
It has no longer valid assumption that "break" breaks after the prologue even
in assembler. So I have changed this assumption of the testfile.
gdb/testsuite/ChangeLog
2015-07-10 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.asm/asm-source.exp (f at main): Stop at gdbasm_enter.
(n at main): New.
* gdb.asm/asmsrc1.s: Add comment "mark: main enter".
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] compile: Warn for old GCC on cv-qualified self-reference
@ 2015-07-08 13:27 sergiodj+buildbot
2015-07-08 14:18 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-07-08 13:27 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT 91affdd27ee8e244df417686ead2b546ee1449bf ***
Author: Jan Kratochvil <jan.kratochvil@redhat.com>
Branch: gdb-7.10-branch
Commit: 91affdd27ee8e244df417686ead2b546ee1449bf
compile: Warn for old GCC on cv-qualified self-reference
GDB could:
compile code struct_object.selffield = &struct_object
./compile/compile-c-types.c:83: internal-error: insert_type: Assertion `add == NULL || add->gcc_type == gcc_type' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.compile/compile.exp: compile code struct_object.selffield = &struct_object (GDB internal
error)
The bug was not in GDB but in the GCC part interfacing with GDB.
Alexandre Oliva has fixed it the right way:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=commitdiff;h=072dfdba0ea62abb65514cb3a90cdf3868efe286
git://gcc.gnu.org/git/gcc.git
aoliva/libcp1
Attaching this GDB testsuite update + info to user s/he should upgrade GCC.
After Alex upstreams the fix I can update the message to contain the specific
GCC release.
gdb/ChangeLog
2015-07-08 Jan Kratochvil <jan.kratochvil@redhat.com>
PR compile/18484
* compile/compile-c-types.c (insert_type): Change gdb_assert to error.
gdb/testsuite/ChangeLog
2015-07-08 Jan Kratochvil <jan.kratochvil@redhat.com>
PR compile/18484
* gdb.compile/compile.c (struct struct_type): Add volatile to
selffield's type.
* gdb.compile/compile.exp
(compile code struct_object.selffield = &struct_object): Skip further
struct_object tests if this one xfails.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Failures on Fedora-s390x-m64, branch gdb-7.10-branch
2015-07-08 13:27 [binutils-gdb/gdb-7.10-branch] compile: Warn for old GCC on cv-qualified self-reference sergiodj+buildbot
@ 2015-07-08 14:18 ` sergiodj+buildbot
0 siblings, 0 replies; 34+ messages in thread
From: sergiodj+buildbot @ 2015-07-08 14:18 UTC (permalink / raw)
To: gdb-testers
Buildslave:
marist-fedora-s390x
Full Build URL:
<http://gdb-build.sergiodj.net/builders/Fedora-s390x-m64/builds/938>
Commit(s) tested:
91affdd27ee8e244df417686ead2b546ee1449bf
Author(s) (in the same order as the commits):
Jan Kratochvil <jan.kratochvil@redhat.com>
Testsuite log (gdb.sum and gdb.log) URL(s):
<http://gdb-build.sergiodj.net/cgit/Fedora-s390x-m64/.git/tree/?h=gdb-7.10-branch&id=aec78ba5ef47711395acde1e5b1c4aea92533e83>
*** Regressions found ***
============================
new FAIL: gdb.base/foll-vfork.exp: exit: vfork relations in info inferiors: vfork relation no longer appears in info inferiors (timeout)
============================
*** Regressions against the baseline ***
============================
PASS -> FAIL: gdb.asm/asm-source.exp: bt 2 in foo2
PASS -> FAIL: gdb.asm/asm-source.exp: bt 3 in foo3
PASS -> FAIL: gdb.asm/asm-source.exp: bt ALL in foo2
PASS -> FAIL: gdb.asm/asm-source.exp: f at main
PASS -> FAIL: gdb.asm/asm-source.exp: f in foo2
new FAIL: gdb.asm/asm-source.exp: finish from foo3 (the program is no longer running)
PASS -> FAIL: gdb.asm/asm-source.exp: info line
PASS -> FAIL: gdb.asm/asm-source.exp: info source asmsrc2.s
PASS -> FAIL: gdb.asm/asm-source.exp: n in foo2
new FAIL: gdb.asm/asm-source.exp: next over foo3 (the program is no longer running)
PASS -> FAIL: gdb.asm/asm-source.exp: next over macro
PASS -> FAIL: gdb.asm/asm-source.exp: return from foo2
PASS -> FAIL: gdb.asm/asm-source.exp: step into foo2
new FAIL: gdb.base/foll-vfork.exp: exit: vfork relations in info inferiors: vfork relation no longer appears in info inferiors (timeout)
new FAIL: gdb.base/gnu_vector.exp: finish shows vector return value
new FAIL: gdb.base/gnu_vector.exp: verify vector return value (the program exited)
PASS -> FAIL: gdb.threads/watchthreads.exp: combination of threaded watchpoints = 30
PASS -> FAIL: gdb.threads/watchthreads.exp: threaded watch loop
PASS -> FAIL: gdb.trace/mi-traceframe-changed.exp: tfile: -trace-find frame-number 0
PASS -> FAIL: gdb.trace/mi-traceframe-changed.exp: tfile: tfind 0 again
============================
^ permalink raw reply [flat|nested] 34+ messages in thread
* [binutils-gdb/gdb-7.10-branch] PR18617 - Incorrect expression bytecode generated for narrowing conversions
@ 2015-07-08 10:51 sergiodj+buildbot
2015-07-08 11:41 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
0 siblings, 1 reply; 34+ messages in thread
From: sergiodj+buildbot @ 2015-07-08 10:51 UTC (permalink / raw)
To: gdb-testers
*** TEST RESULTS FOR COMMIT cc1259417e727c47e58cea1bb4a148974689ad8e ***
Author: Robert O'Callahan <robert@ocallahan.org>
Branch: gdb-7.10-branch
Commit: cc1259417e727c47e58cea1bb4a148974689ad8e
PR18617 - Incorrect expression bytecode generated for narrowing conversions
The existing code preserves 'from' bits, which is incorrect. E.g.
(gdb) maint agent-eval (char)255L
Scope: 0x4008d6
Reg mask: 00
0 const16 255
3 ext 64
5 end
'ext 64' should be 'ext 8'; this bytecode evaluates to 255 instead of
the correct result of -1. The fix is simple. I ran the entire test
suite on x86-64 and there were no new test failures.
gdb/ChangeLog:
2015-07-08 Robert O'Callahan <robert@ocallahan.org>
PR exp/18617
* ax-gdb.c (gen_conversion): Extend to 'to' bits, not 'from'.
gdb/testsuite/ChangeLog:
2015-07-08 Robert O'Callahan <robert@ocallahan.org>
PR exp/18617
* gdb.trace/ax.exp: Add test.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Failures on Fedora-s390x-m64, branch gdb-7.10-branch
2015-07-08 10:51 [binutils-gdb/gdb-7.10-branch] PR18617 - Incorrect expression bytecode generated for narrowing conversions sergiodj+buildbot
@ 2015-07-08 11:41 ` sergiodj+buildbot
0 siblings, 0 replies; 34+ messages in thread
From: sergiodj+buildbot @ 2015-07-08 11:41 UTC (permalink / raw)
To: gdb-testers
Buildslave:
marist-fedora-s390x
Full Build URL:
<http://gdb-build.sergiodj.net/builders/Fedora-s390x-m64/builds/936>
Commit(s) tested:
cc1259417e727c47e58cea1bb4a148974689ad8e
Author(s) (in the same order as the commits):
Robert O'Callahan <robert@ocallahan.org>
Testsuite log (gdb.sum and gdb.log) URL(s):
<http://gdb-build.sergiodj.net/cgit/Fedora-s390x-m64/.git/tree/?h=gdb-7.10-branch&id=f14361656086f6c72e4450bfc8d284544df16e24>
*** Regressions found ***
============================
PASS -> FAIL: gdb.threads/watchthreads.exp: combination of threaded watchpoints = 30
PASS -> FAIL: gdb.threads/watchthreads.exp: threaded watch loop
============================
*** Regressions against the baseline ***
============================
PASS -> FAIL: gdb.asm/asm-source.exp: bt 2 in foo2
PASS -> FAIL: gdb.asm/asm-source.exp: bt 3 in foo3
PASS -> FAIL: gdb.asm/asm-source.exp: bt ALL in foo2
PASS -> FAIL: gdb.asm/asm-source.exp: f at main
PASS -> FAIL: gdb.asm/asm-source.exp: f in foo2
new FAIL: gdb.asm/asm-source.exp: finish from foo3 (the program is no longer running)
PASS -> FAIL: gdb.asm/asm-source.exp: info line
PASS -> FAIL: gdb.asm/asm-source.exp: info source asmsrc2.s
PASS -> FAIL: gdb.asm/asm-source.exp: n in foo2
new FAIL: gdb.asm/asm-source.exp: next over foo3 (the program is no longer running)
PASS -> FAIL: gdb.asm/asm-source.exp: next over macro
PASS -> FAIL: gdb.asm/asm-source.exp: return from foo2
PASS -> FAIL: gdb.asm/asm-source.exp: step into foo2
new FAIL: gdb.base/gnu_vector.exp: finish shows vector return value
new FAIL: gdb.base/gnu_vector.exp: verify vector return value (the program exited)
PASS -> FAIL: gdb.base/siginfo-thread.exp: Extract si_errno
PASS -> FAIL: gdb.threads/watchthreads.exp: combination of threaded watchpoints = 30
PASS -> FAIL: gdb.threads/watchthreads.exp: threaded watch loop
PASS -> FAIL: gdb.trace/mi-traceframe-changed.exp: tfile: -trace-find frame-number 0
PASS -> FAIL: gdb.trace/mi-traceframe-changed.exp: tfile: tfind 0 again
============================
^ permalink raw reply [flat|nested] 34+ messages in thread
[parent not found: <eec595d37293692ec2f57f6b2f8a8244910b4a48@kwanyin>]
* Failures on Fedora-s390x-m64, branch gdb-7.10-branch
[not found] <eec595d37293692ec2f57f6b2f8a8244910b4a48@kwanyin>
@ 2015-07-07 0:44 ` sergiodj+buildbot
0 siblings, 0 replies; 34+ messages in thread
From: sergiodj+buildbot @ 2015-07-07 0:44 UTC (permalink / raw)
To: gdb-testers
Buildslave:
marist-fedora-s390x
Full Build URL:
<http://gdb-build.sergiodj.net/builders/Fedora-s390x-m64/builds/920>
Commit(s) tested:
eec595d37293692ec2f57f6b2f8a8244910b4a48
Author(s) (in the same order as the commits):
Joel Brobecker <brobecker@adacore.com>
Testsuite log (gdb.sum and gdb.log) URL(s):
<http://gdb-build.sergiodj.net/cgit/Fedora-s390x-m64/.git/tree/?h=gdb-7.10-branch&id=46c66150f00864075a2b62675db2a4a3e6713dbd>
*** Regressions found ***
============================
new FAIL: gdb.base/foll-vfork.exp: exit: vfork relations in info inferiors: vfork relation no longer appears in info inferiors (timeout)
new FAIL: gdb.threads/watchpoint-fork.exp: child: singlethreaded: breakpoint after the second fork (timeout)
PASS -> FAIL: gdb.threads/watchthreads.exp: combination of threaded watchpoints = 30
PASS -> FAIL: gdb.threads/watchthreads.exp: threaded watch loop
============================
*** Regressions against the baseline ***
============================
PASS -> FAIL: gdb.asm/asm-source.exp: bt 2 in foo2
PASS -> FAIL: gdb.asm/asm-source.exp: bt 3 in foo3
PASS -> FAIL: gdb.asm/asm-source.exp: bt ALL in foo2
PASS -> FAIL: gdb.asm/asm-source.exp: f at main
PASS -> FAIL: gdb.asm/asm-source.exp: f in foo2
new FAIL: gdb.asm/asm-source.exp: finish from foo3 (the program is no longer running)
PASS -> FAIL: gdb.asm/asm-source.exp: info line
PASS -> FAIL: gdb.asm/asm-source.exp: info source asmsrc2.s
PASS -> FAIL: gdb.asm/asm-source.exp: n in foo2
new FAIL: gdb.asm/asm-source.exp: next over foo3 (the program is no longer running)
PASS -> FAIL: gdb.asm/asm-source.exp: next over macro
PASS -> FAIL: gdb.asm/asm-source.exp: return from foo2
PASS -> FAIL: gdb.asm/asm-source.exp: step into foo2
new FAIL: gdb.base/foll-vfork.exp: exit: vfork relations in info inferiors: vfork relation no longer appears in info inferiors (timeout)
new FAIL: gdb.base/gnu_vector.exp: finish shows vector return value
new FAIL: gdb.base/gnu_vector.exp: verify vector return value (the program exited)
PASS -> FAIL: gdb.base/siginfo-thread.exp: Extract si_errno
new FAIL: gdb.threads/watchpoint-fork.exp: child: singlethreaded: breakpoint after the second fork (timeout)
PASS -> FAIL: gdb.threads/watchthreads.exp: combination of threaded watchpoints = 30
PASS -> FAIL: gdb.threads/watchthreads.exp: threaded watch loop
PASS -> FAIL: gdb.trace/mi-traceframe-changed.exp: tfile: -trace-find frame-number 0
PASS -> FAIL: gdb.trace/mi-traceframe-changed.exp: tfile: tfind 0 again
============================
^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2016-02-11 16:13 UTC | newest]
Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <7366dec04e7aa6cf4a0c962ce6cc2bc13a63e3ea@kwanyin>
2015-07-06 22:21 ` Failures on AIX-POWER7-plain, branch gdb-7.10-branch sergiodj+buildbot
2015-07-07 1:41 ` Failures on Fedora-s390x-m64, " sergiodj+buildbot
2016-02-11 15:36 [binutils-gdb/gdb-7.10-branch] Fix '-data-read-memory-bytes' typo/assertion sergiodj+buildbot
2016-02-11 16:13 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
-- strict thread matches above, loose matches on Subject: below --
2015-12-05 15:56 [binutils-gdb/gdb-7.10-branch] Bump GDB version number to 7.10.1.DATE-cvs sergiodj+buildbot
2015-12-05 17:32 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-12-05 15:33 [binutils-gdb/gdb-7.10-branch] Set GDB version number to 7.10.1 sergiodj+buildbot
2015-12-05 16:27 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-12-02 9:47 [binutils-gdb/gdb-7.10-branch] Fix regression by Do not skip prologue for asm (.S) files sergiodj+buildbot
2015-12-02 10:11 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-11-28 21:54 [binutils-gdb/gdb-7.10-branch] Fix several crashes of C++ demangler on fuzzed input sergiodj+buildbot
2015-11-28 23:12 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-11-28 21:16 [binutils-gdb/gdb-7.10-branch] Adjust GDB to demangler API change sergiodj+buildbot
2015-11-29 1:43 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-11-28 20:37 [binutils-gdb/gdb-7.10-branch] PR other/61321 - demangler crash on casts in template parameters sergiodj+buildbot
2015-11-29 0:37 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-11-28 20:05 [binutils-gdb/gdb-7.10-branch] Implement N4514, C++ Extensions for Transactional Memory sergiodj+buildbot
2015-11-29 0:10 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-11-28 19:19 [binutils-gdb/gdb-7.10-branch] Demangler: Fix constructor names with ABI tags sergiodj+buildbot
2015-11-28 23:54 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-09-15 18:09 [binutils-gdb/gdb-7.10-branch] PR remote/18965: vforkdone stop reply should indicate parent PID sergiodj+buildbot
2015-09-15 19:39 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-28 21:58 [binutils-gdb/gdb-7.10-branch] Set GDB version number to 7.10 sergiodj+buildbot
2015-08-28 22:15 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-28 21:40 [binutils-gdb/gdb-7.10-branch] gdb/NEWS: Rename "Changes since GDB 7.9" into "Changes in GDB 7.10" sergiodj+buildbot
2015-08-28 21:50 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-25 18:44 [binutils-gdb/gdb-7.10-branch] remote: allow aborting long operations (e.g., file transfers) sergiodj+buildbot
2015-08-25 18:44 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-25 17:11 [binutils-gdb/gdb-7.10-branch] signal_command: Leftover cleanup chain regression sergiodj+buildbot
2015-08-25 19:40 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-21 18:24 [binutils-gdb/gdb-7.10-branch] Make remote file transfers interruptible sergiodj+buildbot
2015-08-21 21:56 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-21 17:54 [binutils-gdb/gdb-7.10-branch] Warn when accessing binaries from remote targets sergiodj+buildbot
2015-08-21 21:32 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-19 13:35 [binutils-gdb/gdb-7.10-branch] Prelimit number of bytes to read in "vFile:pread:" sergiodj+buildbot
2015-08-19 13:59 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-18 14:03 [binutils-gdb/gdb-7.10-branch] PR record/18691: Fix fails in solib-precsave.exp sergiodj+buildbot
2015-08-18 15:27 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-13 19:13 [binutils-gdb/gdb-7.10-branch] [amd64] Invalid return address after displaced stepping sergiodj+buildbot
2015-08-13 20:09 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-12 9:20 [binutils-gdb/gdb-7.10-branch] [regression] Do not read from catchpoint/watchpoint locations' addresses when checking for a permanent breakpoint sergiodj+buildbot
2015-08-12 13:10 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-06 17:47 [binutils-gdb/gdb-7.10-branch] PR python/17136 sergiodj+buildbot
2015-08-06 18:39 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-06 12:22 [binutils-gdb/gdb-7.10-branch] gdbserver: Fix non-stop / fork / step-over issues sergiodj+buildbot
2015-08-06 12:40 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-06 11:58 [binutils-gdb/gdb-7.10-branch] Linux gdbserver confused when event randomization picks process exit event sergiodj+buildbot
2015-08-06 12:13 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-08-05 7:33 [binutils-gdb/gdb-7.10-branch] Check for asprintf and vasprintf during configure stage sergiodj+buildbot
2015-08-05 8:09 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-07-30 20:10 [binutils-gdb/gdb-7.10-branch] PR threads/18600: Inferiors left around after fork+thread spawn sergiodj+buildbot
2015-07-30 20:20 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-07-30 19:38 [binutils-gdb/gdb-7.10-branch] PR threads/18600: Threads left stopped after fork+thread spawn sergiodj+buildbot
2015-07-30 19:51 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-07-14 10:30 [binutils-gdb/gdb-7.10-branch] gdbserver/Linux: internal error when killing a process that is already gone sergiodj+buildbot
2015-07-14 10:46 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-07-14 7:24 [binutils-gdb/gdb-7.10-branch] record: set stop_pc in "record goto" command sergiodj+buildbot
2015-07-14 7:35 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-07-10 13:58 [binutils-gdb/gdb-7.10-branch] Fix testsuite regression by: Do not skip prologue for asm (.S) files sergiodj+buildbot
2015-07-10 15:33 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-07-08 13:27 [binutils-gdb/gdb-7.10-branch] compile: Warn for old GCC on cv-qualified self-reference sergiodj+buildbot
2015-07-08 14:18 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
2015-07-08 10:51 [binutils-gdb/gdb-7.10-branch] PR18617 - Incorrect expression bytecode generated for narrowing conversions sergiodj+buildbot
2015-07-08 11:41 ` Failures on Fedora-s390x-m64, branch gdb-7.10-branch sergiodj+buildbot
[not found] <eec595d37293692ec2f57f6b2f8a8244910b4a48@kwanyin>
2015-07-07 0:44 ` sergiodj+buildbot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).