Latest libc++[1] causes transitive include to <locale> when
<mutex> or <thread> header is included. This causes
gdb to not build[2] since <locale> defines isupper/islower etc.
functions that are explicitly macroed-out in safe-ctype.h to
prevent their use.
Use the suggestion from libc++ to include <locale> internally when
building in C++ mode to avoid build errors.
Use safe-gdb-ctype.h as the include instead of "safe-ctype.h"
to keep this isolated to gdb since rest of binutils
does not seem to use much C++.

[1]: https://reviews.llvm.org/D144331
[2]: https://issuetracker.google.com/issues/277967395

It was pointed out during review of another patch that the function
displaced_step_dump_bytes really isn't specific to displaced stepping,
and should really get a more generic name and move into gdbsupport/.

This commit does just that.  The function is renamed to
bytes_to_string and is moved into gdbsupport/common-utils.{cc,h}.  The
function implementation doesn't really change. Much...

... I have updated the function to take an array view, which makes it
slightly easier to call in a couple of places where we already have a
gdb::bytes_vector.  I've then added an inline wrapper to convert a raw
pointer and length into an array view, which is used in places where
we don't easily have a gdb::bytes_vector (or similar).

Updated all users of displaced_step_dump_bytes.

There should be no user visible changes after this commit.

Finally, I ended up having to add an include of gdb_assert.h into
array-view.h.  When I include array-view.h into common-utils.h I ran
into build problems because array-view.h calls gdb_assert.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Replace spaces with tabs in a bunch of places.

Change-Id: If0f87180f1d13028dc178e5a8af7882a067868b0

When building with clang 16, we get:

      CXX    gdb.o
    In file included from /home/smarchi/src/binutils-gdb/gdb/gdb.c:19:
    In file included from /home/smarchi/src/binutils-gdb/gdb/defs.h:65:
    /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/enum-flags.h:95:52: error: integer value -1 is outside the valid range of values [0, 15] for this enumeration type [-Wenum-constexpr-conversion]
        integer_for_size<sizeof (T), static_cast<bool>(T (-1) < T (0))>::type
                                                       ^

The error message does not make it clear in the context of which enum
flag this fails (i.e. what is T in this context), but it doesn't really
matter, we have similar warning/errors for many of them, if we let the
build go through.

clang is right that the value -1 is invalid for the enum type we cast -1
to.  However, we do need this expression in order to select an integer
type with the appropriate signedness.  That is, with the same signedness
as the underlying type of the enum.

I first wondered if that was really needed, if we couldn't use
std::underlying_type for that.  It turns out that the comment just above
says:

    /* Note that std::underlying_type<enum_type> is not what we want here,
       since that returns unsigned int even when the enum decays to signed
       int.  */

