gdb: use gdb_tilde_expand instead of gdb_tilde_expand_up in source_script_with_search

Since this is the latest use of gdb_tilde_expand_up, remove it.

Change-Id: I964c812ce55fe087876abf91e7a3577ad79c0425

gdbsupport: make gdb_realpath_keepfile return an std::string

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

gdbsupport: make gdb_abspath return an std::string

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

gdb: call gdb_tilde_expand instead of gdb_tilde_expand_up in source_script_with_search

This removes a use of gdb_tilde_expand_up, which is removed later in
this series.

Change-Id: I5887d526cea987103e4ca24514a982b0a28e992a

Update gnulib

This updates gnulib to a relatively recent commit.  Most of this was
done by the gnulib import script; the only change I made was to
update-gnulib.sh.

Tested on x86-64 Fedora 34.  I also did a mingw cross build.

Fix C++ cast of derived class to base class

PR c++/28907 points out that casting from a derived class to a base
class fails in some situations.  The problem turned out to be a
missing use of value_embedded_offset.  One peculiarity here is that,
if you managed to construct a pointer-to-derived with an embedded
offset of 0, the cast would work -- for example, one of the two new
tests here passes without the patch.

This embedded offset stuff is an endless source of bugs.  I wonder if
it's possible to get rid of it somehow.

Regression tested on x86-64 Fedora 34.

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

gdb/testsuite: make gdb.ada/mi_prot.exp stop at expected location

This test attempts to run until the line marked "STOP", which is at
prot.adb:34.  It first runs until the "main" symbol, then tries to place
a breakpoint by line at line 34, without specifying the source file.  When looking at the logs:

    -break-insert -t 34^M
    ^done,bkpt={number="2",type="breakpoint",disp="del",enabled="y",addr="0x0000555555558a6c",func="adafinal",file="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_pro    t/b~prot.adb",fullname="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_prot/b~prot.adb",line="44",thread-groups=["i1"],times="0",original-location="/home/simark/b    uild/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_prot/b~prot.adb:34"}^M
    ... continues ...
     *stopped,reason="breakpoint-hit",disp="del",bkptno="2",frame={addr="0x0000555555558a6c",func="adafinal",args=[],file="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/    mi_prot/b~prot.adb",fullname="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_prot/b~prot.adb",line="44",arch="i386:x86-64"},thread-id="1",stopped-threads="all",co    re="8"^M

... we see that the breakpoint is placed in some generated file, not in
the test source file as we expect.  The problem is that "b main" in Ada
does not place a breakpoint on the "Ada main", but on some symbol in a
generated source file.  So when stopped at the "main" symbol, we are not
stopped in the file that contains the STOP marker at line 34.

The test passes anyway today, so it doesn't seem to matter that we are
stopped at an unexpected location.  But it starts failing with this
patch [1], because b~prot.adb:34 happens to be between two functions, so
the breakpoint doesn't resolve.

Fix this by placing the breakpoint at "$srcfile:$line", which works
regardless of what is the current source file.

However, this ends up introducing a path in the test name.  Modify
mi_tbreak and mi_continue_to_line to avoid that.

[1] https://sourceware.org/pipermail/gdb-patches/2022-April/187686.html

Change-Id: I742e2a9993046dcb5e30c64fe2ad920a363baf75

gdb/testsuite: add text_segment option to gdb_compile

LLVM's lld linker doesn't have the "-Ttext-segment" option, but
"--image-base" can be used instead.

To centralize the logic of checking which option is supported, add the
text_segment option to gdb_compile.  Change tests that are currently
using -Ttext-segment to use that new option instead.

This patch fixes only compilation error, for example:

Before:

    $ make check TESTS="gdb.base/jit-elf.exp" RUNTESTFLAGS="CC_FOR_TARGET=clang LDFLAGS_FOR_TARGET=-fuse-ld=ld"
    Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-elf.exp ...
    gdb compile failed, clang-13: warning: -Xlinker -Ttext-segment=0x7000000: 'linker' input unused [-Wunused-command-line-argument]

After:

    $ make check TESTS="gdb.base/jit-elf.exp" RUNTESTFLAGS="CC_FOR_TARGET=clang LDFLAGS_FOR_TARGET=-fuse-ld=ld"
    Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-elf.exp ...
    FAIL: gdb.base/jit-elf.exp: one_jit_test-1: continue to breakpoint: break here 1
    FAIL: gdb.base/jit-elf.exp: one_jit_test-1: continue to breakpoint: break here 2
    FAIL: gdb.base/jit-elf.exp: one_jit_test-2: continue to breakpoint: break here 1
    FAIL: gdb.base/jit-elf.exp: one_jit_test-2: info function ^jit_function
    FAIL: gdb.base/jit-elf.exp: one_jit_test-2: continue to breakpoint: break here 2
    FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: continue to breakpoint: break here 1
    FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach
    FAIL: gdb.base/jit-elf.exp: PIE: one_jit_test-1: continue to breakpoint: break here 1
    FAIL: gdb.base/jit-elf.exp: PIE: one_jit_test-1: continue to breakpoint: break here 2

                    === gdb Summary ===

    # of expected passes            26
    # of unexpected failures        9

Change-Id: I3678c5c9bbfc2f80671698e28a038e6b3d14e635

gdb: fix using clear command to delete non-user breakpoints(PR cli/7161)

The clear command shouldn't delete momentary and internal breakpoints,
nor internal breakpoints created via Python's gdb.Breakpoint.

This patch fixes this issue and adds a testcase.

