aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2015-02-26gdbserver/Linux: Simplify stepping past program breakpoint a littlePedro Alves2-6/+8
.decr_pc_after_break is never higher than .breakpoint_len, so use .breakpoint_len directly. Based on idea from Yao here: https://sourceware.org/ml/gdb-patches/2015-02/msg00689.html gdb/gdbserver/ChangeLog: 2015-02-26 Pedro Alves <palves@redhat.com> * linux-low.c (linux_wait_1): When incrementing the PC past a program breakpoint always use the_low_target.breakpoint_len as increment, rather than the maximum between that and the_low_target.decr_pc_after_break.
2015-02-26Add ATTRIBUTE_PRINTF attributes, and fix falloutPedro Alves9-13/+61
Fixes building gdb on x86_64-apple-darwin14 with clang, which produces a number of warnings from -Wformat-nonliteral. Ref: https://sourceware.org/ml/gdb/2015-02/msg00047.html gdb/ChangeLog: 2015-02-26 Pedro Alves <palves@redhat.com> * auto-load.h (file_is_auto_load_safe): Add ATTRIBUTE_PRINTF. * complaints.c (vcomplaint): Pass argument FMT directly to printf-like functions instead of complaint->fmt. * ctf.c (ctf_save_write_metadata): Add ATTRIBUTE_PRINTF. * darwin-nat.c (inferior_debug): Add ATTRIBUTE_PRINTF. * compile/compile-loc2c.c (pushf, unary, binary): Add ATTRIBUTE_PRINTF. (do_compile_dwarf_expr_to_c): Pass string literal as format string to pushf. (BINARY): Pass string literal as format string to 'binary'. * compile/compile-object-load.c (link_callbacks_einfo): Add ATTRIBUTE_PRINTF. * guile/guile-internal.h (gdbscm_printf): Add ATTRIBUTE_PRINTF.
2015-02-26Rename windows-termcap.c -> stub-termcap.cPedro Alves6-5/+17
Preparation for using this on all hosts. Confirmed that --host=x86_64-w64-mingw32 still builds the stub termcap. gdb/ChangeLog: 2015-02-26 Pedro Alves <palves@redhat.com> * windows-termcap.c: Rename to ... * stub-termcap.c: ... this. Adjust header line. * Makefile.in (SFILES): Refer to stub-termcap.c instead of windows-termcap.c. * configure: Regenerate. * configure.ac: Refer to stub-termcap.o instead of windows-termcap.o. * gdb_curses.h: Mention stub-termcap.c instead of windows-termcap.c.
2015-02-26compile: Fix GNU-IFUNC funcs called from injected codeJan Kratochvil5-2/+122
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 Tremblay4-2/+16
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 Kratochvil6-2/+66
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-26Rework signal frame probing for FreeBSD/x86John Baldwin5-31/+245
- Use signal frame sniffers that look for the signal trampoline instruction sequence to detect most signal frames. - FreeBSD kernels between 9.2 and 10.1 inclusive do not include the signal trampoline code in process core dumps. To detect signal frames for core dumps under these kernels, use the kern.proc.sigtramp.<pid> sysctl to fetch the location of the signal trampoline in the gdb process and assume that PC values within this location are signal frames. This depends on that location being identical for all binaries. gdb/ChangeLog: 2015-02-25 John Baldwin <jhb@FreeBSD.org> * amd64fbsd-nat.c: Include sys/user.h. (_initialize_amd64fbsd_nat): Use the KERN_PROC_SIGTRAMP sysctl instead of KERN_PS_STRINGS to locate the signal trampoline. * i386fbsd-nat.c: Include sys/user.h. (_initialize_i386fbsd_nat): Use the KERN_PROC_SIGTRAMP sysctl instead of KERN_PS_STRINGS to locate the signal trampoline. * amd64fbsd-tdep.c (amd64fbsd_sigtramp_code): New. (amd64fbsd_sigtramp_p): New. (amd64fbsd_sigtramp_start_addr, amd64fbsd_sigtramp_end_addr): No longer set default values. (amd64fbsd_init_abi): Set "sigtramp_p" to "amd64fbsd_sigtramp_p". * i386fbsd-tdep.c (i386fbsd_sigtramp_start) (i386fbsd_sigtramp_middle, i386fbsd_sigtramp_end) (i386fbsd_freebsd4_sigtramp_start) (i386fbsd_freebsd4_sigtramp_middle) (i386fbsd_freebsd4_sigtramp_end, i386fbsd_osigtramp_start) (i386fbsd_osigtramp_middle, i386fbsd_osigtramp_end): New. (i386fbsd_sigtramp_p): New. (i386fbsd_sigtramp_start_addr, i386fbsd_sigtramp_end_addr): No longer set default values. (i386fbsd_init_abi): Set "sigtramp_p" to "i386fbsd_sigtramp_p".
2015-02-26Fix infinite recursion in amd64fbsd_sigcontext_addrJohn Baldwin2-1/+10
amd64fbsd_sigcontext_addr is using frame_unwind_register_unsigned to fetch the stack pointer which results in infinite recursion. This patch changes it to use get_frame_register to match the sigcontext_addr methods in the i386-bsd and amd64-linux targets instead. gdb/ChangeLog: 2015-02-25 John Baldwin <jhb@freebsd.org> * amd64fbsd-tdep.c (amd64fbsd_sigcontext_addr): Use get_frame_register instead of frame_unwind_register_unsigned.
2015-02-26Change // comment in gdb/compile/Jan Kratochvil1-0/+6
Missing ChangeLog in the previous commit: bb2b33b9395662e7562be34b47b9533620b583c6 gdb/ChangeLog 2015-02-26 Jan Kratochvil <jan.kratochvil@redhat.com> PR build/18033 * compile/compile-c-support.c (c_compute_program): Change // comment. * compile/compile-object-load.c (setup_sections): Change // comment.
2015-02-26Change // comment in gdb/compile/Jan Kratochvil2-2/+2
2015-02-26Remove // comment in gdb/iq2000-tdep.cJoel Brobecker2-2/+5
gdb/ChangeLog: PR build/18033: * iq2000-tdep.c (iq2000_frame_cache): Delete C++-style comment.
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-23Fix typo in earlier entry.Doug Evans1-1/+1
2015-02-23PR gdb/18008: Fix typo in documentationSergio Durigan Junior2-1/+7
This obvious patch fixes a typo in our documentation (s/problam/problem). gdb/doc/ChangeLog: 2015-02-23 Sergio Durigan Junior <sergiodj@redhat.com> PR gdb/18008 * gdb.texinfo (maint internal-error, maint internal-warning, maint demangler-warning): Fix typo ("problam").
2015-02-23gdbserver: redo stepping over breakpoint that was on top of a permanent ↵Pedro Alves2-8/+45
breakpoint I'm going to add an alternate mechanism of breakpoint trap identification to 'check_stopped_by_breakpoint' that does not rely on checking the instruction at PC. The mechanism currently used to tell whether we're stepping over a permanent breakpoint doesn't fit in that new method. This patch redoes the whole logic in a different way that works with both old and new methods, in essence moving the "stepped permanent breakpoint" detection "one level up". It makes lower level check_stopped_by_breakpoint always the adjust the PC, and then has linux_wait_1 advance the PC past the breakpoint if necessary. This ends up being better also because this now handles non-decr_pc_after_break targets too. Before, such targets would get stuck forever reexecuting the breakpoint instruction. Tested on x86_64 Fedora 20. gdb/gdbserver/ChangeLog: 2015-02-23 Pedro Alves <palves@redhat.com> * linux-low.c (check_stopped_by_breakpoint): Don't check if the thread was doing a step-over; always adjust the PC if we stepped over a permanent breakpoint. (linux_wait_1): If we stepped over breakpoint that was on top of a permanent breakpoint, manually advance the PC past it.
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-23remote.c: simplify parsing stop reasons in T stop repliesPedro Alves2-85/+89
We need to be careful with parsing optional stop reasons that start with an hex character ("awatch", "core"), as GDBs that aren't aware of them parse them as real numbers. That's silly of course, given that there should be a colon after those magic "numbers". So if strtol on "abbz:" doesn't return "first invalid char" pointing to the colon, we know that "abbz" isn't really a register number. It must be optional stop info we don't know about. This adjusts GDB to work that way, removing the need for the special casing done upfront: /* If this packet is an awatch packet, don't parse the 'a' as a register number. */ if (strncmp (p, "awatch", strlen("awatch")) != 0 && strncmp (p, "core", strlen ("core") != 0)) For as long as we care about compatibility with GDB 7.9, we'll need to continue to be careful about this, so I added a comment. Tested on x86_64 Fedora 20, native gdbserver. gdb/ChangeLog: 2015-02-23 Pedro Alves <palves@redhat.com> * remote.c (skip_to_semicolon): New function. (remote_parse_stop_reply) <T stop reply>: Use it. Don't special case the stop reasons that look like hex numbers upfront. Instead handle real register numbers after matching all the known stop reasons.
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-23gdbserver: 64-bit kernel / 32-inferior, syscall restartingPedro Alves2-2/+12
$ make check RUNTESTFLAGS="--target_board=native-gdbserver/-m32 clone-thread_db.exp" gdb.log shows: Running target native-gdbserver/-m32 ... clone-thread_db: src/gdb/testsuite/gdb.threads/clone-thread_db.c:57: thread_fn: Assertion `res != -1' failed. ... (gdb) FAIL: gdb.threads/clone-thread_db.exp: continue to end That was waitpid returning -1 / EINTR. We don't see that when testing with unix/-m32 (native debugging). Turns out to be that when debugging a 32-bit inferior, a 64-bit GDBserver is reading/writing $orig_eax from/to the wrong ptrace register buffer offset. When gdbserver is 64-bit, the ptrace register buffer is in 64-bit layout, so the register is found at "ORIG_EAX * 8", not at "ORIG_EAX * 4". Fixes these with --target_board=native-gdbserver/-m32 on x86_64 Fedora 20: -FAIL: gdb.threads/clone-thread_db.exp: continue to end +PASS: gdb.threads/clone-thread_db.exp: continue to end -FAIL: gdb.threads/hand-call-in-threads.exp: all dummies popped +PASS: gdb.threads/hand-call-in-threads.exp: all dummies popped PASS: gdb.threads/hand-call-in-threads.exp: breakpoint on all_threads_running PASS: gdb.threads/hand-call-in-threads.exp: breakpoint on hand_call PASS: gdb.threads/hand-call-in-threads.exp: disable scheduler locking @@ -29339,15 +29331,15 @@ PASS: gdb.threads/hand-call-in-threads.e PASS: gdb.threads/hand-call-in-threads.exp: discard hand call, thread 4 PASS: gdb.threads/hand-call-in-threads.exp: discard hand call, thread 5 PASS: gdb.threads/hand-call-in-threads.exp: dummy stack frame number, thread 1 -FAIL: gdb.threads/hand-call-in-threads.exp: dummy stack frame number, thread 2 -FAIL: gdb.threads/hand-call-in-threads.exp: dummy stack frame number, thread 3 -FAIL: gdb.threads/hand-call-in-threads.exp: dummy stack frame number, thread 4 +PASS: gdb.threads/hand-call-in-threads.exp: dummy stack frame number, thread 2 +PASS: gdb.threads/hand-call-in-threads.exp: dummy stack frame number, thread 3 +PASS: gdb.threads/hand-call-in-threads.exp: dummy stack frame number, thread 4 PASS: gdb.threads/hand-call-in-threads.exp: dummy stack frame number, thread 5 PASS: gdb.threads/hand-call-in-threads.exp: enable scheduler locking PASS: gdb.threads/hand-call-in-threads.exp: hand call, thread 1 -FAIL: gdb.threads/hand-call-in-threads.exp: hand call, thread 2 -FAIL: gdb.threads/hand-call-in-threads.exp: hand call, thread 3 -FAIL: gdb.threads/hand-call-in-threads.exp: hand call, thread 4 +PASS: gdb.threads/hand-call-in-threads.exp: hand call, thread 2 +PASS: gdb.threads/hand-call-in-threads.exp: hand call, thread 3 +PASS: gdb.threads/hand-call-in-threads.exp: hand call, thread 4 PASS: gdb.threads/hand-call-in-threads.exp: hand call, thread 5 PASS: gdb.threads/hand-call-in-threads.exp: prepare to discard hand call, thread 1 PASS: gdb.threads/hand-call-in-threads.exp: prepare to discard hand call, thread 2 gdb/gdbserver/ChangeLog 2015-02-23 Pedro Alves <palves@redhat.com> * linux-x86-low.c (REGSIZE): Define in both 32-bit and 64-bit modes. (x86_fill_gregset, x86_store_gregset): Use it when handling $orig_eax.
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 Evans5-17/+63
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 Alves10-172/+291
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-20linux-nat.c: fix a few lin_lwp_attach_lwp issuesPedro Alves2-21/+47
This function has a few latent bugs that are triggered by a non-stop mode test that will be added in a subsequent patch. First, as described in the function's intro comment, the function is supposed to return 1 if we're already auto attached to the thread, but haven't processed the PTRACE_EVENT_CLONE event of its parent thread yet. Then, we may find that we're trying to attach to a clone child that hasn't yet stopped for its initial stop, and therefore 'waitpid(..., WNOHANG)' returns 0. In that case, we're currently adding the LWP to the stopped_pids list, which results in linux_handle_extended_wait skipping the waitpid call on the child, and thus confusing things later on when the child eventually reports the stop. Then, the tail end of lin_lwp_attach_lwp always sets the last_resume_kind of the LWP to resume_stop, which is wrong given that the user may be doing "info threads" while some threads are running. And then, the else branch of lin_lwp_attach_lwp always sets the stopped flag of the LWP. This branch is reached if the LWP is the main LWP, which may well be running at this point (to it's wrong to set its 'stopped' flag). AFAICS, there's no reason anymore for special-casing the main/leader LWP here: - For the "attach" case, linux_nat_attach already adds the main LWP to the lwp list, and sets its 'stopped' flag. - For the "run" case, after linux_nat_create_inferior, end up in linux_nat_wait_1 here: /* The first time we get here after starting a new inferior, we may not have added it to the LWP list yet - this is the earliest moment at which we know its PID. */ if (ptid_is_pid (inferior_ptid)) { /* Upgrade the main thread's ptid. */ thread_change_ptid (inferior_ptid, ptid_build (ptid_get_pid (inferior_ptid), ptid_get_pid (inferior_ptid), 0)); lp = add_initial_lwp (inferior_ptid); lp->resumed = 1; } ... which adds the LWP to the LWP list already, before lin_lwp_attach_lwp can ever be reached. gdb/ChangeLog: 2015-02-20 Pedro Alves <palves@redhat.com> * linux-nat.c (lin_lwp_attach_lwp): No longer special case the main LWP. Handle the case of waitpid returning 0 if we're already attached to the LWP. Don't set the LWP's last_resume_kind to resume_stop if we already knew about the LWP. (linux_nat_filter_event): Add debug logs.
2015-02-20Garbage collect forward_target_decr_pc_after_breakPedro Alves2-4/+5
The definition was removed a year ago, but the declaration managed to stay behind. gdb/ChangeLog 2015-02-20 Pedro Alves <palves@redhat.com> * target.h (forward_target_decr_pc_after_break): Delete declaration.
2015-02-20fix gdbserver/linux-low'c's pending status handlingPedro Alves2-3/+6
Another fix I'm working made schedlock.exp fail with gdbserver frequently. Looking deeper, it turns out to be a pre-existing bug. status_pending_p_callback is filtering out LWPs incorrectly. The result is that that sometimes status_pending_p_callback returns a pending event for an LWP that isn't expected, and then GDBserver gets very confused. E.g,. when doing a step-over, linux_wait_for_event is called with a particular LWP's ptid, meaning events for all other LWPs should be left pending, but here we see it retuning an event for some other LWP: linux_wait_1: [<all threads>] step_over_bkpt set [LWP 29577.29577], doing a blocking wait <-------- my_waitpid (-1, 0x40000001) my_waitpid (-1, 0x80000001): status(57f), 0 LWFE: waitpid(-1, ...) returned 0, ERRNO-OK pc is 0x4007a0 src/gdb/gdbserver/linux-low.c:2587: A problem internal to GDBserver has been detected. linux_wait_1: got event for 29581 <-------- Remote connection closed (gdb) FAIL: gdb.threads/schedlock.exp: continue to breakpoint: return to loop (initial) delete breakpoints Tested on x86_64 Fedora 20. gdb/gdbserver/ChangeLog: 2015-02-20 Pedro Alves <palves@redhat.com> * linux-low.c (status_pending_p_callback): Use ptid_match.
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 Alves5-0/+130
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-20Document the GDB 7.9 release in gdb/ChangeLogJoel Brobecker1-0/+4
gdb/ChangeLog: GDB 7.9 released.
2015-02-192015-02-19 Steve Ellcey <sellcey@imgtec.com>Steve Ellcey2-3/+12
* dtrace-probe.c (dtrace_process_dof_probe): Initialize arg.expr. (dtrace_get_probes) Change type of variable 'dof'.
2015-02-19Fix non executable stack handling when calling functions in the inferior.Antoine Tremblay9-18/+142
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-19[gdb/ax] small "setv" fix and documentation's adjustment.David Taylor4-2/+10
gdb/doc/agentexpr.texi documents the "setv" opcode as follow: @item @code{setv} (0x2d) @var{n}: @result{} @var{v} Set trace state variable number @var{n} to the value found on the top of the stack. The stack is unchanged, so that the value is readily available if the assignment is part of a larger expression. The handling of @var{n} is as described for @code{getv}. The @item line is incorrect (and does not match with its description), so this patch fixes it. Additionally, in gdb/common/ax.def we find the line: DEFOP (setv, 2, 0, 0, 1, 0x2d) From the comment earlier in the file: Each line is of the form: DEFOP (name, size, data_size, consumed, produced, opcode) [...] CONSUMED is the number of stack elements consumed. PRODUCED is the number of stack elements produced. which is saying that nothing is consumed and one item is produced. Both should be 0 or both should be 1. This patch sets them both to 1, which seems better since if nothing is on the stack an error will occur. gdb/ChangeLog: * common/ax.def (setv): Fix consumed entry in setv DEFOP. gdb/doc/ChangeLog: * agentexpr.texi (Bytecode Descriptions): Fix summary line for setv. Tested on x86_64-linux.
2015-02-18Add missing gdb/ChangeLog entry for previous change.Patrick Palka1-0/+15
2015-02-18Asynchronously resize the TUIPatrick Palka2-39/+41
This patch teaches the TUI to resize itself asynchronously instead of synchronously. Asynchronously resizing the screen when the underlying terminal gets resized is the more intuitive behavior and is surprisingly simple to implement thanks to GDB's async infrastructure. The implementation is straightforward. TUI's SIGWINCH handler is just tweaked to asynchronously invoke a new callback, tui_async_resize_screen, which is responsible for safely resizing the screen. Care must be taken to not to attempt to asynchronously resize the screen while the TUI is not active. When the TUI is not active, the callback will do nothing, but the screen will yet be resized in the next call to tui_enable() by virtue of win_resized being TRUE. (So, after the patch there are still two places where the screen gets resized: one in tui_enable() and the other now in tui_async_resize_screen() as opposed to being in tui_handle_resize_during_io(). The one in tui_enable() is still necessary to handle the case where the terminal gets resized inside the CLI: in that case, the TUI still needs resizing, but it must wait until the TUI gets re-enabled.) gdb/ChangeLog: * tui/tui-io.c (tui_handle_resize_during_io): Remove this function. (tui_putc): Don't call tui_handle_resize_during_io. (tui_getc): Likewise. (tui_mld_getc): Likewise. * tui/tui-win.c: Include event-loop.h and tui/tui-io.h. (tui_sigwinch_token): New static variable. (tui_initialize_win): Adjust documentation. Set tui_sigwinch_token. (tui_async_resize_screen): New asynchronous callback. (tui_sigwinch_handler): Adjust documentation. Asynchronously invoke tui_async_resize_screen.
2015-02-18Factorize target program transformations in the GDB_AC_TRANSFORM macro.Jose E. Marchesi10-60/+91
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-17Announce the DTrace USDT probes support in NEWS.Jose E. Marchesi2-0/+7
This patch simply adds a small entry to `Changes since GDB 7.8' announcing the support for dtrace probes. gdb/ChangeLog: 2015-02-17 Jose E. Marchesi <jose.marchesi@oracle.com> * NEWS: Announce the support for DTrace SDT probes.
2015-02-17Documentation for DTrace USDT probes.Jose E. Marchesi2-19/+47
This patch modifies the `Static Probe Points' section on the GDB manual in order to cover the support for DTrace USDT probes, in addition to SystemTap SDT probes. gdb/doc/ChangeLog: 2015-02-17 Jose E. Marchesi <jose.marchesi@oracle.com> * gdb.texinfo (Static Probe Points): Add cindex `static probe point, DTrace'. (Static Probe Points): Modified to cover DTrace probes in addition to SystemTap probes. Also modified to cover the `enable probe' and `disable probe' commands.
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-17Support for DTrace USDT probes in x86_64 targets.Jose E. Marchesi2-0/+164
This patch adds the target-specific code in order to support the calculation of DTrace probes arguments in x86_64 targets, and also the enabling and disabling of probes. This is done by implementing the `dtrace_*' gdbarch handlers. gdb/ChangeLog: 2015-02-17 Jose E. Marchesi <jose.marchesi@oracle.com> * amd64-linux-tdep.c: Include "parser-defs.h" and "user-regs.h". (amd64_dtrace_parse_probe_argument): New function. (amd64_dtrace_probe_is_enabled): Likewise. (amd64_dtrace_enable_probe): Likewise. (amd64_dtrace_disable_probe): Likewise. (amd64_linux_init_abi): Register the `gdbarch_dtrace_probe_argument', `gdbarch_dtrace_enable_probe', `gdbarch_dtrace_disable_probe' and `gdbarch_dtrace_probe_is_enabled' hooks. (amd64_dtrace_disabled_probe_sequence_1): New constant. (amd64_dtrace_disabled_probe_sequence_2): Likewise. (amd64_dtrace_enable_probe_sequence): Likewise. (amd64_dtrace_disable_probe_sequence): Likewise.
2015-02-17New probe type: DTrace USDT probes.Jose E. Marchesi6-4/+960
This patch adds a new type of probe to GDB: the DTrace USDT probes. The new type is added by providing functions implementing all the entries of the `probe_ops' structure defined in `probe.h'. The implementation is self-contained and does not depend on DTrace source code in any way. gdb/ChangeLog: 2015-02-7 Jose E. Marchesi <jose.marchesi@oracle.com> * breakpoint.c (BREAK_ARGS_HELP): Help string updated to mention the -probe-dtrace new vpossible value for PROBE_MODIFIER. * configure.ac (CONFIG_OBS): dtrace-probe.o added if BFD can handle ELF files. * Makefile.in (SFILES): dtrace-probe.c added. * configure: Regenerate. * dtrace-probe.c: New file. (SHT_SUNW_dof): New constant. (dtrace_probe_type): New enum. (dtrace_probe_arg): New struct. (dtrace_probe_arg_s): New typedef. (struct dtrace_probe_enabler): New struct. (dtrace_probe_enabler_s): New typedef. (dtrace_probe): New struct. (dtrace_probe_is_linespec): New function. (dtrace_dof_sect_type): New enum. (dtrace_dof_dofh_ident): Likewise. (dtrace_dof_encoding): Likewise. (DTRACE_DOF_ENCODE_LSB): Likewise. (DTRACE_DOF_ENCODE_MSB): Likewise. (dtrace_dof_hdr): New struct. (dtrace_dof_sect): Likewise. (dtrace_dof_provider): Likewise. (dtrace_dof_probe): Likewise. (DOF_UINT): New macro. (DTRACE_DOF_PTR): Likewise. (DTRACE_DOF_SECT): Likewise. (dtrace_process_dof_probe): New function. (dtrace_process_dof): Likewise. (dtrace_build_arg_exprs): Likewise. (dtrace_get_arg): Likewise. (dtrace_get_probes): Likewise. (dtrace_get_probe_argument_count): Likewise. (dtrace_can_evaluate_probe_arguments): Likewise. (dtrace_evaluate_probe_argument): Likewise. (dtrace_compile_to_ax): Likewise. (dtrace_probe_destroy): Likewise. (dtrace_gen_info_probes_table_header): Likewise. (dtrace_gen_info_probes_table_values): Likewise. (dtrace_probe_is_enabled): Likewise. (dtrace_probe_ops): New variable. (info_probes_dtrace_command): New function. (_initialize_dtrace_probe): Likewise. (dtrace_type_name): Likewise.
2015-02-17New gdbarch functions: dtrace_parse_probe_argument, dtrace_probe_is_enabled, ↵Jose E. Marchesi4-0/+189
dtrace_enable_probe, dtrace_disable_probe. This patch adds several gdbarch functions (along with the corresponding predicates): `dtrace_parse_probe_argument', `dtrace_probe_is_enabled', `dtrace_enable_probe' and `dtrace_disable_probe'. These functions will be implemented by target-specific code, and called from the DTrace probes implementation in order to calculate the value of probe arguments, and manipulate is-enabled probes. gdb/ChangeLog: 2015-02-17 Jose E. Marchesi <jose.marchesi@oracle.com> * gdbarch.sh (dtrace_parse_probe_argument): New. (dtrace_probe_is_enabled): Likewise. (dtrace_enable_probe): Likewise. (dtrace_disable_probe): Likewise. * gdbarch.c: Regenerate. * gdbarch.h: Regenerate.
2015-02-17New commands `enable probe' and `disable probe'.Jose E. Marchesi6-16/+198
This patch adds the above-mentioned commands to the generic probe abstraction implemented in probe.[ch]. The effects associated to enabling or disabling a probe depend on the type of probe being handled, and is triggered by invoking two back-end hooks in `probe_ops'. In case some particular probe type does not support the notion of enabling and/or disabling, the corresponding fields on `probe_ops' can be initialized to NULL. This is the case of SystemTap probes. gdb/ChangeLog: 2015-02-17 Jose E. Marchesi <jose.marchesi@oracle.com> * stap-probe.c (stap_probe_ops): Add NULLs in the static stap_probe_ops for `enable_probe' and `disable_probe'. * probe.c (enable_probes_command): New function. (disable_probes_command): Likewise. (_initialize_probe): Define the cli commands `enable probe' and `disable probe'. (parse_probe_linespec): New function. (info_probes_for_ops): Use parse_probe_linespec. * probe.h (probe_ops): New hooks `enable_probe' and `disable_probe'. gdb/doc/ChangeLog: 2015-02-17 Jose E. Marchesi <jose.marchesi@oracle.com> * gdb.texinfo (Static Probe Points): Cover the `enable probe' and `disable probe' commands.
2015-02-17Move `compute_probe_arg' and `compile_probe_arg' to probe.cJose E. Marchesi5-110/+127
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-17Adapt `info probes' to support printing probes of different types.Jose E. Marchesi4-10/+96
A "probe type" (backend for the probe abstraction implemented in probe.[ch]) can extend the information printed by `info probes' by defining additional columns. This means that when `info probes' is used to print all the probes regardless of their types, some of the columns will be "not applicable" to some of the probes (like, say, the Semaphore column only makes sense for SystemTap probes). This patch makes `info probes' fill these slots with "n/a" marks (currently it breaks the table) and not include headers for which no actual probe has been found in the list of defined probes. This patch also adds support for a new generic column "Type", that displays the type of each probe. SystemTap probes identify themselves as "stap" probes. gdb/ChangeLog: 2015-02-17 Jose E. Marchesi <jose.marchesi@oracle.com> * probe.c (print_ui_out_not_applicables): New function. (exists_probe_with_pops): Likewise. (info_probes_for_ops): Do not include column headers for probe types for which no probe has been actually found on any object. Also invoke `print_ui_out_not_applicables' in order to match the column rows with the header when probes of several types are listed. Print the "Type" column. * probe.h (probe_ops): Added a new probe operation `type_name'. * stap-probe.c (stap_probe_ops): Add `stap_type_name'. (stap_type_name): New function.
2015-02-17Remove superfluous function key_is_command_char()Patrick Palka2-15/+7
The function key_is_command_char() is simply a predicate that determines whether the function tui_dispatch_ctrl_char() will do anything useful. Since tui_dispatch_ctrl_char() performs the same checks as key_is_command_char() it is unnecessary to keep key_is_command_char() around. This patch removes this useless function and instead unconditionally calls tui_dispatch_ctrl_char() inside its only caller, tui_getc(). gdb/ChangeLog: * tui/tui-io.c (tui_getc): Don't call key_is_command_char. (key_is_command_char): Delete.
2015-02-17TUI: resize windows to new terminal size before displaying themPedro Alves2-6/+15
If the user: #1 - disables the TUI #2 - resizes the terminal #3 - and then re-enables the TUI the next wgetch() returns KEY_RESIZE. This indicates to the ncurses client that ncurses detected that the terminal has been resized. We don't handle KEY_RESIZE anywhere, so it gets passed on to readline which interprets it as a multibyte character, and then the end result is that the first key press after enabling the TUI is misinterpreted. We shouldn't really need to handle KEY_RESIZE (and not all ncurses implementations have that). We have our own SIGWINCH handler, and, when we re-enable the TUI, we explicitly detect terminal resizes and resize all windows. The reason ncurses currently does detects a resize is that something within tui_enable forces a refresh/display of some window before we get to do the actual resizing. Setting a break on ncurses' 'resizeterm' function helps find the culprit(s): (top-gdb) bt #0 resizeterm (ToLines=28, ToCols=114) at ../../ncurses/base/resizeterm.c:462 #1 0x0000003b42812f3f in _nc_update_screensize (sp=0x2674730) at ../../ncurses/tinfo/lib_setup.c:443 #2 0x0000003b0821cbe0 in doupdate () at ../../ncurses/tty/tty_update.c:726 #3 0x0000003b08215539 in wrefresh (win=0x2a7bc00) at ../../ncurses/base/lib_refresh.c:65 #4 0x00000000005257cb in tui_refresh_win (win_info=0xd73d60 <_locator>) at /home/pedro/gdb/mygit/src/gdb/tui/tui-wingeneral.c:60 #5 0x000000000052265b in tui_show_locator_content () at /home/pedro/gdb/mygit/src/gdb/tui/tui-stack.c:269 #6 0x00000000005273a6 in tui_set_key_mode (mode=TUI_COMMAND_MODE) at /home/pedro/gdb/mygit/src/gdb/tui/tui.c:321 #7 0x00000000005278c7 in tui_enable () at /home/pedro/gdb/mygit/src/gdb/tui/tui.c:494 #8 0x0000000000527011 in tui_rl_switch_mode (notused1=1, notused2=1) at /home/pedro/gdb/mygit/src/gdb/tui/tui.c:108 That is, tui_enable calls tui_set_key_mode before we've resized all windows, and that refreshes a window as side effect. And if we're already debugging something (there's a frame), then we'll instead show a window from within tui_show_frame_info: (top-gdb) bt #0 resizeterm (ToLines=28, ToCols=114) at ../../ncurses/base/resizeterm.c:462 #1 0x0000003b42812f3f in _nc_update_screensize (sp=0x202e6c0) at ../../ncurses/tinfo/lib_setup.c:443 #2 0x0000003b0821cbe0 in doupdate () at ../../ncurses/tty/tty_update.c:726 #3 0x0000003b08215539 in wrefresh (win=0x2042890) at ../../ncurses/base/lib_refresh.c:65 #4 0x00000000005257cb in tui_refresh_win (win_info=0xd73d60 <_locator>) at /home/pedro/gdb/mygit/src/gdb/tui/tui-wingeneral.c:60 #5 0x000000000052265b in tui_show_locator_content () at /home/pedro/gdb/mygit/src/gdb/tui/tui-stack.c:269 #6 0x0000000000522931 in tui_show_frame_info (fi=0x16b9cc0) at /home/pedro/gdb/mygit/src/gdb/tui/tui-stack.c:364 #7 0x00000000005278ba in tui_enable () at /home/pedro/gdb/mygit/src/gdb/tui/tui.c:491 #8 0x0000000000527011 in tui_rl_switch_mode (notused1=1, notused2=1) at /home/pedro/gdb/mygit/src/gdb/tui/tui.c:108 The fix is to resize windows earlier. gdb/ChangeLog: 2015-02-17 Pedro Alves <palves@redhat.com> * tui/tui.c (tui_enable): Resize windows before anything might show a window.
2015-02-17Fix GDB build fail on Aarch64 when -fno-common is enabledMaxim Ostapenko3-3/+10
Current trunk GDB (and gdb-7.8.1 too) fails to build on Aarch64 when -fno-common is enabled. It fails during link stage due to multiple definition of `tdesc_aarch64': ... [ 199s] aarch64-linux-nat.o: In function `initialize_tdesc_aarch64': [ 199s] /home/abuild/rpmbuild/BUILD/gdb-7.8.1/gdb/features/aarch64.c:11: multiple definition of `tdesc_aarch64' [ 199s] aarch64-tdep.o:/home/abuild/rpmbuild/BUILD/gdb-7.8.1/gdb/objfiles.h:540: first defined here [ 199s] aarch64-linux-nat.o: In function `initialize_tdesc_aarch64': [ 199s] /home/abuild/rpmbuild/BUILD/gdb-7.8.1/gdb/features/aarch64.c:11: multiple definition of `tdesc_aarch64' [ 199s] aarch64-tdep.o:/home/abuild/rpmbuild/BUILD/gdb-7.8.1/gdb/objfiles.h:540: first defined here [ 199s] collect2: error: ld returned 1 exit status [ 199s] make[2]: *** [gdb] Error 1 ... This happens because struct target_desc *tdesc_aarch64 is defined in gdb/features/aarch64.c, which is included by two files (gdb/aarch64-linux-nat.c and gdb/aarch64-tdep.c). gdb/Changelog 2015-02-17 Max Ostapenko <m.ostapenko@partner.samsung.com> PR gdb/17984 * aarch64-linux-nat.c: Don't include features/aarch64.c anymore. (aarch64_linux_read_description): Remove initialize_tdesc_aarch64 call. * aarch64-tdep.h (tdesc_aarch64): Declare.
generated by cgit v1.1 at 2024-10-16 01:08:04 +0000