aboutsummaryrefslogtreecommitdiff
path: root/gdb/ChangeLog
AgeCommit message (Collapse)AuthorFilesLines
2016-08-22Fix PR gdb/20505 - Make vDSO detection work with core filesPedro Alves1-0/+8
Loading a core dump that was either generated on a system running pristine glibc master, or on a Fedora/RHEL system with LD_DEBUG=unused set in the environment, solib-svr4.c:svr4_current_sos fails to filter out the vDSO, resulting in: (gdb) core-file corefile.core^M [New LWP 2362]^M warning: Could not load shared library symbols for linux-vdso.so.1.^M Do you need "set solib-search-path" or "set sysroot"?^M Core was generated by `build-gdb/gdb/testsuite/outputs/gdb.base/corefile/'.^M ... The problem is that gdbarch_vsyscall_range does not support core inferiors at all. When live debugging, we're finding the vDSO's start address with auxv/AT_SYSINFO_EHDR, and then we find the vDSO's size by look for the corresponding mapping, by parsing /proc/PID/maps. When debugging a core dump, we can also determine the starting address from auxv/AT_SYSINFO_EHDR. However, we obviously can't read the core mappings out of the host's /proc. But we can instead look for a corresponding load segment in the core's bfd. gdb/ChangeLog: 2016-08-22 Pedro Alves <palves@redhat.com> PR gdb/20505 * linux-tdep.c (linux_vsyscall_range_raw): For core inferiors, find the vDSO's start address with AT_SYSINFO_EHDR too, and determine the vDSO's size by finding the PT_LOAD segment that matches AT_SYSINFO_EHDR. gdb/testsuite/ChangeLog: 2016-08-22 Pedro Alves <palves@redhat.com> PR gdb/20505 * gdb.base/vdso-warning.exp: Test core dumps too. Use with_test_prefix. Factor out bits to ... (test_no_vdso): ... this new procedure.
2016-08-19[AArch64] Match instruction "STP with base register" in prologueYao Qi1-0/+5
Nowadays, we only match pre-indexed STP in prologue. Due to the change in gcc, https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01933.html, it may generate "STP with base register" in prologue, which GDB doesn't handle. That is to say, previously GCC generates prologue like this, sub sp, sp, #490 stp x29, x30, [sp, #-96]! mov x29, sp with the gcc patch above, GCC generates prologue like like this, sub sp, sp, #4f0 stp x29, x30, [sp] mov x29, sp This patch is to teach GDB to recognize this instruction in prologue analysis. gdb: 2016-08-19 Yao Qi <yao.qi@linaro.org> * aarch64-tdep.c (aarch64_analyze_prologue): Handle register based STP instruction.
2016-08-19null-terminate string in linespec_location_completerYao Qi1-0/+5
If I build gdb with -fsanitize=address and run tests, I get error, malformed linespec error: unexpected colon^M (gdb) PASS: gdb.linespec/ls-errs.exp: lang=C: break : break :=================================================================^M ==3266==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000051451 at pc 0x2b5797a972a8 bp 0x7fffd8e0f3c0 sp 0x7fffd8e0f398^M READ of size 2 at 0x602000051451 thread T0 #0 0x2b5797a972a7 in __interceptor_strlen (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x322a7)^M #1 0x7bd004 in compare_filenames_for_search(char const*, char const*) /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:316^M #2 0x7bd310 in iterate_over_some_symtabs(char const*, char const*, int (*)(symtab*, void*), void*, compunit_symtab*, compunit_symtab*) /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:411^M #3 0x7bd775 in iterate_over_symtabs(char const*, int (*)(symtab*, void*), void*) /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:481^M #4 0x7bda15 in lookup_symtab(char const*) /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:527^M #5 0x7d5e2a in make_file_symbol_completion_list_1 /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:5635^M #6 0x7d61e1 in make_file_symbol_completion_list(char const*, char const*, char const*) /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:5684^M #7 0x88dc06 in linespec_location_completer /home/yao/SourceCode/gnu/gdb/git/gdb/completer.c:288 .... 0x602000051451 is located 0 bytes to the right of 1-byte region [0x602000051450,0x602000051451)^M mallocated by thread T0 here: #0 0x2b5797ab97ef in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x547ef)^M #1 0xbbfb8d in xmalloc /home/yao/SourceCode/gnu/gdb/git/gdb/common/common-utils.c:43^M #2 0x88dabd in linespec_location_completer /home/yao/SourceCode/gnu/gdb/git/gdb/completer.c:273^M #3 0x88e5ef in location_completer(cmd_list_element*, char const*, char const*) /home/yao/SourceCode/gnu/gdb/git/gdb/completer.c:531^M #4 0x8902e7 in complete_line_internal /home/yao/SourceCode/gnu/gdb/git/gdb/completer.c:964^ The code in question is here file_to_match = (char *) xmalloc (colon - text + 1); strncpy (file_to_match, text, colon - text + 1); it is likely that file_to_match is not null-terminated. The patch is to strncpy 'colon - text' bytes and explicitly set '\0'. gdb: 2016-08-19 Yao Qi <yao.qi@linaro.org> * completer.c (linespec_location_completer): Make file_to_match null-terminated.
2016-08-19x32: gdb: Fix 'call' insn relocation with qRelocInsnPedro Alves1-0/+5
Running the fast tracepoints tests against x32 gdbserver exposes a latent bug. E.g.,: (gdb) continue Continuing. Reading /media/sf_host-pedro/gdb/mygit/build-ubuntu-x32/gdb/testsuite/outputs/gdb.trace/change-loc/change-loc-2.sl from remote target... Thread 1 "change-loc" received signal SIGSEGV, Segmentation fault. func4 () at /home/pedro/gdb/src/gdb/testsuite/gdb.trace/change-loc.h:24 24 } (gdb) FAIL: gdb.trace/change-loc.exp: 1 ftrace: continue to marker 2 The test sets a fast tracepoint on a shared library. On x32, shared libraries end up loaded somewhere in the upper 2GB of the 4GB address space x32 has access to. When gdbserver needs to copy an instruction to execute it in the jump pad, it asks gdb to relocate/adjust it, with the qRelocInsn packet. gdb converts "call" instructions into a "push $<2GB-4GB addr> + jmp" sequence, however, the "pushq" instruction sign extends its operand, so later when the called function returns, it returns to an incorrectly sign-extended address. E.g., 0xfffffffffabc0000 instead of 0xfabc0000, resulting in the segmentation fault. Fix this by converting calls at such addresses to "sub + mov + jmp" sequences instead. gdb/ChangeLog: 2016-08-19 Pedro Alves <palves@redhat.com> * amd64-tdep.c (amd64_relocate_instruction) <callq>: Handle return addresses over 0x7fffffff.
2016-08-18Add ChangeLog updates to my previous two commitsCarl E. Love1-0/+4
gdb/ChangeLog: * MAINTAINERS (Write After Approval): Add "Carl Love". gdb/testsuite/ChangeLog: * gdb.arch/powerpc-power.s: Add new Power9 instruction tests and sync up the test with tests in gas/testsuite/gas/ppc. * gdb.arch/powerpc-power.exp: Likewise.
2016-08-18ppc: Fix record of HTM instructionsEdjunior Barbosa Machado1-0/+4
The patch fixes the record support of Hardware Transactional Memory instructions on Power. It also solves a large number of unexpected failures from gdb.reverse testcases sigall-precsave.exp and sigall-reverse.exp that occur on distros which glibc uses HTM instructions. gdb/ChangeLog 2016-08-18 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com> * rs6000-tdep.c (ppc_process_record_op31): Handle HTM instructions.
2016-08-17Fix remove-inferior error messageSimon Marchi1-0/+4
This error message should not contain the word symbol: (gdb) remove-inferiors 1 Warning: Can not remove current symbol inferior 1. gdb/ChangeLog: * inferior.c (remove_inferior_command): Fix error message. gdb/testsuite/ChangeLog: * gdb.multi/remove-inferiors.exp (test_remove_inferiors): Fix expected error message.
2016-08-17Remove stale commentSimon Marchi1-0/+4
This comment seems outdated, since exiting an inferior does not remove it. gdb/ChangeLog: * inferior.c (exit_inferior_1): Remove comment.
2016-08-15[GDB] Fix builds broken by proc-service changes.Matthew Wahab1-0/+6
GLIBC BZ#20311 introduced a change to install proc_service.h so that gdb didn't have to use the version it embeds in gdb_proc_service.h. The embedded version is guarded by HAVE_PROC_SERVICE_H and gdb_proc_service.h has a number other of includes and definitions, all of which are uncondional except for an include for gregset.h. This is only included if HAVE_PROC_SERIVCE_H is not defined. This causes a build failure when cross compiling gdb with the latest glibc because type definitions in gregset are used independently of HAVE_PROC_SERIVCE_H. In particular, they are used in gdb_proc_service.h when PRFPREGSET_T_BROKEN is set. The error messages on the failure are ---- binutils-gdb/gdb/gdb_proc_service.h:173:9: error: ‘gdb_fpregset_t’ does not name a type; did you mean ‘elf_fpregset_t’? typedef gdb_fpregset_t gdb_prfpregset_t; ^~~~~~~~~~~~~~ elf_fpregset_t binutils-gdb/gdb/gdb_proc_service.h:173:9: error: ‘gdb_fpregset_t’ does not name a type; did you mean ‘elf_fpregset_t’? typedef gdb_fpregset_t gdb_prfpregset_t; ^~~~~~~~~~~~~~ elf_fpregset_t binutils-gdb/gdb/proc-service.c:218:15: error: ‘gdb_prfpregset_t’ does not name a type; did you mean ‘gdb_fpregset_t’? const gdb_prfpregset_t *fpregset) ^~~~~~~~~~~~~~~~ gdb_fpregset_t ---- This patch moves the include for gregset.h to before the code guarded by HAVE_PROC_SERIVCE_H, so that it is always included. This is enough to fix the build. 2016-08-15 Matthew Wahab <matthew.wahab@arm.com> PR gdb/20457 * gdb_proc_service.h: Add an include of gregset.h [!HAVE_PROC_SERVICE_H]: Remove the include of gregset.h.
2016-08-15Fix heap-buffer-overflow in explicit_location_lex_oneYao Qi1-0/+6
I build GDB with -fsanitize=address, and see the error in tests, (gdb) PASS: gdb.linespec/ls-errs.exp: lang=C++: break 3 foo break -line 3 foo^M =================================================================^M ==4401==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000047487 at pc 0x819d8e bp 0x7fff4e4e6bb0 sp 0x7fff4e4e6ba8^M READ of size 1 at 0x603000047487 thread T0^[[1m^[[0m^M #0 0x819d8d in explicit_location_lex_one /home/yao/SourceCode/gnu/gdb/git/gdb/location.c:502^M #1 0x81a185 in string_to_explicit_location(char const**, language_defn const*, int) /home/yao/SourceCode/gnu/gdb/git/gdb/location.c:556^M #2 0x81ac10 in string_to_event_location(char**, language_defn const*) /home/yao/SourceCode/gnu/gdb/git/gdb/location.c:687^ the code in question is: > /* Special case: C++ operator,. */ > if (language->la_language == language_cplus > && strncmp (*inp, "operator", 8) <--- [1] > && (*inp)[9] == ',') > (*inp) += 9; > ++(*inp); The error is caused by the access to (*inp)[9] if 9 is out of its bounds. However [1] looks odd to me, because if strncmp returns true (non-zero), the following check "(*inp)[9] == ','" makes no sense any more. I suspect it was a typo in the code we meant to "strncmp () == 0". Another problem in the code above is that if *inp is "operator,", we first increment *inp by 9, and then increment it by one again, which is wrong to me. We should only increment *inp by 8 to skip "operator", and go back to the loop header to decide where we stop. gdb: 2016-08-15 Yao Qi <yao.qi@linaro.org> * location.c (explicit_location_lex_one): Compare the return value of strncmp with zero. Don't check (*inp)[9]. Increment *inp by 8.
2016-08-11Fix fallout from gdb/20413's fix (x32: linux_ptrace_test_ret_to_nx: Cannot ↵Pedro Alves1-0/+6
PTRACE_PEEKUSER) Fixes, on NIOS GNU/Linux: In file included from /scratch/mbilal/nois-lite/src/gdb-trunk/gdb/gdbserver/../nat/linux-ptrace.c:26:0: /scratch/mbilal/nois-lite/src/gdb-trunk/gdb/gdbserver/../gregset.h:27:23: error: unknown type name 'gregset_t' #define GDB_GREGSET_T gregset_t ^ Fix this by including sys/procfs.h directly. We shouldn't really be including a gdb-only header in a gdb/nat/ file, anyway. Whoops. gdb/ChangeLog: 2016-08-11 Pedro Alves <palves@redhat.com> PR gdb/20413 * nat/linux-ptrace.c: Include <sys/procfs.h> instead of "gregset.h".
2016-08-10Fix PR gdb/19187 (process record over a fork causes internal error)Pedro Alves1-0/+7
Right after a fork is detected, we detach breakpoints from the child (detach_breakpoints), which calls into target_remove_breakpoint with inferior_ptid pointing at the child process, but leaves the breakpoint marked inserted (in the parent). The problem is that record-full.c always deletes all knowledge of the breakpoint. Then when we later really delete the breakpoint from the parent, we fail the assertion, since the breakpoint is unexpectedly not found in the record-full.c breakpoint table. The fix is simply to not forget about the breakpoint if we're detaching it from a fork child. gdb/ChangeLog: 2016-08-10 Pedro Alves <palves@redhat.com> PR gdb/19187 * record-full.c (record_full_remove_breakpoint): Don't remove the breakpoint from the record_full_breakpoints VEC if we're detaching the breakpoint from a fork child. gdb/testsuite/ChangeLog: 2016-08-10 Pedro Alves <palves@redhat.com> PR gdb/19187 * gdb.reverse/waitpid-reverse.exp: Add comment and remove setup_kfails.
2016-08-10Plumb enum remove_bp_reason all the way to target_remove_breakpointPedro Alves1-0/+35
So the target knows whether we're detaching breakpoints. Nothing uses the parameter in this patch yet. gdb/ChangeLog: 2016-08-10 Pedro Alves <palves@redhat.com> PR gdb/19187 * break-catch-sig.c (signal_catchpoint_remove_location): Adjust interface. * break-catch-syscall.c (remove_catch_syscall): * breakpoint.c (enum remove_bp_reason): Moved to breakpoint.h. (remove_breakpoint_1): Pass 'reason' down. (remove_catch_fork, remove_catch_vfork, remove_catch_solib) (remove_catch_exec, remove_watchpoint, remove_masked_watchpoint) (base_breakpoint_remove_location, bkpt_remove_location) (bkpt_probe_remove_location, bkpt_probe_remove_location): Adjust interface. * breakpoint.h (enum remove_bp_reason): Moved here from breakpoint.c. (struct breakpoint_ops) <remove_location>: Add 'reason' parameter. * corelow.c (core_remove_breakpoint): New function. (init_core_ops): Install it as to_remove_breakpoint method. * exec.c (exec_remove_breakpoint): New function. (init_exec_ops): Install it as to_remove_breakpoint method. * mem-break.c (memory_remove_breakpoint): Adjust interface. * record-btrace.c (record_btrace_remove_breakpoint): Adjust interface. * record-full.c (record_full_remove_breakpoint) (record_full_core_remove_breakpoint): Adjust interface. * remote.c (remote_remove_breakpoint): Adjust interface. * target-debug.h (target_debug_print_enum_remove_bp_reason): New macro. * target-delegates.c: Regenerate. * target.c (target_remove_breakpoint): Add 'reason' parameter. * target.h (struct target_ops) <to_remove_breakpoint>: Add 'reason' parameter. (target_remove_breakpoint, memory_remove_breakpoint): Add 'reason' parameter.
2016-08-10Introduce 'enum remove_bp_reason'Pedro Alves1-0/+8
Makes the code more obvious. gdb/ChangeLog: 2016-08-10 Pedro Alves <palves@redhat.com> PR gdb/19187 * breakpoint.c (insertion_state_t): Delete. (enum remove_bp_reason): New. (detach_breakpoints, remove_breakpoint_1, remove_breakpoint): Adjust to use enum remove_bp_reason instead of insertion_state_t.
2016-08-10Simplify remove_breakpoint interfacePedro Alves1-0/+9
All callers pass mark_uninserted, so there's no need for the 'is' parameter. gdb/ChangeLog: 2016-08-10 Pedro Alves <palves@redhat.com> PR gdb/19187 * breakpoint.c (remove_breakpoint): Remove 'is' parameter and always pass mark_uninserted to remove_breakpoint_1. (insert_breakpoint_locations, remove_breakpoints) (remove_breakpoints_pid, update_global_location_list): Update callers.
2016-08-10Support setting thread names (MS-Windows)Руслан Ижбулатов1-0/+12
This is done by catching an exception number 0x406d1388 (it has no documented name, though MSDN dubs it "MS_VC_EXCEPTION" in one code example), which is thrown by the program. The exception record contains an ID of a thread and a name to give it. This requires rolling back some changes in handle_exception(), which now again returns more than two distinct values. The new HANDLE_EXCEPTION_IGNORED value means that gdb should just continue, without returning the thread ID up the stack (which would result in further handling of the exception, which is not what we want). gdb/ChangeLog: 2016-08-10 Руслан Ижбулатов <lrn1986@gmail.com> Pedro Alves <palves@redhat.com> * windows-nat.c (MS_VC_EXCEPTION): New define. (handle_exception_result): New enum. (windows_delete_thread): Free the thread's name. (handle_exception): Handle MS_VC_EXCEPTION. (get_windows_debug_event): Handle HANDLE_EXCEPTION_IGNORED. (windows_thread_name): New function. (windows_target): Install it as to_thread_name method. * NEWS: Mention the thread naming support on MS-Windows.
2016-08-10Quiet ARI gettext checksPedro Alves1-0/+6
The ARI complains about this new file: common/signals-state-save-restore.c:46: warning: gettext: All messages should be marked up with _. common/signals-state-save-restore.c:59: warning: gettext: All messages should be marked up with _. common/signals-state-save-restore.c:87: warning: gettext: All messages should be marked up with _. common/signals-state-save-restore.c:92: warning: gettext: All messages should be marked up with _. Since these are untranslatable strings, use () instead of _(). gdb/ChangeLog: 2016-08-10 Pedro Alves <palves@redhat.com> * common/signals-state-save-restore.c (save_original_signals_state, restore_original_signals_state): Wrap perror_with_name arguments with '()'.
2016-08-09Fix PR gdb/20418 - Problems with synchronous commands and new-uiPedro Alves1-0/+23
When executing commands on a secondary UI running the MI interpreter, some commands that should be synchronous are not. MI incorrectly continues processing input right after the synchronous command is sent, before the target stops. The problem happens when we emit MI async events (=library-loaded, etc.), and we go about restoring the previous terminal state, we end up calling target_terminal_ours, which incorrectly always installs the current UI's input_fd in the event loop... That is, code like this: old_chain = make_cleanup_restore_target_terminal (); target_terminal_ours_for_output (); fprintf_unfiltered (mi->event_channel, "library-loaded"); ... do_cleanups (old_chain); The fix is to move the add_file_handler/delete_file_handler calls out of target_terminal_$foo, making these completely no-ops unless called with the main UI as current UI. gdb/ChangeLog: 2016-08-09 Pedro Alves <palves@redhat.com> PR gdb/20418 * event-top.c (ui_register_input_event_handler) (ui_unregister_input_event_handler): New functions. (async_enable_stdin): Register input in the event loop. (async_disable_stdin): Unregister input from the event loop. (gdb_setup_readline): Register input in the event loop. * infrun.c (check_curr_ui_sync_execution_done): Register input in the event loop. * target.c (target_terminal_inferior): Don't unregister input from the event loop. (target_terminal_ours): Don't register input in the event loop. * target.h (target_terminal_inferior) (target_terminal_ours_for_output, target_terminal_ours): Update comments. * top.h (ui_register_input_event_handler) (ui_unregister_input_event_handler): New declarations. * utils.c (ui_unregister_input_event_handler_cleanup) (prepare_to_handle_input): New functions. (defaulted_query, prompt_for_continue): Use prepare_to_handle_input. gdb/testsuite/ChangeLog: 2016-08-09 Pedro Alves <palves@redhat.com> Simon Marchi <simon.marchi@ericsson.com> PR gdb/20418 * gdb.mi/new-ui-mi-sync.c, gdb.mi/new-ui-mi-sync.exp: New files. * lib/mi-support.exp (mi_expect_interrupt): Remove anchors.
2016-08-09Fix PR mi/20431 - Missing MI prompts after sync execution MI command ↵Pedro Alves1-0/+6
(-exec-continue, etc.) errors gdb 7.11 introduced an MI regression: a failing MI sync execution command misses printing the MI prompt, and then all subsequent command miss it too: $ gdb-7.11.1 -i=mi [...] p 1 &"p 1\n" ~"$1 = 1" ~"\n" ^done (gdb) <<< prompted ok -exec-continue ^error,msg="The program is not being run." <<< missing prompt after this print 1 &"print 1\n" ~"$2 = 1" ~"\n" ^done <<< missing prompt after this gdb 7.10.1 behaved correctly, even with "set mi-async on": -exec-continue ^error,msg="The program is not being run." (gdb) <<< prompted ok etc. Bisecting points at: commit 0b333c5e7d6c Author: Pedro Alves <palves@redhat.com> Date: Wed Sep 9 18:23:23 2015 +0100 Merge async and sync code paths some more [...] The problem is that when an exception is thrown, we leave the prompt state set to PROMPT_BLOCKED, and then mi_execute_command_input_handler doesn't print the prompt. It used to work because before that patch, we happened to skip disabling stdin if the current target didn't do async (which it never does before execution). I was surprised to find that this bug isn't caught by the testsuite, so I made a thorough test that tests all combinations of pairs of: - a failing synchronous execution command - a failing non-execution command - a non-failing command gdb/ChangeLog: 2016-08-09 Pedro Alves <palves@redhat.com> PR mi/20431 * mi/mi-main.c (mi_execute_command): Enable input and set prompt state to PROMPT_NEEDED. gdb/testsuite/ChangeLog: 2016-08-09 Pedro Alves <palves@redhat.com> PR mi/20431 * gdb.mi/mi-cmd-error.exp: New file.
2016-08-09Fix PR gdb/18653: gdb disturbs inferior's inherited signal dispositionsPedro Alves1-0/+17
gdb's (or gdbserver's) own signal handling should not interfere with the signal dispositions their spawned children inherit. However, it currently does. For example, some paths in gdb cause SIGPIPE to be set to SIG_IGN, and as consequence, the child starts with SIGPIPE to set to SIG_IGN too, even though gdb was started with SIGPIPE set to SIG_DFL. This is because the exec family of functions does not reset the signal disposition of signals that are set to SIG_IGN: http://pubs.opengroup.org/onlinepubs/7908799/xsh/execve.html Signals set to the default action (SIG_DFL) in the calling process image are set to the default action in the new process image. Signals set to be ignored (SIG_IGN) by the calling process image are set to be ignored by the new process image. Signals set to be caught by the calling process image are set to the default action in the new process image (see <signal.h>). And neither does it reset signal masks or flags. In order to be transparent, when spawning new child processes to debug (with "run", etc.), reset signal actions and mask back to what was originally inherited from gdb/gdbserver's parent, just before execing the target program to debug. gdb/ChangeLog: 2016-08-09 Pedro Alves <palves@redhat.com> PR gdb/18653 * Makefile.in (SFILES): Add common/signals-state-save-restore.c. (HFILES_NO_SRCDIR): Add common/signals-state-save-restore.h. (COMMON_OBS): Add signals-state-save-restore.o. (signals-state-save-restore.o): New rule. * configure: Regenerate. * fork-child.c: Include "signals-state-save-restore.h". (fork_inferior): Call restore_original_signals_state. * main.c: Include "signals-state-save-restore.h". (captured_main): Call save_original_signals_state. * common/common.m4: Add sigaction to AC_CHECK_FUNCS checks. * common/signals-state-save-restore.c: New file. * common/signals-state-save-restore.h: New file. gdb/gdbserver/ChangeLog: 2016-08-09 Pedro Alves <palves@redhat.com> PR gdb/18653 * Makefile.in (OBS): Add signals-state-save-restore.o. (signals-state-save-restore.o): New rule. * config.in: Regenerate. * configure: Regenerate. * linux-low.c: Include "signals-state-save-restore.h". (linux_create_inferior): Call restore_original_signals_state. * server.c: Include "dispositions-save-restore.h". (captured_main): Call save_original_signals_state. gdb/testsuite/ChangeLog: 2016-08-09 Pedro Alves <palves@redhat.com> PR gdb/18653 * gdb.base/signals-state-child.c: New file. * gdb.base/signals-state-child.exp: New file. * gdb.gdb/selftest.exp (do_steps_and_nexts): Add new pattern.
2016-08-09Fix PR gdb/20295: GDB segfaults printing bitfield member of optimized out valuePedro Alves1-0/+5
With something like: struct A { int bitfield:4; } var; If 'var' ends up wholly-optimized out, printing 'var.bitfield' crashes gdb here: (top-gdb) bt #0 0x000000000058b89f in extract_unsigned_integer (addr=0x2 <error: Cannot access memory at address 0x2>, len=2, byte_order=BFD_ENDIAN_LITTLE) at /home/pedro/gdb/mygit/src/gdb/findvar.c:109 #1 0x00000000005a187a in unpack_bits_as_long (field_type=0x16cff70, valaddr=0x0, bitpos=16, bitsize=12) at /home/pedro/gdb/mygit/src/gdb/value.c:3347 #2 0x00000000005a1b9d in unpack_value_bitfield (dest_val=0x1b5d9d0, bitpos=16, bitsize=12, valaddr=0x0, embedded_offset=0, val=0x1b5d8d0) at /home/pedro/gdb/mygit/src/gdb/value.c:3441 #3 0x00000000005a2a5f in value_fetch_lazy (val=0x1b5d9d0) at /home/pedro/gdb/mygit/src/gdb/value.c:3958 #4 0x00000000005a10a7 in value_primitive_field (arg1=0x1b5d8d0, offset=0, fieldno=0, arg_type=0x16d04c0) at /home/pedro/gdb/mygit/src/gdb/value.c:3161 #5 0x00000000005b01e5 in do_search_struct_field (name=0x1727c60 "bitfield", arg1=0x1b5d8d0, offset=0, type=0x16d04c0, looking_for_baseclass=0, result_ptr=0x7fffffffcaf8, [...] unpack_value_bitfield is already optimized-out/unavailable -aware: (...) VALADDR points to the contents of VAL. If the VAL's contents required to extract the bitfield from are unavailable/optimized out, DEST_VAL is correspondingly marked unavailable/optimized out. however, it is not considering the case of the value having no contents buffer at all, as can happen through allocate_optimized_out_value. gdb/ChangeLog: 2016-08-09 Pedro Alves <palves@redhat.com> * value.c (unpack_value_bitfield): Skip unpacking if the parent has no contents buffer to begin with. gdb/testsuite/ChangeLog: 2016-08-09 Pedro Alves <palves@redhat.com> * gdb.dwarf2/bitfield-parent-optimized-out.exp: New file.
2016-08-08Regenerate some target description filesPedro Alves1-0/+7
I regenerated all target description .c files from scratch, and got this spurious diff. It's a simple mid-air collision - these files were clearly generated before commit 73b4f516a037 ("maint_print_c_tdesc_cmd: Use type for TYPE_CODE_FLAGS instead of field_type."), which did the global s/field_type/type/, and pushed to master afterwards. gdb/features/ChangeLog: 2016-08-08 Pedro Alves <palves@redhat.com> * features/i386/amd64-avx-mpx-linux.c: Regenerate. * features/i386/amd64-avx-mpx.c: Regenerate. * features/i386/i386-avx-mpx-linux.c: Regenerate. * features/i386/i386-avx-mpx.c: Regenerate.
2016-08-05Remove unused cli_command_loop declarationSimon Marchi1-0/+4
This declaration is not used anymore. gdb/ChangeLog: * event-top.h (cli_command_loop): Remove.
2016-08-05Fix PR remote/20398: File-IO write always outputs "Quit"Pedro Alves1-0/+6
Commit bb7c96deb1a1 ("gdb/remote-fileio.c: Eliminate custom SIGINT signal handler") regressed the File-IO support. Failed output: (gdb) target remote :8888 Remote debugging using :8888 0x00008098 in _start () (gdb) c Continuing. Quit Quit Quit Quit Quit Quit Quit Quit Quit Quit Quit [Inferior 1 (Remote target) exited normally] Expected output: (gdb) target remote :8888 Remote debugging using :8888 0x00008098 in _start () (gdb) c Continuing. i: 0 i: 1 i: 2 i: 3 i: 4 i: 5 i: 6 i: 7 i: 8 i: 9 [Inferior 1 (Remote target) exited normally] The problem that the new File-IO quit handler forgets to check the quit flag before calling throwing a quit. gdb/ChangeLog: 2016-08-05 Pedro Alves <palves@redhat.com> PR remote/20398 * remote-fileio.c (remote_fileio_quit_handler): Check the quit flag before calling quit.
2016-08-05gdb/NEWS: Mention that C++ is now the defaultPedro Alves1-0/+5
gdb/ChangeLog: 2016-08-05 Pedro Alves <palves@redhat.com> * NEWS: Mention that GDB and GDBserver build with a C++ compiler by default.
2016-08-05gdb/configure --help: suggest --disable-build-with-cxx instead of --enable...Pedro Alves1-0/+6
We build by default with a C++ compiler, but "configure --help" still says "--enable-build-with-cxx", which hints that it is by default disabled. Update the --help text. gdb/ChangeLog: 2016-08-05 Pedro Alves <palves@redhat.com> * build-with-cxx.m4: Change help string to be in terms of --disable-build-with-cxx. * configure: Regenerate. gdb/gdbserver/ChangeLog: 2016-08-05 Pedro Alves <palves@redhat.com> * configure: Regenerate.
2016-08-04Determine target description for native aarch64Yao Qi1-0/+8
I find the following test fail when I test native aarch64 gdb with arm program, (gdb) PASS: gdb.base/attach-pie-noexec.exp: attach set architecture arm^M warning: Selected architecture arm is not compatible with reported target architecture aarch64^M Architecture `arm' not recognized.^M The target architecture is set automatically (currently aarch64)^M (gdb) FAIL: gdb.base/attach-pie-noexec.exp: set architecture arm GDB thinks the target is aarch64, but it isn't. Nowadays, we are using some entries AT_PHENT and AT_HWCAP in auxv to determine whether the process is a 32-bit arm one or 64-bit aarch64 one, and get the right gdbarch. However, in the process of parsing auxv (in inf_ptrace_auxv_parse), the size of int and data pointer of target_gdbarch is used. If debug program exists (in most of cases), target_gdbarch is already set according to the debug program, which is arm in my case. Then, GDB can parse auxv successfully. However, in gdb.base/attach-pie-noexec.exp, the debug program is removed, target_gdbarch is aarch64 when GDB parse auxv, so GDB can't parse it successfully. Instead of using auxv, we check the return value of ptrace NT_ARM_VFP. If the program is an arm process, NT_ARM_VFP is OK, otherwise, error is returned. Additionally, we only return tdesc_arm_with_neon for arm process, because neon is mandatory on ARMv8. gdb: 2016-08-04 Yao Qi <yao.qi@linaro.org> * aarch64-linux-nat.c (tdesc_arm_with_vfpv3): Remove the declaration. (aarch64_linux_read_description): Remove code on getting auxv and select target description on it. Select target description by the result of NT_ARM_VFP ptrace request.
2016-08-03PR python/18565 - make Frame.function work for inline framesTom Tromey1-0/+5
PR python/18565 notes that calling frame filters don't work properly for inlined functions. This happens because Frame.function on an inline frame will yield the wrong result. This patch changes this code to use find_frame_funname instead, which handles inline frames properly. Built and regtested on x86-64 Fedora 24. 2016-08-03 Tom Tromey <tom@tromey.com> PR python/18565: * python/py-frame.c (frapy_function): Use find_frame_funname. 2016-08-03 Tom Tromey <tom@tromey.com> PR python/18565: * gdb.python/py-frame-inline.exp: Add Frame.function test.
2016-08-03Avoid potential memory leak in find_frame_funnameTom Tromey1-0/+5
The PR 18565 thread pointed out that, if cp_remove_params can throw (we aren't quite sure), then find_frame_funname could leak some memory. This patch avoids any potential issue by rearranging some code in find_frame_funname. Built and regtested on x86-64 Fedora 24. 2016-08-03 Tom Tromey <tom@tromey.com> * stack.c (find_frame_funname): Avoid any possible leak in case cp_remove_params can throw.
2016-08-03Update NEWS to mention Python breakpoint eventsTom Tromey1-0/+4
An earlier patch added three new breakpoint-related events to the Python API. However, at that time, I forgot to update NEWS. This patch supplies the missing entry. 2016-08-03 Tom Tromey <tom@tromey.com> * NEWS: Mention new Python breakpoint events.
2016-08-02Add myself as Rust maintainerTom Tromey1-0/+4
A while ago, Pedro announced that I would be the Rust maintainer for gdb. However, I neglected to update the MAINTAINERS file until now. 2016-08-02 Tom Tromey <tom@tromey.com> * MAINTAINERS (Core): Add self as Rust maintainer.
2016-08-01Update NEWS post GDB 7.12 branch creation.Joel Brobecker1-0/+6
gdb/ChangeLog: * NEWS: Create a new section for the next release branch. Rename the section of the current branch, now that it has been cut.
2016-08-01Bump version to 7.12.50.DATE-git.Joel Brobecker1-0/+5
Now that the GDB 7.12 branch has been created, we can bump the version number. gdb/ChangeLog: GDB 7.12 branch created (41bfcd638a4e0e48b96ce4de2845372dea481322): * version.in: Bump version to 7.12.50.DATE-git.
2016-07-27Wean gdb and sim off private libbfd.h headerAlan Modra1-0/+7
The major reason this header was needed, bfd_default_set_arch_mach, has now moved to bfd.h. gdb/ * amd64-darwin-tdep.c: Don't include libbfd.h. * i386-darwin-tdep.c: Likewise. * rs6000-nat.c: Likewise. * rs6000-tdep.c: Likewise. sim/aarch64/ * memory.c: Don't include libbfd.h. sim/rl78/ * load.c: Don't include libbfd.h. (rl78_load): Don't use private iovec seek or read. sim/rx/ * load.c: Don't include libbfd.h. (rx_load): Don't use private iovec seek or read.
2016-07-26PR python/20190 - compute TLS symbol without a frameTom Tromey1-0/+25
PR python/20190 arose from an exception I noticed when trying to use the Python unwinder for Spider Monkey in Firefox. The problem is that the unwinder wants to examine the value of a thread-local variable. However, sympy_value rejects this because symbol_read_needs_frame returns true for a TLS variable. This problem arose once before, though in a different context: https://sourceware.org/bugzilla/show_bug.cgi?id=11803 At the time Pedro and Daniel pointed out a simpler way to fix that bug (see links in 20190 if you are interested); but for this new bug I couldn't think of a similar fix and ended up implementing Daniel's other suggestion: https://sourceware.org/ml/gdb-patches/2010-07/msg00393.html That is, this patch makes it possible to detect whether a symbol needs a specific frame, or whether it just needs the inferior to have registers. Built and regtested on x86-64 Fedora 24. 2016-07-26 Tom Tromey <tom@tromey.com> * symtab.c (register_symbol_computed_impl): Update. PR python/20190: * value.h (symbol_read_needs): Declare. (symbol_read_needs_frame): Add comment. * symtab.h (struct symbol_computed_ops) <read_variable>: Update comment. <get_symbol_read_needs>: Rename. Change return type. * findvar.c (symbol_read_needs): New function. (symbol_read_needs_frame): Rewrite. (default_read_var_value): Use symbol_read_needs. * dwarf2loc.c (struct symbol_needs_baton): Rename. <needs>: Renamed from needs_frame. Changed type. (needs_frame_read_addr_from_reg, symbol_needs_get_reg_value) (symbol_needs_read_mem, symbol_needs_frame_base) (symbol_needs_frame_cfa, symbol_needs_tls_address) (symbol_needs_dwarf_call): Rename. (needs_dwarf_reg_entry_value): Update. (symbol_needs_ctx_funcs, dwarf2_loc_desc_get_symbol_read_needs): Rename and update. (locexpr_get_symbol_read_needs, loclist_symbol_needs): Likewise. (dwarf2_locexpr_funcs, dwarf2_loclist_funcs): Update. * defs.h (enum symbol_needs_kind): New. 2016-07-26 Tom Tromey <tom@tromey.com> PR python/20190: * gdb.threads/tls.exp (check_thread_local): Add python symbol test.
2016-07-26Fix PR gdb/20413 - x32: linux_ptrace_test_ret_to_nx: Cannot PTRACE_PEEKUSERPedro Alves1-0/+6
An x32 gdb always issues this warning: (gdb) start Temporary breakpoint 1 at 0x4043e9: file foo.c, line 25. Starting program: a.out warning: linux_ptrace_test_ret_to_nx: Cannot PTRACE_PEEKUSER: Input/output error Temporary breakpoint 1, main (argc=1, argv=0xffffd544) at foo.c:25 25 { (gdb) As described in Linux commit 55283e253771 (x32: Add ptrace for x32): [...] PTRACE_PEEKUSR and PTRACE_POKEUSR are only allowed to access segment and debug registers. [...] The fix is to use PTRACE_GETREGS instead. gdb/ChangeLog: 2016-07-26 Pedro Alves <palves@redhat.com> * nat/linux-ptrace.c: Include "gregset.h". (linux_ptrace_test_ret_to_nx): Use PTRACE_GETREGS instead of PTRACE_PEEKUSER.
2016-07-26Fix PR gdb/20287 - x32 and "gdb_static_assert (sizeof (nat_siginfo_t) == ↵Pedro Alves1-0/+19
sizeof (siginfo_t))" Building an x32 gdb trips on a static assertion: In file included from .../src/gdb/common/common-defs.h:71:0, from .../src/gdb/nat/amd64-linux-siginfo.c:21: .../src/gdb/common/gdb_assert.h:26:66: error: size of array ‘never_defined_just_used_for_checking’ is negative extern int never_defined_just_used_for_checking[(expr) ? 1 : -1] ^ .../src/gdb/nat/amd64-linux-siginfo.c:113:1: note: in expansion of macro ‘gdb_static_assert’ gdb_static_assert (sizeof (nat_siginfo_t) == sizeof (siginfo_t)); ^ The problem is that the way nat_siginfo_t is defined, it can only match the host's siginfo_t object when gdb is built as a 64-bit program. Several bits of nat_siginfo_t are off: - nat_siginfo_t's _pad field's definition is: int _pad[((128 / sizeof (int)) - 4)]; while /usr/include/bits/siginfo.h has: # define __SI_MAX_SIZE 128 # if __WORDSIZE == 64 # define __SI_PAD_SIZE ((__SI_MAX_SIZE / sizeof (int)) - 4) # else # define __SI_PAD_SIZE ((__SI_MAX_SIZE / sizeof (int)) - 3) # endif and __WORDSIZE == 32 for x32. This is what causes the size of nat_siginfo_t to be wrong and the assertion to fail. - the nat_clock_t type is incorrect for 64-bit. We have this: /* For native 64-bit, clock_t in _sigchld is 64bit aligned at 4 bytes. */ typedef long __attribute__ ((__aligned__ (4))) nat_clock_t; however, /usr/include/bits/siginfo.h has: # if defined __x86_64__ && __WORDSIZE == 32 /* si_utime and si_stime must be 4 byte aligned for x32 to match the kernel. We align siginfo_t to 8 bytes so that si_utime and si_stime are actually aligned to 8 bytes since their offsets are multiple of 8 bytes. */ typedef __clock_t __attribute__ ((__aligned__ (4))) __sigchld_clock_t; # define __SI_ALIGNMENT __attribute__ ((__aligned__ (8))) # else typedef __clock_t __sigchld_clock_t; # define __SI_ALIGNMENT # endif So we're currently forcing 4-byte alignment on clock_t, when it should only be so for x32, not 64-bit. The fix: - Leaves nat_siginfo_t strictly for the 64-bit ABI. - Adds a new typedef for the siginfo type that ptrace uses (ptrace_siginfo_t). An x32 gdb always gets/sets an x32 siginfo_t type with PTRACE_GETSIGINFO/PTRACE_SETSIGINFO. - Uses this new ptrace_siginfo_t type instead of nat_siginfo_t as the intermediate conversion type. gdb/ChangeLog: 2016-07-26 Pedro Alves <palves@redhat.com> * amd64-linux-nat.c (amd64_linux_siginfo_fixup): Rename 'native' parameter to 'ptrace'. * nat/amd64-linux-siginfo.c (GDB_SI_SIZE): New define. (nat_uptr_t): New an unsigned long. (nat_clock_t): Remove attribute __aligned__. (struct nat_timeval): Delete. (nat_siginfo_t): Remove attribute __aligned__. (ptrace_siginfo_t): Define. (compat_siginfo_from_siginfo, siginfo_from_compat_siginfo) (compat_x32_siginfo_from_siginfo) (siginfo_from_compat_x32_siginfo): Make 'from' parameter const. Convert through a ptrace_siginfo_t instead of a nat_siginfo_t. Remove casts. (amd64_linux_siginfo_fixup_common): Rename 'native' parameter to 'ptrace'. Remove static assertions. (top level): New static assertions. gdb/gdbserver/ChangeLog: 2016-07-26 Pedro Alves <palves@redhat.com> * linux-x86-low.c (x86_siginfo_fixup): Rename 'native' parameter to 'ptrace'.
2016-07-25Handle correctly passing a bad interpreter name to new-uiSimon Marchi1-0/+8
When a bad interpreter name is passed to new-ui, such as: (gdb) new-ui bloop /dev/pts/10 A partially created UI is left in the UI list, with interp set to NULL. Trying to do anything that will print on this UI (such as "start") will cause a segmentation fault. Changes in v2: - Use with_test_prefix to namespace test procedures - Give an explicit stable test name - Add a "bad terminal path" test - Remove useless runto_main - Add missing intro comments I did not factor out the pty spawn, as there is some magic involved I don't quite understand. But it wouldn't bring that much anyway. gdb/ChangeLog: * top.h (make_delete_ui_cleanup): New declaration. * top.c (delete_ui_cleanup): New function. (make_delete_ui_cleanup): New function. (new_ui_command): Create restore_ui cleanup earlier, create a delete_ui cleanup and discard it on success. gdb/testsuite/ChangeLog: * gdb.base/new-ui.exp (do_test_invalid_args): New procedure.
2016-07-25linux-procfs: Handle lowercase "t (tracing stop)" statePedro Alves1-0/+6
Since Linux 2.6.33, /proc/PID/status shows "t (tracing stop)", with lowercase 't'. Because GDB is only expecting "T (tracing stop)", GDB can incorrectly suppress errors in check_ptrace_stopped_lwp_gone: 1578 if (!check_ptrace_stopped_lwp_gone (lp)) 1579 throw_exception (ex); Ref: https://sourceware.org/ml/gdb-patches/2016-06/msg00072.html 2016-07-25 Pedro Alves <palves@redhat.com> Jan Kratochvil <jan.kratochvil@redhat.com> * nat/linux-procfs.c (parse_proc_status_state): Handle lowercase 't'.
2016-07-25linux-procfs: Introduce enum proc_statePedro Alves1-0/+15
Parse the process's /proc/PID/status state into an enum instead of the current scheme of passing state strings around. gdb/ChangeLog: 2016-07-25 Pedro Alves <palves@redhat.com> * nat/linux-procfs.c (enum proc_state): New enum. (parse_proc_status_state): New function. (linux_proc_pid_get_state): Replace output string buffer parameter with an output proc_state parameter. Use parse_proc_status_state. (linux_proc_pid_is_gone): Adjust to use proc_state values. (linux_proc_pid_has_state): Change type of 'state' parameter; now an enum proc_state. Adjust to linux_proc_pid_get_state interface change. (linux_proc_pid_is_stopped) (linux_proc_pid_is_trace_stopped_nowarn) (linux_proc_pid_is_zombie_maybe_warn): Adjust to linux_proc_pid_get_state interface change.
2016-07-25Add myself as a write-after-approval GDB maintainer.Tim Wiederhake1-0/+4
2016-07-25btrace: Resume recording after disconnect.Tim Wiederhake1-0/+13
This patch allows gdbserver to continue recording after disconnect. On reconnect, the recorded data is accessible to gdb as if no disconnect happened. A possible application for this feature is remotely examine bugs that occur at irregular intervals, where maintaining a gdb connection is inconvenient. This also fixes the issue mentioned here: https://sourceware.org/ml/gdb-patches/2015-11/msg00424.html Signed-off-by: Tim Wiederhake <tim.wiederhake@intel.com> gdb/ChangeLog: * NEWS: Resume btrace on reconnect. * record-btrace.c: Added record-btrace.h include. (record_btrace_open): Split into this and ... (record_btrace_push_target): ... this. (record_btrace_disconnect): New function. (init_record_btrace_ops): Use record_btrace_disconnect. * record-btrace.h: New file. * remote.c: Added record-btrace.h include. (remote_start_remote): Check recording status. (remote_btrace_maybe_reopen): New function. gdb/doc/ChangeLog: * gdb.texinfo: Resume btrace on reconnect. gdb/testsuite/ChangeLog: * gdb.btrace/reconnect.c: New file. * gdb.btrace/reconnect.exp: New file. Change-Id: I95e8b0ab8a89e58591aba0e63818cee82fd211bc
2016-07-23Implement catch syscall groupGabriel Krisman Bertazi1-0/+64
Implement support to add catchpoints for a group of related syscalls using the syntax: (gdb) catch syscall group:<group> or (gdb) catch syscall g:<group> Several groups are predefined in the xml files for all architectures supported by GDB over Linux. They are based on the groups defined by strace. gdb/ * xml-syscall.c (get_syscalls_by_group): New. (get_syscall_group_names): New. (struct syscall_group_desc): New structure to store group data. (struct syscalls_info): Include field to store the group list. (sysinfo_free_syscall_group_desc): New. (free_syscalls_info): Free group list. (syscall_group_create_syscall_group_desc): New. (syscall_group_add_syscall): New. (syscall_create_syscall_desc): Add syscall to its groups. (syscall_start_syscall): Load group attribute. (syscall_group_get_group_by_name): New. (xml_list_syscalls_by_group): New. (xml_list_of_groups): New. * xml-syscall.h (get_syscalls_by_group): Export function to retrieve a list of syscalls filtered by the group name. (get_syscall_group_names): Export function to retrieve the list of syscall groups. * break-catch-syscall.c (catch_syscall_split_args): Verify if argument is a syscall group and expand it to a list of syscalls when creating catchpoints. (catch_syscall_completer): Add word completion for system call groups. * configure.ac: Include dependency for xsltproc when building in maintainer-mode. * break-catch-syscall.c (_initialize_breakpoint): Update catch syscall command documentation. * NEWS: Include section about catching groups of syscalls. * configure: Regenerate. * data-directory/Makefile.in: Generate syscall xml when building in maintainer mode. * syscalls/gdb-syscalls.dtd: Include group attribute to the syscall element. * syscalls/apply-defaults.xsl: New. * syscalls/linux-defaults.xml.in: New. * syscalls/aarch64-linux.xml: Rename to aarch64-linux.xml.in. * syscalls/amd64-linux.xml: Rename to amd64-linux.xml.in. * syscalls/arm-linux.xml: Rename to arm-linux.xml.in. * syscalls/bfin-linux.xml: Rename to bfin-linux.xml.in. * syscalls/i386-linux.xml: Rename to i386-linux.xml.in. * syscalls/mips-n32-linux.xml: Rename to mips-n32-linux.xml.in. * syscalls/mips-n64-linux.xml: Rename to mips-n64-linux.xml.in. * syscalls/mips-o32-linux.xml: Rename to mips-o32-linux.xml.in. * syscalls/ppc-linux.xml: Rename to ppc-linux.xml.in. * syscalls/ppc64-linux.xml: Rename to ppc64-linux.xml.in. * syscalls/s390-linux.xml: Rename to s390-linux.xml.in. * syscalls/s390x-linux.xml: Rename to s390x-linux.xml.in. * syscalls/sparc-linux.xml: Rename to sparc-linux.xml.in. * syscalls/sparc64-linux.xml: Rename to sparc64-linux.xml.in. * syscalls/aarch64-linux.xml: Regenerate. * syscalls/amd64-linux.xml: Regenerate. * syscalls/arm-linux.xml: Regenerate. * syscalls/i386-linux.xml: Regenerate. * syscalls/mips-n32-linux.xml: Regenerate. * syscalls/mips-n64-linux.xml: Regenerate. * syscalls/mips-o32-linux.xml: Regenerate. * syscalls/ppc-linux.xml: Regenerate. * syscalls/ppc64-linux.xml: Regenerate. * syscalls/s390-linux.xml: Regenerate. * syscalls/s390x-linux.xml: Regenerate. * syscalls/sparc-linux.xml: Regenerate. * syscalls/sparc64-linux.xml: Regenerate. gdb/testsuite/ * gdb.base/catch-syscall.exp (do_syscall_tests): Add call to test_catch_syscall_group. (test_catch_syscall_group): New. gdb/doc/ * gdb.texinfo (Set Catchpoints): Add 'group' argument to catch syscall.
2016-07-23Fix ARMv8.1/v8.2 for hw watchpoint and breakpointAndrew Pinski1-0/+9
The problem here is ARMv8.1 (and ARMv8.2) define a different debug version than ARMv8 (7 and 8 respectively). This fixes hw watchpoints and breakpoints by checking for those debug versions too. Committed as obvious after a test on aarch64-linux-gnu (on a ThunderX machine which has ARMv8.1 support enabled). ChangeLog: * nat/aarch64-linux-hw-point.c (aarch64_linux_get_debug_reg_capacity): Handle ARMv8.1 and ARMv8.2 debug versions. * nat/aarch64-linux-hw-point.h (AARCH64_DEBUG_ARCH_V8_1): New define. (AARCH64_DEBUG_ARCH_V8_2): New define. Signed-off-by: Andrew Pinski <apinski@cavium.com>
2016-07-23Support JIT debugging on MS-WindowsРуслан Ижбулатов1-0/+7
gdb/ChangeLog: 2016-06-30 Руслан Ижбулатов <lrn1986@gmail.com> PR gdb/14529 * windows-nat.c (signal_event_command): New command 'signal-event' for W32 JIT debug support. * NEWS: Add an entry about the new 'signal-event' command. gdb/doc/ChangeLog: 2016-06-30 Руслан Ижбулатов <lrn1986@gmail.com> * gdb.texinfo (Cygwin Native): Document the new 'signal-event' command.
2016-07-22PR rust/20162 - fix gdb regressions caused by rust 1.10Tom Tromey1-0/+10
PR rust/20162 started life as a reminder to test gdb with versions of rust after 1.8; but now concerns some gdb regressions seen with rust 1.10 ("beta") and 1.11 ("nightly"). The failures turn out to be a discrepancy between how rustc emits DWARF and how gdb interprets it. In particular, rustc will emit DWARF like: <2><bc>: Abbrev Number: 9 (DW_TAG_structure_type) <bd> DW_AT_name : (indirect string, offset: 0x46a): HasMethods <c1> DW_AT_byte_size : 4 ... <3><cc>: Abbrev Number: 11 (DW_TAG_subprogram) ... <df> DW_AT_name : (indirect string, offset: 0x514f): new gdb wants to see a separate top-level DW_TAG_subprogram that refers to this one via DW_AT_specification; but rustc doesn't emit one. By my reading of DWARF 4 5.5.7, this is ok, and gdb is incorrect here. Fixing this involved a new case in scan_partial_symbols, and then a further change in process_structure_scope to account for the fact that, in Rust, such functions are not methods and should not be attached to the structure type. Next, it turns out that rust is emitting bad values for DW_AT_linkage_name, e.g.: <db> DW_AT_linkage_name: (indirect string, offset: 0x422): _ZN7methods8{{impl}}3newE The the "{{impl}}" stuff is apparently some side effect of a change to the compiler's internal representation. Oops! This also had a simple fix -- disregard these mangled names. With these changes, there are no regressions in the gdb Rust tests with either 1.10 or 1.11. 1.9, the stable release, is still pretty broken, but I think there's nothing much to do about that. These changes are a bit hackish, but no worse, I think, than other kinds of quirk handling already done in the DWARF parser. I have reported all the rustc bugs upstream. I plan to remove these hacks from gdb some suitable time after they have been fixed in released versions of Rust. 2016-07-22 Tom Tromey <tom@tromey.com> PR rust/20162: * dwarf2read.c (scan_partial_symbols) <DW_TAG_structure_type>: Call scan_partial_symbols for children when reading a Rust CU. (dwarf2_physname): Ignore invalid DW_AT_linkage_name generated by rustc. (process_structure_scope) <DW_TAG_subprogram>: Call read_func_scope for Rust.
2016-07-22Get "num" as unsigned in ctfYao Qi1-0/+5
I see the following fail due to the warning, -trace-frame-collected^M [warning] Extracting signed value from an unsigned int (num)^M .... FAIL: gdb.trace/mi-trace-frame-collected.exp: ctf: -trace-frame-collected In ctf metadata, "num" in "tsv" is defined as unint32_t, ctf_save_write_metadata (&writer->tcs, "event {\n\tname = \"tsv\";\n\tid = %u;\n" "\tfields := struct { \n" "\t\tuint64_t val;\n" "\t\tuint32_t num;\n" "\t};\n" "};\n", CTF_EVENT_ID_TSV); so we should read it as unsigned. The patch below fixes the fail by changing to bt_ctf_get_uint64. gdb: 2016-07-22 Yao Qi <yao.qi@linaro.org> * ctf.c (ctf_traceframe_info): Call bt_ctf_get_uint64 rather than bt_ctf_get_int64.
2016-07-21Allow empty struct expressions in RustTom Tromey1-0/+6
I learned recently that empty struct expressions, like "X{}", have been promoted from experimental to stable in Rust. This patch changes the Rust expression parser to allow this case. New test case included. Built and regtested on x86-64 Fedora 23, using Rust 1.11 beta. 2016-07-21 Tom Tromey <tom@tromey.com> * rust-lang.c (rust_tuple_struct_type_p): Return false for empty structs. * rust-exp.y (struct_expr_list): Allow empty elements. 2016-07-21 Tom Tromey <tom@tromey.com> * gdb.rust/simple.rs (main): Use empty struct expression. * gdb.rust/simple.exp: Add tests for empty struct expression.
2016-07-21Add -Wunused-but-set-* to buildTom Tromey1-0/+6
This adds -Wunused-but-set-variable and -Wunused-but-set-parameter to configure. 2016-07-21 Tom Tromey <tom@tromey.com> * configure: Rebuild. * warning.m4 (AM_GDB_WARNINGS) <build_warnings>: Add -Wunused-but-set-parameter, -Wunused-but-set-variable. 2016-07-21 Tom Tromey <tom@tromey.com> * configure: Rebuild.
2016-07-21Fix djgpp gdb buildPedro Alves1-0/+11
- A few missing casts required by C++, resulting in: ../../src/gdb/ser-go32.c:795:21: error: invalid conversion from 'const void*' to 'const char*' [-fpermissive] etc. - dos_noop has an incompatible prototype with struct serial_ops's setparity, resulting in: ../../src/gdb/ser-go32.c:874:1: error: invalid conversion from 'int (*)(serial*)' to 'int (*)(serial*, int)' [-fpermissive] (I thought of calling the ser-base.c default methods, but djgpp doesn't include ser-base.c in the build.) gdb/ChangeLog: 2016-07-21 Pedro Alves <palves@redhat.com> * go32-nat.c (go32_create_inferior): Add cast. * ser-go32.c (dos_noop): Delete. (dos_flush_output, dos_setparity, dos_drain_output): New functions. (dos_write): Add cast. (dos_ops): Use dos_flush_output, dos_setparity and dos_drain_output. * top.c (do_chdir_cleanup): Add cast.
generated by cgit v1.1 at 2024-12-18 12:46:29 +0000