Regression tested on x86_64 openSUSE Tumbleweed(VERSION_ID="20220413").

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

Automatic date update in version.in

Automatic date update in version.in

Add comments to dwarf2/abbrev-cache.h

This patch started when I noticed that the unordered_set include
wasn't needed in abbrev-cache.h.  (That was probably leftover from
some earlier implementation of the class.)  Then, I noticed that the
class itself was under-commented.  This patch fixes both issues.

Automatic date update in version.in

Return void from gdb_putc

I don't think it's very useful to return the character from gdb_putc,
so this patch changes it to return void.

Handle "set height 1"

PR cli/17151 points out that "set height 1" has pathological behavior
in gdb.  What I see is that gdb will endlessly print the pagination
prompt.  This patch takes a simple and expedient approach to a fix:
pretend that the height is really 2.

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

Allow word wrapping even when paging is disabled

PR cli/20741 points out that when pagination is disabled, this also
disabled word wrapping.  However, the manual documents that these
settings are separate -- if you intend to disable the wrapping, you
must use "set width unlimited".

This patch fixes the bug by letting the pagination-disabled case fall
through to the code that also handles word-wrapping.

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

Implement value_print for Rust

This adds an implementation of the value_print method to Rust.  As
described in PR rust/22254, this removes a bit of weird-looking output
from some "print"s -- because c_value_print is bypassed.  I don't have
a test for the bug that inspired this patch, because I only know how
to reproduce it when using a relatively old Rust compiler.  However,
the new "cast-printing" code in value_print is required, because
omitting this causes some existing tests to fail.

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

Reimplement Rust slice printing

The current nightly Rust compiler (aka 1.61) added better DWARF
representation for unsized types.  Fixing this is PR rust/21466; but
the code is actually the same as what is required to make slice
printing more useful, which is PR rust/23871.  This patch implements
this.  I tested this against various Rust compilers: 1.48, current
stable, current beta, and current nightly.

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

Remove some dead code from the Rust value printer

This removes a bit of dead code from the Rust value printer.  This
code wasn't always dead -- it fixed a real bug, and a test case was
added for it.  However, once val_print was removed, it became
unnecessary.

Match rustc beta versions

The rust_compiler_version proc extracts the Rust compiler version from
the "rustc --version" output.  For a beta compiler, the output looks
like:

    rustc 1.60.0-beta.6 (7bccde197 2022-03-22)

This patch slightly relaxes the regexp -- removing a space -- so that
this can be understood by this proc.

[gdb/testsuite] Fix gdb.ada/float-bits.exp with -m32

With test-case gdb.ada/float-bits.exp and native we get:
...
(gdb) print 16llf#7FFFF7FF4054A56FA5B99019A5C8#^M
$9 = 5.0e+25^M
(gdb) PASS: gdb.ada/float-bits.exp: print 16llf#7FFFF7FF4054A56FA5B99019A5C8#
...
but with target board unix/-m32 we have instead:
...
(gdb) print 16llf#7FFFF7FF4054A56FA5B99019A5C8#^M
Cannot export value 2596145952482202326224873165792712 as 96-bits \
  unsigned integer (must be between 0 and 79228162514264337593543950335)^M
(gdb) FAIL: gdb.ada/float-bits.exp: print 16llf#7FFFF7FF4054A56FA5B99019A5C8#
...

Fix this by testing whether 16llf is supported by doing ptype long_long_float
which gets us either:
...
type = <16-byte float>^M
...
or:
...
type = <12-byte float>^M
...

Tested on x86_64-linux with native and unix/-m32.

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

Remove WITH_SIM define

Since score-tdep.c was removed, the WITH_SIM define is not used in
gdb.  This patch removes it.

Note that re-running autoheader shows a separate change that was
missed.  I've kept it in this patch to avoid extra work.

[gdb/testsuite] Fix gdb.go/methods.exp with check-readmore

When running test-case gdb.go/methods.exp with make check we have:
...
(gdb) break main.T.Foo^M
Function "main.T.Foo" not defined.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) XFAIL: gdb.go/methods.exp: gdb_breakpoint: set breakpoint at main.T.Foo
...
but with make check-readmore the XFAIL fails to trigger:
...
(gdb) break main.T.Foo^M
Function "main.T.Foo" not defined.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: gdb.go/methods.exp: gdb_breakpoint: set breakpoint at main.T.Foo
...

