aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite
AgeCommit message (Collapse)AuthorFilesLines
2015-03-09Make dg-extract-results.sh explicitly treat .{sum,log} files as textPedro Alves2-5/+28
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.
2015-03-05gdb.base/bp-permanent.exp: Tighten regexPedro Alves2-1/+5
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.
2015-03-04Accept all-stop alternative in mi_expect_interruptSimon Marchi2-2/+8
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.
2015-03-04Fix gdb.threads/thread-specific-bp.exp racePedro Alves2-13/+4
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.
2015-03-04Stupid git!Mark Kettenis1-1/+1
Apparently fixing a typo while you're editing the commit message doesn't work.
2015-03-04Enable gdb.base/foll-fork.exp on OpenBSDMark Kettenis2-1/+6
gdb/testsuite/ 2015-03-04 Mark Kettenis <kettenis@gnu.org> * gdb.base/foll-fork.exp: Enable on *-*-openbsd*.
2015-03-04breakpoint-in-ro-region.exp: Support targets stopping in mid-line after "si"Andreas Arnez2-2/+9
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.
2015-03-04catch-syscall.exp: Fix missing architecture name for s390:31-bitAndreas Arnez2-1/+6
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.
2015-03-04gdb.threads/clone-thread_db.c: Add missing includes and fix pthread_join callPedro Alves2-1/+8
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.
2015-03-03follow-exec: delete all non-execing threadsPedro Alves2-3/+26
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.
2015-03-02gdb_test_multiple: return -1 on internal errorPedro Alves2-0/+6
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.
2015-03-02S390: Vector register test caseAndreas Arnez3-0/+303
Add a test case for S/390 vector registers support. gdb/testsuite/ChangeLog: * gdb.arch/s390-vregs.exp: New test. * gdb.arch/s390-vregs.S: New file.
2015-02-27catch_command_errors: Remove 'mask' parameterPedro Alves3-2/+9
All callers of catch_command_errors pass RETURN_MASK_ALL as mask argument. This patch eliminates the mask parameter as unnecessary. gdb/ChangeLog: 2015-02-27 Pedro Alves <palves@redhat.com> * main.c (catch_command_errors, catch_command_errors_const): Remove 'mask' argument. Adjust. (captured_main): Adjust callers. gdb/testsuite/ChangeLog: 2015-02-27 Pedro Alves <palves@redhat.com> * gdb.gdb/python-interrupts.exp (test_python_interrupts): Adjust call to catch_command_errors. * gdb.gdb/python-selftest.exp (selftest_python): Adjust call to catch_command_errors.
2015-02-27Adjust self tests to cope with GDB built as a C++ programPedro Alves3-3/+16
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.
2015-02-27Add "../lib/unbuffer_output.c" and use it in gdb.base/interrupt.cPedro Alves3-0/+50
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.
2015-02-27Don't skip catch-syscall.exp on hppa*-hp-hpux* targetYao Qi2-7/+6
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.
2015-02-26Add missing CHECK_TYPEDEF calls to recent vptr_{fieldno,basetype} cleanup.Doug Evans5-1/+70
gdb/ChangeLog: * gdbtypes.c (internal_type_vptr_fieldno): Add missing call to CHECK_TYPEDEF. (set_type_vptr_fieldno): Ditto. (internal_type_vptr_basetype, set_type_vptr_basetype): Ditto. * gnu-v3-abi.c (gnuv3_dynamic_class): Ditto. gdb/testsuite/ChangeLog: * gdb.cp/class2.cc (Dbase, D): New classes. (main): New local delta. * gdb.cp/class2.exp: Test printing delta. * gdb.cp/classes.cc (DynamicBase2, DynamicBar): New classes. (dynbar): New global. * gdb.cp/classes.exp (test_ptype_class_objects): Test ptype DynamicBar.
2015-02-26compile: Fix GNU-IFUNC funcs called from injected codeJan Kratochvil3-0/+105
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.
2015-02-26Fix print of value type in a corner case of finishAntoine Tremblay2-1/+5
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.
2015-02-26Dwarf assembler: handle one instruction functionYao Qi2-1/+11
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.
2015-02-26SEGV in ppc64_elf_get_synthetic_symtab reading a separate debug fileJan Kratochvil4-0/+57
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.
2015-02-25[aarch64] Fix one fail in gdb.xml/tdesc-regs.expYao Qi2-0/+8
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.
2015-02-23delete_breakpoints: Rewrite using gdb_test_multiplePedro Alves2-14/+29
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.
2015-02-23gdb.base/info-os.c: Include stdlib.hPedro Alves2-0/+5
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.
2015-02-22testcase for PR symtab/17855Doug Evans4-2/+49
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.
2015-02-21PR c++/17976, symtab/17821Doug Evans2-0/+8
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)'.
2015-02-21Testsuite patch for: i386: Fix internal error when prstatus in core file is ↵Jan Kratochvil3-0/+64
too big 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.
2015-02-21gdb.threads/multi-create-ns-info-thr.exp and native-extended-remote boardPedro Alves2-1/+8
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.
2015-02-20Fix gdb.base/solib-corrupted.exp after dtrace probes changesPedro Alves2-1/+6
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.
2015-02-20GNU/Linux: Stop using libthread_db/td_ta_thr_iterPedro Alves2-0/+54
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.
2015-02-20Fix no-attach-trace.exp with "target remote" / gdbserverPedro Alves2-9/+10
$ 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.
2015-02-20PR18006: internal error if threaded program calls clone(CLONE_VM)Pedro Alves3-0/+116
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.
2015-02-19Fix non executable stack handling when calling functions in the inferior.Antoine Tremblay3-0/+105
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.
2015-02-18Factorize target program transformations in the GDB_AC_TRANSFORM macro.Jose E. Marchesi4-38/+39
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.
2015-02-17Simple testsuite for DTrace USDT probes.Jose E. Marchesi8-0/+1357
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.
2015-02-17Move `compute_probe_arg' and `compile_probe_arg' to probe.cJose E. Marchesi2-1/+7
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.
2015-02-11framefilter quit: New testJan Kratochvil2-0/+17
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.
2015-02-11Fix adjust_pc_after_break, remove still current thread checkPedro Alves3-0/+150
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.
2015-02-10lib/gdb.exp (gdb_load): Always return a result.Doug Evans2-0/+6
gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_load): Always return a result.
2015-02-10Add "signal SIGTRAP" testPedro Alves3-0/+118
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.
2015-02-10gdbserver: Fix crash when QTinit is handled with no inferior process attachedAntoine Tremblay4-2/+86
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.
2015-02-09GCC5/DWARFv5 Handle DW_TAG_atomic_type for C11 _Atomic type qualifier.Mark Wielaard3-0/+128
gdb/ChangeLog * c-typeprint.c (cp_type_print_method_args): Handle '_Atomic'. (c_type_print_modifier): Likewise. * dwarf2read.c (read_tag_atomic_type): New function. (read_type_die_1): Handle DW_TAG_atomic_type. * gdbtypes.c (make_atomic_type): New function. (recursive_dump_type): Handle TYPE_ATOMIC. * gdbtypes.h (enum type_flag_values): Renumber. (enum type_instance_flag_value): Add TYPE_INSTANCE_FLAG_ATOMIC. (TYPE_ATOMIC): New macro. (make_atomic_type): Declare. gdb/testsuite/ChangeLog * gdb.dwarf2/atomic.c: New file. * gdb.dwarf2/atomic-type.exp: Likewise. include/ChangeLog * dwarf2.def: Add DW_TAG_atomic_type.
2015-02-09record-btrace: indicate gapsMarkus Metzger11-18/+31
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.
2015-02-09record-btrace: add bts buffer size configuration optionMarkus Metzger2-0/+61
Allow the size of the branch trace ring buffer to be defined by the user. The specified buffer size will be used when BTS tracing is enabled for new threads. The obtained buffer size may differ from the requested size. The actual buffer size for the current thread is shown in the "info record" command. Bigger buffers mean longer traces, but also longer processing time. 2015-02-09 Markus Metzger <markus.t.metzger@intel.com> * btrace.c (parse_xml_btrace_conf_bts): Add size. (btrace_conf_bts_attributes): New. (btrace_conf_children): Add attributes. * common/btrace-common.h (btrace_config_bts): New. (btrace_config)<bts>: New. (btrace_config): Update comment. * nat/linux-btrace.c (linux_enable_btrace, linux_enable_bts): Use config. * features/btrace-conf.dtd: Increment version. Add size attribute to bts element. * record-btrace.c (set_record_btrace_bts_cmdlist, show_record_btrace_bts_cmdlist): New. (record_btrace_adjust_size, record_btrace_print_bts_conf, record_btrace_print_conf, cmd_set_record_btrace_bts, cmd_show_record_btrace_bts): New. (record_btrace_info): Call record_btrace_print_conf. (_initialize_record_btrace): Add commands. * remote.c: Add PACKET_Qbtrace_conf_bts_size enum. (remote_protocol_features): Add Qbtrace-conf:bts:size packet. (btrace_sync_conf): Synchronize bts size. (_initialize_remote): Add Qbtrace-conf:bts:size packet. * NEWS: Announce new commands and new packets. doc/ * gdb.texinfo (Branch Trace Configuration Format): Add size. (Process Record and Replay): Describe new set|show commands. (General Query Packets): Describe Qbtrace-conf:bts:size packet. testsuite/ * gdb.btrace/buffer-size: New. gdbserver/ * linux-low.c (linux_low_btrace_conf): Print size. * server.c (handle_btrace_conf_general_set): New. (hanle_general_set): Call handle_btrace_conf_general_set. (handle_query): Report Qbtrace-conf:bts:size as supported.
2015-02-09record btrace: add configuration structMarkus Metzger10-2/+30
Add a struct to describe the branch trace configuration and use it for enabling branch tracing. The user will be able to set configuration fields for each tracing format to be used for new threads. The actual configuration that is active for a given thread will be shown in the "info record" command. At the moment, the configuration struct only contains a format field that is set to the only available format. The format is the only configuration option that can not be set via set commands. It is given as argument to the "record btrace" command when starting recording. 2015-02-09 Markus Metzger <markus.t.metzger@intel.com> * Makefile.in (XMLFILES): Add btrace-conf.dtd. * x86-linux-nat.c (x86_linux_enable_btrace): Update parameters. (x86_linux_btrace_conf): New. (x86_linux_create_target): Initialize to_btrace_conf. * nat/linux-btrace.c (linux_enable_btrace): Update parameters. Check format. Split into this and ... (linux_enable_bts): ... this. (linux_btrace_conf): New. (perf_event_skip_record): Renamed into ... (perf_event_skip_bts_record): ... this. Updated users. (linux_disable_btrace): Split into this and ... (linux_disable_bts): ... this. (linux_read_btrace): Check format. * nat/linux-btrace.h (linux_enable_btrace): Update parameters. (linux_btrace_conf): New. (btrace_target_info)<ptid>: Moved. (btrace_target_info)<conf>: New. (btrace_target_info): Split into this and ... (btrace_tinfo_bts): ... this. Updated users. * btrace.c (btrace_enable): Update parameters. (btrace_conf, parse_xml_btrace_conf_bts, parse_xml_btrace_conf) (btrace_conf_children, btrace_conf_attributes) (btrace_conf_elements): New. * btrace.h (btrace_enable): Update parameters. (btrace_conf, parse_xml_btrace_conf): New. * common/btrace-common.h (btrace_config): New. * feature/btrace-conf.dtd: New. * record-btrace.c (record_btrace_conf): New. (record_btrace_cmdlist): New. (record_btrace_enable_warn, record_btrace_open): Pass &record_btrace_conf. (record_btrace_info): Print recording format. (cmd_record_btrace_bts_start): New. (cmd_record_btrace_start): Call cmd_record_btrace_bts_start. (_initialize_record_btrace): Add "record btrace bts" subcommand. Add "record bts" alias command. * remote.c (remote_state)<btrace_config>: New. (remote_btrace_reset, PACKET_qXfer_btrace_conf): New. (remote_protocol_features): Add qXfer:btrace-conf:read. (remote_open_1): Call remote_btrace_reset. (remote_xfer_partial): Handle TARGET_OBJECT_BTRACE_CONF. (btrace_target_info)<conf>: New. (btrace_sync_conf, btrace_read_config): New. (remote_enable_btrace): Update parameters. Call btrace_sync_conf and btrace_read_conf. (remote_btrace_conf): New. (init_remote_ops): Initialize to_btrace_conf. (_initialize_remote): Add qXfer:btrace-conf packet. * target.c (target_enable_btrace): Update parameters. (target_btrace_conf): New. * target.h (target_enable_btrace): Update parameters. (target_btrace_conf): New. (target_object)<TARGET_OBJECT_BTRACE_CONF>: New. (target_ops)<to_enable_btrace>: Update parameters and comment. (target_ops)<to_btrace_conf>: New. * target-delegates: Regenerate. * target-debug.h (target_debug_print_const_struct_btrace_config_p) (target_debug_print_const_struct_btrace_target_info_p): New. NEWS: Announce new command and new packet. doc/ * gdb.texinfo (Process Record and Replay): Describe the "record btrace bts" command. (General Query Packets): Describe qXfer:btrace-conf:read packet. (Branch Trace Configuration Format): New. gdbserver/ * linux-low.c (linux_low_enable_btrace): Update parameters. (linux_low_btrace_conf): New. (linux_target_ops)<to_btrace_conf>: Initialize. * server.c (current_btrace_conf): New. (handle_btrace_enable): Rename to ... (handle_btrace_enable_bts): ... this. Pass &current_btrace_conf to target_enable_btrace. Update comment. Update users. (handle_qxfer_btrace_conf): New. (qxfer_packets): Add btrace-conf entry. (handle_query): Report qXfer:btrace-conf:read as supported packet. * target.h (target_ops)<enable_btrace>: Update parameters and comment. (target_ops)<read_btrace_conf>: New. (target_enable_btrace): Update parameters. (target_read_btrace_conf): New. testsuite/ * 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.
2015-02-06"enable count" user input error handling (PR gdb/15678)Simon Marchi2-0/+13
Typing "enable count" by itself crashes GDB. Also, if you omit the breakpoint number/range, the error message is not very clear: (gdb) enable count 2 warning: bad breakpoint number at or near '' (gdb) enable count Segmentation fault (core dumped) With this patch, the error messages are slightly more helpful: (gdb) enable count 2 Argument required (one or more breakpoint numbers). (gdb) enable count Argument required (hit count). gdb/ChangeLog: PR gdb/15678 * breakpoint.c (map_breakpoint_numbers): Check for empty args string. (enable_count_command): Check args for NULL value. gdb/testsuite/ChangeLog: PR gdb/15678 * gdb.base/ena-dis-br.exp: Test "enable count" for bad user input.
2015-02-06Improve gdb.threads/attach-many-short-lived-threads.exp timeout handlingPedro Alves3-4/+51
The buildbot shows that this test is still racy, and occasionally fails with time outs on some machines. I'd like to get major issues with load out of the way. The test currently exits after 180s, which is just a random number, that has no relation to what the .exp file considers a time out. This commit makes the program wait a bit longer than what the .exp file considers a time out, and, resets the timer for each iteration. Tested on x86_64 Fedora 20, native and extended-remote gdbserver. gdb/testsuite/ 2015-02-06 Pedro Alves <palves@redhat.com> * gdb.threads/attach-many-short-lived-threads.c (SECONDS): New macro. (seconds_left, again): New globals. (main): Wait seconds_left in a 1-second sleep loop instead of sleeping 180 seconds. If 'again' is set, reset the seconds counter. * gdb.threads/attach-many-short-lived-threads.exp (test): Set 'again' in the inferior before detaching. Print the seconds left. (options): New global. (top level): Build program with -DTIMEOUT=$timeout.
2015-02-06gdb.base/gdb-sigterm.exp: Fix spurious FAILsPedro Alves3-16/+42
The buildbot shows that some machines FAIL this test frequently. E.g.: https://sourceware.org/ml/gdb-testers/2015-q1/msg00997.html If I stress my machine, I can sometimes see it fail too. Bumping the 200 limit and tweaking the test to show the step count, I get: ... PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 12 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 8 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 13 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 7 times --> FAIL: gdb.base/gdb-sigterm.exp: SIGTERM stepped 228 times <-- PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 11 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 13 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 12 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 8 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 9 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 7 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 11 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 8 times ... Thinking that this might be a problem of SIGTERM reaching GDB, but then the event loop taking too long to handle it, I hacked GDB to print a debug log whenever the SIGTERM handler was called, and, whenever the event loop finally calls the async SIGTERM handler. Here's what I see: infrun: 30011 [Thread 30011], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x4005de --> infrun: got SIGTERM <-- infrun: stepping inside range [0x4005de-0x4005e0] infrun: resume (step=1, signal=GDB_SIGNAL_0), ... infrun: prepare_to_wait --> infrun: handling async SIGTERM <-- Cannot execute this command while the target is running. Use the "interrupt" command to stop the target and then try again. gdb.base/gdb-sigterm.exp: expect eof #27 FAIL: gdb.base/gdb-sigterm.exp: SIGTERM stepped 228 times So, no delay on the GDB side. It just happens that occasionally it takes more than 200 single-steps before SIGTERM even reaches GDB. This just looks like a kernel/scheduling issue --- some extra usage spike in the system (e.g., an I/O spike) might cause it for me. For the build slaves, I'm guessing they're frequently busy enough to trip on this often. Particularly more so now that we're having them run tests in parallel mode. The fix is to detect failure by timeout instead of counting single steps. This should be more reliable. Indeed for me, after this commit, I couldn't trigger a FAIL anymore, even after letting the test run for an hour. By timeout is also nicer in that a board file for a slow host/target can increase it (like, e.g., an embedded GNU/Linux board). Tested on x86_64 Fedora 20, native, gdbserver, and extended-remote gdbserver. gdb/testsuite/ 2015-02-06 Pedro Alves <palves@redhat.com> * gdb.base/gdb-sigterm.c (main): Use the TIMEOUT define to determine how many seconds to pass to 'alarm'. * gdb.base/gdb-sigterm.exp (top level): Build program with -DTIMEOUT=$timeout. (do_test): Return success/failure indication. Add more verbose logging. Don't fail if 200 single steps are seen. Instead, fail when the test times out. (passes): New global. (top level): Break the testing loop if testing fails on any iteration. Use gdb_assert.
2015-02-04Clean up System V IPC objects allocated by test.Don Breazeal2-4/+26
This commit modifies the test program gdb.base/info-os.c so that it cleans up all allocated System V IPC objects when a fatal error occurs. Without this, it was possible for the program to leave IPC objects on the system, and such objects persist until they are manually deleted or the system reboots. I looked at changing the SysV IPC key for allocating the IPC objects to IPC_PRIVATE. That would prevent errors due to namespace conflicts with the key. However, the test needs to read the actual key number from the 'info os' command output, and IPC_PRIVATE won't work for that. gdb/testsuite/ChangeLog: 2015-02-04 Don Breazeal <donb@codesourcery.com> * gdb.base/info-os.c (shmid, semid, msqid): Make variables static and initialize them. (ipc_cleanup): New function. (main): Don't declare shmid, semid, and msqid. Add a call to atexit so that we call ipc_cleanup on exit.
2015-02-04Fix '--target_board=native-extended-gdbserver/-m32'Pedro Alves2-1/+9
Running the testsuite with the native-extended-gdbserver.exp board and passing a variant spec, like make check RUNTESTFLAGS="--target_board=native-extended-gdbserver/-m32" results in dejagnu trying to open a rsh connection to "native-extended-gdbserver", which of course is wrong. The point of this board is running things locally. The issue is that the native-extended-gdbserver board does not clear the "isremote" flag properly. Reported by Sergio at: https://sourceware.org/ml/gdb-patches/2015-02/msg00067.html testsuite/ 2015-02-04 Pedro Alves <palves@redhat.com> * boards/native-extended-gdbserver.exp: Remove any target variant specifications from the board name before clearing the isremote flag from board_info.
generated by cgit v1.1 at 2025-09-19 21:57:53 +0000