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
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
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
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
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
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
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.
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>
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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>
This commit aims to not make use of -Wmissing-prototypes when
compiling with g++.
Use of -Wmissing-prototypes was added with this commit:
commit a0761e34f0
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.
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.
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 99624310dd
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.
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.
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".
This reverts commit fe72c32765.
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&)'
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
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
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
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
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
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
__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
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.
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.
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 5fff6115fe "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.
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 5fff6115fe "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.
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.
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.
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.
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.
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
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
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.
