aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-10-08Switch to futuresusers/cbiesinger/threadpoolChristian Biesinger3-22/+16
2019-10-02Implement a thread poolChristian Biesinger6-24/+129
2019-10-01Don't use the mutex for each symbol_set_names callChristian Biesinger3-92/+115
This avoids the lock contention that was seen with tromey's patch (it moves it to a once- per-thread lock call from a once-per-symbol call). It speeds up "attach to Chrome's content_shell binary" from 44 sec -> 30 sec (32%) (compared to GDB trunk), or from 37 sec compared to this patchset before this patch. gdb/ChangeLog: 2019-09-28 Christian Biesinger <cbiesinger@google.com> * minsyms.c (minimal_symbol_reader::install): Only do demangling on the background thread; still call symbol_set_names on the main thread. * symtab.c (symbol_find_demangled_name): Make public, so that minsyms.c can call it. (symbol_set_names): Remove mutex. Avoid demangle call if the demangled name is already set. * symtab.h (symbol_find_demangled_name): Make public.
2019-10-01Use run_on_main_thread in gdb.post_eventTom Tromey2-69/+70
This changes gdb.post_event to use the new run_on_main_thread function. This is somewhat tricky because the Python GIL must be held while manipulating reference counts. 2019-09-30 Tom Tromey <tom@tromey.com> * python/python.c (class gdbpy_gil): New. (struct gdbpy_event): Add constructor, destructor, operator(). (gdbpy_post_event): Use run_on_main_thread. (gdbpy_initialize_events): Remove. (do_start_initialization): Update.
2019-10-01Add maint set/show max-worker-threadsTom Tromey5-0/+43
This adds maint commands to control the maximum number of worker threads that gdb can use. 2019-09-30 Tom Tromey <tom@tromey.com> * NEWS: Add entry. * maint.c (_initialize_maint_cmds): Add "max-worker-threads" maint commands. gdb/doc/ChangeLog 2019-09-30 Tom Tromey <tom@tromey.com> * gdb.texinfo (Maintenance Commands): Document new maint commands.
2019-10-01Demangle minsyms in parallelTom Tromey5-10/+160
This patch introduces a simple parallel for_each and changes the minimal symbol reader to use it when computing the demangled name for a minimal symbol. This yields a speedup when reading minimal symbols. gdb/ChangeLog 2019-09-30 Tom Tromey <tom@tromey.com> * minsyms.c (minimal_symbol_reader::install): Use parallel_for_each. * gdbsupport/parallel-for.h: New file. * gdbsupport/parallel-for.c: New file. * Makefile.in (HFILES_NO_SRCDIR): Add gdbsupport/parallel-for.h. (COMMON_SFILES): Add gdbsupport/parallel-for.c.
2019-09-30Introduce thread-safe way to handle SIGSEGVTom Tromey4-73/+130
The gdb demangler installs a SIGSEGV handler in order to protect gdb from demangler bugs. However, this is not thread-safe, as signal handlers are global to the process. This patch changes gdb to always install a global SIGSEGV handler, and then lets threads indicate their interest in handling the signal by setting a thread-local variable. This patch then arranges for the demangler code to use this; being sure to arrange for calls to warning and the like to be done on the main thread. One thing I wondered while writing this patch is if there are any systems that do not have "sigaction". If gdb could assume this, it would simplify this code. gdb/ChangeLog 2019-09-30 Tom Tromey <tom@tromey.com> * event-top.h (thread_local_segv_handler): Declare. * event-top.c (thread_local_segv_handler): New global. (install_handle_sigsegv, handle_sigsegv): New functions. (async_init_signals): Install SIGSEGV handler. * cp-support.c (gdb_demangle_jmp_buf): Change type. Now thread-local. (report_failed_demangle): New function. (gdb_demangle): Make core_dump_allowed atomic. Remove signal handler-setting code, instead use segv_handler. Run warning code on main thread.
2019-09-30Introduce run_on_main_threadTom Tromey5-0/+176
This introduces a way for a callback to be run on the main thread. gdb/ChangeLog 2019-09-30 Tom Tromey <tom@tromey.com> * unittests/main-thread-selftests.c: New file. * Makefile.in (SUBDIR_UNITTESTS_SRCS): Add main-thread-selftests.c. * ser-event.h (run_on_main_thread): Declare. * ser-event.c (runnable_event, runnables, runnable_mutex): New globals. (run_events, run_on_main_thread, _initialize_ser_event): New functions.
2019-09-30Lock the demangled hash tableTom Tromey2-65/+93
This introduces a lock that is used when modifying the demangled hash table. gdb/ChangeLog 2019-09-30 Tom Tromey <tom@tromey.com> * symtab.c (demangled_mutex): New global. (symbol_set_names): Use a lock_guard.
2019-09-30Introduce alternate_signal_stack RAII classTom Tromey3-24/+78
This introduces a new RAII class that temporarily installs an alternate signal stack (on systems that have sigaltstack); then changes the one gdb use of sigaltstack to use this class instead. This will be used in a later patch, when creating new threads that may want to handle SIGSEGV. gdb/ChangeLog 2019-09-30 Tom Tromey <tom@tromey.com> * main.c (setup_alternate_signal_stack): Remove. (captured_main_1): Use gdb::alternate_signal_stack. * gdbsupport/alt-stack.h: New file.
2019-09-30Add RAII class for blocking gdb signalsTom Tromey6-0/+291
This adds configury support and an RAII class that can be used to temporarily block signals that are used by gdb. (This class is not used in this patch, but it split out for easier review.) The idea of this patch is that these signals should only be delivered to the main thread. So, when creating a background thread, they are temporarily blocked; the blocked state is inherited by the new thread. gdb/ChangeLog 2019-09-30 Tom Tromey <tom@tromey.com> * gdbsupport/common.m4 (GDB_AC_COMMON): Check for pthread_sigmask. * configure: Rebuild. * gdbsupport/block-signals.h: New file. gdb/gdbserver/ChangeLog 2019-09-30 Tom Tromey <tom@tromey.com> * configure: Rebuild.
2019-09-30Add configure check for std::threadTom Tromey10-4/+1593
This adds a configure check for std::thread. This is needed because std::thread is not available on some systems, like some versions of mingw and DJGPP. This also adds configury to make sure that a threaded gdb links against the correct threading library (-lpthread or the like), and passes the right flags (e.g., -pthread) to the compilations. gdb/ChangeLog 2019-09-30 Tom Tromey <tom@tromey.com> * acinclude.m4: Include ax_pthread.m4. * Makefile.in (PTHREAD_CFLAGS, PTHREAD_LIBS): New variables. (INTERNAL_CFLAGS_BASE): Use PTHREAD_CFLAGS. (CLIBS): Use PTHREAD_LIBS. (aclocal_m4_deps): Add ax_pthread.m4. * config.in, configure: Rebuild. * gdbsupport/common.m4 (GDB_AC_COMMON): Check for std::thread. gdb/gdbserver/ChangeLog 2019-09-30 Tom Tromey <tom@tromey.com> * acinclude.m4: Include ax_pthread.m4. * config.in, configure: Rebuild.
2019-09-30Defer minimal symbol name-settingTom Tromey3-1/+28
Currently the demangled name of a minimal symbol is set when creating the symbol. However, there is no intrinsic need to do this. This patch instead arranges for the demangling to be done just before the minsym hash tables are filled. This will be useful in a later patch. gdb/ChangeLog 2019-09-30 Tom Tromey <tom@tromey.com> * symtab.h (struct minimal_symbol) <name_set>: New member. * minsyms.c (minimal_symbol_reader::record_full): Copy name. Don't call symbol_set_names. (minimal_symbol_reader::install): Call symbol_set_names.
2019-09-30Use m4_include, not sinclude in .m4 filesTom Tromey6-30/+45
Pedro pointed out that sinclude does not error if a file is missing. This patch changes gdb to only use m4_include, which seems more correct. gdb/ChangeLog 2019-09-30 Tom Tromey <tom@tromey.com> * configure: Rebuild. * acinclude.m4: Use m4_include, not sinclude. gdb/gdbserver/ChangeLog 2019-09-30 Tom Tromey <tom@tromey.com> * configure: Rebuild. * acinclude.m4: Use m4_include, not sinclude. gdb/testsuite/ChangeLog 2019-09-30 Tom Tromey <tom@tromey.com> * configure: Rebuild. * aclocal.m4: Use m4_include, not sinclude.
2019-09-30[PATCH v2 2/4] DWARF 5 support: Handle DW_FORM_strxAli Tamur2-0/+15
* Handle DW_FORM_strx forms everywhere. Tested with CC=/usr/bin/gcc (version 8.3.0) against master branch (also with -gsplit-dwarf and -gdwarf-4 flags) and there was no increase in the set of tests that fails. This is part of an effort to support DWARF 5 in gdb. gdb/ChangeLog: * dwarf2read.c (skip_one_die): Handle DW_FORM_strx forms. (dwarf2_string_attr): Likewise.
2019-10-01Automatic date update in version.inGDB Administrator1-1/+1
2019-09-30Remove extra whitespaces at the end of lines.Ali Tamur2-5/+12
gdb/ChangeLog: * dwarf2read.c (process_full_comp_unit): Remove whitespace at the EOL. (process_full_type_unit): Likewise. (dump_die_shallow): Likewise. (cu_debug_loc_section): Likewise.
2019-09-30Use std::sort instead of qsort in minsyms.cChristian Biesinger2-22/+24
This has better typesafety and is also marginally faster (either due to inlining or because it avoids indirection through a function pointer). Note that in this change: - return 1; /* fn1 has no name, so it is "less". */ + return true; /* fn1 has no name, so it is "less". */ else if (name1) /* fn2 has no name, so it is "less". */ - return -1; + return false; I am fairly sure the old code was wrong (ie. code didn't match the comment and the comment seemed correct), so I fixed it. gdb/ChangeLog: 2019-09-28 Christian Biesinger <cbiesinger@google.com> * minsyms.c (compare_minimal_symbols): Rename to... (minimal_symbol_is_less_than): ...this, and adjust to STL conventions (return bool, take arguments as references) (minimal_symbol_reader::install): Call std::sort instead of qsort.
2019-09-30Disable all warnings in gdb.rust/traits.rsTom Tromey2-3/+5
With rustc 1.37, I started seeing compiler warnings from the traits.rs test case: warning: trait objects without an explicit `dyn` are deprecated It seems to me that we generally do not want warnings in these test cases. At some point, we'll probably have to patch traits.rs to use the "dyn" keyword; by that time I expect that all the Rust compilers in common use will support it. In the meantime it seemed simplest to simply disable all warnings in this file. gdb/testsuite/ChangeLog 2019-09-30 Tom Tromey <tromey@adacore.com> * gdb.rust/traits.rs: Disable all warnings.
2019-09-30Improve some comments about msymbol handlingChristian Biesinger3-7/+17
This just clarifies some comments about the hashtables involved in msymbols. gdb/ChangeLog: 2019-09-29 Christian Biesinger <cbiesinger@google.com> * minsyms.h (msymbol_hash): Document that this is a case-insensitive hash and why. * objfiles.h (struct objfile_per_bfd_storage) <demangled_names_hash, msymbol_hash, msymbol_demangled_hash>: Improve comments.
2019-09-30gdb: re-write add_psymbol_to_list doc, move it to header fileSimon Marchi3-14/+33
The comment above the add_psymbol_to_list function seems outdated and misleading, here's an attempt at improving it. gdb/ChangeLog: * psymtab.c (add_psymbol_to_list): Move comment to psympriv.h. * psympriv.h (add_psymbol_to_list): Move comment here and update it.
2019-09-30PR25046, readelf "Reading xxx bytes extends past end of file for dynamic ↵Alan Modra2-3/+9
section" PR 25046 * readelf.c (process_program_headers): Clear dynamic_addr and dynamic_size earlier.
2019-09-30Automatic date update in version.inGDB Administrator1-1/+1
2019-09-29[gdb/contrib] cc-with-tweaks.sh: Create .dwz file in .tmp subdirTom de Vries4-6/+26
When running a test-case gdb.base/foo.exp with cc-with-dwz-m, a file build/gdb/testsuite/outputs/gdb.base/foo/foo.dwz will be created, alongside executable build/gdb/testsuite/outputs/gdb.base/foo/foo. This can cause problems in f.i. test-cases that test file name completion. Make these problems less likely by moving foo.dwz to a .tmp subdir: build/gdb/testsuite/outputs/gdb.base/foo/.tmp/foo.dwz. Tested on x86_64-linux. gdb/ChangeLog: 2019-09-29 Tom de Vries <tdevries@suse.de> * contrib/cc-with-tweaks.sh (get_tmpdir): New function. Use $tmpdir/$(basename "$output_file").dwz instead of "${output_file}.dwz". gdb/testsuite/ChangeLog: 2019-09-29 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/gdb-index.exp: Handle new location of .dwz file.
2019-09-29[gdb/testsuite] Make pass message unique in gdb-index.exp for cc-with-dwz-mTom de Vries2-8/+14
With cc-with-dwz-m, we get: ... PASS: gdb.dwarf2/gdb-index.exp: objcopy PASS: gdb.dwarf2/gdb-index.exp: objcopy ... Make the pass message unique by using with_test_prefix: ... PASS: gdb.dwarf2/gdb-index.exp: objcopy PASS: gdb.dwarf2/gdb-index.exp: modify dwz file: objcopy ... Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2019-09-29 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/gdb-index.exp: Use with_test_prefix for second objcopy.
2019-09-29Automatic date update in version.inGDB Administrator1-1/+1
2019-09-28gdb: include gdbarch.h in hppa-linux-nat.cSimon Marchi2-0/+6
hppa-linux-nat.c fails to build due to the gdbarch stuff not being declared, for example: hppa-linux-nat.c: In function ‘void fetch_register(regcache*, int)’: hppa-linux-nat.c:230:7: error: ‘gdbarch_cannot_fetch_register’ was not declared in this scope if (gdbarch_cannot_fetch_register (gdbarch, regno)) Include gdbarch.h to fix it. gdb/ChangeLog: PR gdb/25045 * hppa-linux-nat.c: Include gdbarch.h.
2019-09-28PR16794, gold ignores R_386_GOTOFF addendAlan Modra3-8/+14
An R_386_GOTOFF relocation has an addend, typically used when a symbol can be replaced by its section symbol plus an offset. psymval->value(object,0) is quite wrong then, fix it. PR 16794 * i386.cc (Target_i386::Relocate::relocate <R_386_GOTOFF>): Don't ignore addend, apply using pcrel32. * x86_64.cc (Target_x86_64::Relocate::relocate <R_X86_64_GOTOFF64>): Similarly use pcrel64.
2019-09-28Automatic date update in version.inGDB Administrator1-1/+1
2019-09-27[gdb/testsuite] Fix incomplete regexps in step-precsave.expTom de Vries2-2/+8
The commit 68f7d34dd50 "[gdb/testsuite] Add KFAIL for missing support of reverse-debugging of vmovd" rewrites a gdb_test into a gdb_test_multiple but forgets to add the $gdb_prompt part in the regexp. Add the missing parts of the regexps. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2019-09-27 Tom de Vries <tdevries@suse.de> * gdb.reverse/step-precsave.exp: Add missing $gdb_prompt in regexps.
2019-09-27[gdb/testsuite] Add KFAIL for missing support of reverse-debugging of vmovdTom de Vries2-1/+14
On my openSUSE Leap 15.1 system I run into: ... (gdb) PASS: gdb.reverse/step-precsave.exp: turn on process record break 76^M Breakpoint 2 at 0x400654: file step-reverse.c, line 76.^M (gdb) PASS: gdb.reverse/step-precsave.exp: breakpoint at end of main continue^M Continuing.^M Process record does not support instruction 0xc5 at address 0x7ffff783fc70.^M Process record: failed to record execution log.^M ^M Program stopped.^M 0x00007ffff783fc70 in __memset_avx2_unaligned_erms () from /lib64/libc.so.6^M (gdb) FAIL: gdb.reverse/step-precsave.exp: run to end of main ... The problem is that the vmovd instruction is not supported in reverse-debugging (PR record/23188). Add a KFAIL for this PR. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2019-09-27 Tom de Vries <tdevries@suse.de> PR record/23188 * gdb.reverse/step-precsave.exp: Add kfail for PR record/23188.
2019-09-27Automatic date update in version.inGDB Administrator1-1/+1
2019-09-26Revert "Improve ptrace-error detection on Linux targets"Sergio Durigan Junior16-487/+31
This reverts commit 381beca6146ac68b57edf47d28cdb335fbd11635. The patch hasn't been fully reviewed yet, and Pedro would like to see more fixes.
2019-09-26Improve ptrace-error detection on Linux targetsSergio Durigan Junior16-31/+487
In Fedora GDB, we carry the following patch: https://src.fedoraproject.org/rpms/gdb/blob/8ac06474ff1e2aa4920d14e0666b083eeaca8952/f/gdb-attach-fail-reasons-5of5.patch Its purpose is to try to detect a specific scenario where SELinux's 'deny_ptrace' option is enabled, which prevents GDB from ptrace'ing in order to debug the inferior (PTRACE_ATTACH and PTRACE_TRACEME will fail with EACCES in this case). I like the idea of improving error detection and providing more information to the user (a simple "Permission denied" can be really frustrating), but I don't fully agree with the way the patch was implemented: it makes GDB link against libselinux only for the sake of consulting the 'deny_ptrace' setting, and then prints a warning if ptrace failed and this setting is on. My first thought (and attempt) was to make GDB print a generic warning when a ptrace error happened; this message would just point the user to our documentation, where she could find more information about possible causes for the error (and try to diagnose/fix the problem). This proved to be too simple, and I was convinced that it is actually a good idea to go the extra kilometre and try to pinpoint the specific problem (or problems) preventing ptrace from working, as well as provide useful suggestions on how the user can fix things. Here is the patch I came up with. It implements a new function, 'linux_ptrace_restricted_fail_reason', which does a few things to check what's wrong with ptrace: - It dlopen's "libselinux.so.1" and checks if the "deny_ptrace" option is enabled. - It reads the contents of "/proc/sys/kernel/yama/ptrace_scope" and checks if it's different than 0. For each of these checks, if it succeeds, the user will see a message informing about the restriction in place, and how it can be disabled. For example, if "deny_ptrace" is enabled, the user will see: # gdb /usr/bin/true ... Starting program: /usr/bin/true warning: Could not trace the inferior process. warning: ptrace: Permission denied The SELinux 'deny_ptrace' option is enabled and preventing GDB from using 'ptrace'. You can disable it by executing (as root): setsebool deny_ptrace off If you are debugging the inferior remotely, the ptrace restriction(s) need to be disabled in the target system (e.g., where GDBserver is running). During startup program exited with code 127. (gdb) In case "/proc/sys/kernel/yama/ptrace_scope" is > 0: # gdb /usr/bin/true ... Starting program: /usr/bin/true warning: Could not trace the inferior process. warning: ptrace: Operation not permitted The Linux kernel's Yama ptrace scope is in effect, which can prevent GDB from using 'ptrace'. You can disable it by executing (as root): echo 0 > /proc/sys/kernel/yama/ptrace_scope If you are debugging the inferior remotely, the ptrace restriction(s) need to be disabled in the target system (e.g., where GDBserver is running). During startup program exited with code 127. (gdb) If both restrictions are enabled, both messages will show up. This works for gdbserver as well, and actually fixes a latent bug I found: when ptrace is restricted, gdbserver would hang due to an unchecked ptrace call: # gdbserver :9988 /usr/bin/true gdbserver: linux_ptrace_test_ret_to_nx: Cannot PTRACE_TRACEME: Operation not permitted gdbserver: linux_ptrace_test_ret_to_nx: status 256 is not WIFSTOPPED! gdbserver: linux_ptrace_test_ret_to_nx: failed to kill child pid 2668100 No such process [ Here you would have to issue a C-c ] Now, you will see: # gdbserver :9988 /usr/bin/true gdbserver: linux_ptrace_test_ret_to_nx: Cannot PTRACE_TRACEME: Permission denied gdbserver: linux_ptrace_test_ret_to_nx: status 256 is not WIFSTOPPED! gdbserver: linux_ptrace_test_ret_to_nx: failed to kill child pid 2766868 No such process gdbserver: Could not trace the inferior process. gdbserver: ptrace: Permission denied The SELinux 'deny_ptrace' option is enabled and preventing GDB from using 'ptrace'. You can disable it by executing (as root): setsebool deny_ptrace off If you are debugging the inferior remotely, the ptrace restriction(s) need to be disabled in the target system (e.g., where GDBserver is running). # (I decided to keep all the other messages, even though I find them a bit distracting). If GDB can't determine the cause for the failure, it will still print the generic error message which tells the user to check our documentation: There might be restrictions preventing ptrace from working. Please see the appendix "Linux kernel ptrace restrictions" in the GDB documentation for more details. If you are debugging the inferior remotely, the ptrace restriction(s) need to be disabled in the target system (e.g., where GDBserver is running). This means that the patch expands our documentation and creates a new appendix section named "Linux kernel ptrace restrictions", with sub-sections for each possible restriction that might be in place. Notice how, on every message, we instruct the user to "do the right thing" if gdbserver is being used. This is because if the user started gdbserver *before* any ptrace restriction was in place, and then, for some reason, one or more restrictions get enabled, then the error message will be displayed both on gdbserver *and* on the connected GDB. Since the user will be piloting GDB, it's important to explicitly say that the ptrace restrictions are enabled in the target, where gdbserver is running. The current list of possible restrictions is: - SELinux's 'deny_ptrace' option (detected). - YAMA's /proc/sys/kernel/yama/ptrace_scope setting (detected). - seccomp on Docker containers (I couldn't find how to detect). It's important to mention that all of this is Linux-specific; as far as I know, SELinux, YAMA and seccomp are Linux-only features. I tested this patch locally, on my Fedora 30 machine (actually, a Fedora Rawhide VM), but I'm not proposing a testcase for it because of the difficulty of writing one. WDYT? gdb/doc/ChangeLog: 2019-09-26 Sergio Durigan Junior <sergiodj@redhat.com> * gdb.texinfo (Linux kernel ptrace restrictions): New appendix section. gdb/ChangeLog: 2019-09-26 Sergio Durigan Junior <sergiodj@redhat.com> Jan Kratochvil <jan.kratochvil@redhat.com> Pedro Alves <palves@redhat.com> * gdbsupport/gdb-dlfcn.h (gdb_dlopen): Update comment and mention that the function throws an error. * inf-ptrace.c (default_inf_ptrace_me_fail_reason): New function. (inf_ptrace_me_fail_reason): New variable. (inf_ptrace_me): Update call to 'trace_start_error_with_name'. * inf-ptrace.h (inf_ptrace_me_fail_reason): New variable. * linux-nat.c (attach_proc_task_lwp_callback): Call 'linux_ptrace_attach_fail_reason_lwp'. (linux_nat_target::attach): Update call to 'linux_ptrace_attach_fail_reason'. (_initialize_linux_nat): Set 'inf_ptrace_me_fail_reason'. * nat/fork-inferior.c (trace_start_error_with_name): Add optional 'append' argument. * nat/fork-inferior.h (trace_start_error_with_name): Update prototype. * nat/linux-ptrace.c: Include "gdbsupport/gdb-dlfcn.h", "gdbsupport/filestuff.h" and "nat/fork-inferior.h". (selinux_ftype): New typedef. (linux_ptrace_restricted_fail_reason): New function. (linux_ptrace_attach_fail_reason_1): New function. (linux_ptrace_attach_fail_reason): Change first argument type from 'ptid_t' to 'pid_t'. Call 'linux_ptrace_attach_fail_reason_1' and 'linux_ptrace_restricted_fail_reason'. (linux_ptrace_attach_fail_reason_lwp): New function. (linux_ptrace_me_fail_reason): New function. (errno_pipe): New variable. (linux_fork_to_function): Initialize pipe before forking. (linux_child_function): Deal with errno-passing from child. Handle ptrace error. (linux_check_child_ptrace_errno): New function. (linux_check_child_ptrace_errno): Call 'linux_check_child_ptrace_errno'. * nat/linux-ptrace.h (linux_ptrace_attach_fail_reason): Update prototype. (linux_ptrace_attach_fail_reason_lwp): New prototype. (linux_ptrace_me_fail_reason): New prototype. * remote.c (extended_remote_target::attach): Handle error message passed by the server when attach fails. gdb/gdbserver/ChangeLog: 2019-09-26 Sergio Durigan Junior <sergiodj@redhat.com> Pedro Alves <palves@redhat.com> * linux-low.c (linux_ptrace_fun): Call 'linux_ptrace_me_fail_reason'. (attach_proc_task_lwp_callback): Call 'linux_ptrace_attach_fail_reason_lwp'. (linux_attach): Call 'linux_ptrace_attach_fail_reason'. * server.c (handle_v_attach): Use try..catch when calling 'attach_inferior', and send an error message to the client when needed. * thread-db.c (attach_thread): Call 'linux_ptrace_attach_fail_reason_lwp'.
2019-09-26Convert symtab.h function signatures to use bool instead of intChristian Biesinger6-68/+95
gdb/ChangeLog: 2019-09-26 Christian Biesinger <cbiesinger@google.com> * blockframe.c (find_pc_partial_function): Change return type to bool. * elfread.c (elf_gnu_ifunc_resolve_name): Likewise. * minsyms.c (in_gnu_ifunc_stub): Likewise. (stub_gnu_ifunc_resolve_name): Likewise. * symtab.c (compare_filenames_for_search): Likewise. (compare_glob_filenames_for_search): Likewise. (matching_obj_sections): Likewise. (symbol_matches_domain): Likewise. (find_line_symtab): Change out param EXACT_MATCH to bool *. (find_line_pc): Change return type to bool. (find_line_pc_range): Likewise. (producer_is_realview): Likewise. * symtab.h (symbol_matches_domain): Likewise. (find_pc_partial_function): Likewise. (find_pc_line_pc_range): Likewise. (in_gnu_ifunc_stub): Likewise. (struct gnu_ifunc_fns) <gnu_ifunc_resolve_name>: Likewise. (find_line_pc): Likewise. (find_line_pc_range): Likewise. (matching_obj_sections): Likewise. (find_line_symtab): Change out parameter to bool. (producer_is_realview): Change return type to bool. (compare_filenames_for_search): Likewise. (compare_glob_filenames_for_search): Likewise.
2019-09-26Remove gdb_usleep.cTom Tromey5-72/+8
I noticed that gdb_usleep is unused, so this patch removes it. gdb/ChangeLog 2019-09-26 Tom Tromey <tom@tromey.com> * Makefile.in (COMMON_SFILES): Remove gdb_usleep.c. (HFILES_NO_SRCDIR): Remove gdb_usleep.h. * gdb_usleep.h: Remove. * gdb_usleep.c: Remove. * utils.c: Don't include gdb_usleep.h.
2019-09-26Do not expose stub types to PythonTom Tromey7-0/+132
dwarf2read.c will create stub types for Ada "Taft Amendment" types. These stub types can currently be exposed to Python code, where they show up as TYPE_CODE_VOID types (but that, mysteriously, can sometimes be used in other ways). While it's possible to work with such types by using strip_typedefs, this seemed unpleasant to me. This patch takes another approach instead, which is to try not to expose stub types to Python users. gdb/ChangeLog 2019-09-26 Tom Tromey <tromey@adacore.com> * python/py-type.c (type_to_type_object): Call check_typedef for stub types. gdb/testsuite/ChangeLog 2019-09-26 Tom Tromey <tromey@adacore.com> * gdb.ada/py_taft.exp: New file. * gdb.ada/py_taft/main.adb: New file. * gdb.ada/py_taft/pkg.adb: New file. * gdb.ada/py_taft/pkg.ads: New file.
2019-09-26Remove initialize_utilsTom Tromey4-54/+54
initialize_utils only registers some commands, so it isn't necessary to run it at any particular time during startup. This patch removes it and merges its contents into _initialize_utils. Tested by the buildbot. gdb/ChangeLog 2019-09-26 Tom Tromey <tom@tromey.com> * utils.h (initialize_utils): Don't declare. * top.c (gdb_init): Don't call initialize_utils. * utils.c (initialize_utils): Remove. Move contents... (_initialize_utils): ... here.
2019-09-26PR24262, plugin search dir doesn't respect --libdirAlan Modra6-35/+73
bfd/ PR 24262 * Makefile.am (AM_CPPFLAGS): Add -DLIBDIR. * plugin.c (load_plugin): Search both ${libdir}/bfd-plugins and ${bindir}/../lib/bfd-plugins if different. * Makefile.in: Regenerate. ld/ PR 24262 * ld.texi (-plugin): Revert 2019-03-15 change.
2019-09-26Automatic date update in version.inGDB Administrator1-1/+1
2019-09-25Remove make_hex_stringTom Tromey4-24/+8
I noticed that make_hex_string does essentially the same thing as bin2hex, and furthermore is only called in a single spot. This patch removes make_hex_string. Tested by the builtbot. gdb/ChangeLog 2019-09-25 Tom Tromey <tom@tromey.com> * python/py-objfile.c (objfpy_get_build_id): Use bin2hex. * utils.h (make_hex_string): Don't declare. * utils.c (make_hex_string): Remove.
2019-09-26SORT_BY_INIT_PRIORITYAlan Modra3-35/+60
I was looking at the implementation of this script keyword today and couldn't remember why we do what we do in get_init_priority, because the comments explain how the init_priority is encoded but don't say why it is necessary to extract the priority and sort on that. So after figuring out why (again), I wrote some more comments. Then I simplified get_init_priority a little, adding some sanity checking on the strtoul result. This actually makes get_init_priority support sorting by numerical suffix more generally, but I figure this feature would be better as a new keyword (without the .ctors/.dtors special case), so haven't documented the extension. * ld.texi (SORT_BY_ALIGNMENT): Reword slightly. (SORT_BY_INIT_PRIORITY): Elucidate. * ldlang.c: Include limits.h. (get_init_priority): Comment. Change param to a section, return an int. Sanity check priority digits. Support sorting more sections with trailing digits. Return -1 on error. (compare_section): Adjust.
2019-09-25Silence a build-time warning about constant comparisons when building with ↵Nick Clifton2-4/+9
clang, * emultempl/avrelf.em (_before_allocation): Silence build warning using clang.
2019-09-25Automatic date update in version.inGDB Administrator1-1/+1
2019-09-24[gdb/tdep] Handle mxcsr kernel bug on Intel Skylake CPUsTom de Vries4-2/+34
On my openSUSE Leap 15.1 x86_64 Skylake system with the default (4.12) kernel, I run into: ... FAIL: gdb.base/gcore.exp: corefile restored all registers ... The problem is that there's a difference in the mxcsr register value before and after the gcore command: ... - mxcsr 0x0 [ ] + mxcsr 0x400440 [ DAZ OM ] ... This can be traced back to amd64_linux_nat_target::fetch_registers, where xstateregs is partially initialized by the ptrace call: ... char xstateregs[X86_XSTATE_MAX_SIZE]; struct iovec iov; amd64_collect_xsave (regcache, -1, xstateregs, 0); iov.iov_base = xstateregs; iov.iov_len = sizeof (xstateregs); if (ptrace (PTRACE_GETREGSET, tid, (unsigned int) NT_X86_XSTATE, (long) &iov) < 0) perror_with_name (_("Couldn't get extended state status")); amd64_supply_xsave (regcache, -1, xstateregs); ... after which amd64_supply_xsave is called. The amd64_supply_xsave call is supposed to only use initialized parts of xstateregs, but due to a kernel bug on intel skylake (fixed from 4.14 onwards by commit 0852b374173b "x86/fpu: Add FPU state copying quirk to handle XRSTOR failure on Intel Skylake CPUs") it can happen that the mxcsr part of xstateregs is not initialized, while amd64_supply_xsave expects it to be initialized, which explains the FAIL mentioned above. Fix the undetermined behaviour by initializing xstateregs before calling ptrace, which makes sure we get a 0x0 for mxcsr when this kernel bug occurs, and which also happens to fix the FAIL. Furthermore, add an xfail for this FAIL which triggers the same kernel bug: ... FAIL: gdb.arch/amd64-init-x87-values.exp: check_setting_mxcsr_before_enable: \ check new value of MXCSR is still in place ... Both FAILs pass when using a 5.3 kernel instead on the system mentioned above. Tested on x86_64-linux. gdb/ChangeLog: 2019-09-24 Tom de Vries <tdevries@suse.de> PR gdb/23815 * amd64-linux-nat.c (amd64_linux_nat_target::fetch_registers): Initialize xstateregs before ptrace PTRACE_GETREGSET call. gdb/testsuite/ChangeLog: 2019-09-24 Tom de Vries <tdevries@suse.de> PR gdb/24598 * gdb.arch/amd64-init-x87-values.exp: Add xfail.
2019-09-24Arm: Fix out of range conditional branch (PR/24991)Tamar Christina5-7/+38
The fix for PR12848 introduced an off by one error in the mask, this corrected the negative overflows but not the positive overflows. As a result the conditional branch instructions accepted a too wide positive immediate which resulted in it corrupting the instruction during encoding. The relocation I believe has been incorrectly named, to be consistent with the other relocations it should have been named BRANCH21 which is why the masks for it are confusing. I've replaced the masks with a function out_of_range_p which should make it harder to make such mistakes. The mask for BL/BLX on Armv6t+ is also wrong, the extended range is 25-bits and so the mask should be checking for 24-bits for positive overflow. gas/ChangeLog: PR gas/24991 * config/tc-arm.c (out_of_range_p): New. (md_apply_fix): Use it in BFD_RELOC_THUMB_PCREL_BRANCH9, BFD_RELOC_THUMB_PCREL_BRANCH12, BFD_RELOC_THUMB_PCREL_BRANCH20, BFD_RELOC_THUMB_PCREL_BRANCH23, BFD_RELOC_THUMB_PCREL_BRANCH25 * testsuite/gas/arm/pr24991.d: New test. * testsuite/gas/arm/pr24991.l: New test. * testsuite/gas/arm/pr24991.s: New test.
2019-09-24PR25031, nm reports wrong address on 32bitAlan Modra2-54/+58
Using saved_format breaks when nm is presented with multiple object files, some 32-bit and some 64-bit. PR 25031 * nm.c (print_format_string): New. (get_print_format): Delete saved_format. Move earlier. (set_print_width): Call get_print_format. (print_value): Use print_format_string.
2019-09-24[ARM]: Modify assembler to accept floating and signless datatypes for MVE ↵Srinath Parvathaneni5-6/+81
instruction VLDR. This patch modifies assembler to accept the equivalent sized floating and signless datatypes for VLDR instruction but as alias for the unsigned version. gas/ChangeLog: 2019-09-23 Srinath Parvathaneni <srinath.parvathaneni@arm.com> * config/tc-arm.c (do_mve_vstr_vldr_RQ): Modify function to allow float * and signless datatypes for few cases of VLDR instruction. * testsuite/gas/arm/mve-vldr-bad-3.l: Modify. * testsuite/gas/arm/mve-vldr-bad-3.s: Likewise. * testsuite/gas/arm/mve-vstrldr-1.d: Likewise. * testsuite/gas/arm/mve-vstrldr-1.s: Likewise.
2019-09-24Fix building gold with gcc-10.Nick Clifton2-0/+5
* descriptors.cc: Include <string>
2019-09-24Automatic date update in version.inGDB Administrator1-1/+1