aboutsummaryrefslogtreecommitdiff
path: root/gdbsupport
AgeCommit message (Collapse)AuthorFilesLines
2024-06-27gdb: add overloads of gdb_tilde_expandAndrew Burgess1-2/+16
Like the previous commit, add two overloads of gdb_tilde_expand, one takes std::string and other takes gdb::unique_xmalloc_ptr<char>. Make use of these overloads throughout GDB and gdbserver. There should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2024-06-27gdb: add overloads of gdb_abspathAndrew Burgess1-0/+16
Add two overloads of gdb_abspath, one which takes std::string and one which takes gdb::unique_xmalloc_ptr<char>, then make use of these overloads throughout GDB and gdbserver. There should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2024-06-24Remove hashtab_obstack_allocateTom Tromey4-53/+1
I think that hashtabs should never be obstack-allocated. In the past this was convenient sometimes, because any new data structure needed a corresponding cleanup. However, with the switch to C++, resource management has become much simpler; for example, a local variable can simply be of type htab_up rather than hashtab_t, and the problem is solved. This patch removes hashtab_obstack_allocate to try to prevent this anti-pattern from being used again.
2024-06-20Revert "Remove LIBINTL_DEP"Alan Modra2-0/+3
This reverts commit e874cbd3879843a83e4bcc4b54cd7107387b1df6. The patch was wrong. LIBINTL_DEP is needed with an in-tree gettext.
2024-06-20Remove LIBINTL_DEPAlan Modra2-3/+0
The intl directory in the source no longer exists. LIBINTL_DEP is thus always empty. Remove references to it. config/ * gettext-sister.m4: Don't AC_SUBST LIBINTL_DEP. bfd/ * Makefile.in: Regenerate. * configure: Regenerate. binutils/ * Makefile.am (*_DEPENDENCIES): Remove LIBINTL_DEP. * Makefile.in: Regenerate. * configure: Regenerate. gas/ * Makefile.am (as_new_DEPENDENCIES): Remove LIBINTL_DEP. * Makefile.in: Regenerate. * configure: Regenerate. gdb/ * Makefile.in (INTL_DEPS): Don't set or reference. * configure: Regenerate. gdbserver/ * Makefile.in (INTL_DEPS): Don't set or reference. gdbsupport/ * Makefile.in: Regenerate. * configure: Regenerate. gold/ * Makefile.am (deps_var): Remove LIBINTL_DEP. (incremental_dump_DEPENDENCIES, dwp_DEPENDENCIES): Likewise. * Makefile.in: Regenerate. * configure: Regenerate. * testsuite/Makefile.am (DEPENDENCIES): Remove LIBINTL_DEP. * testsuite/Makefile.in: Regenerate. gprof/ * Makefile.am (gprof_DEPENDENCIES): Remove LIBINTL_DEP. * Makefile.in: Regenerate. * configure: Regenerate. ld/ * Makefile.am (ld_new_DEPENDENCIES): Remove LIBINTL_DEP. * Makefile.in: Regenerate. * configure: Regenerate. libctf/ * Makefile.in: Regenerate. * configure: Regenerate. opcodes/ * configure.ac (BUILD_LIBS): Remove LIBINTL. (BUILD_LIB_DEPS): Remove LIBINTL_DEP. * Makefile.in: Regenerate. * configure: Regenerate.
2024-06-14gdb/gdbserver: share I386_LINUX_XSAVE_XCR0_OFFSET definitionAndrew Burgess1-0/+20
Share the definition of I386_LINUX_XSAVE_XCR0_OFFSET between GDB and gdbserver. This commit moves the definition into gdbsupport/x86-xstate.h, which allows the #define to be shared. There should be no user visible changes after this commit. Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
2024-06-10autoupdate: add square brackets around arguments of AC_INITMatthieu Longo1-1/+1
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fINIT-2
2024-06-10autoupdate: replace obsolete macros AC_CONFIG_HEADERMatthieu Longo1-1/+1
- AC_CONFIG_HEADER by AC_CONFIG_HEADERS https://www.gnu.org/software/automake/manual/1.12.2/html_node/Obsolete-Macros.html#index-AM_005fCONFIG_005fHEADER
2024-06-07gdb: remove get_exec_fileSimon Marchi1-5/+0
I believe that the get_exec_file function is unnecessary, and the code can be simplified if we remove it. Consider for instance when you "run" a program on Linux with native debugging. 1. run_command_1 obtains the executable file from `current_program_space->exec_filename ()` 2. it passes it to `run_target->create_inferior()`, which is `inf_ptrace_target::create_inferior()` in this case, which then passes it to `fork_inferior()` 3. `fork_inferior()` then has a fallback, where if the passed exec file is nullptr, it gets its from `get_exec_file()`. 4. `get_exec_file()` returns `current_program_space->exec_filename ()` - just like the things we started with - or errors out if the current program space doesn't have a specified executable. If there's no exec filename passed in step 1, there's not going to be any in step 4, so it seems pointless to call `get_exec_file()`, we could just error out when `exec_file` is nullptr. But we can't error out directly in `fork_inferior()`, since the error is GDB-specific, and that function is shared with GDBserver. Speaking of GDBserver, all code paths that lead to `fork_inferior()` provide a non-nullptr exec file. Therefore, to simplify things: - Make `fork_inferior()` assume that the passed exec file is not nullptr, don't call `get_exec_file()` - Change some targets (darwin-nat, go32-nat, gnu-nat, inf-ptrace, nto-procfs, procfs) to error out when the exec file passed to their create_inferior method is nullptr. Some targets are fine with a nullptr exec file, so we can't check that in `run_command_1()`. - Add the `no_executable_specified_error()` function, which re-uses the error message that `get_exec_file()` had. - Change some targets (go32-nat, nto-procfs) to not call `get_exec_file()`, since it's pointless for the same reason as in the example above, if it returns, it's going the be the same value as the `exec_file` parameter. Just rely on `exec_file`. - Remove the final use of `get_exec_file()`, in `load_command()`. - Remove the `get_exec_file()` implementations in GDB and GDBserver and remove the shared declaration. Change-Id: I601c16498e455f7baa1f111a179da2f6c913baa3 Approved-By: Tom Tromey <tom@tromey.com>
2024-06-07gdb: replace `get_exec_file (0)` calls with ↵Simon Marchi1-3/+3
`current_program_space->exec_filename ()` Calls of `get_exec_file (0)` are equivalent to just getting the exec filename from the current program space. I'm looking to remove `get_exec_file`, so replace these uses with `current_program_space->exec_filename ()`. Remove the `err` parameter of `get_exec_wrapper` since all the calls that remain pass 1, meaning to error out if no executable is specified. Change-Id: I7729ea4c7f03dbb046211cc5aa3858ab3a551965 Approved-By: Tom Tromey <tom@tromey.com>
2024-05-16Stop 'configure --enable-threading' if std::thread doesn't workPedro Alves2-6/+21
Currently, if you configure gdb with explicit --enable-threading, but then configure detects std::thread does not work, configure silently disables threading support and continues configuring. This patch makes that scenario cause a configuration error, like so: $ /home/pedro/gdb/src/configure --enable-threading && make ... configure: error: std::thread does not work; disable threading make[1]: *** [Makefile:11225: configure-gdbsupport] Error 1 make[1]: Leaving directory '/home/pedro/gdb/build-windows-threads' make: *** [Makefile:1041: all] Error 2 $ Additionally, if you don't explicitly pass --enable-threading, and std::thread does not work, we will now get a warning (and the build continues): $ /home/pedro/gdb/src/configure && make ... configure: WARNING: std::thread does not work; disabling threading ... This is similar to how we handle --enable-tui and missing curses. The code and error/warning messages were borrowed from there. Change-Id: I73a8b580d1e2a796b23136920c0e181408ae1b22 Approved-By: Tom Tromey <tom@tromey.com>
2024-05-06Fix build issues with mingw toolchainBernd Edlinger2-0/+2
With a x86_64-pc-mingw32 toolchain there is a build issue whether or not the --disable-threading option is used. The problem happens because _WIN32_WINNT is defined to 0x501 before #include <mutex> which makes the compilation abort due to missing support for __gthread_cond_t in std_mutex.h, which is conditional on _WIN32_WINNT >= 0x600. Fix the case when --disable-threading is used, by only including <mutex> in gdb/complaints.c when STD_CXX_THREAD is defined. Additionally make the configure script try to #include <mutex> to automatically select --disable-threading when the header file is not able to compile. Approved-By: Tom Tromey <tom@tromey.com>
2024-04-22gdb: move RequireLongest to gdbsupport/traits.hSimon Marchi1-0/+4
Move it out of defs.h. Change-Id: Ie1743d41a57f81667650048563e66073c72230cf Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-04-21Use std::vector in event-loop.ccTom Tromey1-39/+18
In my occasional and continuing campaign against realloc, this patch changes event-loop.cc to use std::vector to keep track of pollfd objects. Regression tested on x86-64 Fedora 38. Approved-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-04-18gdbsupport: constify some return values in print-utils.{h,cc}Simon Marchi2-18/+18
There is no reason the callers of these functions need to change the returned string, so change the `char *` return types to `const char *`. Update a few callers to also use `const char *`. Change-Id: I94adff574d5e1b326e8cc688cf1817a15b408b96 Approved-By: Tom Tromey <tom@tromey.com>
2024-04-17gdbsupport, gdbserver, gdb: use -Wno-vla-cxx-extensionSimon Marchi2-0/+2
When building with clang 18, I see: CXX aarch64-linux-tdep.o /home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1299:26: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension] 1299 | gdb_byte za_zeroed[za_bytes]; | ^~~~~~~~ /home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1299:26: note: read of non-const variable 'za_bytes' is not allowed in a constant expression /home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1282:10: note: declared here 1282 | size_t za_bytes = std::pow (sve_vl_from_vg (svg), 2); | ^ Since we are using VLAs right now, that warning doesn't make sense for us. add `-Wno-vla-cxx-extension` to the list of warning flags we try to enable. If we ever choose to disallow VLAs, we can remove that flag. Change-Id: Ie41feafc50c343f6e75333d4f836ce32fbeb6d8c
2024-03-26gdb, gdbserver, gdbsupport: remove includes of early headersSimon Marchi40-40/+0
Now that defs.h, server.h and common-defs.h are included via the `-include` option, it is no longer necessary for source files to include them. Remove all the inclusions of these files I could find. Update the generation scripts where relevant. Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837 Approved-By: Pedro Alves <pedro@palves.net>
2024-03-26gdb, gdbserver, gdbsupport: include early header files with `-include`Simon Marchi2-0/+2
The motivation for this change is for analysis tools and IDEs to be better at analyzing header files on their own. There are some definitions and includes we want to occur at the very beginning of all translation units. The way we currently do that is by requiring all source files (.c and .cc files) to include one of defs.h (for gdb), server.h (for gdbserver) of common-defs.h (for gdbsupport and shared source files). These special header files define and include everything that needs to be included at the very beginning. Other header files are written in a way that assume that these special "prologue" header files have already been included. My problem with that is that my editor (clangd-based) provides a very bad experience when editing header files. Since clangd doesn't know that one of defs.h/server.h/common-defs.h was included already, a lot of things are flagged as errors. For instance, CORE_ADDR is not known. It's possible to edit the files in this state, but a lot of the power of the editor is unavailable. My proposal to help with this is to include those things we always want to be there using the compilers' `-include` option. Tom Tromey said that the current approach might exist because not all compilers used to have an option like this. But I believe that it's safe to assume they do today. With this change, clangd picks up the -include option from the compile command, and is able to analyze the header file correctly, as it sees all that stuff included or defined by that -include option. That works because when editing a header file, clangd tries to get the compilation flags from a source file that includes said header file. This change is a bit self-serving, because it addresses one of my frustrations when editing header files, but it might help others too. I'd be curious to know if others encounter the same kinds of problems when editing header files. Also, even if the change is not necessary by any means, I think the solution of using -include for stuff we always want to be there is more elegant than the current solution. Even with this -include flag, many header files currently don't include what they use, but rather depend on files included before them. This will still cause errors when editing them, but it should be easily fixable by adding the appropriate include. There's no rush to do so, as long as the code still compiles, it's just a convenience thing. The changes are: - Add the appropriate `-include` option to the various Makefiles. - There is one particularity for gdbserver's Makefile: we do not want to include server.h when building `gdbreplay.o`, as `gdbreplay.cc` doesn't include it. So we can't simply put the `-include` in `INTERNAL_CFLAGS`. Add the `-include server.h` option to the `COMPILE` and `IPAGENT_COMPILE` variables, and added a special rule to compile `gdbreplay.o` with `-include gdbsupport/common-defs.h`. - Remove the `-include` option from the `check-headers` rule in gdb/Makefile.in, since it is already included in `INTERNAL_CFLAGS`. Change-Id: If3e345d00a9fc42336322f1d8286687d22134340 Approved-By: Pedro Alves <pedro@palves.net>
2024-03-26gdb, gdbserver, gdbsupport: reformat some Makefile variables, one entry per lineSimon Marchi2-8/+22
Reformat some variables definitions. I think it makes them easier to read, and it also makes diffs clearer. Change-Id: I82f63ba0e6d0fe268eb1f1ad5ab22c3cd016ab02 Approved-By: Pedro Alves <pedro@palves.net>
2024-03-21Require trivial destructor in allocate_on_obstackTom Tromey1-1/+5
This patch makes allocate_on_obstack a little bit safer, by enforcing the rule that objects allocated on an obstack must have a trivial destructor. The static assert is done in a method -- doing it inside the class itself won't work because the class is incomplete at that point.
2024-03-19gdbsupport: rename include guard in gdb-checked-static-cast.hAndrew Burgess1-3/+3
I noticed in passing that the include guard in the file gdbsupport/gdb-checked-static-cast.h was wrong, it includes the word DYNAMIC when STATIC would be better, fixed in this commit. There should be no user visible changes after this commit.
2024-03-19gdb: use static_cast in gdb::checked_static_castAndrew Burgess1-8/+4
This commit: commit 6fe4779ac4b1874c995345e3eabd89cb1a05fbdf Date: Sat Feb 24 11:00:20 2024 +0100 [gdb/build] Fix static cast of virtual base addressed an issue where GDB would not compile in production mode due to a use of gdb::checked_static_cast. The problem was that we were asking GDB to cast from a virtual base class to a sub-class, this works fine when using dynamic_cast, but does not work with static_cast. The gdb::checked_static_cast actually uses dynamic_cast under the hood in development mode in order to ensure that the cast is valid, while in a production build we use static_cast as this is more efficient. What this meant however, was that when gdb::checked_static_cast was used to cast from a virtual base class, the dynamic_cast of a non-production build worked fine, while the production build's static_cast caused a build failure. However, the gdb::checked_static_cast function already contains some static_assert calls that are intended to catch any issues with invalid type casting, the goal of these asserts was to prevent issues like this: the build only failing in production mode. Clearly the current asserts are not enough. I don't think there is a std::is_virtual_base type trait check, so what I propose instead is that in non-production mode we also make use of static_cast. This will ensure that any errors that crop up in production mode should also be revealed in non-production mode, and should catch issues like this in the future. There should be no user visible changes after this commit. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31399 Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca>
2024-03-14[gdb/build] Fix build on postmarketosTom de Vries1-6/+2
I tried building gdbserver on postmarketos (which is based on alpine linux, which uses musl libc), and ran into: ... gdbserver/linux-low.cc: In lambda function: gdbserver/linux-low.cc:1907:41: error: \ 'W_EXITCODE' was not declared in this scope 1907 | mark_lwp_dead (leader_lp, W_EXITCODE (0, 0), true); | ^~~~~~~~~~ ... The macro W_EXITCODE is not defined in gdbsupport/gdb_wait.h. OTOH, WSETEXIT is defined there, but unused: ... /* These are not defined in POSIX, but are used by our programs. */ #ifndef WSETEXIT # ifdef W_EXITCODE #define WSETEXIT(w,status) ((w) = W_EXITCODE(status,0)) # else #define WSETEXIT(w,status) ((w) = (0 | ((status) << 8))) # endif #endif ... Fix this by dropping the WSETEXIT definition, and instead defining W_EXITCODE. Tested on x86_64-linux, in combination with an "#undef W_EXITCODE" to make sure the definition is exercised. Approved-By: Tom Tromey <tom@tromey.com> PR build/31483 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31483
2024-02-27Rewrite final cleanupsTom Tromey2-124/+15
This patch rewrites final cleanups to use std::function and otherwise be more C++-ish.
2024-02-27Introduce read_remainder_of_fileTom Tromey2-8/+20
This patch adds a new function, read_remainder_of_file. This is like read_text_file_to_string, but reads from an existing 'FILE *'. This will be used in a subsequent patch. Reviewed-By: Tom de Vries <tdevries@suse.de>
2024-02-23Fix throw_winerror_with_name build error on x86-64 CygwinPedro Alves1-1/+1
The GDB build currently fails on x86-64 Cygwin, with: src/gdbsupport/errors.cc: In function ‘void throw_winerror_with_name(const char*, ULONGEST)’: src/gdbsupport/errors.cc:152:12: error: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘ULONGEST’ {aka ‘long unsigned int’} [-Werror=format=] 152 | error (_("%s (error %d): %s"), string, err, strwinerror (err)); | ^ Fix this by adding a cast. While at it, the error codes are really a DWORD that results from a GetLastError() call, so I think unsigned is more appropriate. That is also what strwinerror already does: sprintf (buf, "unknown win32 error (%u)", (unsigned) error); The cast is necessary on MinGW GDB as well, where ULONGEST is unsigned long long, but for some reason, I don't get a warning there. Approved-By: Tom Tromey <tom@tromey.com> Change-Id: I3f5faa779765fd8021abf58bb5f68d556b309d17
2024-02-21gdbsupport: assume that compiler supports ↵Simon Marchi4-33/+0
std::{is_trivially_constructible,is_trivially_copyable} This code was there to support g++ 4, which didn't support std::is_trivially_constructible and std::is_trivially_copyable. Since we now require g++ >= 9, I think it's fair to assume that GDB will always be compiled with a compiler that supports those. Change-Id: Ie7c1649139a2f48bf662cac92d7f3e38fb1f1ba1
2024-02-21gdb: remove some GCC version checksSimon Marchi1-9/+0
Since we now require C++17, and therefore gcc >= 9, it's no longer useful to have gcc version checks for older gcc version. Change-Id: I3a87baa03c475f2b847b422b16b69c5ff7215b54 Reviewed-by: Kevin Buettner <kevinb@redhat.com> Approved-By: Pedro Alves <pedro@palves.net>
2024-01-12Update copyright year range in header of all files managed by GDBAndrew Burgess149-149/+149
This commit is the result of the following actions: - Running gdb/copyright.py to update all of the copyright headers to include 2024, - Manually updating a few files the copyright.py script told me to update, these files had copyright headers embedded within the file, - Regenerating gdbsupport/Makefile.in to refresh it's copyright date, - Using grep to find other files that still mentioned 2023. If these files were updated last year from 2022 to 2023 then I've updated them this year to 2024. I'm sure I've probably missed some dates. Feel free to fix them up as you spot them.
2024-01-10gdbsupport: tighten up libiberty code a bit with dnlMike Frysinger2-7/+4
No functional change here, just touch up generated output slightly. Approved-By: Tom Tromey <tom@tromey.com>
2024-01-10gdb: libiberty: switch to AC_CHECK_DECLS_ONCEMike Frysinger2-61/+73
Only check these decls once in case other m4 macros also look for them. Approved-By: Tom Tromey <tom@tromey.com>
2024-01-10gdb: move libiberty.m4 to gdbsupportMike Frysinger3-4/+36
This is used by gdb, gdbsupport, and gdbserver. We want to use it in the sim tree too. Move it to gdbsupport which is meant as the common sharing space for these projects. Approved-By: Tom Tromey <tom@tromey.com>
2024-01-08Back out some parallel_for_each featuresTom Tromey1-204/+30
Now that the DWARF reader does not use parallel_for_each, we can remove some of the features that were added just for it: return values and task sizing. The thread_pool typed tasks feature could also be removed, but I haven't done so here. This one seemed less intrusive and perhaps more likely to be needed at some point.
2024-01-08Add gdb::task_groupTom Tromey4-2/+160
This adds gdb::task_group, a convenient way to group background tasks and then call a function when all the tasks have completed.
2023-12-22Fix build with clang 16Tom Tromey1-0/+5
clang 16 reports a missing declaration in new-op.cc. We believed these operators to be declared starting with C++14, but apparently that is not the case. This patch reverts the earlier change and then updates the comment to reflect the current state. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31141
2023-12-14gdb: change regcache interface to use array_viewSimon Marchi3-4/+44
Change most of regcache (and base classes) to use array_view when possible, instead of raw pointers. By propagating the use of array_view further, it enables having some runtime checks to make sure the what we read from or write to regcaches has the expected length (such as the one in the `copy(array_view, array_view)` function. It also integrates well when connecting with other APIs already using gdb::array_view. Add some overloads of the methods using raw pointers to avoid having to change all call sites at once (which is both a lot of work and risky). I tried to do this change in small increments, but since many of these functions use each other, it ended up simpler to do it in one shot than having a lot of intermediary / transient changes. This change extends into gdbserver as well, because there is some part of the regcache interface that is shared. Changing the reg_buffer_common interface to use array_view caused some build failures in nat/aarch64-scalable-linux-ptrace.c. That file currently "takes advantage" of the fact that reg_buffer_common::{raw_supply,raw_collect} operates on `void *`, which IMO is dangerous. It uses raw_supply/raw_collect directly on uint64_t's, which I guess is fine because it is expected that native code will have the same endianness as the debugged process. To accomodate that, add some overloads of raw_collect and raw_supply that work on uint64_t. This file also uses raw_collect and raw_supply on `char` pointers. Change it to use `gdb_byte` pointers instead. Add overloads of raw_collect and raw_supply that work on `gdb_byte *` and make an array_view on the fly using the register's size. Those call sites could be converted to use array_view with not much work, in which case these overloads could be removed, but I didn't want to do it in this patch, to avoid starting to dig in arch-specific code. During development, I inadvertently changed reg_buffer::raw_compare's behavior to not accept an offset equal to the register size. This behavior (effectively comparing 0 bytes, returning true) change was caught by the AArch64 SME core tests. Add a selftest to make sure that this raw_compare behavior is preserved in the future. Change-Id: I9005f04114543ddff738949e12d85a31855304c2 Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-14gdb: use reg_buffer_common throughout gdbsupport/common-regcache.hSimon Marchi2-8/+11
Right now, gdbsupport/common-regcache.h contains two abstractons for a regcache. An opaque type `regcache` (gdb and gdbserver both have their own regcache that is the concrete version of this) and an abstract base class `reg_buffer_common`, that is the base of regcaches on both sides. These abstractions allow code to be written for both gdb and gdbserver, for instance in the gdb/arch sub-directory. However, having two different abstractions is impractical. If some common code has a regcache, and wants to use an operation defined on reg_buffer_common, it can't. It would be better to have just one. Change all instances of `regcache *` in gdbsupport/common-regcache.h to be `reg_buffer_common *`, then fix fallouts. Implementations in gdb and gdbserver now need to down-cast (using gdb::checked_static_cast) from reg_buffer_common to their concrete regcache type. Some of them could be avoided by changing free functions (like regcache_register_size) to be virtual methods on reg_buffer_common. I tried it, it seems to work, but I did not include it in this series to avoid adding unnecessary changes. Change-Id: Ia5503adb6b5509a0f4604bd2a68b4642cc5283fd Reviewed-by: John Baldwin <jhb@FreeBSD.org>
2023-12-04gdb: Enable early init of thread pool sizeRichard Bunt2-0/+5
This commit enables the early initialization commands (92e4e97a9f5) to modify the number of threads used by gdb's thread pool. The motivation here is to prevent gdb from spawning a detrimental number of threads on many-core systems under environments with restrictive ulimits. With gdb before this commit, the thread pool takes the following sizes: 1. Thread pool size is initialized to 0. 2. After the maintenance commands are defined, the thread pool size is set to the number of system cores (if it has not already been set). 3. Using early initialization commands, the thread pool size can be changed using "maint set worker-threads". 4. After the first prompt, the thread pool size can be changed as in the previous step. Therefore after step 2. gdb has potentially launched hundreds of threads on a many-core system. After this change, step 2 and 3 are reversed so there is an opportunity to set the required number of threads without needing to default to the number of system cores first. There does exist a configure option (added in 261b07488b9) to disable multithreading, but this does not allow for an already deployed gdb to be configured. Additionally, the default number of worker threads is clamped at eight to control the number of worker threads spawned on many-core systems. This value was chosen as testing recorded on bugzilla issue 29959 indicates that parallel efficiency drops past this point. GDB built with GCC 13. No test suite regressions detected. Compilers: GCC, ACfL, Intel, Intel LLVM, NVHPC; Platforms: x86_64, aarch64. The scenario that interests me the most involves preventing GDB from spawning any worker threads at all. This was tested by counting the number of clones observed by strace: strace -e clone,clone3 gdb/gdb -q \ --early-init-eval-command="maint set worker-threads 0" \ -ex q ./gdb/gdb |& grep --count clone The new test relies on "gdb: install CLI uiout while processing early init files" developed by Andrew Burgess. This patch will need pushing prior to this change. The clamping was tested on machines with both 16 cores and a single core. "maint show worker-threads" correctly reported eight and one respectively. Approved-By: Tom Tromey <tom@tromey.com>
2023-11-29Remove gdb_static_assertTom Tromey3-14/+9
C++17 makes the second parameter to static_assert optional, so we can remove gdb_static_assert now.
2023-11-29Use C++17 void_tTom Tromey1-10/+1
C++17 has void_t and make_void, so gdbsupport/traits.h can be simplified. Approved-By: Pedro Alves <pedro@palves.net>
2023-11-29Rely on copy elision in scope-exit.hTom Tromey1-20/+2
gdbsupport/scope-exit.h has a couple of comments about being able to rely on copy elision in C++17. This patch makes the change. Approved-By: Pedro Alves <pedro@palves.net>
2023-11-29Rely on C++17 <new> in new-op.ccTom Tromey1-5/+0
gdbsupport/new-op.cc has a comment about relying on the C++-17 <new> header. This patch implements the suggestion. Approved-By: Pedro Alves <pedro@palves.net>
2023-11-29Enable some C++14 code in array-view.hTom Tromey1-9/+8
This changes gdbsupport/array-view.h to enable some code that is C++14-specific. Approved-By: Pedro Alves <pedro@palves.net>
2023-11-29Switch to -Wimplicit-fallthrough=5Tom Tromey2-2/+2
This changes the various gdb-related directories to use -Wimplicit-fallthrough=5, meaning that only the fallthrough attribute can be used in switches -- special 'fallthrough' comments will no longer be usable. Approved-By: Pedro Alves <pedro@palves.net>
2023-11-29Use C++17 [[fallthrough]] attributeTom Tromey2-6/+4
This changes gdb to use the C++17 [[fallthrough]] attribute rather than special comments. This was mostly done by script, but I neglected a few spellings and so also fixed it up by hand. I suspect this fixes the bug mentioned below, by switching to a standard approach that, presumably, clang supports. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23159 Approved-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Luis Machado <luis.machado@arm.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-11-28[gdb] Fix segfault in for_each_block, part 1Tom de Vries1-0/+17
When running test-case gdb.base/vfork-follow-parent.exp on powerpc64 (likewise on s390x), I run into: ... (gdb) PASS: gdb.base/vfork-follow-parent.exp: \ exec_file=vfork-follow-parent-exit: target-non-stop=on: non-stop=off: \ resolution_method=schedule-multiple: print unblock_parent = 1 continue^M Continuing.^M Reading symbols from vfork-follow-parent-exit...^M ^M ^M Fatal signal: Segmentation fault^M ----- Backtrace -----^M 0x1027d3e7 gdb_internal_backtrace_1^M src/gdb/bt-utils.c:122^M 0x1027d54f _Z22gdb_internal_backtracev^M src/gdb/bt-utils.c:168^M 0x1057643f handle_fatal_signal^M src/gdb/event-top.c:889^M 0x10576677 handle_sigsegv^M src/gdb/event-top.c:962^M 0x3fffa7610477 ???^M 0x103f2144 for_each_block^M src/gdb/dcache.c:199^M 0x103f235b _Z17dcache_invalidateP13dcache_struct^M src/gdb/dcache.c:251^M 0x10bde8c7 _Z24target_dcache_invalidatev^M src/gdb/target-dcache.c:50^M ... or similar. The root cause for the segmentation fault is that linux_is_uclinux gives an incorrect result: it should always return false, given that we're running on a regular linux system, but instead it returns first true, then false. In more detail, the segmentation fault happens as follows: - a program space with an address space is created - a second program space is about to be created. maybe_new_address_space is called, and because linux_is_uclinux returns true, maybe_new_address_space returns false, and no new address space is created - a second program space with the same address space is created - a program space is deleted. Because linux_is_uclinux now returns false, gdbarch_has_shared_address_space (current_inferior ()->arch ()) returns false, and the address space is deleted - when gdb uses the address space of the remaining program space, we run into the segfault, because the address space is deleted. Hardcoding linux_is_uclinux to false makes the test-case pass. We leave addressing the root cause for the following commit in this series. For now, prevent the segmentation fault by making the address space a refcounted object. This was already suggested here [1]: ... A better solution might be to have the address spaces be reference counted ... Tested on top of trunk on x86_64-linux and ppc64le-linux. Tested on top of gdb-14-branch on ppc64-linux. Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca> PR gdb/30547 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30547 [1] https://sourceware.org/pipermail/gdb-patches/2023-October/202928.html
2023-11-27Introduce throw_winerror_with_nameTom Tromey2-0/+15
This introduces throw_winerror_with_name, a Windows analog of perror_with_name, and changes various places in gdb to call it. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30770
2023-11-21gdbsupport: Replace gdb::invoke_result with std::invoke_resultLancelot Six5-48/+10
Given that GDB now requires C++17, we can replace gdb::invoke_result with std::invoke_result which is provided by <type_traits>. This patch also removes gdbsupport/invoke-result.h as it is not used anymore. Change-Id: I7e567356d38d6b3d85d8797d61cfc83f6f933f22 Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-11-21gdbsupport: Remove gdb::string_viewLancelot Six2-785/+0
Now that all places using gdb::string_view have been updated to use std::string_view, this patch drops the gdb::string_view implementation and the tests which came with it. As this drops the unittests/string_view-selftests.c, this also implicitly solves PR build/23676, as pointed-out by Tom Tromey. Change-Id: Idf5479b09e0ac536917b3f0e13aca48424b90df0 Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23676
2023-11-21gdb: Use std::string_view instead of gdb::string_viewLancelot Six3-7/+8
Given that GDB now requires a C++17, replace all uses of gdb::string_view with std::string_view. This change has mostly been done automatically: - gdb::string_view -> std::string_view - #include "gdbsupport/gdb_string_view.h" -> #include <string_view> One things which got brought up during review is that gdb::stging_view does support being built from "nullptr" while std::sting_view does not. Two places are manually adjusted to account for this difference: gdb/tui/tui-io.c:tui_getc_1 and gdbsupport/format.h:format_piece::format_piece. The above automatic change transformed "gdb::to_string (const gdb::string_view &)" into "gdb::to_string (const std::string_view &)". The various direct users of this function are now explicitly including "gdbsupport/gdb_string_view.h". A later patch will remove the users of gdb::to_string. The implementation and tests of gdb::string_view are unchanged, they will be removed in a following patch. Change-Id: Ibb806a7e9c79eb16a55c87c6e41ad396fecf0207 Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
generated by cgit v1.1 at 2024-07-16 21:28:17 +0000