aboutsummaryrefslogtreecommitdiff
path: root/gdbsupport
AgeCommit message (Collapse)AuthorFilesLines
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
2022-04-12Specialize std::hash for gdb_exceptionTom Tromey1-0/+19
This adds a std::hash specialization for gdb_exception. This lets us store these objects in a hash table, which is used later in this series to de-duplicate the exception output from multiple threads.
2022-04-12Return vector of results from parallel_for_eachTom Tromey3-30/+141
This changes gdb::parallel_for_each to return a vector of the results. However, if the passed-in function returns void, the return type remains 'void'. This functionality is used later, to parallelize the new indexer.
2022-04-12Add batching parameter to parallel_for_eachTom Tromey1-6/+12
parallel_for_each currently requires each thread to process at least 10 elements. However, when indexing, it's fine for a thread to handle just a single CU. This patch parameterizes this, and updates the one user.
2022-04-12Allow thread-pool.h to work without threadsTom Tromey3-17/+27
thread-pool.h requires CXX_STD_THREAD in order to even be included. However, there's no deep reason for this, and during review we found that one patch in the new DWARF indexer series unconditionally requires the thread pool. Because the thread pool already allows a task to be run in the calling thread (for example if it is configured to have no threads in the pool), it seemed straightforward to make this code ok to use when host threads aren't available at all. This patch implements this idea. I built it on a thread-less host (mingw, before my recent configure patch) and verified that the result builds. After the thread-pool change, parallel-for.h no longer needs any CXX_STD_THREAD checks at all, so this patch removes these as well.
2022-03-30Consolidate definition of current_directoryTom Tromey3-3/+7
I noticed that both gdbserver and gdb define current_directory. However, as it is referenced by gdbsupport, it seemed better to define it there as well. This patch also moves the declaration to pathstuff.h. Tested by rebuilding.
2022-03-07Let phex and phex_nz handle sizeof_l==1Tom Tromey1-0/+8
Currently, neither phex nor phex_nz handle sizeof_l==1 -- they let this case fall through to the default case. However, a subsequent patch in this series needs this case to work correctly. I looked at all calls to these functions that pass a 1 for the sizeof_l parameter. The only such case seems to be correct with this change.
2022-03-03Fix typo in last change.Roland McGrath1-1/+1
2022-03-03Avoid conflict with gnulib open/close macros.Roland McGrath2-5/+5
On some systems, the gnulib configuration will decide to define open and/or close as macros to replace the POSIX C functions. This interferes with using those names in C++ class or namespace scopes. gdbsupport/ * event-pipe.cc (event_pipe::open): Renamed to ... (event_pipe::open_pipe): ... this. (event_pipe::close): Renamed to ... (event_pipe::close_pipe): ... this. * event-pipe.h (class event_pipe): Updated. gdb/ * inf-ptrace.h (async_file_open, async_file_close): Updated. gdbserver/ * gdbserver/linux-low.cc (linux_process_target::async): Likewise.
2022-02-25gdb: add operator+= and operator+ overload for std::stringAndrew Burgess1-0/+19
This commit adds operator+= and operator+ overloads for adding gdb::unique_xmalloc_ptr<char> to a std::string. I could only find 3 places in GDB where this was useful right now, and these all make use of operator+=. I've also added a self test for gdb::unique_xmalloc_ptr<char>, which makes use of both operator+= and operator+, so they are both getting used/tested. There should be no user visible changes after this commit, except when running 'maint selftest', where the new self test is visible.
2022-02-22gdbsupport: Add an event-pipe class.John Baldwin6-3/+190
This pulls out the implementation of an event pipe used to implement target async support in both linux-low.cc (gdbserver) and linux-nat.c (gdb). This will be used to replace the existing event pipe in linux-low.cc and linux-nat.c in future commits. Co-Authored-By: Lancelot SIX <lsix@lancelotsix.com>
2022-01-20gdbsupport/gdb_regex.cc: replace defs.h include with common-defs.hSimon Marchi1-1/+1
This was forgotten when gdb_regex was moved from gdb to gdbsupport. Change-Id: I73b446f71861cabbf7afdb7408ef9d59fa64b804
2022-01-18Move gdb_regex to gdbsupportTom Tromey4-8/+126
This moves the gdb_regex convenience class to gdbsupport.
2022-01-18Introduce gdb-hashtab module in gdbsupportTom Tromey4-9/+106
gdb has some extensions and helpers for working with the libiberty hash table. This patch consolidates these and moves them to gdbsupport.
2022-01-18Move gdb obstack code to gdbsupportTom Tromey4-8/+216
This moves the gdb-specific obstack code -- both extensions like obconcat and obstack_strdup, and things like auto_obstack -- to gdbsupport.
2022-01-18Move gdb_argv to gdbsupportTom Tromey1-0/+204
This moves the gdb_argv class to a new header in gdbsupport.
2022-01-13gdb: don't use -Wmissing-prototypes with g++Andrew Burgess6-4/+137
This commit aims to not make use of -Wmissing-prototypes when compiling with g++. Use of -Wmissing-prototypes was added with this commit: commit a0761e34f054767de6d6389929d27e9015fb299b Date: Wed Mar 11 15:15:12 2020 -0400 gdb: enable -Wmissing-prototypes warning Because clang can provide helpful warnings with this flag. Unfortunately, g++ doesn't accept this flag, and will give this warning: cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++ In theory the fact that this flag is not supported should be detected by the configure check in gdbsupport/warning.m4, but for users of ccache, this check doesn't work due to a long standing ccache issue: https://github.com/ccache/ccache/issues/738 The ccache problem is that -W... options are reordered on the command line, and so -Wmissing-prototypes is seen before -Werror. Usually this doesn't matter, but the above warning (about the flag not being valid) is issued before the -Werror flag is processed, and so is not fatal. There have been two previous attempts to fix this that I'm aware of. The first is: https://sourceware.org/pipermail/gdb-patches/2021-September/182148.html In this attempt, instead of just relying on a compile to check if a flag is valid, the proposal was to both compile and link. As linking doesn't go through ccache, we don't suffer from the argument reordering problem, and the link phase will correctly fail when using -Wmissing-prototypes with g++. The configure script will then disable the use of this flag. This approach was rejected, and the suggestion was to only add the -Wmissing-prototypes flag if we are compiling with gcc. The second attempt, attempts this approach, and can be found here: https://sourceware.org/pipermail/gdb-patches/2021-November/183076.html This attempt only adds the -Wmissing-prototypes flag is the value of GCC is not 'yes'. This feels like it is doing the right thing, unfortunately, the GCC flag is really a 'is gcc like' flag, not a strict, is gcc check. As such, GCC is set to 'yes' for clang, which would mean the flag was not included for clang or gcc. The entire point of the original commit was to add this flag for clang, so clearly the second attempt is not sufficient either. In this new attempt I have added gdbsupport/compiler-type.m4, this file defines AM_GDB_COMPILER_TYPE. This macro sets the variable GDB_COMPILER_TYPE to either 'gcc', 'clang', or 'unknown'. In future the list of values might be extended to cover other compilers, if this is ever useful. I've then modified gdbsupport/warning.m4 to only add the problematic -Wmissing-prototypes flag if GDB_COMPILER_TYPE is not 'gcc'. I've tested this with both gcc and clang and see the expected results, gcc no longer attempts to use the -Wmissing-prototypes flag, while clang continues to use it. When compiling using ccache, I am no longer seeing the warning.
2022-01-11gdbsupport: regenerate Makefile.inAndrew Burgess1-2/+2
I had cause to regenerate gdbsupport/Makefile.in, and noticed some unexpected changes in the copyright header dates. I suspect that this was caused by the end of year date range update process. The Makefile.in contains two date ranges. The first range appears to be the date range for the version of automake being used, that is the range runs up to 2017 only, when automake 1.15.1 was released. The second date range in Makefile.in represents the date range for the generated file, and so, now runs up to 2022. Anyway, this is the result of running autoreconf (using automake 1.15.1) in the gdbsupport directory.
2022-01-04gdb: don't pass nullptr to sigwaitAndrew Burgess1-1/+6
I tried building GDB on GNU/Hurd, and ran into this warning: gdbsupport/scoped_ignore_signal.h:78:16: error: null argument where non-null required (argument 2) [-Werror=nonnull] This is because in this commit: commit 99624310dd82542c389c89c2e55d8cae36bb74e1 Date: Sun Jun 27 15:13:14 2021 -0400 gdb: fall back on sigpending + sigwait if sigtimedwait is not available A call to sigwait was introduced that passes nullptr as the second argument, this call is only reached if sigtimedwait is not supported. The original patch was written for macOS, I assume on that target passing nullptr as the second argument is fine. On my GNU/Linux box, the man-page for sigwait doesn't mention that nullptr is allowed for the second argument, so my assumption would be that nullptr is not OK, and, if I change the '#ifdef HAVE_SIGTIMEDWAIT' introduced by the above patch to '#if 0', and rebuild on GNU/Linux, I see the same warning that I see on GNU/Hurd. I propose that we stop passing nullptr as the second argument to sigwait, and instead pass a valid int pointer. The value returned in the int can then be used in an assert. For testing, I (locally) made the change to the #ifdef I mentioned above, compiled GDB, and ran the usual tests, this meant I was using sigwait instead on sigtimedwait on GNU/Linux, I saw no regressions.
2022-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker138-138/+138
This commit brings all the changes made by running gdb/copyright.py as per GDB's Start of New Year Procedure. For the avoidance of doubt, all changes in this commits were performed by the script.
2021-12-15New --enable-threading configure option to control use of threads in ↵Luis Machado2-4/+42
GDB/GDBserver Add the --enable-threading configure option so multithreading can be disabled at configure time. This is useful for statically-linked builds of GDB/GDBserver, since the thread library doesn't play well with that setup. If you try to run a statically-linked GDB built with threading, it will crash when setting up the number of worker threads. This new option is also convenient when debugging GDB in a system with lots of threads, where the thread discovery code in GDB will emit too many messages, like so: [New Thread 0xfffff74d3a50 (LWP 2625599)] If you have X threads, that message will be repeated X times. The default for --enable-threading is "yes".
2021-12-09Revert "gdbsupport: remove unnecessary `#ifndef IN_PROCESS_AGENT`"Simon Marchi1-0/+2
This reverts commit fe72c32765e1190c8a17d309fc3a7e1882d6a430. It turns out it was wrong, libinproctrace.so does build its own gdbsupport/tdesc.cc. This broke the build: make[1]: Entering directory '/home/simark/build/binutils-gdb-one-target/gdbserver' CXXLD libinproctrace.so /usr/bin/ld: gdbsupport/tdesc-ipa.o: in function `print_xml_feature::visit_pre(target_desc const*)': /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/tdesc.cc:407: undefined reference to `tdesc_architecture_name(target_desc const*)' /usr/bin/ld: /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/tdesc.cc:408: undefined reference to `tdesc_architecture_name(target_desc const*)' /usr/bin/ld: /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/tdesc.cc:411: undefined reference to `tdesc_osabi_name(target_desc const*)' /usr/bin/ld: /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/tdesc.cc:416: undefined reference to `tdesc_compatible_info_list(target_desc const*)' /usr/bin/ld: /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/tdesc.cc:418: undefined reference to `tdesc_compatible_info_arch_name(std::unique_ptr<tdesc_compatible_info, std::default_delete<tdesc_compatible_info> > const&)'
2021-12-09gdbsupport: remove unnecessary `#ifndef IN_PROCESS_AGENT`Simon Marchi1-2/+0
I suppose this code was copied from GDBserver and this ifndef was left there. As far as I know, IN_PROCESS_AGENT will never be defined when building this file, so we can remove this. Change-Id: I84fc408e330b3a29106df830a09342861cadbaf6
2021-12-04gdbsupport: fix memory leak in create_file_handler when re-using file handlerSimon Marchi1-7/+6
ASan made me notice a memory leak, where the memory tied to the file handle name string wasn't freed. When register a file handler with an fd that is already registered, we re-use the file_handler object, so we ended up creating a new std::string object and overwriting the file_handler::name pointer, without free-ing the old std::string. Fix this by allocating file_handler with new, deleting it with delete, and making file_handler::name not a pointer. Change-Id: Ie304cc78ab5ae5dfad9a1366e9890c09de651f43
2021-12-03gdbsupport: add array_view copy functionSimon Marchi1-0/+15
An assertion was recently added to array_view::operator[] to ensure we don't do out of bounds accesses. However, when the array_view is copied to or from using memcpy, it bypasses that safety. To address this, add a `copy` free function that copies data from an array view to another, ensuring that the destination and source array views have the same size. When copying to or from parts of an array_view, we are expected to use gdb::array_view::slice, which does its own bounds check. With all that, any copy operation that goes out of bounds should be caught by an assertion at runtime. copy is implemented using std::copy and std::copy_backward, which, at least on libstdc++, appears to pick memmove when copying trivial data. So in the end there shouldn't be much difference vs using a bare memcpy, as we do right now. When copying non-trivial data, std::copy and std::copy_backward assigns each element in a loop. To properly support overlapping ranges, we must use std::copy or std::copy_backward, depending on whether the destination is before the source or vice-versa. std::copy and std::copy_backward don't support copying exactly overlapping ranges (where the source range is equal to the destination range). But in this case, no copy is needed anyway, so we do nothing. The order of parameters of the new copy function is based on std::copy and std::copy_backward, where the source comes before the destination. Change a few randomly selected spots to use the new function, to show how it can be used. Add a test for the new function, testing both with arrays of a trivial type (int) and of a non-trivial type (foo). Test non-overlapping ranges as well as three kinds of overlapping ranges: source before dest, dest before source, and dest == source. Change-Id: Ibeaca04e0028410fd44ce82f72e60058d6230a03
2021-11-22gdb: introduce target_waitkind_str, use it in target_waitstatus::to_stringSimon Marchi2-4/+8
I would like to print target_waitkind values in debug messages, so I think that a target_waitkind-to-string function would be useful. While at it, use it in target_waitstatus::to_string. This changes the output of target_waitstatus::to_string a bit, but I think it is for the better. The debug messages will show a string matching exactly the target_waitkind enumerator (minus the TARGET_WAITKIND prefix). As a convenience, make string_appendf return the same reference to string it got as a parameter. This allows doing this: return string_appendf (str, "foo"); ... keeping the code concise. Change-Id: I383dffc9c78614e7d0668b1516073905e798eef7
2021-11-20gdbsupport: fix array-view compilation with c++11 && _GLIBCXX_DEBUGSimon Marchi1-3/+3
When building with -std=c++11 and -D_GLIBCXX_DEBUG=1, we get some errors like: CXX unittests/array-view-selftests.o In file included from /home/smarchi/src/binutils-gdb/gdb/utils.h:25, from /home/smarchi/src/binutils-gdb/gdb/defs.h:630, from /home/smarchi/src/binutils-gdb/gdb/unittests/array-view-selftests.c:20: /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/array-view.h: In instantiation of constexpr gdb::array_view<T> gdb::array_view<T>::slice(gdb::array_view<T>::size_type, gdb::array_view<T>::size_type) const [with T = unsigned char; gdb::array_view<T>::size_type = long unsigned int: /home/smarchi/src/binutils-gdb/gdb/unittests/array-view-selftests.c:532:29: required from here /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/array-view.h:192:3: error: body of constexpr function constexpr gdb::array_view<T> gdb::array_view<T>::slice(gdb::array_view<T>::size_type, gdb::array_view<T>::size_type) const [with T = unsigned char; gdb::array_view<T>::size_type = long unsigned int not a return-statement 192 | } | ^ This is because constexpr functions in c++11 can only consist of a single return statement, so we can't have the gdb_assert in there. Make the gdb_assert presence conditional to the __cplusplus version, to enable it only for c++14 and later. Change-Id: I2ac33f7b4bd1765ddc3ac8d07445b16ac1f340f0
2021-11-18gdbsupport: make gdb_assert_not_reached accept a format stringSimon Marchi2-5/+6
Change gdb_assert_not_reached to accept a format string plus corresponding arguments. This allows giving more precise messages. Because the format string passed by the caller is prepended with a "%s:" to add the function name, the callers can no longer pass a translated string (`_(...)`). Make the gdb_assert_not_reached include the _(), just like the gdb_assert_fail macro just above. Change-Id: Id0cfda5a57979df6cdaacaba0d55dd91ae9efee7
2021-11-16gdbsupport: remove FUNCTION_NAMESimon Marchi2-33/+2
__func__ is standard C++11: https://en.cppreference.com/w/cpp/language/function Also, in C++11, __func__ expands to the demangled function name, so the mention in the comment above FUNCTION_NAME doesn't apply anymore. Finally, in places where FUNCTION_NAME is used, I think it's enough to print the function name, no need to print the whole signature. Therefore, I propose to just remove FUNCTION_NAME and update users to use the standard __func__. Change-Id: I778f28155422b044402442dc18d42d0cded1017d
2021-11-16gdb/gdbsupport: make xstrprintf and xstrvprintf return a unique_ptrAndrew Burgess2-7/+8
The motivation is to reduce the number of places where unmanaged pointers are returned from allocation type routines. All of the callers are updated. There should be no user visible changes after this commit.
2021-11-16gdbsupport: move xfree into its own fileAndrew Burgess4-16/+43
In the next commit I'd like to reference gdb_unique_ptr within the common-utils.h file. However, this requires that I include gdb_unique_ptr.h, which requires that xfree be defined. Interestingly, gdb_unique_ptr.h doesn't actually include anything that defines xfree, but I was finding that when I added a gdb_unique_ptr.h include to common-utils.h I was getting a dependency cycle; before my change xfree was defined when gdb_unique_ptr.h was processed, while after my change it was not, and this made g++ unhappy. To break this cycle, I propose to move xfree into its own header file, gdb-xfree.h, which I'll then include into gdb_unique_ptr.h and common-utils.cc.
generated by cgit v1.1 at 2024-09-13 09:18:54 +0000