Just to let people know that this is available and how to use it.
Also updates the description of the setting to say the default is 0.
gdb/ChangeLog:
2019-11-26 Christian Biesinger <cbiesinger@google.com>
* NEWS: Mention the new multithreaded symbol loading.
Change-Id: I263add6aae03b523f0870ad4d1e972eada4b382a
Per discussion on gdb-patches with Joel, this patch turns off multihreaded
symbol loading by default. It can be turned on using:
maint set worker-threads unlimited
To keep the behavior as close as possible to the old code, it still
calls symbol_set_names in the old place if n_worker_threads is 0.
gdb/ChangeLog:
2019-11-27 Christian Biesinger <cbiesinger@google.com>
* maint.c (n_worker_threads): Default to 0.
(worker_threads_disabled): New function.
* maint.h (worker_threads_disabled): New function.
* minsyms.c (minimal_symbol_reader::record_full): Call symbol_set_names
here if worker_threads_disabled () is true.
(minimal_symbol_reader::install): Skip all threading if
worker_threads_disabled () is true.
Change-Id: I92ba4f6bbf07363189666327cad452d6b9c8e01d
This is for the msymbol_hash and msymbol_demangled_hash hashtables
in objfile_per_bfd_storage. This basically computes those hash
codes together with the demangled symbol name in the background,
before it inserts the symbols in the hash table.
gdb/ChangeLog:
2019-11-27 Christian Biesinger <cbiesinger@google.com>
* minsyms.c (add_minsym_to_hash_table): Use a previously computed
hash code if possible.
(add_minsym_to_demangled_hash_table): Likewise.
(minimal_symbol_reader::install): Compute the hash codes for msymbol
on the background thread.
* symtab.h (struct minimal_symbol) <hash_value, demangled_hash_value>:
Add these fields.
Change-Id: Ifaa3346e9998f05743bff9e2eaad3f83b954d071
We can also compute the hash for the mangled name on a background
thread so make this function even faster (about a 7% speedup).
gdb/ChangeLog:
2019-11-27 Christian Biesinger <cbiesinger@google.com>
* minsyms.c (minimal_symbol_reader::install): Also compute the hash
of the mangled name on the background thread.
* symtab.c (symbol_set_names): Allow passing in the hash of the
linkage_name.
* symtab.h (symbol_set_names): Likewise.
Change-Id: I044449e7eb60cffc1c43efd3412f2b485bd9faac
The Fortran test gdb.fortran/info-modules compiles the files
info-types.f90 and info-types-2.f90 in that order. Unfortunately
info-types.f90 makes use of a module defined in info-types-2.f90.
This currently doesn't cause a problem if you run all of the Fortran
tests as the info-types.exp test already compiles info-types-2.f90 and
so the module description file 'mod2.mod' will be created, and can
then be found by info-modules.exp during its compile.
If however you try to run just info-modules.exp in a clean build
directory, the test will fail to compile.
Fix this by compiling the source files in the reverse order so that
the module is compiled first, then the test program that uses the
module.
gdb/testsuite/ChangeLog:
* gdb.fortran/info-modules.exp: Compile source files in correct
order.
Change-Id: Ic3a1eded0486f6264ebe3066cf1beafbd2534a91
Running a GDB with the fix for BZ 25065 should cause these new tests
to all pass.
When run against a GDB without the fix, there will be 2 unresolved
testcases. This is what I see in the gdb.sum file when I try it using
a GDB without the fix:
ERROR: GDB process no longer exists
UNRESOLVED: gdb.dwarf2/imported-unit.exp: ptype main::Foo
ERROR: Couldn't send ptype main::foo to GDB.
UNRESOLVED: gdb.dwarf2/imported-unit.exp: ptype main::foo
These are "unresolved" versus outright failures due to the fact that
GDB dies (segfaults) during the running of the test.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/imported-unit.exp: New file.
* gdb.dwarf2/imported-unit.c: New file.
Change-Id: I073fe69b81bd258951615f752df8e95b6e33a271
This is a fix for BZ 25065.
GDB segfaults when running either gdb.cp/subtypes.exp or
gdb.cp/local.exp in conjunction with using the -flto compiler/linker
flag.
A much simpler program, which was used to help create the test for
this fix, is:
-- doit.cc --
int main()
{
class Foo {
public:
int doit ()
{
return 0;
}
};
Foo foo;
return foo.doit ();
}
-- end doit.cc --
gcc -o doit -flto -g doit.cc
gdb -q doit
Reading symbols from doit...
(gdb) ptype main::Foo
type = class Foo {
Segmentation fault (core dumped)
The segfault occurs due to a NULL physname in
c_type_print_base_struct_union in c-typeprint.c. Specifically,
calling is_constructor_name() eventually causes the SIGSEGV is this
code in c-typeprint.c:
const char *physname = TYPE_FN_FIELD_PHYSNAME (f, j);
int is_full_physname_constructor =
TYPE_FN_FIELD_CONSTRUCTOR (f, j)
|| is_constructor_name (physname)
|| is_destructor_name (physname)
|| method_name[0] == '~';
However, looking at compute_delayed_physnames(), we see that
the TYPE_FN_FIELD_PHYSNAME field should never be NULL. This
field will be set to "" for NULL physnames:
physname = dwarf2_physname (mi.name, mi.die, cu);
TYPE_FN_FIELD_PHYSNAME (fn_flp->fn_fields, mi.index)
= physname ? physname : "";
For this particular case, it turns out that compute_delayed_physnames
wasn't being called, which left TYPE_FN_FIELD_PHYSNAME set to the NULL
value that it started with when that data structure was allocated.
The place to fix it, I think, is towards the end of
inherit_abstract_dies().
My first attempt at fix caused the origin CU's method_list (which is
simply the list of methods whose physnames still need to be computed)
to be added to the CU which is doing the inheriting. One drawback
with this approach is that compute_delayed_physnames is (eventually)
called with a CU that's different than the CU in which the methods
were found. It's not clear whether this will cause problems or not.
A safer approach, which is what I ultimately settled on, is to call
compute_delayed_physnames() from inherit_abstract_dies(). One
potential drawback is that all needed types might not be known at that
point. However, in my testing, I haven't seen a problem along these
lines.
gdb/ChangeLog:
* dwarf2read.c (inherit_abstract_dies): Ensure that delayed
physnames are computed for inherited DIEs.
Change-Id: I6c6ffe96b301a9daab9f653956b89e3a33fa9445
I found a couple of unnecessary backslashes in gdb. This removes
them.
Offhand, I wonder whether this abstract_to_concrete thing could be
done some other way? This seems possibly expensive.
Anyway, tested by rebuilding. I'm going to check this in as obvious.
gdb/ChangeLog
2019-11-27 Tom Tromey <tromey@adacore.com>
* dwarf2read.h (struct dwarf2_per_objfile): Remove unnecessary
backslashes.
* cp-support.c: Remove unnecessary backslashes.
Change-Id: I956c91ae24407eeafec8a731545b45f5222e6a9d
Easier to read, shorter, and will later make it possible to make the
name field private.
gdb/ChangeLog:
2019-11-27 Christian Biesinger <cbiesinger@google.com>
* ada-exp.y (write_ambiguous_var): Replace SYMBOL_SET_LINKAGE_NAME
with sym->set_linkage_name.
* coffread.c (coff_read_enum_type): Likewise.
* mdebugread.c (parse_symbol): Likewise.
* stabsread.c (patch_block_stabs): Likewise.
(define_symbol): Likewise.
(read_enum_type): Likewise.
(common_block_end): Likewise.
* symtab.h (struct general_symbol_info) <set_linkage_name>: New
function.
(SYMBOL_SET_LINKAGE_NAME): Remove.
* xcoffread.c (process_xcoff_symbol): Replace SYMBOL_SET_LINKAGE_NAME
with sym->set_linkage_name.
Change-Id: I174a0542c014f1b035070068076308bb8ae79abb
Add '-symbol-info-modules', an MI version of the CLI 'info modules'
command.
gdb/ChangeLog:
* mi/mi-cmds.c (mi_cmds): Add 'symbol-info-modules' entry.
* mi/mi-cmds.h (mi_cmd_symbol_info_modules): Declare.
* mi/mi-symbol-cmds.c (mi_cmd_symbol_info_modules): New function.
* NEWS: Mention new MI command.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-fortran-modules-2.f90: New file.
* gdb.mi/mi-fortran-modules.exp: New file.
* gdb.mi/mi-fortran-modules.f90: New file.
gdb/doc/ChangeLog:
* doc/gdb.texinfo (GDB/MI Symbol Query): Document new MI command
-symbol-info-modules.
Change-Id: Ibc618010d1d5f36ae8a8baba4fb9d9d724e62b0f
Add new MI commands -symbol-info-functions, -symbol-info-variables,
and -symbol-info-types which correspond to the CLI commands 'info
functions', 'info variables', and 'info types' respectively.
gdb/ChangeLog:
* mi/mi-cmds.c (mi_cmds): Add '-symbol-info-functions',
'-symbol-info-types', and '-symbol-info-variables'.
* mi/mi-cmds.h (mi_cmd_symbol_info_functions): Declare.
(mi_cmd_symbol_info_types): Declare.
(mi_cmd_symbol_info_variables): Declare.
* mi/mi-symbol-cmds.c: Add 'source.h' and 'mi-getopt.h' includes.
(output_debug_symbol): New function.
(output_nondebug_symbol): New function.
(mi_symbol_info): New function.
(mi_info_functions_or_variables): New function.
(mi_cmd_symbol_info_functions): New function.
(mi_cmd_symbol_info_types): New function.
(mi_cmd_symbol_info_variables): New function.
* NEWS: Mention new commands.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-sym-info-1.c: New file.
* gdb.mi/mi-sym-info-2.c: New file.
* gdb.mi/mi-sym-info.exp: New file.
gdb/doc/ChangeLog:
* doc/gdb.texinfo (GDB/MI Symbol Query): Document new MI command
-symbol-info-functions, -symbol-info-types, and
-symbol-info-variables.
Change-Id: Ic2fc6a6750bbce91cdde2344791014e5ef45642d
Split the function print_symbol_info into two parts, the new worker
core returns a string, which print_symbol_info then prints. This will
be useful in a later commit when some new MI commands will be added
which will use the worker core to fill some MI output fields.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* symtab.c (symbol_to_info_string): New function, most content
moved from print_symbol_info, but updated to return a std::string.
(print_symbol_info): Update to use symbol_to_info_string and print
returned string.
* symtab.h (symbol_to_info_string): Declare new function.
Change-Id: I6454ce43cacb61d32fbadb9e3655e70823085777
Introduce a new class to wrap up the parameters needed for the
function search_symbols, which has now become a member function of
this new class.
The motivation is that search_symbols already takes a lot of
parameters, and a future commit is going to add even more. This
commit hopefully makes collecting the state required for a search
easier.
As part of this conversion the list of filenames in which to search
has been converted to a std::vector.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* python/python.c (gdbpy_rbreak): Convert to using
global_symbol_searcher.
* symtab.c (file_matches): Convert return type to bool, change
file list to std::vector, update header comment.
(search_symbols): Rename to...
(global_symbol_searcher::search): ...this and update now its
a member function of global_symbol_searcher. Take account of the
changes to file_matches.
(symtab_symbol_info): Convert to using global_symbol_searcher.
(rbreak_command): Likewise.
(search_module_symbols): Likewise.
* symtab.h (enum symbol_search): Update comment.
(search_symbols): Remove declaration.
(class global_symbol_searcher): New class.
Change-Id: I488ab292a892d9e9e84775c632c5f198b6ad3710
Christian pointed out on irc that the threading series broke the build
on mingw. This patch fixes the problem, by moving the initialization
of gdb_demangle_attempt_core_dump into the appropriate #if.
gdb/ChangeLog
2019-11-26 Tom Tromey <tromey@adacore.com>
* cp-support.c (_initialize_cp_support): Conditionally initialize
gdb_demangle_attempt_core_dump.
Change-Id: I9ace0bea75a51f317ea933b607f6b5a94d651eea
This adds a "name_allocated" field to cmd_list_element, so that
commands can own their "name" when necessary. Then, this changes a
few spots in gdb that currently free the name by hand to instead use
this facility.
gdb/ChangeLog
2019-11-26 Tom Tromey <tom@tromey.com>
* python/py-function.c (fnpy_init): Update.
* value.h (add_internal_function): Adjust declaration.
* value.c (function_destroyer): Remove.
(do_add_internal_function): Don't set destroyer or copy name.
(add_internal_function): Take unique_xmalloc_ptr<char> for name.
Set name_allocated.
* python/py-cmd.c (cmdpy_destroyer): Don't free "name".
(cmdpy_init): Set name_allocated.
* cli/cli-decode.h (struct cmd_list_element) <name_allocated>: New
member.
(~cmd_list_element): Free "name" if needed.
Change-Id: Ie1435cea5bbf4bd92056125f112917c607cbb761
add_internal_function sets a command destroyer that frees the doc
string. However, many callers do not pass in an allocated doc string.
This adds a new overload to clearly differentiate the two cases,
fixing the latent bug.
gdb/ChangeLog
2019-11-26 Tom Tromey <tom@tromey.com>
* value.h (add_internal_function): Add new overload. Move
documentation from value.h.
* value.c (do_add_internal_function): New function.
(add_internal_function): Use it. Add new overload.
(function_destroyer): Don't free doc.
* python/py-function.c (fnpy_init): Update.
Change-Id: I3f6df925bc6b3e1bccbad9eeebc487b908bb5a2a
Python commands manage their "doc" string manually, but
cmd_list_element already has doc_allocated to handle this case. This
changes the Python code to use the existing facility.
gdb/ChangeLog
2019-11-26 Tom Tromey <tom@tromey.com>
* python/py-cmd.c (cmdpy_destroyer): Don't free "doc".
(cmdpy_init): Set "doc_allocated".
Change-Id: I0014edc117b051bba1f4db267687d231e7fe9b56
This adds some configury so that gdb can set the names of worker
threads. This makes them show up more nicely when debugging gdb
itself.
2019-11-26 Tom Tromey <tom@tromey.com>
* gdbsupport/thread-pool.c (thread_pool::set_thread_count): Set
name of worker thread.
* gdbsupport/common.m4 (GDB_AC_COMMON): Check for
pthread_setname_np.
* configure, config.in: Rebuild.
gdb/gdbserver/ChangeLog
2019-11-26 Tom Tromey <tom@tromey.com>
* configure, config.in: Rebuild.
Change-Id: I60473d65ae9ae14d8c56ddde39684240c16aaf35
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-11-26 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.
Change-Id: Ie4431e60f328dae48bd96b6c6a8e875e70bda1de
This adds maint commands to control the number of worker threads that
gdb can use.
2019-11-26 Tom Tromey <tom@tromey.com>
* NEWS: Add entry.
* maint.c (_initialize_maint_cmds): Add "worker-threads" maint
commands. Call update_thread_pool_size.
(update_thread_pool_size, maintenance_set_worker_threads): New
functions.
(n_worker_threads): New global.
gdb/doc/ChangeLog
2019-11-26 Tom Tromey <tom@tromey.com>
* gdb.texinfo (Maintenance Commands): Document new maint
commands.
Change-Id: I4fb514faa05879d8afe62c77036a4469d57dca2a
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.
2019-11-26 Christian Biesinger <cbiesinger@google.com>
Tom Tromey <tom@tromey.com>
* minsyms.c (minimal_symbol_reader::install): Use
parallel_for_each.
* gdbsupport/parallel-for.h: New file.
* Makefile.in (HFILES_NO_SRCDIR): Add gdbsupport/parallel-for.h.
Change-Id: I220341f70e94dd02df5dd424272c50a5afb64978
This adds a simple thread pool to gdb. In the end, this seemed
preferable to the approach taken in an earlier version of this series;
namely, starting threads in the parallel-foreach implementation. This
approach reduces the overhead of starting new threads, and also lets
the user control (in a subsequent patch) exactly how many worker
threads are running.
gdb/ChangeLog
2019-11-26 Christian Biesinger <cbiesinger@google.com>
Tom Tromey <tom@tromey.com>
* gdbsupport/thread-pool.h: New file.
* gdbsupport/thread-pool.c: New file.
* Makefile.in (COMMON_SFILES): Add thread-pool.c.
(HFILES_NO_SRCDIR): Add thread-pool.h.
Change-Id: I597bb642780cb9d578ca92373d2a638efb44fe52
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-11-26 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.
Change-Id: Ic832bbb033b64744e4b44f14b41db7e4168ce427
This introduces a way for a callback to be run on the main thread.
gdb/ChangeLog
2019-11-26 Tom Tromey <tom@tromey.com>
* run-on-main-thread.c: New file.
* run-on-main-thread.h: New file.
* unittests/main-thread-selftests.c: New file.
* Makefile.in (SUBDIR_UNITTESTS_SRCS): Add
main-thread-selftests.c.
(HFILES_NO_SRCDIR): Add run-on-main-thread.h.
(COMMON_SFILES): Add run-on-main-thread.c.
Change-Id: I16ef82f0564e9f8a524bdc64cb31df79a988ad9f
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-11-26 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.
Change-Id: I721c047ae9d51a35fd274a6dbc00a58c6440dae6
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.
The sigprocmask man page says:
The use of sigprocmask() is unspecified in a multithreaded
process; see pthread_sigmask(3).
This patch changes gdb to use pthread_sigmask when appropriate, by
introducing a convenience define.
I've updated gdbserver as well, because I had to touch gdbsupport, and
because the threading patches will make it link against the thread
library.
I chose not to touch the NTO code, because I don't know anything about
that platform and because I cannot test it.
Finally, this modifies an existing spot in the Guile layer to use the
new facility.
gdb/ChangeLog
2019-11-26 Tom Tromey <tom@tromey.com>
* gdbsupport/signals-state-save-restore.c (original_signal_mask):
Remove comment.
(save_original_signals_state, restore_original_signals_state): Use
gdb_sigmask.
* linux-nat.c (block_child_signals, restore_child_signals_mask)
(_initialize_linux_nat): Use gdb_sigmask.
* guile/guile.c (_initialize_guile): Use block_signals.
* Makefile.in (HFILES_NO_SRCDIR): Add gdb-sigmask.h.
* gdbsupport/gdb-sigmask.h: New file.
* event-top.c (async_sigtstp_handler): Use gdb_sigmask.
* cp-support.c (gdb_demangle): Use gdb_sigmask.
* gdbsupport/common.m4 (GDB_AC_COMMON): Check for
pthread_sigmask.
* configure, config.in: Rebuild.
* gdbsupport/block-signals.h: New file.
gdb/gdbserver/ChangeLog
2019-11-26 Tom Tromey <tom@tromey.com>
* remote-utils.c (block_unblock_async_io): Use gdb_sigmask.
* linux-low.c (linux_wait_for_event_filtered, linux_async): Use
gdb_sigmask.
* configure, config.in: Rebuild.
Change-Id: If3f37dc57dd859c226e9e4d79458a0514746e8c6
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.
Note that this also links gdbserver against the thread library. This
is not strictly necessary at this point in the series, but a later
patch will change gdbsupport to use pthread_sigmask, at which point
this will be needed.
gdb/ChangeLog
2019-11-26 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-11-26 Tom Tromey <tom@tromey.com>
* Makefile.in (PTHREAD_CFLAGS, PTHREAD_LIBS): New variables.
(INTERNAL_CFLAGS_BASE): Use PTHREAD_CFLAGS.
(GDBSERVER_LIBS): Use PTHREAD_LIBS.
* acinclude.m4: Include ax_pthread.m4.
* config.in, configure: Rebuild.
Change-Id: I00ec55db6077f2615421a93461fc3be57e916aa0
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-11-26 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.
Change-Id: I4fe3993b99fb3a43968067806e294d48e377fd76
When running GDB tests under Valgrind, various tests are failing due
to invalid memory access.
Here is the stack trace reported by Valgrind, for gdb.base/freebpcmd.exp :
==18658== Invalid read of size 8
==18658== at 0x7F9107: is_main (signalmodule.c:195)
==18658== by 0x7F9107: PyOS_InterruptOccurred (signalmodule.c:1730)
==18658== by 0x3696E2: check_quit_flag() (extension.c:829)
==18658== by 0x36980B: restore_active_ext_lang(active_ext_lang_state*) (extension.c:782)
==18658== by 0x48F617: gdbpy_enter::~gdbpy_enter() (python.c:235)
==18658== by 0x47BB71: add_thread_object(thread_info*) (object.h:470)
==18658== by 0x53A84D: operator() (std_function.h:687)
==18658== by 0x53A84D: notify (observable.h:106)
==18658== by 0x53A84D: add_thread_silent(ptid_t) (thread.c:311)
==18658== by 0x3CD954: inf_ptrace_target::create_inferior(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&
, char**, int) (inf-ptrace.c:139)
==18658== by 0x3FE644: linux_nat_target::create_inferior(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&,
char**, int) (linux-nat.c:1094)
==18658== by 0x3D5727: run_command_1(char const*, int, run_how) (infcmd.c:633)
==18658== by 0x2C05D1: cmd_func(cmd_list_element*, char const*, int) (cli-decode.c:1948)
==18658== by 0x53F29F: execute_command(char const*, int) (top.c:639)
==18658== by 0x3638EB: command_handler(char const*) (event-top.c:586)
==18658== by 0x36468C: command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) (event-top.c:771)
==18658== by 0x36407C: gdb_rl_callback_handler(char*) (event-top.c:217)
==18658== by 0x5B2A1F: rl_callback_read_char (callback.c:281)
==18658== by 0x36346D: gdb_rl_callback_read_char_wrapper_noexcept() (event-top.c:175)
==18658== by 0x363F70: gdb_rl_callback_read_char_wrapper(void*) (event-top.c:192)
==18658== by 0x3633AF: stdin_event_handler(int, void*) (event-top.c:514)
==18658== by 0x362504: gdb_wait_for_event (event-loop.c:857)
==18658== by 0x362504: gdb_wait_for_event(int) (event-loop.c:744)
==18658== by 0x362676: gdb_do_one_event() [clone .part.11] (event-loop.c:321)
==18658== by 0x3627AD: gdb_do_one_event (event-loop.c:303)
==18658== by 0x3627AD: start_event_loop() (event-loop.c:370)
==18658== by 0x41D35A: captured_command_loop() (main.c:381)
==18658== by 0x41F2A4: captured_main (main.c:1224)
==18658== by 0x41F2A4: gdb_main(captured_main_args*) (main.c:1239)
==18658== by 0x227D0A: main (gdb.c:32)
==18658== Address 0x10 is not stack'd, malloc'd or (recently) free'd
The problem seems to be created by gdbpy_enter::~gdbpy_enter () releasing the GIL lock
too early:
~gdbpy_enter () does:
...
PyGILState_Release (m_state);
python_gdbarch = m_gdbarch;
python_language = m_language;
restore_active_ext_lang (m_previous_active);
}
So, it releases the GIL lock, does 2 assignments and then leads to the following
call sequence:
restore_active_ext_lang => check_quit_flag => python.c gdbpy_check_quit_flag
=> PyOS_InterruptOccurred => is_main.
is_main code is:
static int
is_main(_PyRuntimeState *runtime)
{
unsigned long thread = PyThread_get_thread_ident();
PyInterpreterState *interp = _PyRuntimeState_GetThreadState(runtime)->interp;
return (thread == runtime->main_thread
&& interp == runtime->interpreters.main);
}
The macros and functions to access the thread state are documented as:
/* Variable and macro for in-line access to current thread
and interpreter state */
#define _PyRuntimeState_GetThreadState(runtime) \
((PyThreadState*)_Py_atomic_load_relaxed(&(runtime)->gilstate.tstate_current))
/* Get the current Python thread state.
Efficient macro reading directly the 'gilstate.tstate_current' atomic
variable. The macro is unsafe: it does not check for error and it can
return NULL.
The caller must hold the GIL.
See also PyThreadState_Get() and PyThreadState_GET(). */
#define _PyThreadState_GET() _PyRuntimeState_GetThreadState(&_PyRuntime)
So, we see that GDB releases the GIL and then potentially calls
_PyRuntimeState_GetThreadState that needs the GIL.
It is not very clear why the problem is only observed when running under
Valgrind. Probably caused by the slowdown due to Valgrind and/or to the 'single
thread' scheduling by Valgrind.
This patch fixes the crashes by releasing the GIT lock later.
2019-11-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* python/python.c (gdbpy_enter::~gdbpy_enter): Release GIL after
restore_active_ext_lang, as GIL is needed for (indirectly)
called PyOS_InterruptOccurred.
When building sparc-nat.c with -Wmissing-declarations, we get:
CXX sparc-nat.o
/home/smarchi/src/binutils-gdb/gdb/sparc-nat.c: In function ‘target_xfer_status sparc_xfer_wcookie(target_ops*, target_object, const char*, gdb_byte*, const gdb_byte*, ULONGEST, ULONGEST, ULONGEST*)’:
/home/smarchi/src/binutils-gdb/gdb/sparc-nat.c:255:1: error: no previous declaration for ‘target_xfer_status sparc_xfer_wcookie(target_ops*, target_object, const char*, gdb_byte*, const gdb_byte*, ULONGEST, ULONGEST, ULONGEST*)’ [-Werror=missing-declarations]
sparc_xfer_wcookie (struct target_ops *ops, enum target_object object,
^~~~~~~~~~~~~~~~~~
Indeed, the declaration is not in sync with the definition, fix that.
sparc_xfer_wcookie is used in sparc_target::xfer_partial. sparc_target
is only used in the BSD sparc native files. The error above was
obtained by running "make sparc-nat.o" on Linux with a cross-compiler
for sparc64-linux-gnu. But I presume that if we were to build for real
with a BSD/sparc compiler, we would end up with an undefined symbol.
gdb/ChangeLog:
* sparc-nat.c (sparc_xfer_wcookie): Sync declaration with
definition.
Change-Id: Id41e706e5516968ff6a49469ddc48eceb29dd3ea
The simulator_command function is not used outside its file, so make it
static. Remove the declaration, which is not needed and not even in
sync with the definition.
gdb/ChangeLog:
* remote-sim.c (simulator_command): Make static, remove
declaration.
Change-Id: I40bd1e3662f849c4c9970443931ab9ee0ccccea1
The declaration of tui_set_var_cmd is not in sync with the definition.
Since tui_set_var_cmd is only used in the file where it's defined,
remove the declaration and make the definition static.
gdb/ChangeLog:
* tui-win.h (tui_set_var_cmd): Remove.
* tui-win.c (tui_set_var_cmd): Make static.
Change-Id: If4bddbfb573347fb7254fb6f1a940052a72f464f
rbreak_command_wrapper is unused, so remove it. And while at it, remove
other declarations around it.
gdb/ChangeLog:
* breakpoint.h (hbreak_command_wrapper, thbreak_command_wrapper,
rbreak_command_wrapper): Remove.
* symtab.c (rbreak_command_wrapper): Remove.
Change-Id: If9782f205e4913f8dfc5beeaa526544f25e099c6
The info_terminal_command declaration in inflow.h does not match the
current definition. It is not needed anyway, as info_terminal_command
is only used locally, so remove it and make the definition static.
gdb/ChangeLog:
* inferior.h (info_terminal_command): Remove declaration.
* inflow.c (info_terminal_command): Make static.
Change-Id: I22c3fcc44244e3cf877b5e27eff189af11c39503
This function is not used in the code base.
gdb/ChangeLog:
* inferior.c (exit_inferior_silent): Remove.
Change-Id: Ib2b7662744da079185ceac2a165b47590bd3113c
These functions are not used in the code base, remove them.
gdb/ChangeLog:
* dictionary.c (dict_empty, mdict_empty): Remove.
* dictionary.c (mdict_empty): Remove.
Change-Id: I4c1b08c730f6790b2f3d28b680607618e3c08e48
The following errors show that these files are missing the include of
their matching header, add them.
CXX dwarf-index-write.o
/home/smarchi/src/binutils-gdb/gdb/dwarf-index-write.c: In function ‘void write_psymtabs_to_index(dwarf2_per_objfile*, const char*, const char*, const char*, dw_index_kind)’:
/home/smarchi/src/binutils-gdb/gdb/dwarf-index-write.c:1670:1: error: no previous declaration for ‘void write_psymtabs_to_index(dwarf2_per_objfile*, const char*, const char*, const char*, dw_index_kind)’ [-Werror=missing-declarations]
write_psymtabs_to_index (struct dwarf2_per_objfile *dwarf2_per_objfile,
^~~~~~~~~~~~~~~~~~~~~~~
CXX mi/mi-interp.o
/home/smarchi/src/binutils-gdb/gdb/mi/mi-interp.c: In function ‘void mi_output_solib_attribs(ui_out*, so_list*)’:
/home/smarchi/src/binutils-gdb/gdb/mi/mi-interp.c:1030:1: error: no previous declaration for ‘void mi_output_solib_attribs(ui_out*, so_list*)’ [-Werror=missing-declarations]
mi_output_solib_attribs (ui_out *uiout, struct so_list *solib)
^~~~~~~~~~~~~~~~~~~~~~~
gdb/ChangeLog:
* dwarf-index-write.c: Include dwarf-index-write.h.
* mi/mi-interp.c: Include mi/mi-interp.h.
Change-Id: I0103b8669e16e0fcaa476f8c5e96f49608157745
The error below shows that aarch32-tdep.c is missing an include for
aarch32-tdep.h, add it.
CXX aarch32-tdep.o
/home/smarchi/src/binutils-gdb/gdb/aarch32-tdep.c: In function ‘const target_desc* aarch32_read_description()’:
/home/smarchi/src/binutils-gdb/gdb/aarch32-tdep.c:27:1: error: no previous declaration for ‘const target_desc* aarch32_read_description()’ [-Werror=missing-declarations]
aarch32_read_description ()
^~~~~~~~~~~~~~~~~~~~~~~~
Putting the include of aarch32-tdep.h early in aarch32-tdep.c gives us
an error about target_desc not being defined. Indeed, aarch32-tdep.h
uses target_desc without forward-declaring it or including the proper
header. Add a forward-declaration for it.
gdb/ChangeLog:
* aarch32-tdep.c: Include aarch32-tdep.h.
* aarch32-tdep.h: Forward-declare struct target_desc.
Change-Id: Ica4be4de0fbd7f22d56a29a40fbf0a31b5abdb16
This provides threadsafety. Unfortunately, since libinproctrace.so
does not link to gnulib, we can't use it there, especially since it
still includes the gnulib headers (so it is difficult to directly
call the system strerror_r).
gdb/ChangeLog:
2019-11-26 Christian Biesinger <cbiesinger@google.com>
* linux-nat.c (detach_one_lwp): Call safe_strerror instead of
strerror.
* nto-procfs.c (nto_procfs_target::create_inferior): Likewise.
* windows-nat.c (windows_nat_target::create_inferior): Likewise.
gdb/gdbserver/ChangeLog:
2019-11-26 Christian Biesinger <cbiesinger@google.com>
* debug.c (debug_set_output): Call safe_strerror instead of
strerror.
* linux-low.c (attach_proc_task_lwp_callback): Likewise.
(linux_kill_one_lwp): Likewise.
(linux_detach_one_lwp): Likewise.
(linux_wait_for_event_filtered): Likewise.
(store_register): Likewise.
* lynx-low.c (lynx_attach): Likewise.
* mem-break.c (insert_memory_breakpoint): Likewise.
(remove_memory_breakpoint): Likewise.
(delete_fast_tracepoint_jump): Likewise.
(set_fast_tracepoint_jump): Likewise.
(uninsert_fast_tracepoint_jumps_at): Likewise.
(reinsert_fast_tracepoint_jumps_at): Likewise.
* nto-low.c (nto_xfer_memory): Likewise.
(nto_resume): Likewise.
Change-Id: I9e259cdcaa6e11bbcc4ee6bdc5b7127d73e11abe
Christian pointed out that I had accidentally put a ChangeLog entry
into gdbserver that was meant for testsuite.
I'm checking in this patch to fix it.
Change-Id: Iba6124cea6f63539ad66494d3355fb657b78a66d
The words.sh script in its current form extracts c comments from files, which
it then transforms into a list of words.
To use the script on the documentation (as I did for commit 6b92c0d353
"[gdb/doc] Fix typos"), I needed to disable the "extract c comments" part.
Add an option -c that enables extracting c comments, and is off by default.
gdb/ChangeLog:
2019-11-25 Tom de Vries <tdevries@suse.de>
* contrib/words.sh: Add -c option.
Change-Id: Ifa34d435b3c41b3ff845dc07ae4b0d9f02d92a2d
This does not touch "int from_tty" and a couple of other instances
that require a bigger change.
gdb/ChangeLog:
2019-11-25 Christian Biesinger <cbiesinger@google.com>
* solib.c (solib_find_1): Change int to bool.
(exec_file_find): Change int to bool.
(solib_find): Change int to bool.
(solib_read_symbols): Change int to bool.
(solib_used): Change int to bool.
(solib_add): Change int to bool.
(info_sharedlibrary_command): Change int to bool.
(solib_contains_address_p): Change int to bool.
(solib_keep_data_in_core): Change int to bool.
(in_solib_dynsym_resolve_code): Change int to bool.
(reload_shared_libraries_1): Change int to bool.
(gdb_sysroot_changed): Change int to bool.
* solib.h (solib_read_symbols): Change int to bool.
(solib_contains_address_p): Change int to bool.
(solib_keep_data_in_core): Change int to bool.
(in_solib_dynsym_resolve_code): Change int to bool.
(libpthread_name_p): Change int to bool.
Change-Id: Id695ed4ed0c3526af477d4d2bf585a7193c36cab
While debugging, i felt the need to adjust the truncation length of remote
packets so i could see more or less data as needed. The default is currently
set to 512 bytes.
This patch makes this option adjustable through the new "set debug
remote-packet-max-chars" command. It can be set to unlimited if we want to
completely disable truncation.
Update on v5:
- Adjusted function and variable documentation, NEWS entry and GDB manual.
gdb/ChangeLog:
2019-11-25 Luis Machado <luis.machado@linaro.org>
* NEWS (New Commands): Mention "set debug remote-packet-max-chars".
* remote.c (REMOTE_DEBUG_MAX_CHAR): Remove.
(remote_packet_max_chars): New static global.
(show_remote_packet_max_chars): New function.
(remote_target::putpkt_binary): Adjust to use new
remote_packet_max_chars option.
(remote_target::getpkt_or_notif_sane_1): Likewise.
(_initialize_remote): Register new remote-packet-max-chars option.
gdb/doc/ChangeLog:
2019-11-25 Luis Machado <luis.machado@linaro.org>
* gdb.texinfo (Debugging Output): Document set debug
remote-packet-max-chars.
Change-Id: I2e871b37bfcaa6376537c3fe3db8f016dd806a7c
Fix this compilation error, and a bunch of similar ones:
CXX m68k-linux-nat.o
/home/smarchi/src/binutils-gdb/gdb/m68k-linux-nat.c: In function ‘void fetch_register(regcache*, int)’:
/home/smarchi/src/binutils-gdb/gdb/m68k-linux-nat.c:133:9: error: ‘gdbarch_register_name’ was not declared in this scope
gdbarch_register_name (gdbarch, regno),
^~~~~~~~~~~~~~~~~~~~~
gdb/ChangeLog:
* m68k-linux-nat.c: Include gdbarch.h.
Change-Id: I7cd47bc5d094241b2596e29c244eb55ed11f7a02
This changes require_partial_symbols to use bool as its parameter
type.
gdb/ChangeLog
2019-11-24 Tom Tromey <tom@tromey.com>
* symfile.c (read_symbols): Update.
* psymtab.c (require_partial_symbols): Change type of "verbose" to
bool.
(psym_map_symtabs_matching_filename, find_pc_sect_psymtab)
(psym_lookup_symbol, psym_find_last_source_symtab)
(psym_forget_cached_source_info, psym_print_stats)
(psym_expand_symtabs_for_function, psym_expand_all_symtabs)
(psym_expand_symtabs_with_fullname, psym_map_symbol_filenames)
(psym_map_matching_symbols, psym_expand_symtabs_matching)
(psym_find_compunit_symtab_by_address)
(maintenance_print_psymbols, maintenance_info_psymtabs)
(maintenance_check_psymtabs): Update.
* psymtab.h (require_partial_symbols): Change type of "verbose" to
bool.
Change-Id: Iae87aa5e4590706bb9e90a33adb86f1fe0fbf3c7
Ages ago, when we switched observables to be templates, Joel asked me
to restore the parameter names that were used in the old
observer.texi.
I've finally done this, putting the names into comments. I also
updated the comments in this file to use the GNU metasyntactic
variable convention as well.
gdb/ChangeLog
2019-11-22 Tom Tromey <tom@tromey.com>
* observable.h: Update comments.
Change-Id: Id71bea7a7fcaa8f5d4491f33aa8861c56ba9c3f0