This happens because this gdb_test_multiple "maintenance print symbols"
regexp:
...
    -re "\r\n$gdb_prompt $" {
...
matches the entire command output.

Fix this by adding the missing ^ at the regexp start.

Tested on x86_64-linux.

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

Automatic date update in version.in

gdbserver: Eliminate prepare_to_access_memory

Given:

 - The prepare_to_access_memory machinery was added for non-stop mode.

 - Only Linux supports non-stop.

 - Linux no longer needs the prepare_to_access_memory machinery.  In
   fact, after the previous patch,
   linux_process_target::prepare_to_access_memory became a nop.

Thus, prepare_to_access_memory can go away, simplifying core GDBserver
code.

Change-Id: I93ac8bfe66bd61c3d1c4a0e7d419335163120ecf

gdbserver/linux: Access memory even if threads are running

Similarly to how the native Linux target was changed
and subsequently reworked in these commits:

 05c06f318fd9 Linux: Access memory even if threads are running
 8a89ddbda2ec Avoid /proc/pid/mem races (PR 28065)

... teach GDBserver to access memory even when the current thread is
running, by always accessing memory via /proc/PID/mem.

The existing comment:

  /* Neither ptrace nor /proc/PID/mem allow accessing memory through a
     running LWP.  */

... is incorrect for /proc/PID/mem does allow that.

Actually, from GDB's perspective, GDBserver could already access
memory while threads were running, but at the expense of pausing all
threads for the duration of the memory access, via
prepare_to_access_memory.  This new implementation does not require
pausing any thread, thus
linux_process_target::prepare_to_access_memory /
linux_process_target::done_accessing_memory become nops.  A subsequent
patch will remove the whole prepare_to_access_memory infrastructure
completely.

The GDBserver linux-low.cc implementation is simpler than GDB's
linux-nat.c's, because GDBserver always adds the unfollowed vfork/fork
children to the process list immediately when the fork/vfork event is
seen out of ptrace.  I.e., there's no need to keep the file descriptor
stored on a side map, we can store it directly in the process
structure.

Change-Id: I0abfd782ceaa4ddce8d3e5f3e2dfc5928862ef61

gdbserver: special case target_write_memory len==0

The next patch in this series adds a common helper routine for both
memory reads and writes, like this:

 static int
 proc_xfer_memory (CORE_ADDR memaddr, unsigned char *readbuf,
  const gdb_byte *writebuf, int len)
 {
   gdb_assert ((readbuf == nullptr) != (writebuf == nullptr));
   ...
 }

 int
 linux_process_target::read_memory (CORE_ADDR memaddr,
                                    unsigned char *myaddr, int len)
 {
   return proc_xfer_memory (memaddr, myaddr, nullptr, len);
 }

 linux_process_target::write_memory (CORE_ADDR memaddr,
                                    const unsigned char *myaddr, int len)
 {
   return proc_xfer_memory (memaddr, nullptr, myaddr, len);
 }

Surprisingly, the assertion fails.  That happens because it can happen
that target_write_memory is called with LEN==0, due to this in
gdb/remote.c:

 /* Determine whether the remote target supports binary downloading.
    This is accomplished by sending a no-op memory write of zero length
    to the target at the specified address. (...) */

 void
 remote_target::check_binary_download (CORE_ADDR addr)
 {
 ...
       p = rs->buf.data ();
       *p++ = 'X';
       p += hexnumstr (p, (ULONGEST) addr);
       *p++ = ',';
       p += hexnumstr (p, (ULONGEST) 0);
       *p++ = ':';
       *p = '\0';

In this scenario, in gdbserver's target_write_memory, the "myaddr"
argument of the_target->write_memory is passed the data() of a local
gdb::byte_vector (which is a specialized std::vector).  It's valid for
std::vector::data() to return NULL when the vector is empty.

This commit adds an early return to target_write_memory to avoid
target backends having to care about this.  For good measure, do the
same on the read side, in read_inferior_memory.

Change-Id: Iac8f04fcf99014c624ef4036bd318ca1771ad491

gdbserver/qXfer::threads, prepare_to_access_memory=>target_pause_all

handle_qxfer_threads_proper needs to pause all threads even if the
target can read memory when threads are running, so use
target_pause_all instead, which is what the Linux implementation of
prepare_to_access_memory uses.  (Only Linux implements this hook.)

A following patch will make the Linux backend be able to access memory
when threads are running, and thus will also make
prepare_to_access_memory do nothing, which would cause testsuite
regressions without this change.

Change-Id: I127fec7246b7c45b60dfa7341e781606bf54b5da

Ignore 0,0 entries in .debug_aranges

When running the internal AdaCore test suite against the new DWARF
indexer, I found one regression on RISC-V.  The test in question uses
--gc-sections, and winds up with an entry in the middle of a
.debug_aranges that has both address and length of 0.  In this
scenario, gdb assumes the entries are terminated and then proceeds to
reject the section because it reads a subsequent entry as if it were a
header.

It seems to me that, because each header describes the size of each
.debug_aranges CU, it's better to simply ignore 0,0 entries and simply
read to the end.  That is what this patch does.

I've patched an existing test to provide a regression test for this.

Use GetThreadDescription on Windows

Windows 10 introduced SetThreadDescription and GetThreadDescription, a
simpler way to set a thread's name.  This changes gdb and gdbserver to
use this convention when it is available.

This is part of PR win32/29050.

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

Set the worker thread name on Windows

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

Implement thread_name for gdbserver

This changes gdbserver to implement thread_name method.

Share handle_ms_vc_exception with gdbserver

Currently, gdb's native Windows target implements the exception-based
approach for setting thread names, but gdbserver does not.  This patch
moves handle_ms_vc_exception to the shared nat/windows-nat.c code, as
preparation for adding this support to gdbserver.

Move target_read_string to target/target.c

This moves the two overloads of target_read_string to a new file,
target/target.c, and updates both gdb and gdbserver to build this.

Remove the byte order parameter to target_read_string

target_read_string takes a byte order parameter, but only uses this to
check whether a given character is zero.  This is readily done without
requiring the parameter, so remove it.

Rename read_string

This renames read_string to be an overload of target_read_string.
This makes it more consistent for the eventual merger with gdbserver.

Don't call QUIT in read_string

read_string does not need to call QUIT, because target_read_memory
already does.  This change is needed to make string-reading usable by
gdbserver.

Fix possible Cygwin build problem

I noticed that nat/windows-nat.c checks __USEWIDE, but nothing sets it
there -- I forgot to copy over the definition when making this file.
This patch tries to fix the problem.  I don't have a Cygwin setup, so
I don't know whether this is sufficient, but it's probably necessary.

gdb/testsuite: Fix race in gdb.dwarf2/calling-convention.exp

Pedro Alves warned me that there is a race in
gdb.dwarf2/calling-convention.exp making the test sometimes fail on his
setup.  This can be reliably reproduced using :

    make check-read1 TESTS="gdb.dwarf2/calling-convention.exp"

The relevant part of the gdb.log file is:

    return 35
    Function 'foo' does not follow the target calling convention.
    If you continue, setting the return value will probably lead to unpredictable behaviors.
    Make foo return now? (y or n) PASS: gdb.dwarf2/calling-convention.exp: return 35
    n
    Not confirmed
    (gdb) FAIL: gdb.dwarf2/calling-convention.exp: finish

The issue is that when doing the test for "return 35", the DejaGnu test
sends "n" (to tell GDB not to perform the return action) but never
consumes the "Not confirmed" acknowledgment sent by GDB.  Later, when
trying to do the next test, DejaGnu tries to match the leftover output
from the "return" test. As this output is not expected, the test fails.

Fix by using gdb_test to send the "n" answer and match the confirmation
and consume all output to the prompt.

Also do minor adjustments to the main regex:
  - Remove the leading ".*" which is not required.
  - Ensure that the "?" from the question is properly escaped.

Tested on x86_64-gnu-linux, using

- make check TESTS="gdb.dwarf2/calling-convention.exp"
- make check-read1 TESTS="gdb.dwarf2/calling-convention.exp"
- make check-readmore TESTS="gdb.dwarf2/calling-convention.exp"

Co-authored-by: Pedro Alves <pedro@palves.net>
Change-Id: I42858b13db2cbd623c5c1739de65ad423e0c0938

Silence -Wmaybe-uninitialized warning from target_waitstatus

Currently, one use of target_waitstatus yields a warning:

     target/waitstatus.h: In function 'void stop_all_threads()':
     target/waitstatus.h:175:13: warning: 'ws.target_waitstatus::m_value' may be used uninitialized in this function [-Wmaybe-uninitialized]
       175 |     m_value = other.m_value;
   |     ~~~~~~~~^~~~~~~~~~~~~~~

This patch silences the warning.  I tried the "volatile member"
approach that was used for gdb::optional, but that didn't work, so
this patch simply initializes the member.

Fix regression on Windows with WOW64

Internally at AdaCore, we recently started testing a 64-bit gdb
debugging 32-bit processes.  This failed with gdb head, but not with
gdb 11.

The tests fail like this:

     Starting program: [...].exe
     warning: Could not load shared library symbols for WOW64_IMAGE_SECTION.
     Do you need "set solib-search-path" or "set sysroot"?
     warning: Could not load shared library symbols for WOW64_IMAGE_SECTION.
     Do you need "set solib-search-path" or "set sysroot"?
     warning: Could not load shared library symbols for NOT_AN_IMAGE.
     Do you need "set solib-search-path" or "set sysroot"?
     warning: Could not load shared library symbols for NOT_AN_IMAGE.
     Do you need "set solib-search-path" or "set sysroot"?

After some debugging and bisecting, to my surprise the bug was
introduced by commit 183be222 ("gdb, gdbserver: make target_waitstatus
safe").

The problem occurs in handle_exception.  Previously the code did:

    -  ourstatus->kind = TARGET_WAITKIND_STOPPED;
    [...]
 case EXCEPTION_BREAKPOINT:
    [...]
    -   ourstatus->kind = TARGET_WAITKIND_SPURIOUS;
    [...]
   /* FALLTHROUGH */
 case STATUS_WX86_BREAKPOINT:
   DEBUG_EXCEPTION_SIMPLE ("EXCEPTION_BREAKPOINT");
    -      ourstatus->value.sig = GDB_SIGNAL_TRAP;
    [...]
    -  last_sig = ourstatus->value.sig;

However, in the new code, the fallthrough case does:

    +      ourstatus->set_stopped (GDB_SIGNAL_TRAP);

... which changes the 'kind' in 'ourstatus' after falling through.

This patch rearranges the 'last_sig' setting to more closely match
what was done before (this is probably not strictly needed but also
seemed harmless), and removes the fall-through in the
'ignore_first_breakpoint' case when __x86_64__ is defined.

Reorganize Python events documentation

This slightly reorganizes the Python events documentation.  It hoists
the "ThreadEvent" text out of the list of events, where it seemed to
be misplaced.  It tidies the formatting a little bit (adding some
vertical space for easier reading in info), fixes a typo, adds some
missing commas, and fixes an incorrect reference to NewInferiorEvent.

gdb: remove move constructor and move assignment operator from cooked_index

Building with clang++-14, I see:

      CXX    dwarf2/cooked-index.o
    In file included from /home/smarchi/src/binutils-gdb/gdb/dwarf2/cooked-index.c:21:
    /home/smarchi/src/binutils-gdb/gdb/dwarf2/cooked-index.h:172:12: error: explicitly defaulted move constructor is implicitly deleted [-Werror,-Wdefaulted-function-deleted]
      explicit cooked_index (cooked_index &&other) = default;
               ^
    /home/smarchi/src/binutils-gdb/gdb/dwarf2/cooked-index.h:225:16: note: move constructor of 'cooked_index' is implicitly deleted because field 'm_storage' has a deleted move constructor
      auto_obstack m_storage;
                   ^
    /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/gdb_obstack.h:128:28: note: 'auto_obstack' has been explicitly marked deleted here
      DISABLE_COPY_AND_ASSIGN (auto_obstack);
                               ^
    In file included from /home/smarchi/src/binutils-gdb/gdb/dwarf2/cooked-index.c:21:
    /home/smarchi/src/binutils-gdb/gdb/dwarf2/cooked-index.h:174:17: error: explicitly defaulted move assignment operator is implicitly deleted [-Werror,-Wdefaulted-function-deleted]
      cooked_index &operator= (cooked_index &&other) = default;
                    ^
    /home/smarchi/src/binutils-gdb/gdb/dwarf2/cooked-index.h:225:16: note: move assignment operator of 'cooked_index' is implicitly deleted because field 'm_storage' has a deleted move assignment operator
      auto_obstack m_storage;
                   ^
    /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/gdb_obstack.h:128:3: note: 'operator=' has been explicitly marked deleted here
      DISABLE_COPY_AND_ASSIGN (auto_obstack);
      ^
    /home/smarchi/src/binutils-gdb/gdb/../include/ansidecl.h:425:8: note: expanded from macro 'DISABLE_COPY_AND_ASSIGN'
      void operator= (const TYPE &) = delete
           ^

We explicitly make cooked_index have a default move constructor and
move assignment operator.  But it doesn't actually happen because
cooked_index has a field of type auto_obstack, which isn't movable.
We don't actually need cooked_index to be movable at the moment, so
remove those lines.

Change-Id: Ifc1fe3d7d67e3ae1a14363d6c1869936fe80b0a2

Let std::thread check pass even without pthreads

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.

gdb: fix build errors in gdbsupport/thread-pool.h used with old gcc

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>

[gdb/testsuite] Detect 'No MPX support'

On openSUSE Leap 15.3, mpx support has been disabled for m32, so I run into:
...
(gdb) run ^M
Starting program: outputs/gdb.arch/i386-mpx/i386-mpx ^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
No MPX support^M
...
and eventually into all sort of fails in this and other mpx test-cases.

Fix this by detecting the "No MPX support" message in have_mpx.

Tested on x86_64-linux with target boards unix and unix/-m32.

M68K: avoid quadratic slowdlow in label alignment check

Before the change tc-m68k maintained a list of seen labels.
Alignment check traversed label list to resolve symbol to label.
This caused quadratic slowdown as each symbol was checked against
each label. Worst affected files are the ones built with debugging
enabled as DWARF generates many labels.

The change embeds auxiliary label information right into symbol using
TC_SYMFIELD_TYPE.

Before the change test from PR 29058 did not finish in 10 minutes. After
the change it finishes in 2 seconds.

gas/ChangeLog:

PR 29058
* config/tc-m68k.h (TC_SYMFIELD_TYPE): define as m68k_tc_sy.
* config/tc-m68k.c (m68k_frob_label): Use TC_SYMFIELD_TYPE to
store label information.

ld:LoongArch: Fix glibc fail: tst-audit25a/b.

  bfd/

  * elfnn-loongarch.c: Add new func elf_loongarch64_hash_symbol.

Automatic date update in version.in

gdb: add ATTRIBUTE_PRINTF to complaint_interceptor::issue_complaint

Fix this error when building with clang++-14:

      CXX    complaints.o
    /home/smarchi/src/binutils-gdb/gdb/complaints.c:130:65: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
      g_complaint_interceptor->m_complaints.insert (string_vprintf (fmt, args));
                                                                    ^~~

Change-Id: I0ef11f970510eb8638d1651fa0d5eeecd6a9d31a

gdb: fix clang build failure in msymbol_is_mips

Building with clang++-14, I see:

      CXX    mips-tdep.o
    /home/smarchi/src/binutils-gdb/gdb/mips-tdep.c:453:12: error: use of bitwise '|' with boolean operands [-Werror,-Wbitwise-instead-of-logical]
      return !(MSYMBOL_TARGET_FLAG_MIPS16 (msym)
              ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    /home/smarchi/src/binutils-gdb/gdb/mips-tdep.h:54:2: note: expanded from macro 'MSYMBOL_TARGET_FLAG_MIPS16'
            (sym)->target_flag_1 ()
            ^
    /home/smarchi/src/binutils-gdb/gdb/mips-tdep.c:453:12: note: cast one or both operands to int to silence this warning
    /home/smarchi/src/binutils-gdb/gdb/mips-tdep.h:54:2: note: expanded from macro 'MSYMBOL_TARGET_FLAG_MIPS16'
            (sym)->target_flag_1 ()
            ^

That's since commit e165fcef1e7 ("gdb: remove MSYMBOL_TARGET_FLAG_{1,2}
macros").  Fix this by using the boolean || rather than the bitwise |,
since the new methods return bool values.  No change in behavior
expected.

Change-Id: Ia82664135aa25db64c29c92f5c1141859d345bf7

binutils: enable PE on 32bit haiku build

* config.bfd (x86-haiku): Add i386_pei_vec as a selectable format.

Make intrusive_list_node's next/prev private

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

Tidy gdb.base/parse_number.exp

Now that Ada is able to parse & print 0xffffffffffffffff (2^64-1) in
hex, move it to the else branch like most other languages.

Change-Id: Ib305f6bb2b6b230a1190ea783b245b865821094c

ubsan: member access within null pointer of union

Add some nonsense to cover "undefined behaviour".

* ldlang.c (section_for_dot): Avoid UB.

Automatic date update in version.in

Fix bug in Ada number lexing

On irc, Pedro pointed out that Ada couldn't properly handle
0xffffffffffffffff.  This used to work, but is a regression due to
some patches I wrote in the Ada lexer.  This patch fixes the bug.

gdb: fix "passing NULL to memcpy" UBsan error in dwarf2/cooked-index.c

Reading a simple file compiled with :

    $ gcc -DONE=1 -gdwarf-4 -g3  test.c
    $ gcc --version
    gcc (Ubuntu 9.4.0-1ubuntu1~20.04) 9.4.0

I get:

    Reading symbols from /tmp/cwd/a.out...
    /home/smarchi/src/binutils-gdb/gdb/dwarf2/cooked-index.c:332:11: runtime error: null pointer passed as argument 2, which is declared to never be null

It looks like even if the size is 0 (the size of the `entries` vector is
0), we shouldn't be passing a NULL pointer to memcpy.  And
`entries.data ()` returns NULL.

Fix that by using std::vector::insert to insert the items of entries
into m_entries.  I haven't checked, but it should essentially compile
down to a memcpy, since the vector elements are trivially copyiable.

Change-Id: I75f1c901e9b522e42e89eb5936e2c70d68eb21e5

gdb: change subfile::line_vector to an std::vector

Change this field to an std::vector to facilitate memory management.
Since the linetable_entry array is copied into the symtab resulting from
the subfile, it is possible to change it without changing how symtab
stores the linetable entries (which would be a much larger change).

There is a small change in buildsym_compunit::record_line to avoid
accessing a now invalid linetable_entry.  Before this patch, we keep a
pointer to the last linetable entry, pop it from the vector, and then
read last->line.  It works with the manually-maintained array, but since
we now use std::vector::pop_back, I am afraid that it could be flagged
as an invalid access by the various static / dynamic analysis tools to
access the linetable_entry object after popping it from the vector.
Instead, record just the line number in an optional and use it.

There are substantial changes in xcoffread.c that simplify the code, but
I can't test them.  I was hesitant to do this change because of that,
but I decided to send it anyway.  I don't think that an almost dead
platform should hold back improving the code in the common parts of GDB.

The changes in xcoffread.c are:

 - Make arrange_linetable "arrange" the linetable passed as a parameter,
   instead of returning possibly a new one, possibly the same one.
 - In the "Process main file's line numbers.", I'm not too sure what
   happens.  We get the lintable from "main_subfile", "arrange" it, but
   then assign the result to the current subfile, obtained with
   get_current_subfile.  I assume that the current subfile is also the
   main one, so now I just call arrange_linetable on the main subfile's
   line table.
 - Remove that weird "Useless if!!!" FIXME comment.  It's been there
   forever, but the "if" is still there, so I guess the "if" can stay
   there.

Change-Id: I11799006fd85189e8cf5bd3a168f8f38c2c27a80

gdb: use std::vector for temporary linetable_entry array in arrange_linetable

Reduce manual memory management and make the code a bit easier to read.
This helps me a bit in the following patch.

I don't have a way to test this, it's best-effort.

Change-Id: I64af9cd756311deabc6cd95e701dfb21234a40a5

gdb: change subfile::name and buildsym_compunit::m_comp_dir to strings

Change subfile::name to be a string, for easier memory management.
Change buildsym_compunit::m_comp_dir as well, since we move one in to
the other at some point in patch_subfile_names, so it's easier to do
both at the same time.  There are various NULL checks for both fields
currently, replace them with empty checks, I think it ends up
equivalent.

I can't test the change in xcoffread.c, it's best-effort.

Change-Id: I62b5fb08b2089e096768a090627ac7617e90a016

gdb: allocate subfile with new

Allocate struct subfile with new, initialize its fields instead of
memset-ing it to 0.  Use a unique_ptr for the window after a subfile has
been allocated but before it is linked in the buildsym_compunit's list
of subfile (and therefore owned by the buildsym_compunit.

I can't test the change in xcoffread.c, it's best-effort.  I couldn't
find where subfiles are freed in that file, I assume they were
intentionally (or not) leaked.

Change-Id: Ib3b6877de31b7e65bc466682f08dbf5840225f24

gdb: use decltype instead of typeof in dwarf2/read.c

When building with -std=c++11, I get:

  CXX    dwarf2/read.o
/home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c: In function â€˜void dwarf2_build_psymtabs_hard(dwarf2_per_objfile*)’:
/home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:7130:23: error: expected type-specifier before â€˜typeof’
 7130 |     using iter_type = typeof (per_bfd->all_comp_units.begin ());
      |                       ^~~~~~

This is because typeof is a GNU extension.  Use C++'s decltype keyword
instead.

Change-Id: Ieca2e8d25e50f71dc6c615a405a972a54de3ef14

gdbsupport: use result_of_t instead of result_of in parallel-for.h

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

Remove dwarf2_per_cu_data::v

Now that the psymtab reader has been removed, the
dwarf2_per_cu_data::v union is no longer needed.  Instead, we can
simply move the members from dwarf2_per_cu_quick_data into
dwarf2_per_cu_data and remove the "quick" object entirely.

Delete DWARF psymtab code

This removes the DWARF psymtab reader.

Enable the new DWARF indexer

This patch finally enables the new indexer.  It is left until this
point in the series to avoid any regressions; in particular, it has to
come after the changes to the DWARF index writer to avoid this
problem.

However, if you experiment with the series, this patch can be moved
anywhere from the patch to wire in the new reader to this point.
Moving this patch around is how I got separate numbers for the
parallelization and background finalization patches.

In the ongoing performance example, this reduces the time from the
baseline of 1.598869 to 0.903534.

Adapt .debug_names writer to new DWARF scanner

This updates the .debug_names writer to work with the new DWARF
scanner.

Adapt .gdb_index writer to new DWARF scanner

This updates the .gdb_index writer to work with the new DWARF scanner.
The .debug_names writer is deferred to another patch, to make review
simpler.

This introduces a small hack to psyms_seen_size, but is
inconsequential because this function will be deleted in a subsequent
patch.

Genericize addrmap handling in the DWARF index writer

This updates the DWARF index writing code to make the addrmap-writing
a bit more generic.  Now, it can handle multiple maps, and it can work
using the maps generated by the new indexer.

Note that the new addrmap_index_data::using_index field will be
deleted in a future patch, when the rest of the DWARF psymtab code is
removed.

Change parameters to write_address_map

To support the removal of partial symtabs from the DWARF index writer,
this makes a small change to have write_address_map accept the address
map as a parameter, rather than assuming it always comes from the
per-BFD object.

Change the key type in psym_index_map

In order to change the DWARF index writer to avoid partial symtabs,
this patch changes the key type in psym_index_map (and renames that
type as well).  Using the dwarf2_per_cu_data as the key makes it
simpler to reuse this code with the new indexer.

Rename write_psymtabs_to_index

We'll be removing all the psymtab code from the DWARF reader.  As a
preparatory step, this renames write_psymtabs_to_index to avoid the
"psymtab" name.

"Finalize" the DWARF index in the background

After scanning the CUs, the DWARF indexer merges all the data into a
single vector, canonicalizing C++ names as it proceeds.  While not
necessarily single-threaded, this process is currently done in just
one thread, to keep memory costs lower.

However, this work is all done without reference to any data outside
of the indexes.  This patch improves the apparent performance of GDB
by moving it to the background.  All uses of the index are then made
to wait for this process to complete.

In our ongoing example, this reduces the scanning time on gdb itself
to 0.173937 (wall).  Recall that before this patch, the time was
0.668923; and psymbol reader does this in 1.598869.  That is, at the
end of this series, we see about a 10x speedup.

Parallelize DWARF indexing

This parallelizes the new DWARF indexer.  The indexer's storage was
designed so that each storage object and each indexer is fully
independent.  This setup makes it simple to scan different CUs
independently.

This patch creates a new cooked index storage object per thread, and
then scans a subset of all the CUs in each such thread, using gdb's
existing thread pool.

In the ongoing "gdb gdb" example, this patch reduces the wall time
down to 0.668923, from 0.903534.  (Note that the 0.903534 is the time
for the new index -- that is, when the "enable the new index" patch is
rebased to before this one.  However, in the final series, that patch
appears toward the end.  Hopefully this isn't too confusing.)

Pre-read DWARF section data

Because BFD is not thread-safe, we need to be sure that any section
data that is needed is read before trying to do any DWARF indexing in
the background.

This patch takes a simple approach to this -- it pre-reads the
"info"-related sections.  This is done for the main file, but also any
auxiliary files as well, such as the DWO file.

This patch could be perhaps enhanced by removing some now-redundant
calls to dwarf2_section_info::read.

Introduce thread-safe handling for complaints

This introduces a new class that can be used to make the "complaint"
code thread-safe.  Instantiating the class installs a new handler that
collects complaints, and then prints them all when the object is
destroyed.

This approach requires some locks.  I couldn't think of a better way
to handle this, though, because the I/O system is not thread-safe.

It seemed to me that only GDB developers are likely to enable
complaints, and because the complaint macro handle this case already
(before any locks are required), I reasoned that any performance
degradation that would result here would be fine.

As an aside about complaints -- are they useful at all?  I just ignore
them, myself, since mostly they seem to indicate compiler problems
that can't be solved in the GDB world anyway.  I'd personally prefer
them to be in a separate tool, like a hypothetical 'dwarflint'.

Wire in the new DWARF indexer

This wires the new DWARF indexer into the existing reader code.  That
is, this patch makes the modification necessary to enable the new
indexer.  It is not actually enabled by this patch -- that will be
done later.

I did a bit of performance testing for this patch and a few others.  I
copied my built gdb to /tmp, so that each test would be done on the
same executable.  Then, each time, I did:

    $ ./gdb -nx
    (gdb) maint time 1
    (gdb) file /tmp/gdb

This patch is the baseline and on one machine came in at 1.598869 wall
time.

Implement quick_symbol_functions for cooked DWARF index

This implements quick_symbol_functions for the cooked DWARF index.
This is the code that interfaces between the new index and the rest of
gdb.  Cooked indexes still aren't created by anything.

For the most part this is straightforward.  It shares some concepts
with the existing DWARF indices.  However, because names are stored
pre-split in the cooked index, name lookup here is necessarily
different; see expand_symtabs_matching for the gory details.

The new DWARF indexer

This patch adds the code to index DWARF.  This is just the scanner; it
reads the DWARF and constructs the index, but nothing calls it yet.

The indexer is split into two parts: a storage object and an indexer
object.  This is done to support the parallelization of this code -- a
future patch will create a single storage object per thread.

Introduce the new DWARF index class

This patch introduces the new DWARF index class.  It is called
"cooked" to contrast against a "raw" index, which is mapped from disk
without extra effort.

Nothing constructs a cooked index yet.  The essential idea here is
that index entries are created via the "add" method; then when all the
entries have been read, they are "finalize"d -- name canonicalization
is performed and the entries are added to a sorted vector.

Entries use the DWARF name (DW_AT_name) or linkage name, not the full
name as is done for partial symbols.

These two facets -- the short name and the deferred canonicalization
-- help improve the performance of this approach.  This will become
clear in later patches, when parallelization is added.

Some special code is needed for Ada, because GNAT only emits mangled
("encoded", in the Ada lingo) names, and so we reconstruct the
hierarchical structure after the fact.  This is also done in the
finalization phase.

One other aspect worth noting is that the way the "main" function is
found is different in the new code.  Currently gdb will notice
DW_AT_main_subprogram, but won't recognize "main" during reading --
this is done later, via explicit symbol lookup.  This is done
differently in the new code so that finalization can be done in the
background without then requiring a synchronization to look up the
symbol.

Update skip_one_die for new abbrev properties

This updates skip_one_die to speed it up in the cases where either
sibling_offset or size_if_constant are set.

Statically examine abbrev properties

The new DIE scanner works more or less along the lines indicated by
the text for the .debug_names section, disregarding the bugs in the
specification.

While working on this, I noticed that whether a DIE is interesting is
a static property of the DIE's abbrev.  It also turns out that many
abbrevs imply a static size for the DIE data, and additionally that
for many abbrevs, the sibling offset is stored at a constant offset
from the start of the DIE.

This patch changes the abbrev reader to analyze each abbrev and stash
the results on the abbrev.  These combine to speed up the new indexer.
If the "interesting" flag is false, GDB knows to skip the DIE
immediately.  If the sibling offset is statically known, skipping can
be done without reading any attributes; and in some other cases, the
DIE can be skipped using simple arithmetic.

Introduce DWARF abbrev cache

The replacement for the DWARF psymbol reader works in a somewhat
different way.  The current reader reads and stores all the DIEs that
might be interesting.  Then, if it is missing a DIE, it re-scans the
CU and reads them all.  This approach is used for both intra- and
inter-CU references.

I instrumented the partial DIE hash to see how frequently it was used:

    [  0] -> 1538165
    [  1] ->    4912
    [  2] ->   96102
    [  3] ->     175
    [  4] ->     244

That is, most DIEs are never used, and some are looked up twice -- but
this is just an artifact of the implementation of
partial_die_info::fixup, which may do two lookups.

Based on this, the new implementation doesn't try to store any DIEs,
but instead just re-scans them on demand.  In order to do this,
though, it is convenient to have a cache of DWARF abbrevs.  This way,
if a second CU is needed to resolve an inter-CU reference, the abbrevs
for that CU need only be computed a single time.

Add "fullname" handling to file_and_directory

This changes the file_and_directory object to be able to compute and
cache the "fullname" in the same way that is done by other code, like
the psymtab reader.

Specialize std::hash for gdb_exception

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.

Return vector of results from parallel_for_each

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.

Add batching parameter to parallel_for_each

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.

Refactor build_type_psymtabs_reader

The new DWARF scanner needs to save the entire cutu_reader object, not
just parts of it.  In order to make this possible, this patch
refactors build_type_psymtabs_reader.  This change is done separately
because it is easy to review in isolation and it helps make the later
patches smaller.

Add new overload of dwarf5_djb_hash

This adds a new overload of dwarf5_djb_hash.  This is used in
subsequent patches.

Add name splitting

The new DWARF index code works by keeping names pre-split.  That is,
rather than storing a symbol name like "a::b::c", the names "a", "b",
and "c" will be stored separately.

This patch introduces some helper code to split a full name into its
components.

Let skip_one_die not skip children

This patch adds an option to skip_one_die that causes it not to skip
child DIEs.  This is needed in the new scanner.

Allow ada_decode not to decode operators

The new DWARF scanner records names as they appear in DWARF.  However,
because Ada is unusual, it also decodes the Ada names to synthesize
package components for them.  In order for this to work out properly,
gdb also needs a mode where ada_decode can be instructed not to decode
Ada operator names.  That is what this patch implements.

Refactor dwarf2_get_pc_bounds

This changes dwarf2_get_pc_bounds so that it does not directly access
a psymtab or psymtabs_addrmap.  Instead, both the addrmap and the
desired payload are passed as parameters.  This makes it suitable to
be used by the new indexer.

Add dwarf2_per_cu_data::addresses_seen

This adds a new member to dwarf2_per_cu_data that indicates whether
addresses have been seen for this CU.  This is then set by the
.debug_aranges reader.  The idea here is to detect when a CU does not
have address information, so that the new indexer will know to do
extra scanning in that case.

Fix latent bug in read_addrmap_from_aranges

Tom de Vries found a failure that we tracked down to a latent bug in
read_addrmap_from_aranges (previously create_addrmap_from_aranges).
The bug is that this code can erroneously reject .debug_aranges when
dwz is in use, due to CUs at duplicate offsets.  Because aranges can't
refer to a CU coming from the dwz file, the fix is to simply skip such
CUs in the loop.

Split create_addrmap_from_aranges

This patch splits create_addrmap_from_aranges into a wrapper function
and a worker function.  The worker function is then used in a later
patch.

Allow thread-pool.h to work without threads

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.

Rebase the zlib sources to the 1.2.12 release

[gdb/testsuite] Fix gdb.base/stap-probe.exp with read1

When running test-case gdb.base/stap-probe.exp with make target check-read1, I
run into this and similar:
...
FAIL: gdb.base/stap-probe.exp: without semaphore, not optimized: \
  info probes stap (timeout)
...

Fix this by using gdb_test_lines instead of gdb_test.

Tested on x86_64-linux.