| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
|
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 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.
|
|
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.
|
|
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".
|
|
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&)'
|
|
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 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.
|
|
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.
|
|
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.
|
|
Now that there is a register_test variant that accepts std::function,
it seems to me that the 'selftest' struct and accompanying code is
obsolete -- simply always using std::function is simpler. This patch
implements this idea.
|
|
Say we use a gcc version that (while supporting c++11) does not support c++11
by default, and needs an -std setting to enable it.
If gdb would use the default AX_CXX_COMPILE_STDCXX from autoconf-archive, then
we'd have:
...
CXX="g++ -std=gnu++11"
...
That mechanism however has the following problem (quoting from commit
0bcda685399):
...
the top level Makefile passes CXX down to subdirs, and that overrides whatever
gdb/Makefile may set CXX to. The result would be that a make invocation from
the build/gdb/ directory would use "g++ -std=gnu++11" as expected, while a
make invocation at the top level would not.
...
Commit 0bcda685399 fixes this by using a custom AX_CXX_COMPILE_STDCXX which
does:
...
CXX=g++
CXX_DIALECT=-std=gnu++11
...
The problem reported in PR28318 is that using the custom instead of the
default AX_CXX_COMPILE_STDCXX makes the configure test for std::thread
support fail.
We could simply add $CXX_DIALECT to the test for std::thread support, but
that would have to be repeated for each added c++ support test.
Instead, fix this by doing:
...
CXX="g++ -std=gnu++11"
CXX_DIALECT=-std=gnu++11
...
This is somewhat awkward, since it results in -std=gnu++11 occuring twice in
some situations:
...
$ touch src/gdb/dwarf2/read.c
$ ( cd build/gdb; make V=1 dwarf2/read.o )
g++-4.8 -std=gnu++11 -x c++ -std=gnu++11 ...
...
However, both settings are needed:
- the switch in CXX for the std::thread tests (and other tests)
- the switch in CXX_DIALECT so it can be appended in Makefiles, to
counteract the fact that the top-level Makefile overrides CXX
The code added in gdb/ax_cxx_compile_stdcxx.m4 is copied from the default
AX_CXX_COMPILE_STDCXX from autoconf-archive.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28318
|
|
In the gdbsupport configure.ac file, there is an attempt to define
TARGET_WORD_SIZE. This is done by running grep on the file
../bfd/bfd-in3.h.
The problem with this is, the file bfd-in3.h is generated into the bfd
build directory when bfd is configured, and there is no dependency
between the gdbsupport module and the bfd module, so, for example, if
I do:
$ ../src/configure
$ make all-gdbsupport
Then bfd will neither be configured, or built. In this case
TARGET_WORD_SIZE ends up being defined, but with no value because the
grep on bfd-in3.h fails.
However, it turns out that this doesn't matter; we don't actually use
TARGET_WORD_SIZE anywhere.
My proposal in this commit is to just remove the definition of
TARGET_WORD_SIZE, the alternative would be to add a dependency between
configure-gdbsupport and configure-bfd into Makefile.def, but adding a
dependency for something we don't need seems pretty pointless.
|
|
This encourages the callers to use automatic file descriptor management.
Change-Id: I137a81df6f3607b457e28c35aafde8ed6f3a3344
|
|
Make gdb_open_cloexec return a scoped_fd, to encourage using automatic
management of the file descriptor closing. Except in the most trivial
cases, I changed the callers to just release the fd, which retains their
existing behavior. That will allow the transition to using scoped_fd
more to go gradually, one caller at a time.
Change-Id: Ife022b403f96e71d5ebb4f1056ef6251b30fe554
|
|
The following patches wants to change gdb_fopen_cloexec and
gdb_mkostemp_cloexec to return a scoped_fd. Doing this causes a cyclic
include between scoped_fd.h and filestuff.h, that both want to include
each other. scoped_fd.h includes filestuff.h because of the
scoped_fd::to_file method's return value. filestuff.h would then
include scoped_fd.h for gdb_fopen_cloexec's and gdb_mkostemp_cloexec's
return values.
To fix that, move gdb_file_up to its own file, gdb_file.h.
Change-Id: Ic82a48914b2aacee8f14af535b7469245f88b93d
|
|
The ptid_t 'tid' member is normally used as an address in gdb -- both
bsd-uthread and ravenscar-thread use it this way. However, because
the type is 'long', this can cause problems with sign extension.
This patch changes the type to ULONGEST to ensure that sign extension
does not occur.
|
|
I wanted to find, and potentially modify, all the spots where the
'tid' parameter to the ptid_t constructor was used. So, I temporarily
removed this parameter and then rebuilt.
In order to make it simpler to search through the "real" (nonzero)
uses of this parameter, something I knew I'd have to do multiple
times, I removed any ", 0" from constructor calls.
Co-Authored-By: John Baldwin <jhb@FreeBSD.org>
|
|
The print_one_insn selftest in gdb/disasm-selftests.c contains:
...
/* If you want to see the disassembled instruction printed to gdb_stdout,
set verbose to true. */
static const bool verbose = false;
...
Make this parameter available in the maint selftest command using a new option
-verbose, such that we can do:
...
(gdb) maint selftest -verbose print_one_insn
...
Tested on x86_64-linux.
|
|
Change register_test to use std::function arg, such that we can do:
...
register_test (test_name, [=] () { SELF_CHECK (...); });
...
Tested on x86_64-linux.
|
|
Bug 28341 shows that GDB fails to compile when built with -std=c++11.
I don't know much about the use case, but according to the author of the
bug:
I encountered the scenario where CXX is set to "g++ -std=c++11" when
I try to compile binutils under GCC as part of the GCC 3-stage
compilation, which is common for building a cross-compiler.
The author of the bug suggests using __typeof__ instead of typeof. But
since we're using C++, we might as well use decltype, which is standard.
This is what this patch does.
The failure (and fix) can be observed by configuring GDB with CXX="g++
-std=c++11":
CXX linux-low.o
In file included from /home/simark/src/binutils-gdb/gdbserver/gdb_proc_service.h:22,
from /home/simark/src/binutils-gdb/gdbserver/linux-low.h:27,
from /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:20:
/home/simark/src/binutils-gdb/gdbserver/../gdbsupport/gdb_proc_service.h:177:50: error: expected constructor, destructor, or type conversion before (token
177 | __attribute__((visibility ("default"))) typeof (SYM) SYM
| ^
/home/simark/src/binutils-gdb/gdbserver/../gdbsupport/gdb_proc_service.h:179:1: note: in expansion of macro PS_EXPORT
179 | PS_EXPORT (ps_get_thread_area);
| ^~~~~~~~~
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28341
Change-Id: I84fbaae938209d8d935ca08dec9b7e6a0dd1bda0
|
|
The libstdc++ version of optional contains some runtime checks enabled
when _GLIBCXX_DEBUG is defined. I think it would be useful if our
version contained similar checks.
Add checks in the two `get` methods, also conditional on _GLIBCXX_DEBUG.
I think it's simpler to use that macro rather than introducing a new
GDB-specific one, as I think that if somebody is interested in enabling
these runtime checks, they'll also be interested in enabling the
libstdc++ runtime checks (and vice-versa).
I implemented these checks using gdb_assert. Note that gdb_assert
throws (after querying the user), and we are in noexcept methods. That
means that std::terminate / abort will immediately be called. I think
this is ok, since if those were "real" _GLIBCXX_DEBUG checks, abort
would be called straight away.
If I add a dummy failure, it looks like so:
$ ./gdb -q -nx --data-directory=data-directory
/home/simark/src/binutils-gdb/gdb/../gdbsupport/gdb_optional.h:206: internal-error: T& gdb::optional<T>::get() [with T = int]: Assertion `this->has_value ()' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n
[1] 658767 abort (core dumped) ./gdb -q -nx --data-directory=data-directory
Change-Id: Iadfdcd131425bd2ca6a2de30d7b22e9b3cc67793
|
|
I noticed that exception_print_same is only used in a single spot, and
it seemed to be better as an operator!= method attached to
gdb_exception.
Regression tested on x86-64 Fedora 34.
|
|
With trunk gcc (12.0) we're running into a -Werror=nonnull-compare build
breaker in gdb, which caused a broader review of the usage of the nonnull
attribute.
The current conclusion is that it's best to disable this. This is explained
at length in the gdbsupport/common-defs.h comment.
Tested by building with trunk gcc.
gdb/ChangeLog:
2021-07-29 Tom de Vries <tdevries@suse.de>
* gdbsupport/common-defs.h (ATTRIBUTE_NONNULL): Disable.
|
|
In commit:
commit f069ea46a03ae868581d1c852da28e979ea1245a
Date: Sat Jul 3 16:29:08 2021 -0700
Rename gdb/ChangeLog to gdb/ChangeLog-2021
The gdb/ChangeLog file was renamed, but all of the other ChangeLog
files relating to gdb were left in place.
As I understand things, the no ChangeLogs policy applies to all the
GDB related directories, so this commit renames all of the remaining
GDB related ChangeLog files.
As with the original commit, the intention behind this commit is to
hopefully stop people merging ChangeLog entries by mistake.
The renames carried out in this commit are:
gdb/doc/ChangeLog -> gdb/doc/ChangeLog-1991-2021
gdb/stubs/ChangeLog -> gdb/stubs/ChangeLog-2012-2020
gdb/testsuite/ChangeLog -> gdb/testsuite/ChangeLog-2014-2021
gdbserver/ChangeLog -> gdbserver/ChangeLog-2002-2021
gdbsupport/ChangeLog -> gdbsupport/ChangeLog-2020-2021
|
|
Same idea as the previous patch, but for m_cwd.
To keep things consistent across the board, change get_inferior_cwd as
well, which is shared with GDBserver. So update the related GDBserver
code too.
Change-Id: Ia2c047fda738d45f3d18bc999eb67ceb8400ce4e
|
|
The declaration of set_inferior_cwd is currently shared between gdb and
gdbserver, in gdbsupport/common-inferior.h. It doesn't need to be, as
set_inferior_cwd is not called from common code. Only get_inferior_cwd
needs to.
The motivation for this is that a future patch will change the prototype
of set_inferior_cwd in gdb, and I don't want to change it for gdbserver
unnecessarily. I see this as a good cleanup in any case, to reduce to
just the essential what is shared between GDB and GDBserver.
Change-Id: I3127d27d078f0503ebf5ccc6fddf14f212426a73
|
|
The test gdb.threads/fork-plus-threads.exp fails since 08bdefb58b78
("gdb: make inferior_list use intrusive_list"):
FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: only inferior 1 left
Looking at the log, we see that we are left with a bunch of inferiors in
the detach-on-fork=off case:
info inferiors^M
Num Description Connection Executable ^M
* 1 <null> <snip>/fork-plus-threads ^M
2 <null> <snip>/fork-plus-threads ^M
3 <null> <snip>/fork-plus-threads ^M
4 <null> <snip>/fork-plus-threads ^M
5 <null> <snip>/fork-plus-threads ^M
6 <null> <snip>/fork-plus-threads ^M
7 <null> <snip>/fork-plus-threads ^M
8 <null> <snip>/fork-plus-threads ^M
9 <null> <snip>/fork-plus-threads ^M
10 <null> <snip>/fork-plus-threads ^M
11 <null> <snip>/fork-plus-threads ^M
(gdb) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: only inferior 1 left
when we expect to have just one. The problem is prune_inferiors not
pruning inferiors. And this is caused by all_inferiors_safe not
actually iterating on inferiors. The current implementation:
inline all_inferiors_safe_range
all_inferiors_safe ()
{
return {};
}
default-constructs an all_inferiors_safe_range, which default-constructs
an all_inferiors_safe_iterator as its m_begin field, which
default-constructs a all_inferiors_iterator. A default-constructed
all_inferiors_iterator is an end iterator, which means we have
constructed an (end,end) all_inferiors_safe_range.
We actually need to pass down the list on which we want to iterator
(that is the inferior_list global), so that all_inferiors_iterator's
first constructor is chosen. We also pass nullptr as the proc_target
filter. In this case, we don't do any filtering, but if in the future
all_inferiors_safe needed to allow filtering on process target (like
all_inferiors does), we could pass down a process target pointer.
basic_safe_iterator's constructor needs to be changed to allow
constructing the wrapped iterator with multiple arguments, not just one.
With this, gdb.threads/fork-plus-threads.exp is passing once again for
me.
Change-Id: I650552ede596e3590c4b7606ce403690a0278a01
|
|
status
Looking up threads that are both resumed and have a pending wait
status to report is something that we do quite often in the fast path
and is expensive if there are many threads, since it currently requires
walking whole thread lists.
The first instance is in maybe_set_commit_resumed_all_targets. This is
called after handling each event in fetch_inferior_event, to see if we
should ask targets to commit their resumed threads or not. If at least
one thread is resumed but has a pending wait status, we don't ask the
targets to commit their resumed threads, because we want to consume and
handle the pending wait status first.
The second instance is in random_pending_event_thread, where we want to
select a random thread among all those that are resumed and have a
pending wait status. This is called every time we try to consume
events, to see if there are any pending events that we we want to
consume, before asking the targets for more events.
To allow optimizing these cases, maintain a per-process-target list of
threads that are resumed and have a pending wait status.
In maybe_set_commit_resumed_all_targets, we'll be able to check in O(1)
if there are any such threads simply by checking whether the list is
empty.
In random_pending_event_thread, we'll be able to use that list, which
will be quicker than iterating the list of threads, especially when
there are no resumed with pending wait status threads.
About implementation details: using the new setters on class
thread_info, it's relatively easy to maintain that list. Any time the
"resumed" or "pending wait status" property is changed, we check whether
that should cause the thread to be added or removed from the list.
In set_thread_exited, we try to remove the thread from the list, because
keeping an exited thread in that list would make no sense (especially if
the thread is freed). My first implementation assumed that a process
stratum target was always present when set_thread_exited is called.
That's however, not the case: in some cases, targets unpush themselves
from an inferior and then call "exit_inferior", which exits all the
threads. If the target is unpushed before set_thread_exited is called
on the threads, it means we could mistakenly leave some threads in the
list. I tried to see how hard it would be to make it such that targets
have to exit all threads before unpushing themselves from the inferior
(that would seem logical to me, we don't want threads belonging to an
inferior that has no process target). That seemed quite difficult and
not worth the time at the moment. Instead, I changed
inferior::unpush_target to remove all threads of that inferior from the
list.
As of this patch, the list is not used, this is done in the subsequent
patches.
The debug messages in process-stratum-target.c need to print some ptids.
However, they can't use target_pid_to_str to print them without
introducing a dependency on the current inferior (the current inferior
is used to get the current target stack). For debug messages, I find it
clearer to print the spelled out ptid anyway (the pid, lwp and tid
values). Add a ptid_t::to_string method that returns a string
representation of the ptid that is meant for debug messages, a bit like
we already have frame_id::to_string.
Change-Id: Iad8f93db2d13984dd5aa5867db940ed1169dbb67
|
|
The threads that need a step-over are currently linked using an
hand-written intrusive doubly-linked list, so that seems a very good
candidate for intrusive_list, convert it.
For this, we have a use case of appending a list to another one (in
start_step_over). Based on the std::list and Boost APIs, add a splice
method. However, only support splicing the other list at the end of the
`this` list, since that's all we need.
Add explicit default assignment operators to
reference_to_pointer_iterator, which are otherwise implicitly deleted.
This is needed because to define thread_step_over_list_safe_iterator, we
wrap reference_to_pointer_iterator inside a basic_safe_iterator, and
basic_safe_iterator needs to be able to copy-assign the wrapped
iterator. The move-assignment operator is therefore not needed, only
the copy-assignment operator is. But for completeness, add both.
Change-Id: I31b2ff67c7b78251314646b31887ef1dfebe510c
|
|
GDB currently has several objects that are put in a singly linked list,
by having the object's type have a "next" pointer directly. For
example, struct thread_info and struct inferior. Because these are
simply-linked lists, and we don't keep track of a "tail" pointer, when
we want to append a new element on the list, we need to walk the whole
list to find the current tail. It would be nice to get rid of that
walk. Removing elements from such lists also requires a walk, to find
the "previous" position relative to the element being removed. To
eliminate the need for that walk, we could make those lists
doubly-linked, by adding a "prev" pointer alongside "next". It would be
nice to avoid the boilerplate associated with maintaining such a list
manually, though. That is what the new intrusive_list type addresses.
With an intrusive list, it's also possible to move items out of the
list without destroying them, which is interesting in our case for
example for threads, when we exit them, but can't destroy them
immediately. We currently keep exited threads on the thread list, but
we could change that which would simplify some things.
Note that with std::list, element removal is O(N). I.e., with
std::list, we need to walk the list to find the iterator pointing to
the position to remove. However, we could store a list iterator
inside the object as soon as we put the object in the list, to address
it, because std::list iterators are not invalidated when other
elements are added/removed. However, if you need to put the same
object in more than one list, then std::list<object> doesn't work.
You need to instead use std::list<object *>, which is less efficient
for requiring extra memory allocations. For an example of an object
in multiple lists, see the step_over_next/step_over_prev fields in
thread_info:
/* Step-over chain. A thread is in the step-over queue if these are
non-NULL. If only a single thread is in the chain, then these
fields point to self. */
struct thread_info *step_over_prev = NULL;
struct thread_info *step_over_next = NULL;
The new intrusive_list type gives us the advantages of an intrusive
linked list, while avoiding the boilerplate associated with manually
maintaining it.
intrusive_list's API follows the standard container interface, and thus
std::list's interface. It is based the API of Boost's intrusive list,
here:
https://www.boost.org/doc/libs/1_73_0/doc/html/boost/intrusive/list.html
Our implementation is relatively simple, while Boost's is complicated
and intertwined due to a lot of customization options, which our version
doesn't have.
The easiest way to use an intrusive_list is to make the list's element
type inherit from intrusive_node. This adds a prev/next pointers to
the element type. However, to support putting the same object in more
than one list, intrusive_list supports putting the "node" info as a
field member, so you can have more than one such nodes, one per list.
As a first guinea pig, this patch makes the per-inferior thread list use
intrusive_list using the base class method.
Unlike Boost's implementation, ours is not a circular list. An earlier
version of the patch was circular: the intrusive_list type included an
intrusive_list_node "head". In this design, a node contained pointers
to the previous and next nodes, not the previous and next elements.
This wasn't great for when debugging GDB with GDB, as it was difficult
to get from a pointer to the node to a pointer to the element. With the
design proposed in this patch, nodes contain pointers to the previous
and next elements, making it easy to traverse the list by hand and
inspect each element.
The intrusive_list object contains pointers to the first and last
elements of the list. They are nullptr if the list is empty.
Each element's node contains a pointer to the previous and next
elements. The first element's previous pointer is nullptr and the last
element's next pointer is nullptr. Therefore, if there's a single
element in the list, both its previous and next pointers are nullptr.
To differentiate such an element from an element that is not linked into
a list, the previous and next pointers contain a special value (-1) when
the node is not linked. This is necessary to be able to reliably tell
if a given node is currently linked or not.
A begin() iterator points to the first item in the list. An end()
iterator contains nullptr. This makes iteration until end naturally
work, as advancing past the last element will make the iterator contain
nullptr, making it equal to the end iterator. If the list is empty,
a begin() iterator will contain nullptr from the start, and therefore be
immediately equal to the end.
Iterating on an intrusive_list yields references to objects (e.g.
`thread_info&`). The rest of GDB currently expects iterators and ranges
to yield pointers (e.g. `thread_info*`). To bridge the gap, add the
reference_to_pointer_iterator type. It is used to define
inf_threads_iterator.
Add a Python pretty-printer, to help inspecting intrusive lists when
debugging GDB with GDB. Here's an example of the output:
(top-gdb) p current_inferior_.m_obj.thread_list
$1 = intrusive list of thread_info = {0x61700002c000, 0x617000069080, 0x617000069400, 0x61700006d680, 0x61700006eb80}
It's not possible with current master, but with this patch [1] that I
hope will be merged eventually, it's possible to index the list and
access the pretty-printed value's children:
(top-gdb) p current_inferior_.m_obj.thread_list[1]
$2 = (thread_info *) 0x617000069080
(top-gdb) p current_inferior_.m_obj.thread_list[1].ptid
$3 = {
m_pid = 406499,
m_lwp = 406503,
m_tid = 0
}
Even though iterating the list in C++ yields references, the Python
pretty-printer yields pointers. The reason for this is that the output
of printing the thread list above would be unreadable, IMO, if each
thread_info object was printed in-line, since they contain so much
information. I think it's more useful to print pointers, and let the
user drill down as needed.
[1] https://sourceware.org/pipermail/gdb-patches/2021-April/178050.html
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I3412a14dc77f25876d742dab8f44e0ba7c7586c0
|
|
I was always a bit confused by next_adapter, because it kind of mixes
the element type and the iterator type. In reality, it is not much more
than a class that wraps two iterators (begin and end). However, it
assumes that:
- you can construct the begin iterator by passing a pointer to the
first element of the iterable
- you can default-construct iterator to make the end iterator
I think that by generalizing it a little bit, we can re-use it at more
places.
Rename it to "iterator_range". I think it describes a bit better: it's
a range made by wrapping a begin and end iterator. Move it to its own
file, since it's not related to next_iterator anymore.
iterator_range has two constructors. The variadic one, where arguments
are forwarded to construct the underlying begin iterator. The end
iterator is constructed through default construction. This is a
generalization of what we have today.
There is another constructor which receives already constructed begin
and end iterators, useful if the end iterator can't be obtained by
default-construction. Or, if you wanted to make a range that does not
end at the end of the container, you could pass any iterator as the
"end".
This generalization allows removing some "range" classes, like
all_inferiors_range. These classes existed only to pass some arguments
when constructing the begin iterator. With iterator_range, those same
arguments are passed to the iterator_range constructed and then
forwarded to the constructed begin iterator.
There is a small functional difference in how iterator_range works
compared to next_adapter. next_adapter stored the pointer it received
as argument and constructeur an iterator in the `begin` method.
iterator_range constructs the begin iterator and stores it as a member.
Its `begin` method returns a copy of that iterator.
With just iterator_range, uses of next_adapter<foo> would be replaced
with:
using foo_iterator = next_iterator<foo>;
using foo_range = iterator_range<foo_iterator>;
However, I added a `next_range` wrapper as a direct replacement for
next_adapter<foo>. IMO, next_range is a slightly better name than
next_adapter.
The rest of the changes are applications of this new class.
gdbsupport/ChangeLog:
* next-iterator.h (class next_adapter): Remove.
* iterator-range.h: New.
gdb/ChangeLog:
* breakpoint.h (bp_locations_range): Remove.
(bp_location_range): New.
(struct breakpoint) <locations>: Adjust type.
(breakpoint_range): Use iterator_range.
(tracepoint_range): Use iterator_range.
* breakpoint.c (breakpoint::locations): Adjust return type.
* gdb_bfd.h (gdb_bfd_section_range): Use iterator_range.
* gdbthread.h (all_threads_safe): Pass argument to
all_threads_safe_range.
* inferior-iter.h (all_inferiors_range): Use iterator_range.
(all_inferiors_safe_range): Use iterator_range.
(all_non_exited_inferiors_range): Use iterator_range.
* inferior.h (all_inferiors, all_non_exited_inferiors): Pass
inferior_list as argument.
* objfiles.h (struct objfile) <compunits_range>: Remove.
<compunits>: Return compunit_symtab_range.
* progspace.h (unwrapping_objfile_iterator)
<unwrapping_objfile_iterator>: Take parameter by value.
(unwrapping_objfile_range): Use iterator_range.
(struct program_space) <objfiles_range>: Define with "using".
<objfiles>: Adjust.
<objfiles_safe_range>: Define with "using".
<objfiles_safe>: Adjust.
<solibs>: Return so_list_range, define here.
* progspace.c (program_space::solibs): Remove.
* psymtab.h (class psymtab_storage) <partial_symtab_iterator>:
New.
<partial_symtab_range>: Use iterator_range.
* solist.h (so_list_range): New.
* symtab.h (compunit_symtab_range):
New.
(symtab_range): New.
(compunit_filetabs): Change to a function.
* thread-iter.h (inf_threads_range,
inf_non_exited_threads_range, safe_inf_threads_range,
all_threads_safe_range): Use iterator_range.
* top.h (ui_range): New.
(all_uis): Use ui_range.
Change-Id: Ib7a9d2a3547f45f01aa1c6b24536ba159db9b854
|
|
The macOS platform does not provide sigtimedwait, so we get:
CXX compile/compile.o
In file included from /Users/smarchi/src/binutils-gdb/gdb/compile/compile.c:46:
/Users/smarchi/src/binutils-gdb/gdb/../gdbsupport/scoped_ignore_signal.h:69:4: error: use of undeclared identifier 'sigtimedwait'
sigtimedwait (&set, nullptr, &zero_timeout);
^
An alternative to sigtimedwait with a timeout of 0 is to use sigpending,
to first check which signals are pending, and then sigwait, to consume
them. Since that's slightly more expensive (2 syscalls instead of 1),
keep using sigtimedwait for the platforms that provide it, and fall back
to sigpending + sigwait for the others.
gdbsupport/ChangeLog:
* scoped_ignore_signal.h (struct scoped_ignore_signal)
<~scoped_ignore_signal>: Use sigtimedwait if HAVE_SIGTIMEDWAIT
is defined, else use sigpending + sigwait.
Change-Id: I2a72798337e81dd1bbd21214736a139dd350af87
Co-Authored-By: John Baldwin <jhb@FreeBSD.org>
|
|
The next patch will make the use of sigtimedwait conditional to whether
the platform provides it. Start by adding a configure check for it.
gdbsupport/ChangeLog:
* common.m4 (GDB_AC_COMMON): Check for sigtimedwait.
* config.in, configure: Re-generate.
gdb/ChangeLog:
* config.in, configure: Re-generate.
gdbserver/ChangeLog:
* config.in, configure: Re-generate.
Change-Id: Ic7613fe14521b966b4d991bbcd0933ab14629c05
|
|
Because SIGTTOU is sent to the whole process instead of to a specific
thread, consuming a pending SIGTTOU in the destructor of
scoped_ignore_sigttou could consume a SIGTTOU signal raised due to
actions done by some other thread. Simply avoid sigtimedwait in
scoped_ignore_sigttou, thus plugging the race. This works because we
know that when the thread writes to the terminal and the signal is
blocked, the kernel does not raise the signal at all.
Tested on GNU/Linux, Solaris 11 and FreeBSD.
gdb/ChangeLog:
yyyy-mm-dd Pedro Alves <pedro@palves.net>
* scoped_ignore_signal.h (scoped_ignore_signal): Add
ConsumePending template parameter.
(scoped_ignore_signal::~scoped_ignore_signal): Skip calling
sigtimedwait if ConsumePending is false.
(scoped_ignore_sigpipe): Initialize with ConsumePending=true.
* scoped_ignore_sigttou.h (scoped_ignore_sigttou)
<m_ignore_signal>: Initialize with ConsumePending=false.
Change-Id: I92f754dbc45c45819dce2ce68b8c067d8d5c61b1
|
|
The problem with using signal(...) to temporarily ignore a signal, is
that that changes the the signal disposition for the whole process.
If multiple threads do it at the same time, you have a race.
Fix this by using sigprocmask + sigtimedwait to implement the ignoring
instead, if available, which I think probably means everywhere except
Windows nowadays. This way, we only change the signal mask for the
current thread, so there's no race.
Change-Id: Idfe3fb08327ef8cae926f3de9ee81c56a83b1738
gdbsupport/ChangeLog:
yyyy-mm-dd Pedro Alves <pedro@palves.net>
* scoped_ignore_signal.h
(scoped_ignore_signal::scoped_ignore_signal)
[HAVE_SIGPROCMASK]: Use sigprocmask to block the signal instead of
changing the signal disposition for the whole process.
(scoped_ignore_signal::~scoped_ignore_signal) [HAVE_SIGPROCMASK]:
Use sigtimedwait and sigprocmask to flush and unblock the signal.
|
