binutils-gdb

Commit Graph

Author	SHA1	Message	Date
Simon Marchi	523e454fab	gdbsupport: constify some return values in print-utils.{h,cc} 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>	2 years ago
Simon Marchi	cbb97c5be3	gdbsupport, gdbserver, gdb: use -Wno-vla-cxx-extension 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	2 years ago
Simon Marchi	18d2988e5d	gdb, gdbserver, gdbsupport: remove includes of early headers 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>	2 years ago
Simon Marchi	ab7daea3ad	gdb, gdbserver, gdbsupport: include early header files with `-include` 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>	2 years ago
Simon Marchi	2f3dfa7f90	gdb, gdbserver, gdbsupport: reformat some Makefile variables, one entry per line 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>	2 years ago
Tom Tromey	7f032bbedf	Require trivial destructor in allocate_on_obstack 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.	2 years ago
Andrew Burgess	8695c3a693	gdbsupport: rename include guard in gdb-checked-static-cast.h 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.	2 years ago
Andrew Burgess	7d18eb9983	gdb: use static_cast in gdb::checked_static_cast This commit: commit `6fe4779ac4` 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>	2 years ago
Tom de Vries	97e9c24c38	[gdb/build] Fix build on postmarketos 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	2 years ago
Tom Tromey	1eae7be116	Rewrite final cleanups This patch rewrites final cleanups to use std::function and otherwise be more C++-ish.	2 years ago
Tom Tromey	5c92d8456d	Introduce read_remainder_of_file 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>	3 years ago
Pedro Alves	593318f69b	Fix throw_winerror_with_name build error on x86-64 Cygwin 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	3 years ago
Simon Marchi	23acbfee6a	gdbsupport: assume that compiler supports 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	3 years ago
Simon Marchi	aca8a74923	gdb: remove some GCC version checks 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>	3 years ago
Andrew Burgess	1d506c26d9	Update copyright year range in header of all files managed by GDB 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.	3 years ago
Mike Frysinger	761ed61e7b	gdbsupport: tighten up libiberty code a bit with dnl No functional change here, just touch up generated output slightly. Approved-By: Tom Tromey <tom@tromey.com>	3 years ago
Mike Frysinger	908ff469f5	gdb: libiberty: switch to AC_CHECK_DECLS_ONCE Only check these decls once in case other m4 macros also look for them. Approved-By: Tom Tromey <tom@tromey.com>	3 years ago
Mike Frysinger	3f258212a8	gdb: move libiberty.m4 to gdbsupport 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>	3 years ago
Tom Tromey	afdd136635	Back out some parallel_for_each features 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.	4 years ago
Tom Tromey	542e23ffbe	Add gdb::task_group This adds gdb::task_group, a convenient way to group background tasks and then call a function when all the tasks have completed.	3 years ago
Tom Tromey	9b9e5c09b1	Fix build with clang 16 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	3 years ago
Simon Marchi	51e6b8cfd6	gdb: change regcache interface to use array_view 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>	3 years ago
Simon Marchi	e4e20d4511	gdb: use reg_buffer_common throughout gdbsupport/common-regcache.h 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>	3 years ago
Richard Bunt	33ae45434d	gdb: Enable early init of thread pool size This commit enables the early initialization commands (`92e4e97a9f`) 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 `261b07488b`) 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>	3 years ago
Tom Tromey	69f6730df3	Remove gdb_static_assert C++17 makes the second parameter to static_assert optional, so we can remove gdb_static_assert now.	3 years ago
Tom Tromey	d02f31bb13	Use C++17 void_t C++17 has void_t and make_void, so gdbsupport/traits.h can be simplified. Approved-By: Pedro Alves <pedro@palves.net>	3 years ago
Tom Tromey	cc87f13181	Rely on copy elision in scope-exit.h 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>	3 years ago
Tom Tromey	553b78748f	Rely on C++17 <new> in new-op.cc 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>	3 years ago
Tom Tromey	dead89d276	Enable some C++14 code in array-view.h This changes gdbsupport/array-view.h to enable some code that is C++14-specific. Approved-By: Pedro Alves <pedro@palves.net>	3 years ago
Tom Tromey	d57f38ec74	Switch to -Wimplicit-fallthrough=5 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>	3 years ago
Tom Tromey	d182e39881	Use C++17 [[fallthrough]] attribute 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>	3 years ago
Tom de Vries	f9582a22db	[gdb] Fix segfault in for_each_block, part 1 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	3 years ago
Tom Tromey	602971b386	Introduce throw_winerror_with_name 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	3 years ago
Lancelot Six	70d02be7e3	gdbsupport: Replace gdb::invoke_result with std::invoke_result 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>	3 years ago
Lancelot Six	393be56421	gdbsupport: Remove gdb::string_view 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	3 years ago
Lancelot Six	8082468ffe	gdb: Use std::string_view instead of gdb::string_view 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>	3 years ago
Lancelot Six	42742fc581	gdbsupport: remove gdb::optional The previous patch migrated all the uses of gdb::optional to use std::optional instead, so gdb::optional can be removed entirely as well as the self-tests which came with it. Change-Id: I96ecd67b850b01be10ef00eb85a78ac647d5adc7 Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>	3 years ago
Lancelot Six	6b09f1342c	gdb: Replace gdb::optional with std::optional Since GDB now requires C++17, we don't need the internally maintained gdb::optional implementation. This patch does the following replacing: - gdb::optional -> std::optional - gdb::in_place -> std::in_place - #include "gdbsupport/gdb_optional.h" -> #include <optional> This change has mostly been done automatically. One exception is gdbsupport/thread-pool.* which did not use the gdb:: prefix as it already lives in the gdb namespace. Change-Id: I19a92fa03e89637bab136c72e34fd351524f65e9 Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>	3 years ago
Lancelot Six	6b62451ad0	gdb: Use C++17's std::make_unique instead of gdb::make_unique gdb::make_unique is a wrapper around std::make_unique when compiled with C++17. Now that C++17 is required, use std::make_unique directly in the codebase, and remove gdb::make_unique. Change-Id: I80b615e46e4b7c097f09d78e579a9bdce00254ab Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net	3 years ago
Arsen Arsenovi?	862776f26a	Finalized intl-update patches * intl: Remove directory. Replaced with out-of-tree GNU gettext. * .gitignore: Add '/gettext'. configure.ac (host_libs): Replace intl with gettext. (hbaseargs, bbaseargs, baseargs): Split baseargs into {h,b}baseargs. (skip_barg): New flag. Skips appending current flag to bbaseargs. <library exemptions>: Exempt --with-libintl-{type,prefix} from target and build machine argument passing. * configure: Regenerate. * Makefile.def (host_modules): Replace intl module with gettext module. (configure-ld): Depend on configure-gettext. * Makefile.in: Regenerate. * src-release.sh: Remove references to the intl/ directory.	3 years ago
Tom Tromey	cf0d07fd07	Remove EXTERN_C and related defines common-defs.h has a few defines that I suspect were used during the transition to C++. These aren't needed any more, so remove them. Tested by rebuilding. Approved-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: Andrew Burgess <aburgess@redhat.com>	3 years ago
Simon Marchi	8cb2c7fc2e	gdbsupport: mark array_view::slice with [[nodiscard]] I (almost) had a bug where I did: buffer.slice (...) but I meant: buffer = buffer.slice (...) The first one does nothing, it creates a new array_view but without using it, it's useless. Mark the slice methods with [[nodiscard]] (which is standard C++17) so that error would generate a warning. I guess that many functions could be marked as nodiscard, essentially function that is pure (doesn't have side-effects). But this one seems particularly easy to mis-use. Change-Id: Ib39a0a65a5728a3cfd68a02ae31635810baeaccb Approved-By: Tom Tromey <tom@tromey.com>	3 years ago
Simon Marchi	dbbfabb441	gdbsupport: record and print failed selftest names Since "maint selftest" now runs quite a lot of tests (especially in an all-targets build), I thought it would be useful to print a summary at the end of what failed. So, implement that. Print the summary before the "Ran %d unit tests, %zu failed\n" line, so that that one remains the last line, and the gdb.gdb/unittest.exp doesn't need to be changed. The output looks like (if I force a failure in a test): (gdb) maint selftest ... Running selftest value_copy. Running selftest xml_escape_text. Running selftest xml_escape_text_append. Failures: aarch64-analyze-prologue Ran 4134 unit tests, 1 failed (gdb) Change-Id: If3aaabdd6f8078d0e6e50e8d08f3e558ab85277e Approved-By: Tom Tromey <tom@tromey.com>	3 years ago
Lancelot Six	f74dc26792	gdb/gdbsupport/gdbserver: Require c++17 This patch proposes to require a C++17 compiler to build gdb / gdbsupport / gdbserver. Before this patch, GDB required a C++11 compiler. The general policy regarding bumping C++ language requirement in GDB (as stated in [1]) is: Our general policy is to wait until the oldest compiler that supports C++NN is at least 3 years old. Rationale: We want to ensure reasonably widespread compiler availability, to lower barrier of entry to GDB contributions, and to make it easy for users to easily build new GDB on currently supported stable distributions themselves. 3 years should be sufficient for latest stable releases of distributions to include a compiler for the standard, and/or for new compilers to appear as easily installable optional packages. Requiring everyone to build a compiler first before building GDB, which would happen if we required a too-new compiler, would cause too much inconvenience. See the policy proposal and discussion [here](https://sourceware.org/ml/gdb-patches/2016-10/msg00616.html). The first GCC release which with full C++17 support is GCC-9[2], released in 2019[3], which is over 4 years ago. Clang has had C++17 support since Clang-5[4] released in 2018[5]. A discussions with many distros showed that a C++17-able compiler is always available, meaning that this no hard requirement preventing us to require it going forward. [1] https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#When_is_GDB_going_to_start_requiring_C.2B-.2B-NN_.3F [2] https://gcc.gnu.org/projects/cxx-status.html#cxx17 [3] https://gcc.gnu.org/gcc-9/ [4] https://clang.llvm.org/cxx_status.html [5] https://releases.llvm.org/ Change-Id: Id596f5db17ea346e8a978668825787b3a9a443fd Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>	3 years ago
Lancelot Six	eb4de4047d	gdb/ax_cxx_compile_stdcxx.m4: upgrade This patch upgrades gdb/ax_cxx_compile_stdcxx.m4 to follow changes available in [1] and regenerates the configure script. [1] https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx.html Change-Id: I5b16adc65c9e48a13ad65202d58ab7a9d487214e Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>	3 years ago
Simon Marchi	1f08aca9d0	gdbsupport: use "reference" and "pointer" type aliases in intrusive_list It seems to me like the code should used the defined type aliases, for consistency. Change-Id: Ib52493ff18ad29464405275bc10a0c6704ed39e9 Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>	3 years ago
Tom Tromey	5772d79823	Move -lsocket check to common.m4 A user pointed out that the -lsocket check in gdb should also apply to gdbserver -- otherwise it can't find the Solaris socketpair. This patch makes the change. It also removes a couple of redundant function checks from gdb's configure.ac. This was tested by the person who reported the bug. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30927 Approved-By: Pedro Alves <pedro@palves.net>	3 years ago
John Baldwin	a8ff7b9f87	gdb_unique_ptr.h: Fix a typo in a comment	3 years ago
Tom Tromey	ef0f16ccf8	Remove explanatory comments from includes I noticed a comment by an include and remembered that I think these don't really provide much value -- sometimes they are just editorial, and sometimes they are obsolete. I think it's better to just remove them. Tested by rebuilding. Approved-By: Andrew Burgess <aburgess@redhat.com>	3 years ago
Tom Tromey	0e0edacca5	Fix build failure with GCC 4.8 A user pointed out that the build failed with GCC 4.8. The problem was that the form used by the std::hash specialization of ptid_t was not accepted. This patch rewrites this code into a form that is acceptable to the older compiler. Approved-By: Simon Marchi <simon.marchi@efficios.com>	3 years ago

1 2 3 4 5 ...

317 Commits (523e454fab831e07c83a648c5d07370375a1c376)