aboutsummaryrefslogtreecommitdiff
path: root/gdbsupport
AgeCommit message (Collapse)AuthorFilesLines
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.
2021-11-11[gdb/build] Fix Wimplicit-exception-spec-mismatch in clang buildTom de Vries1-2/+2
When building with clang 13 (and -std=gnu++17 to work around an issue in string_view-selftests.c), we run into a few Wimplicit-exception-spec-mismatch warnings: ... src/gdbsupport/new-op.cc:102:1: error: function previously declared with an \ explicit exception specification redeclared with an implicit exception \ specification [-Werror,-Wimplicit-exception-spec-mismatch] operator delete (void *p) ^ /usr/include/c++/11/new:130:6: note: previous declaration is here void operator delete(void*) _GLIBCXX_USE_NOEXCEPT ^ ... These are due to recent commit 5fff6115fea "Fix LD_PRELOAD=/usr/lib64/libasan.so.6 gdb". Fix this by adding the missing noexcept. Build on x86_64-linux, using gcc 7.5.0 and clang 13.0.0.
2021-11-11[gdb/build] Fix build with -std=c++11Tom de Vries1-0/+5
When building with -std=c++11, we run into two Werror=missing-declarations: ... new-op.cc: In function 'void operator delete(void*, std::size_t)': new-op.cc:114:1: error: no previous declaration for \ 'void operator delete(void*, std::size_t)' [-Werror=missing-declarations] operator delete (void *p, std::size_t) noexcept ^~~~~~~~ new-op.cc: In function 'void operator delete [](void*, std::size_t)': new-op.cc:132:1: error: no previous declaration for \ 'void operator delete [](void*, std::size_t)' [-Werror=missing-declarations] operator delete[] (void *p, std::size_t) noexcept ^~~~~~~~ ... These are due to recent commit 5fff6115fea "Fix LD_PRELOAD=/usr/lib64/libasan.so.6 gdb". The declarations are provided by <new> (which is included) for c++14 onwards, but they are missing for c++11. Fix this by adding the missing declarations. Tested on x86_64-linux, with gcc 7.5.0, both without (implying -std=gnu++14) and with -std=c++11.
2021-11-09Fix build on rhES5Tom Tromey3-0/+25
The rhES5 build failed due to an upstream import a while back. The bug here is that, while the 'personality' function exists, ADDR_NO_RANDOMIZE is only defined in <linux/personality.h>, not <sys/personality.h>. However, <linux/personality.h> does not declare the 'personality' function, and <sys/personality.h> and <linux/personality.h> cannot both be included. This patch restores one of the removed configure checks and updates the code to check it. We had this as a local patch at AdaCore, because it seemed like there was no interest upstream. However, now it turns out that this fixes PR build/28555, so I'm sending it now.
2021-11-08Improve gdb::array_view ctor from contiguous containersLancelot SIX1-3/+4
While reading the interface of gdb::array_view, I realized that the constructor that builds an array_view on top of a contiguous container (such as std::vector, std::array or even gdb::array_view) can be missused. Lets consider the following code sample: struct Parent { Parent (int a): a { a } {} int a; }; std::ostream &operator<< (std::ostream& os, const Parent & p) { os << "Parent {a=" << p.a << "}"; return os; } struct Child : public Parent { Child (int a, int b): Parent { a }, b { b } {} int b; }; std::ostream &operator<< (std::ostream& os, const Child & p) { os << "Child {a=" << p.a << ", b=" << p.b << "}"; return os; } template <typename T> void print (const gdb::array_view<const T> &p) { std::for_each (p.begin (), p.end (), [](const T &p) { std::cout << p << '\n'; }); } Then with the current interface nothinng prevents this usage of array_view to be done: const std::array<Child, 3> elts = { Child {1, 2}, Child {3, 4}, Child {5, 6} }; print_all<Parent> (elts); This compiles fine and produces the following output: Parent {a=1} Parent {a=2} Parent {a=3} which is obviously wrong. There is nowhere in memory a Parent-like object for which the A member is 2 and this call to print_all<Parent> shold not compile at all (calling print_all<Child> is however fine). This comes down to the fact that a Child* is convertible into a Parent*, and that an array view is constructed to a pointer to the first element and a size. The valid type pointed to that can be used with this constructor are restricted using SFINAE, which requires that a pointer to a member into the underlying container can be converted into a pointer the array_view's data type. This patch proposes to change the constraints on the gdb::array_view ctor which accepts a container now requires that the (decayed) type of the elements in the container match the (decayed) type of the array_view being constructed. Applying this change required minimum adjustment in GDB codebase, which are also included in this patch. Tested by rebuilding.
2021-11-05Introduce make_unique_xstrndupTom Tromey1-0/+9
This adds a new make_unique_xstrndup function, which is the "n" analogue of make_unique_xstrdup. It also updates a couple existing places to use this function.
2021-11-03Fix LD_PRELOAD=/usr/lib64/libasan.so.6 gdbJan Kratochvil1-0/+42
Currently for a binary compiled normally (without -fsanitize=address) but with LD_PRELOAD of ASAN one gets: $ ASAN_OPTIONS=detect_leaks=0:alloc_dealloc_mismatch=1:abort_on_error=1:fast_unwind_on_malloc=0 LD_PRELOAD=/usr/lib64/libasan.so.6 gdb ================================================================= ==1909567==ERROR: AddressSanitizer: alloc-dealloc-mismatch (malloc vs operator delete []) on 0x602000001570 #0 0x7f1c98e5efa7 in operator delete[](void*) (/usr/lib64/libasan.so.6+0xb0fa7) ... 0x602000001570 is located 0 bytes inside of 2-byte region [0x602000001570,0x602000001572) allocated by thread T0 here: #0 0x7f1c98e5cd1f in __interceptor_malloc (/usr/lib64/libasan.so.6+0xaed1f) #1 0x557ee4a42e81 in operator new(unsigned long) (/usr/libexec/gdb+0x74ce81) SUMMARY: AddressSanitizer: alloc-dealloc-mismatch (/usr/lib64/libasan.so.6+0xb0fa7) in operator delete[](void*) ==1909567==HINT: if you don't care about these errors you may set ASAN_OPTIONS=alloc_dealloc_mismatch=0 ==1909567==ABORTING Despite the code called properly operator new[] and operator delete[]. But GDB's new-op.cc provides its own operator new[] which gets translated into malloc() (which gets recogized as operatore new(size_t)) but as it does not translate also operators delete[] Address Sanitizer gets confused. The question is how many variants of the delete operator need to be provided. There could be 14 operators new but there are only 4, GDB uses 3 of them. There could be 16 operators delete but there are only 6, GDB uses 2 of them. It depends on libraries and compiler which of the operators will get used. Currently being used: U operator new[](unsigned long) U operator new(unsigned long) U operator new(unsigned long, std::nothrow_t const&) U operator delete[](void*) U operator delete(void*, unsigned long) Tested on x86_64-linux.
2021-10-28gdb: add selftest name completionSimon Marchi1-1/+3
After the previous commit, it is easy to add completion for selftest names. Again, this is not particularly high value, but I rarely touched completion, so it served as a simple example to get some practice. Change the for_each_selftest_ftype parameter to gdb::function_view, so that we can pass a lambda that captures things. Change-Id: I87cac299ddca9ca7eb0ffab78342e850a98d954c
2021-10-25gdbsupport: add assertions in array_viewSimon Marchi1-4/+24
Add assertions to ensure we don't access an array_view out of bounds. Enable these assertions only when _GLIBCXX_DEBUG is set, as we did for gdb::optional. Change-Id: Iffaee38252405073735ed123c8e57fde6b2c6be3
2021-10-19Fix format_pieces selftest on WindowsTom Tromey3-0/+70
The format_pieces selftest currently fails on Windows hosts. The selftest doesn't handle the "%ll" -> "%I64" rewrite that the formatter may perform, but also gdbsupport was missing a configure check for PRINTF_HAS_LONG_LONG. This patch fixes both issues.
generated by cgit v1.1 at 2024-09-17 22:47:50 +0000