This fixes several problems with this test.
E.g,. with --target_board=native-extended-gdbserver on x86_64 Fedora
20, I get:
Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/disp-step-syscall.exp ...
FAIL: gdb.base/disp-step-syscall.exp: vfork: get hexadecimal valueof "$pc" (timeout)
FAIL: gdb.base/disp-step-syscall.exp: vfork: single step over vfork final pc
FAIL: gdb.base/disp-step-syscall.exp: vfork: delete break vfork insn
FAIL: gdb.base/disp-step-syscall.exp: vfork: continue to marker (vfork) (the program is no longer running)
And with --target=native-gdbserver, I get:
Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/disp-step-syscall.exp ...
KPASS: gdb.base/disp-step-syscall.exp: vfork: single step over vfork (PRMS server/13796)
FAIL: gdb.base/disp-step-syscall.exp: vfork: get hexadecimal valueof "$pc" (timeout)
FAIL: gdb.base/disp-step-syscall.exp: vfork: single step over vfork final pc
FAIL: gdb.base/disp-step-syscall.exp: vfork: delete break vfork insn
FAIL: gdb.base/disp-step-syscall.exp: vfork: continue to marker (vfork) (the program is no longer running)
First, the lack of fork support on remote targets is supposed to be
kfailed, so the KPASS is obviously bogus. The extended-remote board
should have KFAILed too.
The problem is that the test is using "is_remote" instead of
gdb_is_target_remote.
And then, I get:
(gdb) PASS: gdb.base/disp-step-syscall.exp: vfork: set displaced-stepping on
stepi
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) PASS: gdb.base/disp-step-syscall.exp: vfork: single step over vfork
Obviously, that should be a FAIL. The problem is that the test only
expects SIGILL, not SIGSEGV. It also doesn't bail correctly if an
internal error or some other pattern caught by gdb_test_multiple
matches. The test doesn't really need to match specific exits/crashes
patterns, if the PASS regex is improved, like in ...
... this and the other "stepi" tests are a bit too lax, passing on
".*". This tightens those up to expect "x/i" and the "=>" current PC
indicator, like in:
1: x/i $pc
=> 0x3b36abc9e2 <vfork+34>: syscall
On x86_64 Fedora 20, I now get a quick KFAIL instead of timeouts with
both the native-extended-gdbserver and native-gdbserver boards:
PASS: gdb.base/disp-step-syscall.exp: vfork: delete break vfork
PASS: gdb.base/disp-step-syscall.exp: vfork: continue to syscall insn vfork
PASS: gdb.base/disp-step-syscall.exp: vfork: set displaced-stepping on
KFAIL: gdb.base/disp-step-syscall.exp: vfork: single step over vfork (PRMS: server/13796)
and a full pass with native testing.
gdb/testsuite/
2015-03-18 Pedro Alves <palves@redhat.com>
* gdb.base/disp-step-syscall.exp (disp_step_cross_syscall):
Use gdb_is_target_remote instead of is_remote. Use
gdb_test_multiple instead of gdb_expect. Exit early if
gdb_test_multiple hits its internal matches. Tighten stepi tests
expected output. Fail on exit with any signal, instead of just
SIGILL.
Hi,
This patch is to support catch syscall on aarch64 linux. We
implement gdbarch method get_syscall_number for aarch64-linux,
and add aarch64-linux.xml file, which looks straightforward, however
the changes to test case doesn't.
First of all, we enable catch-syscall.exp on aarch64-linux target,
but skip the multi_arch testing on current stage. I plan to touch
multi arch debugging on aarch64-linux later.
Then, when I run catch-syscall.exp on aarch64-linux, gcc errors that
SYS_pipe isn't defined. We find that aarch64 kernel only has pipe2
syscall and libc already convert pipe to pipe2. As a result, I change
catch-syscall.c to use SYS_pipe if it is defined, otherwise use
SYS_pipe2 instead. The vector all_syscalls in catch-syscall.exp can't
be pre-determined, so I add a new proc setup_all_syscalls to fill it,
according to the availability of SYS_pipe.
Regression tested on {x86_64, aarch64}-linux x {native, gdbserver}.
gdb:
2015-03-18 Yao Qi <yao.qi@linaro.org>
PR tdep/18107
* aarch64-linux-tdep.c: Include xml-syscall.h
(aarch64_linux_get_syscall_number): New function.
(aarch64_linux_init_abi): Call
set_gdbarch_get_syscall_number.
* syscalls/aarch64-linux.xml: New file.
gdb/testsuite:
2015-03-18 Yao Qi <yao.qi@linaro.org>
PR tdep/18107
* gdb.base/catch-syscall.c [!SYS_pipe] (pipe2_syscall): New
variable.
* gdb.base/catch-syscall.exp: Don't skip it on
aarch64*-*-linux* target. Remove elements in all_syscalls.
(test_catch_syscall_multi_arch): Skip it on aarch64*-linux*
target.
(setup_all_syscalls): New proc.
We see some fails in watchpoint-reuse-slot.exp on aarch64-linux, because
it sets some HW breakpoint on some address doesn't meet the alignment
requirements by kernel, kernel will reject the
ptrace (PTRACE_SETHBPREGS) call, and some fails are caused, for example:
(gdb) PASS: gdb.base/watchpoint-reuse-slot.exp: always-inserted off: watch x hbreak: : width 1, iter 0: base + 0: delete $bpnum
hbreak *(buf.byte + 0 + 1)^M
Hardware assisted breakpoint 80 at 0x410a61^M
(gdb) PASS: gdb.base/watchpoint-reuse-slot.exp: always-inserted off: watch x hbreak: : width 1, iter 0: base + 1: hbreak *(buf.byte + 0 + 1)
stepi^M
Warning:^M
Cannot insert hardware breakpoint 80.^M
Could not insert hardware breakpoints:^M
You may have requested too many hardware breakpoints/watchpoints.^M
^M
(gdb) FAIL: gdb.base/watchpoint-reuse-slot.exp: always-inserted off: watch x hbreak: : width 1, iter 0: base + 1: stepi advanced
hbreak *(buf.byte + 0 + 1)^M
Hardware assisted breakpoint 440 at 0x410a61^M
Warning:^M
Cannot insert hardware breakpoint 440.^M
Could not insert hardware breakpoints:^M
You may have requested too many hardware breakpoints/watchpoints.^M
^M
(gdb) FAIL: gdb.base/watchpoint-reuse-slot.exp: always-inserted on: watch x hbreak: : width 1, iter 0: base + 1: hbreak *(buf.byte + 0 + 1)
This patch is to skip some tests by checking proc valid_addr_p.
We can handle other targets in valid_addr_p too.
gdb/testsuite:
2015-03-16 Yao Qi <yao.qi@linaro.org>
* gdb.base/watchpoint-reuse-slot.exp (valid_addr_p): New proc.
(top level): Skip tests if valid_addr_p returns false for
$cmd1 or $cmd2.
Unfortunately, the Python version of the dg-extract-results.sh script
doesn't produce stable-enough results for GDB. The test messages
appear to end up alpha sorted (losing the original sequence) and also
sorting changes between runs for some reason. That may be tolerable
for GCC, but for GDB, it often renders test results diffing between
different revisions unworkable.
Until that is fixed upstream, delete the script from the GDB tree.
testsuite/ChangeLog:
2015-03-09 Pedro Alves <palves@redhat.com>
* dg-extract-results.py: Delete.
This merges Sergio's fix from GCC:
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01293.html
gdb/testsuite/ChangeLog:
2015-03-09 Pedro Alves <palves@redhat.com>
Merge dg-extract-results.sh from GCC upstream (r218843).
2014-12-17 Sergio Durigan Junior <sergiodj@redhat.com>
* dg-extract-results.sh: Use --text with grep to avoid issues with
binary files. Fall back to cat -v, if that doesn't work.
Trying to fix a permanent breakpoints bug, I broke "next" over a
regular breakpoint. "next" would immediately hit the breakpoint the
program was already stopped at. But, the "next over setup" test
failed to notice this and still issued a pass. That's because the
regex matches "testsuite" in:
Breakpoint 2 at 0x400687: file src/gdb/testsuite/gdb.base/bp-permanent.c, line 46.
gdb/testsuite/ChangeLog:
2015-03-05 Pedro Alves <palves@redhat.com>
* gdb.base/bp-permanent.exp: Tighten "next over setup" regex.
When interrupting a thread in non-stop vs all-stop, the signal given in
the MI *stopped event is not the same. Currently, mi_expect_interrupt only
accepts the case for non-stop, so this adds the alternative for all-stop.
gdb/testsuite/ChangeLog:
* lib/mi-support.exp (mi_expect_interrupt): Accept
alternative event for when in all-stop mode.
Gary stumbled on this:
(gdb) PASS: gdb.threads/thread-specific-bp.exp: all-stop: continue to end
info threads
Id Target Id Frame
* 1 Thread 0x7ffff7fdb700 (LWP 13717) "thread-specific" end () at /home/gary/work/archer/startswith/src/gdb/testsuite/gdb.threads/thread-specific-bp.c:29
(gdb) FAIL: gdb.threads/thread-specific-bp.exp: all-stop: thread start is gone
info breakpoint
The problem is that "...archer/startswith/src..." has a "start" in it,
which matches the too-lax regex in the test.
Rather than tweaking the regex, we can just remove the whole "info
threads", like we removed similar ones in other files -- GDB nowadays
does this implicitly already, so things should work without it. Thus
removing this even improves testing here a bit.
gdb/testsuite/ChangeLog:
2015-03-04 Pedro Alves <palves@redhat.com>
* gdb.threads/thread-specific-bp.exp: Delete "info threads" test.
On some targets each of the assignments "i = 0" in the C source for
"breakpoint-in-ro-region.exp" are compiled to a single instruction.
Then each "si" stops at the beginning of the next source line. But on
some other targets (like s390) such an assignment compiles to multiple
instructions. Then "si" may stop in mid-line, and GDB displays the PC
address in addition to the source line number. This was not considered
by the regexp for this case.
gdb/testsuite/ChangeLog:
* gdb.base/breakpoint-in-ro-region.exp (test_single_step): In the
regexps for GDB's current line display, accept a hex address
preceding the line number.
For the "multiple targets" test in catch-syscall.exp, set the 'arch1'
variable to a valid string.
gdb/testsuite/ChangeLog:
* gdb.base/catch-syscall.exp (test_catch_syscall_multi_arch): Set
the 'arch1' variable for "s390*-linux*" targets.
This fixes:
> gdb compile failed, /gdb/testsuite/gdb.threads/clone-thread_db.c: In function 'main':
> /gdb/testsuite/gdb.threads/clone-thread_db.c:67:3: warning: implicit declaration of function 'alarm' [-Wimplicit-function-declaration]
> alarm (300);
> ^
> /gdb/testsuite/gdb.threads/clone-thread_db.c:69:3: warning: implicit declaration of function 'pthread_create' [-Wimplicit-function-declaration]
> pthread_create (&child, NULL, thread_fn, NULL);
> ^
> /gdb/testsuite/gdb.threads/clone-thread_db.c:70:3: warning: implicit declaration of function 'pthread_join' [-Wimplicit-function-declaration]
> pthread_join (child);
> ^
And then adding the missing headers revealed the pthread_join call was
incorrect. This probably fixes the crash we see on ppc64be, e.g., at
https://sourceware.org/ml/gdb-testers/2015-q1/msg04415.html
the logs there show:
...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x3fffb7ff54a0 (LWP 9275)]
0x00003fffb7f3ce74 in .pthread_join () from /lib64/libpthread.so.0
(gdb) FAIL: gdb.threads/clone-thread_db.exp: continue to end
...
Tested on x86_64 Fedora 20.
gdb/testsuite/
2015-03-04 Pedro Alves <palves@redhat.com>
* gdb.threads/clone-thread_db.c: Include unistd.h and pthread.h.
(main): Pass missing retval argument to pthread_join call.
This fixes invalid reads Valgrind first caught when debugging against
a GDBserver patched with a series that adds exec events to the remote
protocol. Like these, using the gdb.threads/thread-execl.exp test:
$ valgrind ./gdb -data-directory=data-directory ./testsuite/gdb.threads/thread-execl -ex "tar extended-remote :9999" -ex "b thread_execler" -ex "c" -ex "set scheduler-locking on"
...
Breakpoint 1, thread_execler (arg=0x0) at src/gdb/testsuite/gdb.threads/thread-execl.c:29
29 if (execl (image, image, NULL) == -1)
(gdb) n
Thread 32509.32509 is executing new program: build/gdb/testsuite/gdb.threads/thread-execl
[New Thread 32509.32532]
==32510== Invalid read of size 4
==32510== at 0x5AA7D8: delete_breakpoint (breakpoint.c:13989)
==32510== by 0x6285D3: delete_thread_breakpoint (thread.c:100)
==32510== by 0x628603: delete_step_resume_breakpoint (thread.c:109)
==32510== by 0x61622B: delete_thread_infrun_breakpoints (infrun.c:2928)
==32510== by 0x6162EF: for_each_just_stopped_thread (infrun.c:2958)
==32510== by 0x616311: delete_just_stopped_threads_infrun_breakpoints (infrun.c:2969)
==32510== by 0x616C96: fetch_inferior_event (infrun.c:3267)
==32510== by 0x63A2DE: inferior_event_handler (inf-loop.c:57)
==32510== by 0x4E0E56: remote_async_serial_handler (remote.c:11877)
==32510== by 0x4AF620: run_async_handler_and_reschedule (ser-base.c:137)
==32510== by 0x4AF6F0: fd_event (ser-base.c:182)
==32510== by 0x63806D: handle_file_event (event-loop.c:762)
==32510== Address 0xcf333e0 is 16 bytes inside a block of size 200 free'd
==32510== at 0x4A07577: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==32510== by 0x77CB74: xfree (common-utils.c:98)
==32510== by 0x5AA954: delete_breakpoint (breakpoint.c:14056)
==32510== by 0x5988BD: update_breakpoints_after_exec (breakpoint.c:3765)
==32510== by 0x61360F: follow_exec (infrun.c:1091)
==32510== by 0x6186FA: handle_inferior_event (infrun.c:4061)
==32510== by 0x616C55: fetch_inferior_event (infrun.c:3261)
==32510== by 0x63A2DE: inferior_event_handler (inf-loop.c:57)
==32510== by 0x4E0E56: remote_async_serial_handler (remote.c:11877)
==32510== by 0x4AF620: run_async_handler_and_reschedule (ser-base.c:137)
==32510== by 0x4AF6F0: fd_event (ser-base.c:182)
==32510== by 0x63806D: handle_file_event (event-loop.c:762)
==32510==
[Switching to Thread 32509.32532]
Breakpoint 1, thread_execler (arg=0x0) at src/gdb/testsuite/gdb.threads/thread-execl.c:29
29 if (execl (image, image, NULL) == -1)
(gdb)
The breakpoint in question is the step-resume breakpoint of the
non-main thread, the one that was "next"ed.
The exact same issue can be seen on mainline with native debugging, by
running the thread-execl.exp test in non-stop mode, because the kernel
doesn't report a thread exit event for the execing thread.
Tested on x86_64 Fedora 20.
gdb/ChangeLog:
2015-03-02 Pedro Alves <palves@redhat.com>
* infrun.c (follow_exec): Delete all threads of the process except
the event thread. Extended comments.
gdb/testsuite/ChangeLog:
2015-03-02 Pedro Alves <palves@redhat.com>
* gdb.threads/thread-execl.exp (do_test): Handle non-stop.
(top level): Call do_test with non-stop as well.
gdb_test_multiple is supposed to return -1 on internal error:
# Returns:
# 1 if the test failed, according to a built-in failure pattern
# 0 if only user-supplied patterns matched
# -1 if there was an internal error.
But alas, that's broken, it returns success... It looks like the code
is assuming an earlier 'set result -1' is still in effect, but
'result' is set to 0 at the end, just before we call gdb_expect:
set result 0
set code [catch {gdb_expect $code} string]
gdb/testsuite/
2015-03-02 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_test_multiple) <internal error>: Set result to
-1.
gdb/testsuite/
2015-02-27 Pedro Alves <palves@redhat.com>
* gdb.gdb/complaints.exp (test_initial_complaints): Also accept
"true" for boolean result.
* gdb.gdb/selftest.exp (test_with_self): Also accept full
prototype of main.
In some scenarios, GDB or GDBserver can be spawned with input _not_
connected to a tty, and then tests that rely on stdio fail with
timeouts, because the inferior's stdout and stderr streams end up
fully buffered.
See discussion here:
https://sourceware.org/ml/gdb-patches/2015-02/msg00809.html
We have a hack in place that works around this for Windows testing,
that forces every test program to link with an .o file that does
(lib/set_unbuffered_mode.c):
static int __gdb_set_unbuffered_output (void) __attribute__ ((constructor));
static int
__gdb_set_unbuffered_output (void)
{
setvbuf (stdout, NULL, _IONBF, BUFSIZ);
setvbuf (stderr, NULL, _IONBF, BUFSIZ);
}
That's a bit hacky; it ends up done for _all_ tests.
This patch adds a way to do this unbuffering explicitly from the test
code itself, so it is done only when necessary, and for all
targets/hosts. For starters, it adjusts gdb.base/interrupt.c to use
it.
Tested on x86_64 Fedora 20, native, and against a remote gdbserver
board file that connects to the target with ssh, with and without -t
(create pty).
gdb/testsuite/
2015-02-27 Pedro Alves <palves@redhat.com>
* lib/unbuffer_output.c: New file.
* gdb.base/interrupt.c: Include "../lib/unbuffer_output.c".
(main): Call gdb_unbuffer_output.
As far as I know, "catch syscall" is supported on hppa*-hp-hpux*, but
the test catch-syscall.exp is skipped on this target by mistake. This
patch is to fix it. However, I don't have a hpux machine to test.
gdb/testsuite:
2015-02-27 Yao Qi <yao.qi@linaro.org>
* gdb.base/catch-syscall.exp: Don't skip it on hppa*-hp-hpux*
target.
One could not call IFUNCs (=indirect functions) from the compiled injected
code. Either it errored with:
gdb command line:1:1: error: function return type cannot be function
or it just called the IFUNC dispatcher in normal way, returning real function
implementation address instead of the function return value (and thus no
function was called).
gdb/ChangeLog
2015-02-26 Jan Kratochvil <jan.kratochvil@redhat.com>
* compile/compile-c-symbols.c (convert_one_symbol, convert_symbol_bmsym)
(gcc_symbol_address): Call gnu_ifunc_resolve_addr.
gdb/testsuite/ChangeLog
2015-02-26 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.compile/compile-ifunc.c: New file.
* gdb.compile/compile-ifunc.exp: New file.
When doing finish in a function, if gdb fails to return a value, gdb
also fails at printing the value type if this type is a struct.
For example :
(gdb) fin
....
Value returned has type: . Cannot determine contents
This patch fixes this by calling type_to_string to print the type
so that we can support these types.
This patch returns the following example output :
(gdb) fin
....
Value returned has type: struct test. Cannot determine contents
Also, this patch modifies structs.exp to check that we return the
correct type.
gdb/ChangeLog:
* gdb/infcmd.c (print_return_value): use type_to_string to print type.
gdb/testsuite/ChangeLog:
* gdb.base/structs.exp: Check for correct struct on finish.
On aarch64, we got the following fail:
(gdb) disassemble func
Dump of assembler code for function func:
0x0000000000400730 <+0>: ret
End of assembler dump.^M
(gdb) x/2i func+0^M
0x400730 <func>: ret^M
0x400734 <main>: stp x29, x30, [sp,#-16]!^M
(gdb) FAIL: gdb.dwarf2/dw2-ifort-parameter.exp: x/2i func+0
the pattern in proc function_range expects to match <func+0>, however,
GDB doesn't display the offset when it is zero. This patch is to
adjust the pattern when $func_length is zero.
gdb/testsuite:
2015-02-26 Yao Qi <yao.qi@linaro.org>
* lib/dwarf.exp (function_range): Adjust pattern when $func_length
is zero.
The attached patch fixes the SEGV and lets GDB successfully
load all kernel modules installed by default on RHEL 7.
Valgrind on F-21 x86_64 host has shown me more clear what is the problem:
Reading symbols from /home/jkratoch/t/cordic.ko...Reading symbols from
/home/jkratoch/t/cordic.ko.debug...=================================================================
==22763==ERROR: AddressSanitizer: heap-use-after-free on address 0x6120000461c8 at pc 0x150cdbd bp 0x7fffffffc7e0 sp 0x7fffffffc7d0
READ of size 8 at 0x6120000461c8 thread T0
#0 0x150cdbc in ppc64_elf_get_synthetic_symtab /home/jkratoch/redhat/gdb-test-asan/bfd/elf64-ppc.c:3282
#1 0x8c5274 in elf_read_minimal_symbols /home/jkratoch/redhat/gdb-test-asan/gdb/elfread.c:1205
#2 0x8c55e7 in elf_symfile_read /home/jkratoch/redhat/gdb-test-asan/gdb/elfread.c:1268
[...]
0x6120000461c8 is located 264 bytes inside of 288-byte region [0x6120000460c0,0x6120000461e0)
freed by thread T0 here:
#0 0x7ffff715454f in __interceptor_free (/lib64/libasan.so.1+0x5754f)
#1 0xde9cde in xfree common/common-utils.c:98
#2 0x9a04f7 in do_my_cleanups common/cleanups.c:155
#3 0x9a05d3 in do_cleanups common/cleanups.c:177
#4 0x8c538a in elf_read_minimal_symbols /home/jkratoch/redhat/gdb-test-asan/gdb/elfread.c:1229
#5 0x8c55e7 in elf_symfile_read /home/jkratoch/redhat/gdb-test-asan/gdb/elfread.c:1268
[...]
previously allocated by thread T0 here:
#0 0x7ffff71547c7 in malloc (/lib64/libasan.so.1+0x577c7)
#1 0xde9b95 in xmalloc common/common-utils.c:41
#2 0x8c4da2 in elf_read_minimal_symbols /home/jkratoch/redhat/gdb-test-asan/gdb/elfread.c:1147
#3 0x8c55e7 in elf_symfile_read /home/jkratoch/redhat/gdb-test-asan/gdb/elfread.c:1268
[...]
SUMMARY: AddressSanitizer: heap-use-after-free /home/jkratoch/redhat/gdb-test-asan/bfd/elf64-ppc.c:3282 ppc64_elf_get_synthetic_symtab
[...]
==22763==ABORTING
A similar case a few lines later I have fixed in 2010 by:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=3f1eff0a2c7f0e7078f011f55b8e7f710aae0cc2
My testcase does not always reproduce it but at least a bit:
* GDB without ppc64 target (even as a secondary one) is reported as "untested"
* ASAN-built GDB with ppc64 target always crashes (and PASSes with this fix)
* unpatched non-ASAN-built GDB with ppc64 target crashes from commandline
* unpatched non-ASAN-built GDB with ppc64 target PASSes from runtest (?)
gdb/ChangeLog
2015-02-26 Jan Kratochvil <jan.kratochvil@redhat.com>
* elfread.c (elf_read_minimal_symbols): Use bfd_alloc for
bfd_canonicalize_symtab.
gdb/testsuite/ChangeLog
2015-02-26 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.arch/cordic.ko.bz2: New file.
* gdb.arch/cordic.ko.debug.bz2: New file.
* gdb.arch/ppc64-symtab-cordic.exp: New file.
Hi,
I see the following fail in aarch64-linux-gnu testing...
(gdb) set tdesc file /XXX/gdb/testsuite/gdb.xml/single-reg.xml^M
warning: Architecture rejected target-supplied description^M
(gdb) FAIL: gdb.xml/tdesc-regs.exp: set tdesc file single-reg.xml
core-regs isn't set for aarch64 target, and looks it is an oversight
when aarch64 port was added.
gdb/testsuite:
2015-02-25 Yao Qi <yao.qi@linaro.org>
* gdb.xml/tdesc-regs.exp: Set core-regs to aarch64-core.xml for
aarch64*-*-* target.
Because delete_breakpoints uses gdb_expect directly, an internal error
results in slow timeouts instead of quickly bailing out. This patch
rewrites the procedure to use gdb_test_multiple instead, while
preserving the existing general logic ("delete breakpoints" + "info
breakpoints").
gdb/testsuite/
2015-02-23 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (delete_breakpoints): Rewrite using
gdb_test_multiple.
Fixes:
> gdb compile failed, /gdb/testsuite/gdb.base/info-os.c: In function 'main':
> /gdb/testsuite/gdb.base/info-os.c:65:3: warning: implicit declaration of function 'atexit' [-Wimplicit-function-declaration]
> atexit (ipc_cleanup);
> ^
> FAIL: gdb.base/info-os.exp: cannot compile test program
with recent GCCs.
gdb/testsuite/ChangeLog:
2015-02-23 Pedro Alves <palves@redhat.com>
* gdb.base/info-os.c: Include stdlib.h.
gdb/testsuite/ChangeLog:
PR symtab/17855
* gdb.ada/exec_changed.exp: Add second test where symbol lookup cache
is read after symbols have been re-read.
* gdb.ada/exec_changed/first.adb (First): New procedure Break_Me.
* gdb.ada/exec_changed/second.adb (Second): Ditto.
This patch addresses two issues.
The basic problem is that "(anonymous namespace)" doesn't get entered
into the symbol table because when dwarf2read.c:new_symbol_full is called
the DIE has no name (dwarf2_name returns NULL).
PR 17976: ptype '(anonymous namespace)' should work like any namespace
PR 17821: perf issue looking up (anonymous namespace)
bash$ gdb monster-program
(gdb) mt set per on
(gdb) mt set symbol-cache-size 0
(gdb) break (anonymous namespace)::foo
Before:
Command execution time: 3.266289 (cpu), 6.169030 (wall)
Space used: 811429888 (+12910592 for this command)
After:
Command execution time: 1.264076 (cpu), 4.057408 (wall)
Space used: 798781440 (+0 for this command)
gdb/ChangeLog:
PR c++/17976, symtab/17821
* cp-namespace.c (cp_search_static_and_baseclasses): New parameter
is_in_anonymous. All callers updated.
(find_symbol_in_baseclass): Ditto.
(cp_lookup_nested_symbol_1): Ditto. Don't search all static blocks
for symbols in an anonymous namespace.
* dwarf2read.c (namespace_name): Don't call dwarf2_name, fetch
DW_AT_name directly.
(dwarf2_name): Convert missing namespace name to
CP_ANONYMOUS_NAMESPACE_STR.
gdeb/testsuite/ChangeLog:
* gdb.cp/anon-ns.exp: Add test for ptype '(anonymous namespace)'.
gdb/testsuite/ChangeLog
2015-02-21 Jan Kratochvil <jan.kratochvil@redhat.com>
PR corefiles/17808
* gdb.arch/i386-biarch-core.core.bz2: New file.
* gdb.arch/i386-biarch-core.exp: New file.
The buildbot shows that the new
gdb.threads/multi-create-ns-info-thr.exp test is timing out when
tested with --target=native-extended-remote. The reason is:
No breakpoints or watchpoints.
(gdb) break main
Breakpoint 1 at 0x10000b00: file ../../../binutils-gdb/gdb/testsuite/gdb.threads/multi-create.c, line 72.
(gdb) run
Starting program: /home/gdb-buildbot/fedora-21-ppc64be-1/fedora-ppc64be-native-extended-gdbserver/build/gdb/testsuite/outputs/gdb.threads/multi-create-ns-info-thr/multi-cre
ate-ns-info-thr
Process /home/gdb-buildbot/fedora-21-ppc64be-1/fedora-ppc64be-native-extended-gdbserver/build/gdb/testsuite/outputs/gdb.threads/multi-create-ns-info-thr/multi-create-ns-inf
o-thr created; pid = 16266
Unexpected vCont reply in non-stop mode: T0501:00003fffffffd190;40:00000080560fe290;thread:p3f8a.3f8a;core:0;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(gdb) break multi-create.c:45
Breakpoint 2 at 0x10000994: file ../../../binutils-gdb/gdb/testsuite/gdb.threads/multi-create.c, line 45.
(gdb) commands
Type commands for breakpoint(s) 2, one per line.
Non-stop tests don't really work with the
--target_board=native-extended-remote board, because tests toggle
non-stop on after GDB is already connected to gdbserver, while
Currently, non-stop must be enabled before connecting.
This adjusts the test to bail if running to main fails, like all other
non-stop tests.
Note non-stop tests do work with --target_board=native-gdbserver.
gdb/testsuite/ChangeLog:
2015-02-21 Pedro Alves <palves@redhat.com>
* gdb.threads/multi-create-ns-info-thr.exp: Return early if
runto_main fails.
Commit 6f9b8491 (Adapt `info probes' to support printing probes of
different types.) added a new type column to "info probes". That
caused a solib-corrupted.exp regression:
~~~~~~~~~~~~~~~~~~~~~
Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/solib-corrupted.exp ...
FAIL: gdb.base/solib-corrupted.exp: corrupted list
=== gdb Summary ===
# of expected passes 2
# of unexpected failures 1
~~~~~~~~~~~~~~~~~~~~~
Tested on x86_64 Fedora 20.
gdb/testsuite/ChangeLog:
2015-02-20 Pedro Alves <palves@redhat.com>
* gdb.base/solib-corrupted.exp: Expect "stap" as first column of
info probes.
TL;DR - GDB can hang if something refreshes the thread list out of the
target while the target is running. GDB hangs inside td_ta_thr_iter.
The fix is to not use that libthread_db function anymore.
Long version:
Running the testsuite against my all-stop-on-top-of-non-stop series is
still exposing latent non-stop bugs.
I was originally seeing this with the multi-create.exp test, back when
we were still using libthread_db thread event breakpoints. The
all-stop-on-top-of-non-stop series forces a thread list refresh each
time GDB needs to start stepping over a breakpoint (to pause all
threads). That test hits the thread event breakpoint often, resulting
in a bunch of step-over operations, thus a bunch of thread list
refreshes while some threads in the target are running.
The commit adds a real non-stop mode test that triggers the issue,
based on multi-create.exp, that does an explicit "info threads" when a
breakpoint is hit. IOW, it does the same things the as-ns series was
doing when testing multi-create.exp.
The bug is a race, so it unfortunately takes several runs for the test
to trigger it. In fact, even when setting the test running in a loop,
it sometimes takes several minutes for it to trigger for me.
The race is related to libthread_db's td_ta_thr_iter. This is
libthread_db's entry point for walking the thread list of the
inferior.
Sometimes, when GDB refreshes the thread list from the target,
libthread_db's td_ta_thr_iter can somehow see glibc's thread list as a
cycle, and get stuck in an infinite loop.
The issue is that when a thread exits, its thread control structure in
glibc is moved from a "used" list to a "cache" list. These lists are
simply circular linked lists where the "next/prev" pointers are
embedded in the thread control structure itself. The "next" pointer
of the last element of the list points back to the list's sentinel
"head". There's only one set of "next/prev" pointers for both lists;
thus a thread can only be in one of the lists at a time, not in both
simultaneously.
So when thread C exits, simplifying, the following happens. A-C are
threads. stack_used and stack_cache are the list's heads.
Before:
stack_used -> A -> B -> C -> (&stack_used)
stack_cache -> (&stack_cache)
After:
stack_used -> A -> B -> (&stack_used)
stack_cache -> C -> (&stack_cache)
td_ta_thr_iter starts by iterating at the list's head's next, and
iterates until it sees a thread whose next pointer points to the
list's head again. Thus in the before case above, C's next points to
stack_used, indicating end of list. In the same case, the stack_cache
list is empty.
For each thread being iterated, td_ta_thr_iter reads the whole thread
object out of the inferior. This includes the thread's "next"
pointer.
In the scenario above, it may happen that td_ta_thr_iter is iterating
thread B and has already read B's thread structure just before thread
C exits and its control structure moves to the cached list.
Now, recall that td_ta_thr_iter is running in the context of GDB, and
there's no locking between GDB and the inferior. From it's local copy
of B, td_ta_thr_iter believes that the next thread after B is thread
C, so it happilly continues iterating to C, a thread that has already
exited, and is now in the stack cache list.
After iterating C, td_ta_thr_iter finds the stack_cache head, which
because it is not stack_used, td_ta_thr_iter assumes it's just another
thread. After this, unless the reverse race triggers, GDB gets stuck
in td_ta_thr_iter forever walking the stack_cache list, as no thread
in thatlist has a next pointer that points back to stack_used (the
terminating condition).
Before fully understanding the issue, I tried adding cycle detection
to GDB's td_ta_thr_iter callback. However, td_ta_thr_iter skips
calling the callback in some cases, which means that it's possible
that the callback isn't called at all, making it impossible for GDB to
break the loop. I did manage to get GDB stuck in that state more than
once.
Fortunately, we can avoid the issue altogether. We don't really need
td_ta_thr_iter for live debugging nowadays, given PTRACE_EVENT_CLONE.
We already know how to map and lwp id to a thread id without iterating
(thread_from_lwp), so use that more.
gdb/ChangeLog:
2015-02-20 Pedro Alves <palves@redhat.com>
* linux-nat.c (linux_handle_extended_wait): Call
thread_db_notice_clone whenever a new clone LWP is detected.
(linux_stop_and_wait_all_lwps, linux_unstop_all_lwps): New
functions.
* linux-nat.h (thread_db_attach_lwp): Delete declaration.
(thread_db_notice_clone, linux_stop_and_wait_all_lwps)
(linux_unstop_all_lwps): Declare.
* linux-thread-db.c (struct thread_get_info_inout): Delete.
(thread_get_info_callback): Delete.
(thread_from_lwp): Use td_thr_get_info and record_thread.
(thread_db_attach_lwp): Delete.
(thread_db_notice_clone): New function.
(try_thread_db_load_1): If /proc is mounted and shows the
process'es task list, walk over all LWPs and call thread_from_lwp
instead of relying on td_ta_thr_iter.
(attach_thread): Don't call check_thread_signals here. Split the
tail part of the function (which adds the thread to the core GDB
thread list) to ...
(record_thread): ... this function. Call check_thread_signals
here.
(thread_db_wait): Don't call thread_db_find_new_threads_1. Always
call thread_from_lwp.
(thread_db_update_thread_list): Rename to ...
(thread_db_update_thread_list_org): ... this.
(thread_db_update_thread_list): New function.
(thread_db_find_thread_from_tid): Delete.
(thread_db_get_ada_task_ptid): Simplify.
* nat/linux-procfs.c: Include <sys/stat.h>.
(linux_proc_task_list_dir_exists): New function.
* nat/linux-procfs.h (linux_proc_task_list_dir_exists): Declare.
gdb/gdbserver/ChangeLog:
2015-02-20 Pedro Alves <palves@redhat.com>
* thread-db.c: Include "nat/linux-procfs.h".
(thread_db_init): Skip listing new threads if the kernel supports
PTRACE_EVENT_CLONE and /proc/PID/task/ is accessible.
gdb/testsuite/ChangeLog:
2015-02-20 Pedro Alves <palves@redhat.com>
* gdb.threads/multi-create-ns-info-thr.exp: New file.
$ make check RUNTESTFLAGS="--target_board=native-gdbserver no-attach-trace.exp"
...
(gdb) trace main
Tracepoint 1 at 0x400594: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.trace/no-attach-trace.c, line 25.
(gdb) PASS: gdb.trace/no-attach-trace.exp: set tracepoint on main
tstart
You can't do that when your target is `exec'
(gdb) FAIL: gdb.trace/no-attach-trace.exp: tstart
Even though this target supports tracing, the test restarts GDB and
doesn't do gdb_run_cmd so does not reconnect to the remote target. So
at that point, GDB only has the "exec" target, which obviously doesn't
do tracing.
The test is about doing "tstart" before running a program, so the fix
is to do gdb_target_supports_trace with whatever target GDB ends up
connected after clean_restart.
Tested on x86_64 Fedora 20, native, native-gdbserver and
native-extended-gdbserver boards. The test passes with the latter,
and is skipped with the first two.
gdb/testsuite/ChangeLog:
2015-02-20 Pedro Alves <palves@redhat.com>
* gdb.trace/no-attach-trace.exp: Don't run to main. Do
clean_restart before gdb_target_supports_trace.
On GNU/Linux, if a pthreaded program has a thread call clone(CLONE_VM)
directly, and then that clone LWP hits a debug event (breakpoint,
etc.) GDB internal errors. Threaded programs shouldn't really be
calling clone directly, but GDB shouldn't crash either.
The crash looks like this:
(gdb) break clone_fn
Breakpoint 2 at 0x4007d8: file clone-thread_db.c, line 35.
(gdb) r
...
[Thread debugging using libthread_db enabled]
...
src/gdb/linux-nat.c:1030: internal-error: lin_lwp_attach_lwp: Assertion `lwpid > 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
The problem is that 'clone' ends up clearing the parent thread's tid
field in glibc's thread data structure. For x86_64, the glibc code in
question is here:
sysdeps/unix/sysv/linux/x86_64/clone.S:
...
testq $CLONE_THREAD, %rdi
jne 1f
testq $CLONE_VM, %rdi
movl $-1, %eax <----
jne 2f
movl $SYS_ify(getpid), %eax
syscall
2: movl %eax, %fs:PID
movl %eax, %fs:TID <----
1:
When GDB refreshes the thread list out of libthread_db, it finds a
thread with LWP with pid -1 (the clone's parent), which naturally
isn't yet on the thread list. GDB then tries to attach to that bogus
LWP id, which is caught by that assertion.
The fix is to detect the bad PID early.
Tested on x86-64 Fedora 20. GDBserver doesn't need any fix.
gdb/ChangeLog:
2015-02-20 Pedro Alves <palves@redhat.com>
PR threads/18006
* linux-thread-db.c (thread_get_info_callback): Return early if
the thread's lwp id is -1.
gdb/testsuite/ChangeLog:
2015-02-20 Pedro Alves <palves@redhat.com>
PR threads/18006
* gdb.threads/clone-thread_db.c: New file.
* gdb.threads/clone-thread_db.exp: New file.
When gdb creates a dummy frame to execute a function in the inferior,
the process may generate a SIGSEGV, SIGTRAP or SIGILL because the stack
is non executable. If the signal handler set in gdb has option print
or stop enabled for these signals gdb handles this correctly.
However, in the case of noprint and nostop the signal is short-circuited
and the inferior process is sent the signal directly. This causes the
inferior to crash because of gdb.
This patch adds a check for SIGSEGV, SIGTRAP or SIGILL so that these
signals are sent to gdb rather than short-circuited in the inferior.
gdb then handles them properly and the inferior process does not
crash.
This patch also fixes the same behavior in gdbserver.
Also added a small testcase to test the issue called catch-gdb-caused-signals.
This applies to Linux only, tested on Linux.
gdb/ChangeLog:
PR breakpoints/16812
* linux-nat.c (linux_nat_filter_event): Report SIGTRAP,SIGILL,SIGSEGV.
* nat/linux-ptrace.c (linux_wstatus_maybe_breakpoint): Add.
* nat/linux-ptrace.h: Add linux_wstatus_maybe_breakpoint.
gdb/gdbserver/ChangeLog:
PR breakpoints/16812
* linux-low.c (wstatus_maybe_breakpoint): Remove.
(linux_low_filter_event): Update wstatus_maybe_breakpoint name.
(linux_wait_1): Report SIGTRAP,SIGILL,SIGSEGV.
gdb/testsuite/ChangeLog:
PR breakpoints/16812
* gdb.base/catch-gdb-caused-signals.c: New file.
* gdb.base/catch-gdb-caused-signals.exp: New file.
This patch introduces a new M4 macro GDB_AC_TRANSFORM to avoid repeating
the common idiom which is the transformation of target program names,
i.e. from gdb to sparc64-linux-gnu-gdb. It also makes gdb/configure.ac
and gdb/testsuite/configure.ac to use the new macro.
gdb/ChangeLog:
2015-02-18 Jose E. Marchesi <jose.marchesi@oracle.com>
* configure: Regenerated.
* configure.ac: Use GDB_AC_TRANSFORM.
* Makefile.in (aclocal_m4_deps): Added transform.m4.
* acinclude.m4: sinclude transform.m4.
* transform.m4: New file.
(GDB_AC_TRANSFORM): New macro.
gdb/testsuite/ChangeLog:
2015-02-18 Jose E. Marchesi <jose.marchesi@oracle.com>
* configure: Regenerated.
* configure.ac: Use GDB_AC_TRANSFORM.
* aclocal.m4: sinclude ../transform.m4.
This patch adds some simple tests testing the support for DTrace USDT
probes. The testsuite will be skipped as unsupported in case the user
does not have DTrace installed on her system. The tests included in the
test suite test breakpointing on DTrace probes, enabling and disabling
probes, printing of probe arguments of several types and also
breakpointing on several probes with the same name.
gdb/ChangeLog:
2015-02-17 Jose E. Marchesi <jose.marchesi@oracle.com>
* lib/dtrace.exp: New file.
* gdb.base/dtrace-probe.exp: Likewise.
* gdb.base/dtrace-probe.d: Likewise.
* gdb.base/dtrace-probe.c: Likewise.
* lib/pdtrace.in: Likewise.
* configure.ac: Output variables with the transformed names of
the strip, readelf, as and nm tools. AC_SUBST lib/pdtrace.in.
* configure: Regenerated.
This patch moves the `compute_probe_arg' and `compile_probe_arg' functions
from stap-probe.c to probe.c. The rationale is that it is reasonable to
assume that all backends will provide the `$_probe_argN' convenience
variables, and that the user must be placed on the PC of the probe when
requesting that information. The value and type of the argument can still be
determined by the probe backend via the `pops->evaluate_probe_argument' and
`pops->compile_to_ax' handlers.
Note that a test in gdb.base/stap-probe.exp had to be adjusted because the "No
SystemTap probe at PC" messages are now "No probe at PC".
gdb/ChangeLog:
2015-02-17 Jose E. Marchesi <jose.marchesi@oracle.com>
* probe.c (compute_probe_arg): Moved from stap-probe.c
(compile_probe_arg): Likewise.
(probe_funcs): Likewise.
* stap-probe.c (compute_probe_arg): Moved to probe.c.
(compile_probe_arg): Likewise.
(probe_funcs): Likewise.
gdb/testsuite/ChangeLog:
2015-02-17 Jose E. Marchesi <jose.marchesi@oracle.com>
* gdb.base/stap-probe.exp (stap_test): Remove "SystemTap" from
expected message when trying to access $_probe_* convenience
variables while not on a probe.
It definitely does not test all the RETURN_MASK_ERROR cases. But it tests at
least two of them.
gdb/testsuite/ChangeLog
2015-02-11 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.python/py-framefilter.exp (pagination quit - *): New tests.
On decr_pc_after_break targets, GDB adjusts the PC incorrectly if a
background single-step stops somewhere where PC-$decr_pc has a
breakpoint, and the thread that finishes the step is not the current
thread, like:
ADDR1 nop <-- breakpoint here
ADDR2 jmp PC
IOW, say thread A is stepping ADDR2's line in the background (an
infinite loop), and the user switches focus to thread B. GDB's
adjust_pc_after_break logic confuses the single-step stop of thread A
for a hit of the breakpoint at ADDR1, and thus adjusts thread A's PC
to point at ADDR1 when it should not, and reports a breakpoint hit,
when thread A did not execute the instruction at ADDR1 at all.
The test added by this patch exercises exactly that.
I can't find any reason we'd need the "thread to be examined is still
the current thread" condition in adjust_pc_after_break, at least
nowadays; it might have made sense in the past. Best just remove it,
and rely on currently_stepping().
Here's the test's log of a run with an unpatched GDB:
35 while (1);
(gdb) PASS: gdb.threads/step-bg-decr-pc-switch-thread.exp: next over nop
next&
(gdb) PASS: gdb.threads/step-bg-decr-pc-switch-thread.exp: next& over inf loop
thread 1
[Switching to thread 1 (Thread 0x7ffff7fc2740 (LWP 29027))](running)
(gdb)
PASS: gdb.threads/step-bg-decr-pc-switch-thread.exp: switch to main thread
Breakpoint 2, thread_function (arg=0x0) at ...src/gdb/testsuite/gdb.threads/step-bg-decr-pc-switch-thread.c:34
34 NOP; /* set breakpoint here */
FAIL: gdb.threads/step-bg-decr-pc-switch-thread.exp: no output while stepping
gdb/ChangeLog:
2015-02-11 Pedro Alves <pedro@codesourcery.com>
* infrun.c (adjust_pc_after_break): Don't adjust the PC just
because the event thread is not the current thread.
gdb/testsuite/ChangeLog:
2015-02-11 Pedro Alves <pedro@codesourcery.com>
* gdb.threads/step-bg-decr-pc-switch-thread.c: New file.
* gdb.threads/step-bg-decr-pc-switch-thread.exp: New file.
Some local changes I was working on related to SIGTRAP handling
resulted in "signal SIGTRAP" no longer passing the SIGTRAP to the
inferior.
Surprisingly, only annota1.exp catches this. This commit adds a test
that doesn't rely on annotations, so that at the point annotations are
finaly dropped, we still have this use case covered ...
This is a multi-threaded test to also exercise the case of first
needing to do a step-over before delivering the signal.
Tested on x86_64 Fedora 20, native, remote/extended-remote gdbserver.
gdb/testsuite/
2015-02-10 Pedro Alves <palves@redhat.com>
* gdb.threads/signal-sigtrap.c: New file.
* gdb.threads/signal-sigtrap.exp: New file.
When gdbserver is called with --multi and attach has not been called yet
and tstart is called on the gdb client, gdbserver would crash.
This patch fixes gdbserver so that it returns E01 to the gdb client.
Also this patch adds a testcase to verify this bug named no-attach-trace.exp
gdb/gdbserver/ChangeLog:
PR breakpoints/15956
* tracepoint.c (cmd_qtinit): Add check for current_thread.
gdb/testsuite/ChangeLog:
* gdb.trace/no-attach-trace.c: New file.
* gdb.trace/no-attach-trace.exp: New file.
Indicate gaps in the trace due to decode errors. Internally, a gap is
represented as a btrace function segment without instructions and with a
non-zero format-specific error code.
Show the gap when traversing the instruction or function call history.
Also indicate gaps in "info record".
It looks like this:
(gdb) info record
Active record target: record-btrace
Recording format: Branch Trace Store.
Buffer size: 64KB.
Recorded 32 instructions in 5 functions (1 gaps) for thread 1 (process 7182).
(gdb) record function-call-history /cli
1 fib inst 1,9 at src/fib.c:9,14
2 fib inst 10,20 at src/fib.c:6,14
3 [decode error (1): instruction overflow]
4 fib inst 21,28 at src/fib.c:11,14
5 fib inst 29,33 at src/fib.c:6,9
(gdb) record instruction-history 20,22
20 0x000000000040062f <fib+47>: sub $0x1,%rax
[decode error (1): instruction overflow]
21 0x0000000000400613 <fib+19>: add $0x1,%rax
22 0x0000000000400617 <fib+23>: mov %rax,0x200a3a(%rip)
(gdb)
Gaps are ignored during reverse execution and replay.
2015-02-09 Markus Metzger <markus.t.metzger@intel.com>
* btrace.c (ftrace_find_call): Skip gaps.
(ftrace_new_function): Initialize level.
(ftrace_new_call, ftrace_new_tailcall, ftrace_new_return)
(ftrace_new_switch): Update
level computation.
(ftrace_new_gap): New.
(ftrace_update_function): Create new function after gap.
(btrace_compute_ftrace_bts): Create gap on error.
(btrace_stitch_bts): Update parameters. Clear trace if it
becomes empty.
(btrace_stitch_trace): Update parameters. Update callers.
(btrace_clear): Reset the number of gaps.
(btrace_insn_get): Return NULL if the iterator points to a gap.
(btrace_insn_number): Return zero if the iterator points to a gap.
(btrace_insn_end): Allow gaps at the end.
(btrace_insn_next, btrace_insn_prev, btrace_insn_cmp): Handle gaps.
(btrace_find_insn_by_number): Assert that the found iterator does
not point to a gap.
(btrace_call_next, btrace_call_prev): Assert that the last function
is not a gap.
* btrace.h (btrace_bts_error): New.
(btrace_function): Update comment.
(btrace_function) <insn, insn_offset, number>: Update comment.
(btrace_function) <errcode>: New.
(btrace_thread_info) <ngaps>: New.
(btrace_thread_info) <replay>: Update comment.
(btrace_insn_get): Update comment.
* record-btrace.c (btrace_ui_out_decode_error): New.
(record_btrace_info): Print number of gaps.
(btrace_insn_history, btrace_call_history): Call
btrace_ui_out_decode_error for gaps.
(record_btrace_step_thread, record_btrace_start_replaying): Skip gaps.
testsuite/
* gdb.btrace/buffer-size.exp: Update "info record" output.
* gdb.btrace/delta.exp: Update "info record" output.
* gdb.btrace/enable.exp: Update "info record" output.
* gdb.btrace/finish.exp: Update "info record" output.
* gdb.btrace/instruction_history.exp: Update "info record" output.
* gdb.btrace/next.exp: Update "info record" output.
* gdb.btrace/nexti.exp: Update "info record" output.
* gdb.btrace/step.exp: Update "info record" output.
* gdb.btrace/stepi.exp: Update "info record" output.
* gdb.btrace/nohist.exp: Update "info record" output.