aboutsummaryrefslogtreecommitdiff
path: root/gdbsupport
AgeCommit message (Collapse)AuthorFilesLines
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
2022-04-25gdbsupport/pathstuff.h: #include <array> explicitly for std::array<>John Baldwin1-0/+1
This fixes build breakage using clang with libc++ on FreeBSD where std::array<> is not yet declared when used by the path_join variadic function template.
2022-04-21gdbsupport: add path_join functionSimon Marchi2-15/+53
In this review [1], Eli pointed out that we should be careful when concatenating file names to avoid duplicated slashes. On Windows, a double slash at the beginning of a file path has a special meaning. So naively concatenating "/" and "foo/bar" would give "//foo/bar", which would not give the desired results. We already have a few spots doing: if (first_path ends with a slash) path = first_path + second_path else path = first_path + slash + second_path In general, I think it's nice to avoid superfluous slashes in file paths, since they might end up visible to the user and look a bit unprofessional. Introduce the path_join function that can be used to join multiple path components together (along with unit tests). I initially wanted to make it possible to join two absolute paths, to support the use case of prepending a sysroot path to a target file path, or the prepending the debug-file-directory to a target file path. But the code in solib_find_1 shows that it is more complex than this anyway (for example, when the right hand side is a Windows path with a drive letter). So I don't think we need to support that case in path_join. That also keeps the implementation simpler. Change a few spots to use path_join to show how it can be used. I believe that all the spots I changed are guarded by some checks that ensure the right hand side operand is not an absolute path. Regression-tested on Ubuntu 18.04. Built-tested on Windows, and I also ran the new unit-test there. [1] https://sourceware.org/pipermail/gdb-patches/2022-April/187559.html Change-Id: I0df889f7e3f644e045f42ff429277b732eb6c752
2022-04-19gdbsupport/selftest: Allow lazy registrationLancelot SIX2-0/+32
This patch adds a way to delay the registration of tests until the latest possible moment. This is intended for situations where GDB needs to be fully initialized in order to decide if a particular selftest can be executed or not. This mechanism will be used in the next patch. Change-Id: I7f6b061f4c0a6832226c7080ab4e3a2523e1b0b0
2022-04-19gdbsupport/selftest: Replace for_each_selftest with an iterator_rangeLancelot SIX2-22/+36
Remove the callback-based selftests::for_each_selftest function and use an iterator_range instead. Also use this iterator range in run_tests so all iterations over the selftests are done in a consistent way. This will become useful in a later commit. Change-Id: I0b3a5349a7987fbcb0071f11c394e353df986583
2022-04-18gdb: use gdb_tilde_expand instead of gdb_tilde_expand_up in ↵Simon Marchi2-13/+0
source_script_with_search Since this is the latest use of gdb_tilde_expand_up, remove it. Change-Id: I964c812ce55fe087876abf91e7a3577ad79c0425
2022-04-18gdbsupport: make gdb_realpath_keepfile return an std::stringSimon Marchi2-9/+5
I'm trying to switch these functions to use std::string instead of char arrays, as much as possible. Some callers benefit from it (can avoid doing a copy of the result), while others suffer (have to make one more copy). Change-Id: I793aab17baaef8345488f4c40b9094e2695425bc
2022-04-18gdbsupport: make gdb_abspath return an std::stringSimon Marchi2-22/+21
I'm trying to switch these functions to use std::string instead of char arrays, as much as possible. Some callers benefit from it (can avoid doing a copy of the result), while others suffer (have to make one more copy). Change-Id: Iced49b8ee2f189744c5072a3b217aab5af17a993
2022-04-14Set the worker thread name on WindowsTom Tromey1-8/+64
This patch is a bit different from the rest of the series, in that it is a change to gdb's behavior on the host. It changes gdb's thread pool to try to set the thread name on Windows, if SetThreadDescription is available. This is part of PR win32/29050. This patch isn't likely to be useful to many people in the short term, because the Windows port of the libstdc++ thread code is not upstream. (AdaCore uses it, and sent it upstream, but it did not land, I don't know why.) However, if that patch does ever go in, or presumably if you build using some other C++ runtime library, then this will be useful. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29050
2022-04-14Let std::thread check pass even without pthreadsTom Tromey2-26/+24
Currently, the configure check for std::thread relies on pthreads existing. However, this means that if std::thread is implemented for a non-pthreads host, then the check will yield the wrong answer. This happened in AdaCore internal builds. Here, we have this GCC patch: https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ... which adds mingw support to GCC's gthreads implementation, and also to std::thread. This configure change fixes this problem and enables threading for gdb.
2022-04-14gdb: fix build errors in gdbsupport/thread-pool.h used with old gccTiezhu Yang2-3/+3
When I build gdb with gcc 8.3, there exist the following build errors, rename the typedef to task_t to fix them. CXX thread-pool.o In file included from /home/loongson/gdb.git/gdbsupport/thread-pool.cc:21: /home/loongson/gdb.git/gdbsupport/../gdbsupport/thread-pool.h: In member function ‘std::future<void> gdb::thread_pool::post_task(std::function<void()>&&)’: /home/loongson/gdb.git/gdbsupport/../gdbsupport/thread-pool.h:69:44: error: declaration of ‘task’ shadows a previous local [-Werror=shadow=local] std::packaged_task<void ()> task (std::move (func)); ^~~~ /home/loongson/gdb.git/gdbsupport/../gdbsupport/thread-pool.h:102:39: note: shadowed declaration is here typedef std::packaged_task<void ()> task; ^~~~ /home/loongson/gdb.git/gdbsupport/../gdbsupport/thread-pool.h: In member function ‘std::future<_Res> gdb::thread_pool::post_task(std::function<T()>&&)’: /home/loongson/gdb.git/gdbsupport/../gdbsupport/thread-pool.h:80:41: error: declaration of ‘task’ shadows a previous local [-Werror=shadow=local] std::packaged_task<T ()> task (std::move (func)); ^~~~ /home/loongson/gdb.git/gdbsupport/../gdbsupport/thread-pool.h:102:39: note: shadowed declaration is here typedef std::packaged_task<void ()> task; ^~~~ Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2022-04-13Make intrusive_list_node's next/prev privatePedro Alves1-1/+12
Tromey noticed that intrusive_list_node leaves its data members public, which seems sub-optimal. This commit makes intrusive_list_node's data fields private. intrusive_list_iterator, intrusive_list_reverse_iterator, and intrusive_list do need to access the fields, so they are made friends. Change-Id: Ia8b306b40344cc218d423c8dfb8355207a612ac5
2022-04-12gdbsupport: use result_of_t instead of result_of in parallel-for.hSimon Marchi1-3/+3
When building with -std=c++11, I get: In file included from /home/smarchi/src/binutils-gdb/gdb/unittests/parallel-for-selftests.c:22: /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/parallel-for.h:134:10: error: ‘result_of_t’ is not a member of ‘std’; did you mean ‘result_of’? 134 | std::result_of_t<RangeFunction (RandomIt, RandomIt)> | ^~~~~~~~~~~ | result_of This is because result_of_t has been introduced in C++14. Use the equivalent result_of<...>::type instead. result_of and result_of_t have been removed in C++20 though, so I think we'll need some patches eventually to make the code use invoke_result instead, depending on the C++ version. Change-Id: I4817f361c0ebcdd4b32976898fc368bb302b61b9
generated by cgit v1.1 at 2024-11-30 01:14:05 +0000