I was surprised, because std::is_signed<std::underlying_type<enum_type>>
returns the right thing.  So I tried replacing all this with
std::underlying_type, see if that would work.  Doing so causes some
build failures in unittests/enum-flags-selftests.c:

      CXX    unittests/enum-flags-selftests.o
    /home/smarchi/src/binutils-gdb/gdb/unittests/enum-flags-selftests.c:254:1: error: static assertion failed due to requirement 'gdb::is_same<selftests::enum_flags_tests::check_valid_expr254::archetype<enum_flags<s
    elftests::enum_flags_tests::RE>, selftests::enum_flags_tests::RE, enum_flags<selftests::enum_flags_tests::RE2>, selftests::enum_flags_tests::RE2, enum_flags<selftests::enum_flags_tests::URE>, selftests::enum_fla
    gs_tests::URE, int>, selftests::enum_flags_tests::check_valid_expr254::archetype<enum_flags<selftests::enum_flags_tests::RE>, selftests::enum_flags_tests::RE, enum_flags<selftests::enum_flags_tests::RE2>, selfte
    sts::enum_flags_tests::RE2, enum_flags<selftests::enum_flags_tests::URE>, selftests::enum_flags_tests::URE, unsigned int>>::value == true':
    CHECK_VALID (true,  int,  true ? EF () : EF2 ())
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    /home/smarchi/src/binutils-gdb/gdb/unittests/enum-flags-selftests.c:91:3: note: expanded from macro 'CHECK_VALID'
      CHECK_VALID_EXPR_6 (EF, RE, EF2, RE2, UEF, URE, VALID, EXPR_TYPE, EXPR)
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/valid-expr.h:105:3: note: expanded from macro 'CHECK_VALID_EXPR_6'
      CHECK_VALID_EXPR_INT (ESC_PARENS (typename T1, typename T2,           \
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/valid-expr.h:66:3: note: expanded from macro 'CHECK_VALID_EXPR_INT'
      static_assert (gdb::is_detected_exact<archetype<TYPES, EXPR_TYPE>,    \
      ^              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is a bit hard to decode, but basically enumerations have the
following funny property that they decay into a signed int, even if
their implicit underlying type is unsigned.  This code:

    enum A {};
    enum B {};

    int main() {
      std::cout << std::is_signed<std::underlying_type<A>::type>::value
                << std::endl;
      std::cout << std::is_signed<std::underlying_type<B>::type>::value
                << std::endl;
      auto result = true ? A() : B();
      std::cout << std::is_signed<decltype(result)>::value << std::endl;
    }

produces:

    0
    0
    1

So, the "CHECK_VALID" above checks that this property works for enum flags the
same way as it would if you were using their underlying enum types.  And
somehow, changing integer_for_size to use std::underlying_type breaks that.

Since the current code does what we want, and I don't see any way of doing it
differently, ignore -Wenum-constexpr-conversion around it.

Change-Id: Ibc82ae7bbdb812102ae3f1dd099fc859dc6f3cc2

This commit adds a new exception 'gdb_exception_forced_quit', reason
code 'REASON_FORCED_QUIT', return mask 'RETURN_MASK_FORCED_QUIT', and
a wrapper for throwing the exception, throw_forced_quit().

The addition of this exception plus supporting code will allow us to
recognize that a SIGTERM has been received by GDB and then propagate
recognition of that fact to the upper levels of GDB where it can be
correctly handled.  At the moment, when GDB receives a SIGTERM, it
will attempt to exit via a series of calls from the QUIT checking
code.  However, before it can exit, it must do various cleanups, such
as killing or detaching all inferiors.  Should these cleanups be
attempted while GDB is executing very low level code, such as reading
target memory from within ps_xfer_memory(), it can happen that some of
GDB's state is out of sync with regard to the cleanup code's
expectations.  In the case just mentioned, it's been observed that
inferior_ptid and the current_thread_ are not in sync; this triggers
an assert / internal error.

This commit only introduces the exception plus supporting machinery;
changes which use this new exception are in later commits in this
series.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761
Tested-by: Tom de Vries <tdevries@suse.de>
Approved-by: Pedro Alves <pedro@palves.net>

I've long wanted to remove 'struct buffer', and thanks to Simon's
earlier patch, I was finally able to do so.  My feeling has been that
gdb already has several decent structures available for growing
strings: std::string of course, but also obstack and even objalloc
from BFD and dyn-string from libiberty.  The previous patches in this
series removed all the uses of struct buffer, so this one can remove
the code and the remaining #includes.

While investigating something else, I noticed some weird code in
agent_run_command (use of memcpy rather than strcpy).  Then I noticed
that 'cmd' is used as both an in and out parameter, despite being
const.

Casting away const like this is bad.  This patch removes the const and
fixes the memcpy.  I also added a static assert to assure myself that
the code in gdbserver is correct -- gdbserver is passing its own
buffer directly to agent_run_command.

Reviewed-By: Andrew Burgess <aburgess@redhat.com>

gdbsupport/errors.h declares perror_with_name and leaves the
implementation to the clients.

However gdb and gdbserver's implementations are essentially the
same, resulting in unnecessary code duplication.

Fix this by implementing perror_with_name in gdbsupport.  Add an
optional parameter for specifying the errno used to generate the
error message.

Also move the implementation of perror_string to gdbsupport since
perror_with_name requires it.

Approved-By: Tom Tromey <tom@tromey.com>

Use <climits> instead of <limits.h> and ditch local fallback definitions
for minimum and maximum value macros provided by C++11.  Add LONGEST_MAX
and LONGEST_MIN definitions.

Approved-By: Tom Tromey <tom@tromey.com>

In PR gdb/29854, Simon pointed out that it would be good to be able to
use C-c when the DWARF cooked index is waiting for finalization.  The
idea here is to be able to interrupt a command like "break" -- not to
stop the finalization process itself, which runs in a worker thread.

This patch implements this idea, by changing the index wait functions
to, by default, allow a quit.  Polling is done, because there doesn't
seem to be a better way to interrupt a wait on a std::future.

For v2, I realized that the thread compatibility code in thread-pool.h
also needed an update.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29854