aboutsummaryrefslogtreecommitdiff
path: root/gdbsupport
AgeCommit message (Collapse)AuthorFilesLines
2023-01-11Set _WIN32_WINNT in common.m4 configure checkTom Tromey3-3/+26
GCC recently added support for the Windows thread model, enabling libstdc++ to support Windows natively. However, this supporrt requires a version of Windows later than the minimum version that is supported by GDB. PR build/29966 points out that the GDB configure test for std::thread does not work in this situation, because _WIN32_WINNT is not defined in test program, and so <thread> seems to be fine. This patch is an attempt to fix the problem, by using the same setting for _WIN32_WINNT at configure time as is used at build time. I don't have access to one of the older systems so I don't think I can truly test this. I did do a mingw cross build, though. I'm going to ask the bug reporter to test it. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29966
2023-01-05gdbsupport: fix scoped_debug_start_end's move constructorSimon Marchi1-1/+20
I spotted a problem with scoped_debug_start_end's move constructor. When constructing a scoped_debug_start_end through it, it doesn't disable the moved-from object, meaning there are now two objects that will do the side-effects of decrementing the debug_print_depth global and printing the "end" message. Decrementing the debug_print_depth global twice is actually problematic, because the increments and decrements get out of sync, meaning we should hit this assertion, in theory: gdb_assert (debug_print_depth > 0); However, in practice, we don't see that. This is because despite the move constructor being required for this to compile: template<typename PT> static inline scoped_debug_start_end<PT &> ATTRIBUTE_NULL_PRINTF (6, 7) make_scoped_debug_start_end (PT &&pred, const char *module, const char *func, const char *start_prefix, const char *end_prefix, const char *fmt, ...) { va_list args; va_start (args, fmt); auto res = scoped_debug_start_end<PT &> (pred, module, func, start_prefix, end_prefix, fmt, args); va_end (args); return res; } ... it is never actually called, because compilers elide the move constructors all the way (the scoped_debug_start_end gets constructed directly in the instance of the top-level caller). To confirm this, I built GDB with -fno-elide-constructors, and now I see it: /home/simark/src/binutils-gdb/gdb/../gdbsupport/common-debug.h:147: internal-error: ~scoped_debug_start_end: Assertion `debug_print_depth > 0' failed. #9 0x00005614ba5f17c3 in internal_error_loc (file=0x5614b8749960 "/home/simark/src/binutils-gdb/gdb/../gdbsupport/common-debug.h", line=147, fmt=0x5614b8733fa0 "%s: Assertion `%s' failed.") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:58 #10 0x00005614b8e1b2e5 in scoped_debug_start_end<bool&>::~scoped_debug_start_end (this=0x7ffc6c5e7b40, __in_chrg=<optimized out>) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/common-debug.h:147 #11 0x00005614b96dbe34 in make_scoped_debug_start_end<bool&> (pred=@0x5614baad7200: true, module=0x5614b891d840 "infrun", func=0x5614b891d800 "infrun_debug_show_threads", start_prefix=0x5614b891d7c0 "enter", end_prefix=0x5614b891d780 "exit", fmt=0x0) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/common-debug.h:235 Fix this by adding an m_disabled field to scoped_debug_start_end, and setting it in the move constructor. Change-Id: Ie5213269c584837f751d2d11de831f45ae4a899f
2023-01-05gdbsupport: add gdb::string_view_hashSimon Marchi1-0/+17
Add the string_view_hash type, which will be useful to be able to use gdb::string_view as std::unordered_map keys. Use it in gdb/symtab.c, to exercise it. Change-Id: Id69a466ab19a9f6620b5df8a2dd29b5cddd94c00 Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-01-05gdbsupport: move fast_hash to gdbsupport/common-utils.hSimon Marchi1-0/+21
The following patch adds a hash type for gdb::string_view in gdbsupport, which will use the fast_hash function. Move the latter to gdbsupport. Change-Id: Id74510e17801e775bd5ffa5f443713d79adf14ad Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-01-05gdbsupport: move libxxhash configure check to gdbsupportSimon Marchi4-0/+544
The following patch moves the fast_hash function, which uses libxxhash, to gdbsupport. Move the libxxhash configure check to gdbsupport (and transitively to gdbserver). Change-Id: I242499e50c8cd6fe9f51e6e92dc53a1b3daaa96e Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker151-151/+151
This commit is the result of running the gdb/copyright.py script, which automated the update of the copyright year range for all source files managed by the GDB project to be updated to include year 2023.
2022-12-16gdbsupport: add string_xml_appendfSimon Marchi2-0/+115
Add a version of buffer_xml_printf (defined in gdbsupport/buffer.{c,h}) that appends to an std::string, rather than a struct buffer. Call it "string" rather than "buffer" since it operates on an std::string rather than a buffer. And call it "appendf" rather than "printf", since it appends to and does not replace the string's content. This mirrors string_appendf. Place the new version in gdbsupport/xml-utils.h. The code is a direct copy of buffer_xml_printf. The old version is going to disappear at some point, which is why I didn't do any effort to share code. Change-Id: I30e030627ab4970fd0b9eba3b7e8cec78fa561ba Approved-By: Pedro Alves <pedro@palves.net>
2022-12-15gdbsupport: change xml_escape_text_append's parameter from pointer to referenceSimon Marchi2-9/+9
The passed in string can't be nullptr, it makes more sense to pass in a reference. Change-Id: Idc8bd38abe1d6d9b44aa227d7856956848c233b3
2022-12-15Move streq and compare_cstrings to gdbsupportTom Tromey1-0/+16
It seems to me that streq and compare_cstrings belong near the other string utility functions in common-utils.h; and furthermore that streq ought to be inlined. This patch makes this change. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-12-14gdb: add SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXITAndrew Burgess1-19/+73
After the previous commit converted symbol-lookup debug to use the new debug scheme, this commit adds SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT. The previous commit didn't add SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT because symbol-lookup debug is controlled by an 'unsigned int' rather than a 'bool' control variable, we use the numeric value to offer different levels of verbosity for symbol-lookup debug. The *_SCOPED_DEBUG_ENTER_EXIT mechanism currently relies on capturing a reference to the bool control variable, and evaluating the variable both on entry, and at exit, this is done in the scoped_debug_start_end class (see gdbsupport/common-debug.h). This commit templates scoped_debug_start_end so that the class can accept either a 'bool &' or an invokable object, e.g. a lambda function, or a function pointer. The existing scoped_debug_start_end and scoped_debug_enter_exit macros in common-debug.h are updated to support scoped_debug_enter_exit being templated, however, nothing outside of common-debug.h needs to change. I've then added SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT in symtab.h, and added a couple of token uses in symtab.c. I didn't want to add too much in this first commit, this is really about updating common-debug.h to support this new functionality. Within symtab.h I created a couple of global functions that can be used to query the status of the symbol_lookup_debug control variable, these functions are then used within the two existing macros: symbol_lookup_debug_printf symbol_lookup_debug_printf_v and also in the new SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT macro.
2022-11-27fix leak in gdb_environPhilippe Waroquiers1-0/+2
valgrind reports a leak when assigning a gdb_environ to another gdb_environ. The memory allocated for the target gdb_environ env variables is not released. The gdb_environ selftest reproduces the leak (see below). Fix the leak by clearing the target gdb_environ before std::move-ing the members. Tested natively and re-running all tests under valgrind. ==3261873== 4,842 bytes in 69 blocks are definitely lost in loss record 6,772 of 6,839 ==3261873== at 0x483979B: malloc (vg_replace_malloc.c:393) ==3261873== by 0x25A454: xmalloc (alloc.c:57) ==3261873== by 0x7D1E4E: xstrdup (xstrdup.c:34) ==3261873== by 0x7E2A51: gdb_environ::from_host_environ() (environ.cc:56) ==3261873== by 0x66F1C8: test_reinit_from_host_environ (environ-selftests.c:78) ==3261873== by 0x66F1C8: selftests::gdb_environ_tests::run_tests() (environ-selftests.c:285) ==3261873== by 0x7EFC43: operator() (std_function.h:622) = Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-11-17gdb: new $_inferior_thread_count convenience variableAndrew Burgess1-0/+4
Add a new convenience variable $_inferior_thread_count that contains the number of live (non-exited) threads in the current inferior. This can be used in command scripts, or breakpoint conditions, etc to adjust the behaviour for multi-threaded inferiors. This value is only stable in all-stop mode. In non-stop mode, where new threads can be started, and existing threads exit, at any time, this convenience variable can give a different value each time it is evaluated.
2022-11-13Fix Cygwin build after 02d04eacJon Turney2-3/+3
Commit 02d04eac "Use strwinerror in gdb/windows-nat.c" also moves strwinerror() under the USE_WIN32API conditional, which is not defined for Cygwin (and looks like it shouldn't be, as appears to imply non-POSIX and MiNGW and WinSock...) Also enable the declaration and definition of strwinerror() when __CYGWIN__ is defined.
2022-11-08gdbsupport, gdb: add read_text_file_to_string, use it in ↵Simon Marchi2-0/+41
linux_common_core_of_thread I would like to add more code to nat/linux-osdata.c that reads an entire file from /proc or /sys and processes it as a string afterwards. I would like to avoid duplicating the somewhat error-prone code that reads an entire file to a buffer. I think we should have a utility function that does that. Add read_file_to_string to gdbsupport/filestuff.{c,h}, and make linux_common_core_of_thread use it. I want to make the new function return an std::string, and because strtok doesn't play well with std::string (it requires a `char *`, std::string::c_str returns a `const char *`), change linux_common_core_of_thread to use std::string methods instead. Approved-By: Tom Tromey <tom@tromey.com> Change-Id: I1793fda72a82969c28b944a84acb953f74c9230a
2022-10-19internal_error: remove need to pass __FILE__/__LINE__Pedro Alves8-31/+35
Currently, every internal_error call must be passed __FILE__/__LINE__ explicitly, like: internal_error (__FILE__, __LINE__, "foo %d", var); The need to pass in explicit __FILE__/__LINE__ is there probably because the function predates widespread and portable variadic macros availability. We can use variadic macros nowadays, and in fact, we already use them in several places, including the related gdb_assert_not_reached. So this patch renames the internal_error function to something else, and then reimplements internal_error as a variadic macro that expands __FILE__/__LINE__ itself. The result is that we now should call internal_error like so: internal_error ("foo %d", var); Likewise for internal_warning. The patch adjusts all calls sites. 99% of the adjustments were done with a perl/sed script. The non-mechanical changes are in gdbsupport/errors.h, gdbsupport/gdb_assert.h, and gdb/gdbarch.py. Approved-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: Ia6f372c11550ca876829e8fd85048f4502bdcf06
2022-10-09gdbsupport: re-generate configureSimon Marchi1-2/+2
I get this diff when re-generating configure, probably leftover from 67d1991b785 ("egrep in binutils"). Change-Id: I759c88c2bad648736d33ff98089db45c9b686356
2022-09-21gdbsupport: move fileio_errno_to_host to fileio.{h,cc} and renameSimon Marchi2-0/+57
gdb_bfd.c and remote.c contain identical implementations of a fileio_error -> errno function. Factor that out to gdbsupport/fileio.{h,cc}. Rename it fileio_error_to_host, for symmetry with host_to_fileio_error. Change-Id: Ib9b8807683de2f809c94a5303e708acc2251a0df
2022-09-21gdbsupport: convert FILEIO_* macros to an enumSimon Marchi2-24/+28
Converting from free-form macros to an enum gives a bit of type-safety. This caught places where we would assign host error numbers to what should contain a target fileio error number, for instance in target_fileio_pread. I added the FILEIO_SUCCESS enumerator, because remote.c:remote_hostio_parse_result initializes the remote_errno output variable to 0. It seems better to have an explicit enumerator than to assign a value for which there is no enumerator. I considered initializing this variable to FILEIO_EUNKNOWN instead, such that if the remote side replies with an error and omits the errno value, we'll get an errno that represents an error instead of 0 (which reprensents no error). But it's not clear what the consequences of that change would be, so I prefer to err on the side of caution and just keep the existing behavior (there is no intended change in behavior with this patch). Note that remote_hostio_parse_resul still reads blindly what the remote side sends as a target errno into this variable, so we can still end up with a nonsensical value here. It's not good, but out of the scope of this patch. Convert host_to_fileio_error and fileio_errno_to_host to return / accept a fileio_error instead of an int, and cascade the change in the whole chain that uses that. Change-Id: I454b0e3fcf0732447bc872252fa8e57d138b0e03
2022-09-21gdbsupport: move include/gdb/fileio.h contents to fileio.hSimon Marchi1-1/+109
I don't see why include/gdb/fileio.h is placed there. It's not installed by "make install", and it's not included by anything outside of gdb/gdbserver/gdbsupport. Move its content back to gdbsupport/fileio.h. I have omitted the bits inside an `#if 0`, since it's obviously not used, as well as the "limits" constants, which are also unused. Change-Id: I6fbc2ea10fbe4cfcf15f9f76006b31b99c20e5a9
2022-09-21gdbsupport: change path_join parameter to array_view<const char *>Simon Marchi2-8/+8
When a GDB built with -D_GLIBCXX_DEBUG=1 reads a binary with a single character name, we hit this assertion failure: $ ./gdb -q --data-directory=data-directory -nx ./x /usr/include/c++/12.1.0/string_view:239: constexpr const std::basic_string_view<_CharT, _Traits>::value_type& std::basic_string_view<_CharT, _Traits>::operator[](size_type) const [with _CharT = char; _Traits = std::char_traits<char>; const_reference = const char&; size_type = long unsigned int]: Assertion '__pos < this->_M_len' failed. The backtrace: #3 0x00007ffff6c0f002 in std::__glibcxx_assert_fail (file=<optimized out>, line=<optimized out>, function=<optimized out>, condition=<optimized out>) at /usr/src/debug/gcc/libstdc++-v3/src/c++11/debug.cc:60 #4 0x000055555da8a864 in std::basic_string_view<char, std::char_traits<char> >::operator[] (this=0x7fffffffcc30, __pos=1) at /usr/include/c++/12.1.0/string_view:239 #5 0x00005555609dcb88 in path_join[abi:cxx11](gdb::array_view<std::basic_string_view<char, std::char_traits<char> > const>) (paths=...) at /home/simark/src/binutils-gdb/gdbsupport/pathstuff.cc:203 #6 0x000055555e0443f4 in path_join<char const*, char const*> () at /home/simark/src/binutils-gdb/gdb/../gdbsupport/pathstuff.h:84 #7 0x00005555609dc336 in gdb_realpath_keepfile[abi:cxx11](char const*) (filename=0x6060000a8d40 "/home/simark/build/binutils-gdb-one-target/gdb/./x") at /home/simark/src/binutils-gdb/gdbsupport/pathstuff.cc:122 #8 0x000055555ebd2794 in exec_file_attach (filename=0x7fffffffe0f9 "./x", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:471 #9 0x000055555f2b3fb0 in catch_command_errors (command=0x55555ebd1ab6 <exec_file_attach(char const*, int)>, arg=0x7fffffffe0f9 "./x", from_tty=1, do_bp_actions=false) at /home/simark/src/binutils-gdb/gdb/main.c:513 #10 0x000055555f2b7e11 in captured_main_1 (context=0x7fffffffdb60) at /home/simark/src/binutils-gdb/gdb/main.c:1209 #11 0x000055555f2b9144 in captured_main (data=0x7fffffffdb60) at /home/simark/src/binutils-gdb/gdb/main.c:1319 #12 0x000055555f2b9226 in gdb_main (args=0x7fffffffdb60) at /home/simark/src/binutils-gdb/gdb/main.c:1344 #13 0x000055555d938c5e in main (argc=5, argv=0x7fffffffdcf8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32 The problem is this line in path_join: gdb_assert (strlen (path) == 0 || !IS_ABSOLUTE_PATH (path)); ... where `path` is "x". IS_ABSOLUTE_PATH eventually calls HAS_DRIVE_SPEC_1: #define HAS_DRIVE_SPEC_1(dos_based, f) \ ((f)[0] && ((f)[1] == ':') && (dos_based)) This macro accesses indices 0 and 1 of the input string. However, `f` is a string_view of length 1, so it's incorrect to try to access index 1. We know that the string_view's underlying object is a null-terminated string, so in practice there's no harm. But as far as the string_view is concerned, index 1 is considered out of bounds. This patch makes the easy fix, that is to change the path_join parameter from a vector of to a vector of `const char *`. Another solution would be to introduce a non-standard gdb::cstring_view class, which would be a view over a null-terminated string. With that class, it would be correct to access index 1, it would yield the NUL character. If there is interest in having this class (it has been mentioned a few times in the past) I can do it and use it here. This was found by running tests such as gdb.ada/arrayidx.exp, which produce 1-char long filenames, so adding a new test is not necessary. Change-Id: Ia41a16c7243614636b18754fd98a41860756f7af
2022-09-08gdbsupport: Fix config.status dependencyTsukasa OI3-2/+3
Commit 171fba11ab27 ("Make GDBserver abort on internal error in development mode") created a new substitution CONFIG_STATUS_DEPENDENCIES but this is used by Makefile.in (which is not regenerated by that commit). After regenerating it, it is found that CONFIG_STATUS_DEPENDENCIES value is not valid, making gdbsupport fail to build. Since the CONFIG_STATUS_DEPENDENCIES value is used in the Makefile, macro substitution must have a Makefile format but commit 171fba11ab27 used shell format "$srcdir/../bfd/development.sh". This commit fixes this issue by substituting "$srcdir" (shell format) to "$(srcdir)" (Makefile format). It preserves the dependency as Pedro intended and fixes the build problem. It also regenerates corresponding files with the maintainer mode. gdbsupport/ChangeLog: * configure.ac: Fix config.status dependency. * Makefile.in: Regenerate. * configure: Regenerate.
2022-08-30gdbsupport: add wrapper around result_of and invoke_resultSimon Marchi3-6/+44
When building with Clang 14 (using gcc 12 libstdc++ headers), I get: CXX dwarf2/read.o In file included from /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:94: /home/simark/src/binutils-gdb/gdb/../gdbsupport/parallel-for.h:142:21: error: 'result_of<(lambda at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7124:5) (__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter> *, std::__cxx1998::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>>, std::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>, std::random_access_iterator_tag>, __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter> *, std::__cxx1998::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>>, std::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>, std::random_access_iterator_tag>)>' is deprecated: use 'std::invoke_result' instead [-Werror,-Wdeprecated-declarations] = typename std::result_of<RangeFunction (RandomIt, RandomIt)>::type; ^ /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7122:14: note: in instantiation of function template specialization 'gdb::parallel_for_each<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter> *, std::__cxx1998::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>>, std::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>, std::random_access_iterator_tag>, (lambda at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7124:5)>' requested here = gdb::parallel_for_each (1, per_bfd->all_comp_units.begin (), ^ /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../include/c++/12.1.1/type_traits:2597:9: note: 'result_of<(lambda at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7124:5) (__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter> *, std::__cxx1998::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>>, std::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>, std::random_access_iterator_tag>, __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter> *, std::__cxx1998::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>>, std::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>, std::random_access_iterator_tag>)>' has been explicitly marked deprecated here { } _GLIBCXX17_DEPRECATED_SUGGEST("std::invoke_result"); ^ /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../include/c++/12.1.1/x86_64-pc-linux-gnu/bits/c++config.h:120:45: note: expanded from macro '_GLIBCXX17_DEPRECATED_SUGGEST' # define _GLIBCXX17_DEPRECATED_SUGGEST(ALT) _GLIBCXX_DEPRECATED_SUGGEST(ALT) ^ /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../include/c++/12.1.1/x86_64-pc-linux-gnu/bits/c++config.h:96:19: note: expanded from macro '_GLIBCXX_DEPRECATED_SUGGEST' __attribute__ ((__deprecated__ ("use '" ALT "' instead"))) ^ It complains about the use of std::result_of, which is deprecated in C++17 and removed in C++20: https://en.cppreference.com/w/cpp/types/result_of Given we'll have to transition to std::invoke_result eventually, make a GDB wrapper to mimimc std::invoke_result, which uses std::invoke_result for C++ >= 17 and std::result_of otherwise. This way, it will be easy to remove the wrapper in the future, just replace gdb:: with std::. Tested by building with gcc 12 in -std=c++11 and -std=c++17 mode, and clang in -std=c++17 mode (I did not test fully with clang in -std=c++11 mode because there are other unrelated issues). Change-Id: I50debde0a3307a7bc67fcf8fceefda51860efc1d
2022-08-26gdbsupport: fix gdb::optional compilation with C++11 && _GLIBCXX_DEBUGSimon Marchi1-2/+2
Similar to 911438f9f4 ("gdbsupport: fix array-view compilation with c++11 && _GLIBCXX_DEBUG"), but for gdb::optional. I get this error when building with Clang 14 and -std=c++11: CXX agent.o In file included from /home/simark/src/binutils-gdb/gdbsupport/agent.cc:20: In file included from /home/simark/src/binutils-gdb/gdbsupport/common-defs.h:210: In file included from /home/simark/src/binutils-gdb/gdbsupport/common-debug.h:23: /home/simark/src/binutils-gdb/gdbsupport/../gdbsupport/gdb_optional.h:213:5: error: use of this statement in a constexpr function is a C++14 extension [-Werror,-Wc++14-extensions] gdb_assert (this->has_value ()); ^ /home/simark/src/binutils-gdb/gdbsupport/gdb_assert.h:35:3: note: expanded from macro 'gdb_assert' ((void) ((expr) ? 0 : \ ^ Change-Id: If0cf55607fc9dbd1925ccb97cd9abbf8993ff264
2022-08-26gdb, gdbsupport: configure: factor out yes/no/auto value checkingSimon Marchi1-0/+28
Factor out the code that checks that a value is yes/no or yes/no/auto. Add two macros to gdbsupport/common.m4 and use them in gdb/configure.ac I inspected the changes to configure. Other than whitespace changes, we have some benign changes to the error messages (one of them had an error actually). There are changes to the --enable-source-highlight and --enable-libbacktrace handling, but setting enable_source_highlight / enable_libbacktrace was not really useful anyway, they already had the right value. Change-Id: I92587aec36874309e1605e2d60244649f09a757a
2022-08-19gdb_do_one_event: use integer test syntaxPatrick Monnerat1-2/+2
Timeout is an int, not a bool.
2022-08-18gdbsupport/event-loop: add a timeout parameter to gdb_do_one_eventPatrick Monnerat2-11/+36
Since commit b2d8657, having a per-interpreter event/command loop is not possible anymore. As Insight uses a GUI that has its own event loop, gdb and GUI event loops have then to be "merged" (i.e.: work together). But this is problematic as gdb_do_one_event is not aware of this alternate event loop and thus may wait forever. A solution is to delegate GUI events handling to the gdb events handler. Insight uses Tck/Tk as GUI and the latter offers a "notifier" feature to implement such a delegation. The Tcl notifier spec requires the event wait function to support a timeout parameter. Unfortunately gdb_do_one_event does not feature such a parameter. This timeout cannot be implemented externally with a gdb timer, because it would become an event by itself and thus can cause a legitimate event to be missed if the timeout is 0. Tcl implements "idle events" that are (internally) triggered only when no other event is pending. For this reason, it can call the event wait function with a 0 timeout quite often. This patch implements a wait timeout to gdb_do_one_event. The initial pending events monitoring is performed as before without the possibility to enter a wait state. If no pending event has been found during this phase, a timer is then created for the given timeout in order to re-use the implemented timeout logic and the event wait is then performed. This "internal" timer only limits the wait time and should never be triggered. It is deleted upon gdb_do_one_event exit. The new parameter defaults to "no timeout" (-1): as it is used by Insight only, there is no need to update calls from the gdb source tree.
2022-08-16Use strwinerror in gdb/windows-nat.cTom Tromey2-0/+70
When working on windows-nat.c, it's useful to see an error message in addition to the error number given by GetLastError. This patch moves strwinerror from gdbserver to gdbsupport, and then updates windows-nat.c to use it. A couple of minor changes to strwinerror (constify the return type and use the ARRAY_SIZE macro) are also included.
2022-08-05[gdbsupport] Add task size parameter in parallel_for_eachTom de Vries1-22/+91
Add a task_size parameter to parallel_for_each, defaulting to nullptr, and use the task size to distribute similarly-sized chunks to the threads. Tested on x86_64-linux.
2022-08-05Introduce gdb::make_function_viewPedro Alves1-0/+127
This adds gdb::make_function_view, which lets you create a function view from a callable without specifying the function_view's template parameter. For example, this: auto lambda = [&] (int) { ... }; auto fv = gdb::make_function_view (lambda); instead of: auto lambda = [&] (int) { ... }; gdb::function_view<void (int)> fv = lambda; It is particularly useful if you have a template function with an optional function_view parameter, whose type depends on the function's template parameters. Like: template<typename T> void my_function (T v, gdb::function_view<void(T)> callback = nullptr); For such a function, the type of the callback argument you pass must already be a function_view. I.e., this wouldn't compile: auto lambda = [&] (int) { ... }; my_function (1, lambda); With gdb::make_function_view, you can write the call like so: auto lambda = [&] (int) { ... }; my_function (1, gdb::make_function_view (lambda)); Unit tests included. Tested by building with GCC 9.4, Clang 10, and GCC 4.8.5, on x86_64 GNU/Linux, and running the unit tests. Change-Id: I5c4b3b4455ed6f0d8878cf1be189bea3ee63f626
2022-08-05[gdb] Add debug_{exp,val}Tom de Vries1-0/+6
When debugging cc1 I heavily rely on simple one-parameter debug functions that allow me to inspect a variable of a common type, like: - debug_generic_expr - debug_gimple_stmt - debug_rtx and I miss similar functions in gdb. Add functions to dump variables of types 'value' and 'expression': - debug_exp, and - debug_val. Tested on x86_64-linux, by breaking on varobj_create, and doing: ... (gdb) call debug_exp (var->root->exp.get ()) &"Operation: OP_VAR_VALUE\n" &" Block symbol:\n" &" Symbol: aaa\n" &" Block: 0x2d064f0\n" (gdb) ... and: ... (gdb) call debug_val (value) &"5" (gdb) ...
2022-07-25struct packed: Add fallback byte array implementationPedro Alves1-3/+48
Attribute gcc_struct is not implemented in Clang targeting Windows, so add a fallback standard-conforming implementation based on arrays. I ran the testsuite on x86_64 GNU/Linux with this implementation forced, and saw no regressions. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29373 Change-Id: I023315ee03622c59c397bf4affc0b68179c32374
2022-07-25struct packed: Unit tests and more operatorsPedro Alves1-30/+49
For PR gdb/29373, I wrote an alternative implementation of struct packed that uses a gdb_byte array for internal representation, needed for mingw+clang. While adding that, I wrote some unit tests to make sure both implementations behave the same. While at it, I implemented all relational operators. This commit adds said unit tests and relational operators. The alternative gdb_byte array implementation will come next. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29373 Change-Id: I023315ee03622c59c397bf4affc0b68179c32374
2022-07-25struct packed: Use gcc_struct on WindowsPedro Alves1-1/+9
Building GDB on mingw/gcc hosts is currently broken, due to a static assertion failure in gdbsupport/packed.h: In file included from ../../../../../binutils-gdb/gdb/../gdbsupport/common-defs.h:201, from ../../../../../binutils-gdb/gdb/defs.h:28, from ../../../../../binutils-gdb/gdb/dwarf2/read.c:31: ../../../../../binutils-gdb/gdb/../gdbsupport/packed.h: In instantiation of 'packed<T, Bytes>::packed(T) [with T = dwarf_unit_type; long long unsigned int Bytes = 1]': ../../../../../binutils-gdb/gdb/dwarf2/read.h:181:74: required from here ../../../../../binutils-gdb/gdb/../gdbsupport/packed.h:41:40: error: static assertion failed 41 | gdb_static_assert (sizeof (packed) == Bytes); | ~~~~~~~~~~~~~~~~^~~~~~~~ ../../../../../binutils-gdb/gdb/../gdbsupport/gdb_assert.h:27:48: note: in definition of macro 'gdb_static_assert' 27 | #define gdb_static_assert(expr) static_assert (expr, "") | ^~~~ ../../../../../binutils-gdb/gdb/../gdbsupport/packed.h:41:40: note: the comparison reduces to '(4 == 1)' 41 | gdb_static_assert (sizeof (packed) == Bytes); | ~~~~~~~~~~~~~~~~^~~~~~~~ The issue is that mingw gcc defaults to "-mms-bitfields", which affects how bitfields are laid out. We can however tell GCC that we want the regular GCC layout instead using attribute gcc_struct. Attribute gcc_struct is not implemented in "clang -target x86_64-pc-windows-gnu", so that will need a different fix. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29373 Change-Id: I023315ee03622c59c397bf4affc0b68179c32374
2022-07-21gdbsupport: add checked_static_castAndrew Burgess1-0/+68
This commit was inspired by these mailing list posts: https://sourceware.org/pipermail/gdb-patches/2022-June/190323.html https://sourceware.org/pipermail/gdb-patches/2022-April/188098.html The idea is to add a new function gdb::checked_static_cast, which can, in some cases, be used as a drop-in replacement for static_cast. And so, if I previously wrote this: BaseClass *base = get_base_class_pointer (); DerivedClass *derived = static_cast<DerivedClass *> (base); I can now write: BaseClass *base = get_base_class_pointer (); DerivedClass *derived = gdb::checked_static_cast<DerivedClass *> (base); The requirement is that BaseClass and DerivedClass must be polymorphic. The benefit of making this change is that, when GDB is built in developer mode, a run-time check will be made to ensure that `base` really is of type DerivedClass before the cast is performed. If `base` is not of type DerivedClass then GDB will assert. In a non-developer build gdb::checked_static_cast is equivalent to a static_cast, and there should be no performance difference. This commit adds the support function, but does not make use of this function, a use will be added in the next commit. Co-Authored-By: Pedro Alves <pedro@palves.net> Co-Authored-By: Tom Tromey <tom@tromey.com>
2022-07-21[gdbsupport] Fix type of parallel_for_each_debugTom de Vries1-1/+1
When I changed the initialization of parallel_for_each_debug from 0 to false, I forgot to change the type from int to bool. Fix this. Tested by rebuilding on x86_64-linux.
2022-07-18[gdbsupport] Improve thread scheduling in parallel_for_eachTom de Vries1-0/+8
When running a task using parallel_for_each, we get the following distribution: ... Parallel for: n_elements: 7271 Parallel for: minimum elements per thread: 10 Parallel for: elts_per_thread: 1817 Parallel for: elements on worker thread 0 : 1817 Parallel for: elements on worker thread 1 : 1817 Parallel for: elements on worker thread 2 : 1817 Parallel for: elements on worker thread 3 : 0 Parallel for: elements on main thread : 1820 ... Note that there are 4 active threads, and scheduling elts_per_thread on each of those handles 4 * 1817 == 7268, leaving 3 "left over" elements. These leftovers are currently handled in the main thread. That doesn't seem to matter much for this example, but for say 10 threads and 99 elements, you'd have 9 threads handling 9 elements and 1 thread handling 18 elements. Instead, distribute the left over elements over the worker threads, such that we have: ... Parallel for: elements on worker thread 0 : 1818 Parallel for: elements on worker thread 1 : 1818 Parallel for: elements on worker thread 2 : 1818 Parallel for: elements on worker thread 3 : 0 Parallel for: elements on main thread : 1817 ... Tested on x86_64-linux.
2022-07-18[gdbsupport] Add parallel_for_each_debugTom de Vries1-1/+23
Add a parallel_for_each_debug variable, set to false by default. With an a.out compiled from hello world, we get with parallel_for_each_debug == true: ... $ gdb -q -batch a.out -ex start ... Parallel for: n_elements: 7271 Parallel for: minimum elements per thread: 10 Parallel for: elts_per_thread: 1817 Parallel for: elements on worker thread 0 : 1817 Parallel for: elements on worker thread 1 : 1817 Parallel for: elements on worker thread 2 : 1817 Parallel for: elements on worker thread 3 : 0 Parallel for: elements on main thread : 1820 Temporary breakpoint 1, main () at /home/vries/hello.c:6 6 printf ("hello\n"); ... Tested on x86_64-linux.
2022-07-14[gdbsupport] Add sequential_for_eachTom de Vries1-0/+23
Add a sequential_for_each alongside the parallel_for_each, which can be used as a drop-in replacement. This can be useful when debugging multi-threading behaviour, and you want to limit multi-threading in a fine-grained way. Tested on x86_64-linux, by using it instead of the parallel_for_each in dwarf2_build_psymtabs_hard.
2022-07-14[gdb/build] Fix gdb build with gcc 4.8.5Tom de Vries1-0/+2
When building gdb with gcc 4.8.5, we run into: ... In file included from /usr/include/c++/4.8/future:43:0, from gdbsupport/thread-pool.h:30, from gdb/dwarf2/cooked-index.h:33, from gdb/dwarf2/read.h:26, from gdb/dwarf2/abbrev-cache.c:21: /usr/include/c++/4.8/atomic: In instantiation of \ ‘_Tp std::atomic<_Tp>::load(std::memory_order) const [with _Tp = \ packed<dwarf_unit_type, 1ul>; std::memory_order = std::memory_order]’: gdb/dwarf2/read.h:332:44: required from here /usr/include/c++/4.8/atomic:208:13: error: no matching function for call to \ ‘packed<dwarf_unit_type, 1ul>::packed()’ _Tp tmp; ^ ... Fix this by adding the default constructor for packed. Tested on x86_64-linux, with gdb build with gcc 4.8.5.
2022-07-12[gdb/build] Fix build with gcc 4.8.5Tom de Vries1-0/+4
When building gdb with gcc 4.8.5, we run into problems due to unconditionally using: ... gdb_static_assert (std::is_trivially_copyable<packed>::value); ... in gdbsupport/packed.h. Fix this by guarding the usage with HAVE_IS_TRIVIALLY_COPYABLE. Tested by doing a full gdb build with gcc 4.8.5.
2022-07-12Introduce struct packed templatePedro Alves1-0/+90
When building gdb with -fsanitize=thread and gcc 12, and running test-case gdb.dwarf2/dwz.exp, we run into a few data races. For example, between: ... Write of size 1 at 0x7b200000300e by thread T4: #0 process_psymtab_comp_unit gdb/dwarf2/read.c:6789 (gdb+0x830720) ... and: ... Previous read of size 1 at 0x7b200000300e by main thread: #0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \ abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6164 \ (gdb+0x82edab) ... In other words, between: ... this_cu->unit_type = DW_UT_partial; ... and: ... if (this_cu->reading_dwo_directly) ... The problem is that the written fields are part of the same memory location as the read fields, so executing a read and write in different threads is undefined behavour. Making the written fields separate memory locations, like this: ... struct { ENUM_BITFIELD (dwarf_unit_type) unit_type : 8; }; ... fixes it, however that also increases the size of struct dwarf2_per_cu_data, because it introduces padding due to alignment of these new structs, which align on the natural alignment of the specified type of their fields. We can fix that with __attribute__((packed)), like so: struct { ENUM_BITFIELD (dwarf_unit_type) unit_type : 8 __attribute__((packed)); }; but to avoid having to write that in several places and add suitable comments explaining how that concoction works, introduce a new struct packed template that wraps/hides this. Instead of the above, we'll be able to write: packed<dwarf_unit_type, 1> unit_type; Note that we can't change the type of dwarf_unit_type, as that is defined in include/, and shared with other projects, some of those written in C. This patch just adds the struct packed type. Following patches will make use of it. One of those patches will want to wrap a struct packed in an std::atomic, like: std::atomic<std::packed<language, 1>> m_lang; so the new gdbsupport/packed.h header adds some operators to make comparisions between that std::atomic and the type that the wrapped struct packed wraps work, like in: if (m_lang == language_c) It would be possible to implement struct packed without using __attribute__((packed)), by having it store an array of bytes of the appropriate size instead, however that would make it less convenient to debug GDB. The way it's implemented, printing a struct packed variable just prints its field using its natural type, which is particularly useful if the type is an enum. I believe that __attribute__((packed)) is supported by all compilers that are able to build GDB. Even a few BFD headers use on ATTRIBUTE_PACKED on external types: include/coff/external.h: } ATTRIBUTE_PACKED include/coff/external.h:} ATTRIBUTE_PACKED ; include/coff/external.h:} ATTRIBUTE_PACKED ; include/coff/pe.h:} ATTRIBUTE_PACKED ; include/coff/pe.h:} ATTRIBUTE_PACKED; include/elf/external.h:} ATTRIBUTE_PACKED Elf_External_Versym; It is not possible to build GDB with MSVC today, but if it could, that would be one compiler that doesn't support this attribute. However, it supports packing via pragmas, so there's a way to cross that bridge if we ever get to it. I believe any compiler worth its salt supports some way of packing. In any case, the worse that happens without the attribute is that some types become larger than ideal. Regardless, I've added a couple static assertions to catch such compilers in action: /* Ensure size and aligment are what we expect. */ gdb_static_assert (sizeof (packed) == Bytes); gdb_static_assert (alignof (packed) == 1); Change-Id: Ifa94f0a2cebfae5e8f6ddc73265f05e7fd9e1532
2022-06-30[gdb] Block SIGTERM in worker threadsTom de Vries1-0/+1
With gdb build with gcc-12 and -fsanitize=thread, and test-case gdb.base/gdb-sigterm.exp, I run into: ... WARNING: ThreadSanitizer: data race (pid=9722)^M Write of size 4 at 0x00000325bc68 by thread T1:^M #0 handle_sigterm(int) src/gdb/event-top.c:1211 (gdb+0x8ec01f)^M ... Previous read of size 4 at 0x00000325bc68 by main thread:^M [failed to restore the stack]^M ^M Location is global 'sync_quit_force_run' of size 4 at \ 0x00000325bc68 (gdb+0x325bc68)^M ... SUMMARY: ThreadSanitizer: data race gdb/event-top.c:1211 in \ handle_sigterm(int)^M ... and 3 more data races involving handle_sigterm and locations: - active_ext_lang - quit_flag - heap block of size 40 (XNEW (async_signal_handler) in create_async_signal_handler) This was reported in PR29297. The testcase executes a "kill -TERM $gdb_pid", which generates a process-directed signal. A process-directed signal can be delivered to any thread, and what we see here is the fallout of the signal being delivered to a worker thread rather than the main thread. Fix this by blocking SIGTERM in the worker threads. [ I have not been able to reproduce this after it occurred for the first time, so unfortunately I cannot confirm that the patch fixes the problem. ] Tested on x86_64-linux, with and without -fsanitize=thread. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29297
2022-06-27Make GDBserver abort on internal error in development modePedro Alves3-0/+26
Currently, if GDBserver hits some internal assertion, it exits with error status, instead of aborting. This makes it harder to debug GDBserver, as you can't just debug a core file if GDBserver fails an assertion. I've had to hack the code to make GDBserver abort to debug something several times before. I believe the reason it exits instead of aborting, is to prevent potentially littering the filesystem of smaller embedded targets with core files. I think I recall Daniel Jacobowitz once saying that many years ago, but I can't be sure. Anyhow, that seems reasonable to me. Since we nowadays have a distinction between development and release modes, I propose to make GDBserver abort on internal error if in development mode, while keeping the status quo when in release mode. Thus, after this patch, in development mode, you get: $ ../gdbserver/gdbserver ../../src/gdbserver/server.cc:3711: A problem internal to GDBserver has been detected. captured_main: Assertion `0' failed. Aborted (core dumped) $ while in release mode, you'll continue to get: $ ../gdbserver/gdbserver ../../src/gdbserver/server.cc:3711: A problem internal to GDBserver has been detected. captured_main: Assertion `0' failed. $ echo $? 1 I do not think that this requires a separate configure switch. A "--target_board=native-extended-gdbserver" run on Ubuntu 20.04 ends up with: === gdb Summary === # of unexpected core files 29 ... for me, of which 8 are GDBserver core dumps, 7 more than without this patch. Change-Id: I6861e08ad71f65a0332c91ec95ca001d130b0e9d
2022-05-26Finalize each cooked index separatelyTom Tromey1-0/+121
After DWARF has been scanned, the cooked index code does a "finalization" step in a worker thread. This step combines all the index entries into a single master list, canonicalizes C++ names, and splits Ada names to synthesize package names. While this step is run in the background, gdb will wait for the results in some situations, and it turns out that this step can be slow. This is PR symtab/29105. This can be sped up by parallelizing, at a small memory cost. Now each index is finalized on its own, in a worker thread. The cost comes from name canonicalization: if a given non-canonical name is referred to by multiple indices, there will be N canonical copies (one per index) rather than just one. This requires changing the users of the index to iterate over multiple results. However, this is easily done by introducing a new "chained range" class. When run on gdb itself, the memory cost seems rather low -- on my current machine, "maint space 1" reports no change due to the patch. For performance testing, using "maint time 1" and "file" will not show correct results. That approach measures "time to next prompt", but because the patch only affects background work, this shouldn't (and doesn't) change. Instead, a simple way to make gdb wait for the results is to set a breakpoint. Before: $ /bin/time -f%e ~/gdb/install/bin/gdb -nx -q -batch \ -ex 'break main' /tmp/gdb Breakpoint 1 at 0x43ec30: file ../../binutils-gdb/gdb/gdb.c, line 28. 2.00 After: $ /bin/time -f%e ./gdb/gdb -nx -q -batch \ -ex 'break main' /tmp/gdb Breakpoint 1 at 0x43ec30: file ../../binutils-gdb/gdb/gdb.c, line 28. 0.65 Regression tested on x86-64 Fedora 34. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29105
2022-05-23[gdbsupport] Fix UB in print-utils.cc:int_stringTom de Vries1-1/+5
When building gdb with -fsanitize=undefined, I run into: ... (gdb) PASS: gdb.ada/access_to_packed_array.exp: set logging enabled on maint print symbols^M print-utils.cc:281:29:runtime error: negation of -9223372036854775808 cannot \ be represented in type 'long int'; cast to an unsigned type to negate this \ value to itself (gdb) FAIL: gdb.ada/access_to_packed_array.exp: maint print symbols ... By running in a debug session, we find that this happens during printing of: ... typedef system.storage_elements.storage_offset: \ range -9223372036854775808 .. 9223372036854775807; ... Possibly, an ada test-case could be created that exercises this in isolation. The problem is here in int_string, where we negate a val with type LONGEST: ... return decimal2str ("-", -val, width); ... Fix this by, as recommend, using "-(ULONGEST)val" instead. Tested on x86_64-linux.
2022-05-19gdbsupport: fix path_join crash with -std=c++17 and -D_GLIBCXX_DEBUGSimon Marchi1-1/+1
When building GDB with -std=c++17 and -D_GLIBCXX_DEBUG=1, I get: $ ./gdb -nx --data-directory=data-directory -q -ex "maint selftest path_join" /usr/include/c++/11.2.0/string_view:233: constexpr const value_type& std::basic_string_view<_CharT, _Traits>::operator[](std::basic_string_view<_CharT, _Traits>::size_type) const [with _CharT = char; _Traits = std::char_traits<char>; std::basic_string_view<_CharT, _Traits>::const_reference = const char&; std::basic_string_view<_CharT, _Traits>::size_type = long unsigned int]: Assertion '__pos < this->_M_len' failed. The problem is that we're passing an empty string_view to IS_ABSOLUTE_PATH. IS_ABSOLUTE_PATH accesses [0] on that string_view, which is out-of-bounds. The reason this is not seen with -std less than c++17 is that our local copy of string_view (used with C++ < 17) does not have the assert in operator[], as that wouldn't work in a constexpr method: https://gitlab.com/gnutools/binutils-gdb/-/blob/5890af36e5112bcbb8d7555e63570f68466e6944/gdbsupport/gdb_string_view.h#L180 IS_ABSOLUTE_PATH is normally used with null-terminated string. It's fine to pass an empty null-terminated string to IS_ABSOLUTE_PATH, because index 0 in such a string is valid. But not with an empty string_view. Fix that by avoiding the "call" to IS_ABSOLUTE_PATH if the string_view is empty. Change-Id: Idf4df961b63f513b3389235e93814c02b89ea32e
2022-05-16Reindent gdbsupport/event-loop.cc:handle_file_eventPedro Alves1-54/+50
The handle_file_event function has a few unnecessary {} lexical blocks, presumably because they were originally if blocks, and the conditions were removed, or something along those lines. Remove the unnecessary blocks, and reindent. Change-Id: Iaecbe5c9f4940a80b81dbbc42e51ce506f6aafb2
2022-05-16gdbsupport/event-loop.cc: simplify !HAVE_POLL pathsPedro Alves1-61/+27
gdbsupport/event-loop.cc throughout handles the case of use_poll being true on a system where HAVE_POLL is not defined, by calling internal_error if that situation ever happens. Simplify this by moving the "use_poll" global itself under HAVE_POLL, so that it's way more unlikely to ever end up in such a situation. Then, move the code that checks the value of use_poll under HAVE_POLL too, and remove the internal_error calls. Like, from: if (use_poll) { #ifdef HAVE_POLL // poll code #else internal_error (....); #endif /* HAVE_POLL */ } else { // select code } to #ifdef HAVE_POLL if (use_poll) { // poll code } else #endif /* HAVE_POLL */ { // select code } While at it, make use_poll be a bool. The current code is using unsigned char most probably to save space, but I don't think it really matters here. Co-Authored-By: Youling Tang <tangyouling@loongson.cn> Change-Id: I0dd74fdd4d393ccd057906df4cd75e8e83c1cdb4
2022-05-10Fix --disable-threading buildTom Tromey3-11/+75
PR build/29110 points out that GDB fails to build on mingw when the "win32" thread model is in use. It turns out that the Fedora cross tools using the "posix" thread model, which somehow manages to support std::future, whereas the win32 model does not. While looking into this, I found that the configuring with --disable-threading will also cause a build failure. This patch fixes this build by introducing a compatibility wrapper for std::future. I am not able to test the win32 thread model build, but I'm going to ask the reporter to try this patch. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29110
2022-05-10Move non-dependent gdb::observers::observable::visit_state outside templatePedro Alves1-15/+24
The other day, while looking at the symbols that end up in a GDB index, I noticed that the gdb::observers::observable::visit_state enum class appears a number of times: $ grep VISIT gdb-index-symbol-names.txt gdb::observers::observable<bpstat*, int>::visit_state::NOT_VISITED gdb::observers::observable<bpstat*, int>::visit_state::VISITED gdb::observers::observable<bpstat*, int>::visit_state::VISITING gdb::observers::observable<breakpoint*>::visit_state::NOT_VISITED gdb::observers::observable<breakpoint*>::visit_state::VISITED gdb::observers::observable<breakpoint*>::visit_state::VISITING gdb::observers::observable<char const*, char const*>::visit_state::NOT_VISITED gdb::observers::observable<char const*, char const*>::visit_state::VISITED gdb::observers::observable<char const*, char const*>::visit_state::VISITING gdb::observers::observable<char const*>::visit_state::NOT_VISITED gdb::observers::observable<char const*>::visit_state::VISITED gdb::observers::observable<char const*>::visit_state::VISITING gdb::observers::observable<enum_flags<user_selected_what_flag> >::visit_state::NOT_VISITED gdb::observers::observable<enum_flags<user_selected_what_flag> >::visit_state::VISITED gdb::observers::observable<enum_flags<user_selected_what_flag> >::visit_state::VISITING gdb::observers::observable<frame_info*, int>::visit_state::NOT_VISITED gdb::observers::observable<frame_info*, int>::visit_state::VISITED gdb::observers::observable<frame_info*, int>::visit_state::VISITING gdb::observers::observable<gdbarch*>::visit_state::NOT_VISITED gdb::observers::observable<gdbarch*>::visit_state::VISITED gdb::observers::observable<gdbarch*>::visit_state::VISITING gdb::observers::observable<gdb_signal>::visit_state::NOT_VISITED gdb::observers::observable<gdb_signal>::visit_state::VISITED gdb::observers::observable<gdb_signal>::visit_state::VISITING [... snip ...] $ grep VISIT gdb-index-symbol-names.txt | wc -l 72 enum class visit_state is defined inside the class template observable, but it doesn't have to be, as it does not depend on the template parameters. This commit moves it out, so that only one such type exists. This reduces the size of a -O0 -g3 build for me by around 0.6%, like so: $ du -b gdb.before gdb.after 164685280 gdb.before 163707424 gdb.fixed and codesize by some 0.5%. Change-Id: I405f4ef27b8358fdd22158245b145d849b45658e
generated by cgit v1.1 at 2024-11-25 23:27:08 +0000