Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Fix parameter-less template regression in new DWARF reader

PR c++/29896 points out a regression in the new DWARF reader.  It does
not properly handle a case like "break fn", where "fn" is a template
function.

This happens because the new index uses strncasecmp to compare.
However, to make this work correctly, we need a custom function that
ignores template parameters.

This patch adds a custom comparison function and fixes the bug.  A new
test case is included.

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

(cherry picked from commit ac37b79cc440e37fc704d425a6e450afb3c7ee89)

Move hash_entry and eq_entry into cooked_index::do_finalize

I was briefly confused by the hash_entry and eq_entry functions in the
cooked index.  They are only needed in a single method, and that
method already has a couple of local lambdas for a different hash
table.  So, it seemed cleaner to move these there as well.

(cherry picked from commit 5a89072f36ddd3be71103e3806d42ff5e49ff616)

Avoid submitting empty tasks in parallel_for_each

I found that parallel_for_each would submit empty tasks to the thread
pool.  For example, this can happen if the number of tasks is smaller
than the number of available threads.  In the DWARF reader, this
resulted in the cooked index containing empty sub-indices.  This patch
arranges to instead shrink the result vector and process the trailing
entries in the calling thread.

(cherry picked from commit 63078a04984b73e1fdeb4571a63605ee5c13f929)

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Set _WIN32_WINNT in common.m4 configure check

GCC recently added support for the Windows thread model, enabling
libstdc++ to support Windows natively.  However, this supporrt
requires a version of Windows later than the minimum version that is
supported by GDB.

PR build/29966 points out that the GDB configure test for std::thread
does not work in this situation, because _WIN32_WINNT is not defined
in test program, and so <thread> seems to be fine.

This patch is an attempt to fix the problem, by using the same setting
for _WIN32_WINNT at configure time as is used at build time.

I don't have access to one of the older systems so I don't think I can
truly test this.  I did do a mingw cross build, though.  I'm going to
ask the bug reporter to test it.

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

(cherry picked from commit 2124b2de4bba05063218501dcccfc4cffe648cda)

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

[gdb] Fix segfault during inferior call to ifunc

With a simple test-case:
...
$ cat test.c
char *p = "a";
int main (void) {
  return strlen (p);
}
$ gcc -g test.c
...
we run into this segfault:
...
$ gdb -q -batch a.out -ex start -ex "p strlen (p)"
Temporary breakpoint 1 at 0x1151: file test.c, line 4.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Temporary breakpoint 1, main () at test.c:4
4   return strlen (p);

Fatal signal: Segmentation fault
...

The strlen is an ifunc, and consequently during the call to
call_function_by_hand_dummy for "p strlen (p)" another call
to call_function_by_hand_dummy is used to resolve the ifunc.

This invalidates the get_current_frame () result in the outer call.

Fix this by using prepare_reinflate and reinflate.

Note that this series (
https://inbox.sourceware.org/gdb-patches/20221214033441.499512-1-simon.marchi@polymtl.ca/ )
should address this problem, but this patch is a simpler fix which is easy to
backport.

Tested on x86_64-linux.

Co-Authored-By: Tom de Vries <tdevries@suse.de>
PR gdb/29941
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29941

Automatic date update in version.in

Fix target remote pipe command for MinGW

The cced7cacecad104fff0 ("gdb: preserve `|` in connection details string")
commit added '|' detection and removal to ser-pipe.c, but missed to add it
to ser-mingw.c.

This results in the error message below for MinGW hosts:
error starting child process '| <executable> <args>': CreateProcess: No such file or directory

This commit add the missing '|' detection and removal to ser-mingw.c.

(cherry picked from commit c43d829bca5e45c5e6c0255a549abc5766f6de7f)

Automatic date update in version.in

manual copyright year range of various GDB files to add 2023

This commit updates the following file...

   gdb/doc/gdb.texinfo
   gdb/doc/refcard.tex
   gdb/syscalls/update-netbsd.sh

... by hand as instructed by the gdb/copyright.py script.
The update by hand is needed because the copyright headers
to update are actually nested inside those files, rather
than located at the start of the file.

(cherry picked from commit 944bfb2ccb564803279f41019e75c62d7ec8e5af)

Update copyright year range in header of all files managed by GDB

This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.

gdb/copyright.py: Adjust following rename of sim/ppc/ppc-instructions...

... to sim/ppc/powerpc.igen

This file is in the NOT_FSF_LIST because this file has a copyright
which is not assigned to the FSF. Since the file got renamed,
the corresponding entry in NOT_FSF_LIST needs to be renamed as well.

(cherry picked from commit e4661570ead7be521c9d693f188b0944d7b8c78c)

Update copyright year in help message of gdb, gdbserver, gdbreplay

This commit updates the copyright year displayed by gdb, gdbserver
and gdbreplay's help message from 2022 to 2023, as per our Start
of New Year procedure. The corresponding source files' copyright
header are also updated accordingly.

(cherry picked from commit e1ca55341ca328b2343ecc5cb78699fdbd1caa22)

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Fix "set debug timestamp"

PR cli/29945 points out that "set debug timestamp 1" stopped working
-- this is a regression due to commit b8043d27 ("Remove a ui-related
memory leak").

This patch fixes the bug and adds a regression test.

I think this should probably be backported to the gdb 13 branch.

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

(cherry picked from commit a60535c39ba52d88c47740db6ab116db32e2331a)

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Fix MinGW build using mingw.org's MinGW

This allows to build GDB even though the default value of
_WIN32_WINNT is lower than the one needed to expose some
new APIs used here, and leave the test for their actual
support to run time.
* gdb/nat/windows-nat.c (EXTENDED_STARTUPINFO_PRESENT): Define if
not defined.
(create_process_wrapper): Use 'gdb_lpproc_thread_attribute_list'
instead of 'PPROC_THREAD_ATTRIBUTE_LIST' (which might not be defined
at compile time).  This fixes compilation error using mingw.org's
MinGW.

PR29915, bfdio.c does not compile with mingw.org's MinGW

PR 29915
* configure.ac: Add AC_CHECK_DECLS test ___lc_codepage_func.
* configure: Regenerate.
* config.in: Regenerate.
* bfdio.c (___lc_codepage_func): Move declaration to..
(_bfd_real_fopen): ..here, and use !HAVE_DECL____LC_CODEPAGE_FUNC.

(cherry picked from commit 9d0991449285833b9a77cc02850a1e113e460362)

Automatic date update in version.in

Automatic date update in version.in

Fix install-strip target

The libtool patch broke install-strip of gdb:

/bin/sh ../../gdb/../mkinstalldirs /src/gdb/inst/share/gdb/python/gdb
transformed_name=`t='s,y,y,'; \
                  echo gdb | sed -e "$t"` ; \
        if test "x$transformed_name" = x; then \
          transformed_name=gdb ; \
        else \
          true ; \
        fi ; \
        /bin/sh ../../gdb/../mkinstalldirs /src/gdb/inst/bin ; \
        /bin/sh ./libtool --mode=install STRIPPROG='strip' /bin/sh /src/gdb/gdb.git/install-sh -c -s \
                gdb \
                /src/gdb/inst/bin/$transformed_name ; \
        /bin/sh ../../gdb/../mkinstalldirs /src/gdb/inst/include/gdb ; \
        /usr/bin/install -c -m 644 jit-reader.h /src/gdb/inst/include/gdb/jit-reader.h
libtool: install: `/src/gdb/inst/bin/gdb' is not a directory
libtool: install: Try `libtool --help --mode=install' for more information.

Since INSTALL_PROGRAM_ENV is no longer at the beginning of the command, the
gdb executable is not installed with install-strip.

gdb: fix command lookup in execute_command ()

Commit b5661ff2 ("gdb: fix possible use-after-free when
executing commands") used lookup_cmd_exact () to lookup
command again after its execution to avoid possible
use-after-free error.

However this change broke test gdb.base/define.exp which
defines a post-hook for subcommand ("target testsuite").
In this case,  lookup_cmd_exact () returned NULL because
there's no command 'testsuite' in top-level commands.

This commit fixes this case by looking up the command again
using the original command line via lookup_cmd ().

Approved-By: Simon Marchi <simon.marchi@efficios.com>
(cherry picked from commit 37e5833da583310268dc1b04fc6839e81b987897)

Automatic date update in version.in

Automatic date update in version.in

Set development mode to "off" by default.

This is done by setting the "development" variable to "false"
in bfd/development.sh.

Bump version to 13.0.90.DATE-git.

Now that the GDB 13 branch has been created,
this commit bumps the version number in gdb/version.in to
13.0.90.DATE-git

For the record, the GDB 13 branch was created
from commit 71c90666e601c511a5f495827ca9ba545e4cb463.

Automatic date update in version.in

bfd_get_relocated_section_contents allow NULL data buffer

This patch removes the bfd_malloc in default_indirect_link_order and
bfd_simple_get_relocated_section_contents, pushing the allocation down
to bfd_get_relocated_section_contents.  The idea is to make use of the
allocation done with sanity checking in bfd_get_full_section_contents,
which is called by bfd_generic_get_relocated_section_contents.

Doing this exposed a bug in bfd_get_full_section_contents.  With
relaxation it is possible that an input section rawsize is different
to the section size.  In that case we want to use the larger of
rawsize (the on-disk size for input sections) and size.

* reloc.c (bfd_generic_get_relocated_section_contents),
* reloc16.c (bfd_coff_reloc16_get_relocated_section_contents),
* coff-alpha.c (alpha_ecoff_get_relocated_section_contents),
* coff-sh.c (sh_coff_get_relocated_section_contents),
* elf-m10200.c (mn10200_elf_get_relocated_section_contents),
* elf-m10300.c (mn10300_elf_get_relocated_section_contents),
* elf32-avr.c (elf32_avr_get_relocated_section_contents),
* elf32-cr16.c (elf32_cr16_get_relocated_section_contents),
* elf32-crx.c (elf32_crx_get_relocated_section_contents),
* elf32-h8300.c (elf32_h8_get_relocated_section_contents),
* elf32-nds32.c (nds32_elf_get_relocated_section_contents),
* elf32-sh.c (sh_elf_get_relocated_section_contents),
* elfxx-mips.c (_bfd_elf_mips_get_relocated_section_contents):
Handle NULL data buffer.
* bfd.c (bfd_get_section_alloc_size): New function.
* bfd-in2.h: Regenerate.
* compress.c (bfd_get_full_section_contents): Correct section
malloc size.
* linker.c (default_indirect_link_order): Don't malloc memory
here before calling bfd_get_relocated_section_contents.
* simple.c (bfd_simple_get_relocated_section_contents): Likewise.

asan: elf.c:12621:18: applying zero offset to null pointer

That's this line in elf_parse_notes:
  while (p < buf + size)

* elf.c (_bfd_elf_make_section_from_shdr): Don't call
elf_parse_notes when sh_size is zero.

Re: The problem with warning in elf_object_p

Commit 5aa0f10c424e added a per_xvec_warn array to provide support for
warnings from elf_object_p (and a later patch for warnings from
pe_bfd_object_p) to be cached and then only printed if the target
matches.  It was quite limited in the style of message supported, only
one message could be printed, and didn't really meet the stated aim of
only warning when a target matches:  There are many other errors and
warnings that can be emitted by functions called from elf_object_p.

So this patch extends the error handler functions to support printing
to a string buffer, extends per_xvec_warn to support multiple errors/
warnings, and hooks this all into bfd_check_format_matches.  If
bfd_check_format_matches succeeds then any errors/warnings are printed
for the matching target.  If bfd_check_format_matches fails either due
to no match or to multiple matches and only one target vector produced
errors, then those errors are printed.

* bfd.c (MAX_ARGS): Define, use throughout.
(print_func): New typedef.
(_bfd_doprnt): Add new print param.  Replace calls to fprintf
with print.
(PRINT_TYPE): Similarly.
(error_handler_fprintf): Renamed from error_handler_internal.
Use _bfd_get_error_program_name.  Add fprintf arg.  Move code
setting up args..
(_bfd_doprnt_scan): ..to here.  Add ap param.
(struct buf_stream): New.
(err_sprintf): New function.
(error_handler_bfd): New static variable.
(error_handler_sprintf): New function.
(_bfd_set_error_handler_caching): New function.
(_bfd_get_error_program_name): New function.
* elfcode.h (elf_swap_shdr_in): Use _bfd_error_handler in
warning messages.
(elf_object_p): Likewise.
* format.c (print_warnmsg): New function.
(clear_warnmsg): Rewrite.
(null_error_handler): New function.
(bfd_check_format_matches): Ignore warnings from recursive calls
checking first element of an archive.  Use caching error handler
otherwise.  Print warnings on successful match, or when only one
target has emitted warnings/errors.
* peicode.h (pe_bfd_object_p): Use _bfd_error_handler in
warning messages.
* targets.c (per_xvec_warn): Change type of array elements.
(struct per_xvec_message): New.
(_bfd_per_xvec_warn): Rewrite.
* Makefile.am (LIBBFD_H_FILES): Add bfd.c.
* Makefile.in: Regenerate.
* bfd-in2.h: Regenerate.
* libbfd.h: Regenerate.

sframe: doc: update spec for the mangled-RA bit in FRE

ChangeLog:

* libsframe/doc/sframe-spec.texi

gas: sframe: testsuite: add testcase for .cfi_negate_ra_state

Add a new test to check that .cfi_negate_ra_state on aarch64 is handled
well (a non-empty SFrame section with valid SFrame FREs is generated).

ChangeLog:

* testsuite/gas/cfi-sframe/cfi-sframe-aarch64-2.d: New test.
* testsuite/gas/cfi-sframe/cfi-sframe-aarch64-2.s: Likewise.
* testsuite/gas/cfi-sframe/cfi-sframe.exp: Adjust the list
accordingly.

objdump/readelf: sframe: emit marker for FREs with mangled RA

In the textual dump of the SFrame section, when an SFrame FRE recovers a
mangled RA, use string "[s]" in the output to indicate that the return
address is a signed (mangled) one.

ChangeLog:

        * libsframe/sframe-dump.c (dump_sframe_func_with_fres): Postfix
with "[s]" if RA is signed with authorization code.

libsframe: provide new access API for mangled RA bit

include/ChangeLog:

* sframe-api.h (sframe_fre_get_ra_mangled_p): New declaration.

ChangeLog:

* libsframe/sframe.c (sframe_get_fre_ra_mangled_p): New
definition.
(sframe_fre_get_ra_mangled_p): New static function.

gas: sframe: add support for .cfi_negate_ra_state

DW_CFA_AARCH64_negate_ra_state in aarch64 is multiplexed with
DW_CFA_GNU_window_save in the DWARF format.

Remove the common-empty-4 testcase because the generated SFrame section
will not be be empty anymore.  A relevant test will be added in a later
commit.

ChangeLog:

* gas/gen-sframe.c (sframe_v1_set_fre_info): Add new argument
for mangled_ra_p.
(sframe_set_fre_info): Likewise.
(output_sframe_row_entry): Handle mangled_ra_p.
(sframe_row_entry_new): Reset mangled_ra_p.
(sframe_row_entry_initialize): Initialize mangled_ra_p.
(sframe_xlate_do_gnu_window_save): New definition.
(sframe_do_cfi_insn): Handle DW_CFA_GNU_window_save.
* gas/gen-sframe.h (struct sframe_row_entry): New member.
(struct sframe_version_ops): Add a new argument for
mangled_ra_p.
* gas/testsuite/gas/cfi-sframe/cfi-sframe.exp: Remove test.
* gas/testsuite/gas/cfi-sframe/common-empty-4.d: Removed.
* gas/testsuite/gas/cfi-sframe/common-empty-4.s: Removed.

sframe.h: add support for .cfi_negate_ra_state

Use the last remaining bit in the 'SFrame FRE info' word to store whether
the RA is signed/unsigned with PAC authorization code: this bit is named
as the "mangled RA" bit.  This bit is still unused for x86-64.

The behaviour of the mangled-RA info bit in SFrame format closely
follows the behaviour of DW_CFA_AARCH64_negate_ra_state in DWARF.  During
unwinding, whenever an SFrame FRE with non-zero "mangled RA" bit is
encountered, it means the upper bits of the return address contain Pointer
Authentication code.  The unwinder, hence, must use appropriate means to
restore LR correctly in such cases.

include/ChangeLog:

* sframe.h (SFRAME_V1_FRE_INFO_UPDATE_MANGLED_RA_P): New macro.
(SFRAME_V1_FRE_MANGLED_RA_P): Likewise.

Automatic date update in version.in

Delay checking whether /proc/pid/mem is writable (PR gdb/29907)

As of 1bcb0708f229 ("gdb/linux-nat: Check whether /proc/pid/mem is
writable"), GDB checks if /proc/pid/mem is writable.  This is done
early at GDB startup, in order to get a consistent warning, instead of
a warning that depends on whenever GDB writes to inferior memory.

PR gdb/29907 points out that some build systems (like QEMU's,
apparently) may call 'gdb --version' to check GDB's presence & its
version on the system, and that Gentoo's build process has sandboxing
which blocks the /proc/pid/mem access and thus GDB warns, which
results in build fails.

To help with that, this patch delays the /proc/pid/mem check until we
start or attach to an inferior.  Ends up potentially emiting a warning
close where we already emit other ptrace- and /proc- related warnings,
which just Feels Right.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29907
Change-Id: I5537653ecfbbe76a04ab035e40e59d09b4980763

Fix previous delta to allow for compilation on 32-bit systems

[gdb/testsuite] Fix race in gdb.threads/detach-step-over.exp

Once in a while I run into:
...
FAIL: gdb.threads/detach-step-over.exp: \
  breakpoint-condition-evaluation=host: target-non-stop=off: non-stop=off: \
  displaced=off: iter 1: all threads running
...

In can easily reproduce this by doing:
...
     # Wait a bit, to give time for the threads to hit the
     # breakpoint.
-    sleep 1

     return true
...

Fix this by counting the running threads in a loop, effectively allowing 10
seconds (instead of 1) for the threads to start running, but only sleeping if
needed.

Reduces total execution time from 1m27s to 56s.

Tested on x86_64-linux.

gdb: fix crash when getting the value of a label symbol

When the source program contains a goto label, it turns out it's
actually pretty hard for a user to find out more about that label.
For example:

  (gdb) p some_label
  No symbol "some_label" in current context.
  (gdb) disassemble some_label
  No symbol "some_label" in current context.
  (gdb) x/10i some_label
  No symbol "some_label" in current context.
  (gdb) break some_label
  Breakpoint 2 at 0x401135: file /tmp/py-label-symbol-value.c, line 35.

In all cases, some_label is a goto label within the current frame.
Only placing a breakpoint on the label worked.

This all seems a little strange to me, it feels like asking about a
goto label would not be an unreasonable thing for a user to do.

This commit doesn't fix any of the above issues, I mention them just
to provide a little context for why the following issue has probably
not been seen before.

It turns out there is one way a user can access the symbol for a goto
label, through the Python API:

  python frame = gdb.selected_frame()
  python frame_pc = frame.pc()
  python block = gdb.current_progspace().block_for_pc(frame_pc)
  python symbol,_ = gdb.lookup_symbol('some_label', block, gdb.SYMBOL_LABEL_DOMAIN)
  python print(str(symbol.value()))
  ../../src/gdb/findvar.c:204: internal-error: store_typed_address: Assertion `type->is_pointer_or_reference ()' failed.

The problem is that label symbols are created using the
builtin_core_addr type, which is a pure integer type.

When GDB tries to fetch the value of a label symbol then we end up in
findvar.c, in the function language_defn::read_var_value, in the
LOC_LABEL case.  From here store_typed_address is called to store the
address of the label into a value object with builtin_core_addr type.

The problem is that store_typed_address requires that the destination
type be a pointer or reference, which the builtin_core_addr type is
not.

Now it's not clear what type a goto label address should have, but
GCC has an extension that allows users to take the address of a goto
label (using &&), in that case the result is of type 'void *'.

I propose that when we convert the CORE_ADDR value to a GDB value
object, we use builtin_func_ptr type instead of builtin_core_addr,
this means the result will be of type 'void (*) ()'.  The benefit of
this approach is that when gdbarch_address_to_pointer is called the
target type will be correctly identified as a pointer to code, which
should mean any architecture specific adjustments are done correctly.

We can then cast the new value to 'void *' type with a call to
value_cast_pointer, this should not change the values bit
representation, but will just update the type.

After this asking for the value of a label symbol works just fine:

  (gdb) python print(str(symbol.value()))
  0x401135 <main+35>

And the type is maybe what we'd expect:

  (gdb) python print(str(symbol.value().type))
  void *

gdb: convert linux-osdata.c from buffer to std::string

Replace the use of struct buffer in linux-osdata.c with std::string.
There is no change in the logic, so there should be no user-visible
change.

Change-Id: I27f53165d401650bbd0bebe8ed88221e25545b3f
Approved-By: Pedro Alves <pedro@palves.net>

gdbsupport: add string_xml_appendf

Add a version of buffer_xml_printf (defined in gdbsupport/buffer.{c,h})
that appends to an std::string, rather than a struct buffer.  Call it
"string" rather than "buffer" since it operates on an std::string rather
than a buffer.  And call it "appendf" rather than "printf", since it
appends to and does not replace the string's content.  This mirrors
string_appendf.

Place the new version in gdbsupport/xml-utils.h.

The code is a direct copy of buffer_xml_printf.  The old version is
going to disappear at some point, which is why I didn't do any effort to
share code.

Change-Id: I30e030627ab4970fd0b9eba3b7e8cec78fa561ba
Approved-By: Pedro Alves <pedro@palves.net>

gdb: clean up some inefficient std::string usage

This commit:

  commit 53cf95c3389a3ecd97276d322e4a60fe3396a201
  Date:   Wed Dec 14 14:17:44 2022 +0000

      gdb: make more use of make_target_connection_string

Introduced a couple of inefficient uses of std::string, both of which
are fixed in this commit.

There should be no user visible changes after this commit.

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

Fix a potential illegal memory access when parsing corrupt DWARF information.

PR 29908
* dwarf.c (display_debug_addr): Check for corrupt header lengths.

gdb/testsuite: add test for Python commands redefining itself

This commit adds a test that creates a Python command that redefines
itself during its execution. This is to test use-after-free in
execute_command ().

This test needs run with ASan enabled in order to fail when it
should.

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

[aarch64] Fix removal of non-address bits for PAuth

PR gdb/28947

The address_significant gdbarch setting was introduced as a way to remove
non-address bits from pointers, and it is specified by a constant.  This
constant represents the number of address bits in a pointer.

Right now AArch64 is the only architecture that uses it, and 56 was a
correct option so far.

But if we are using Pointer Authentication (PAuth), we might use up to 2 bytes
from the address space to store the required information.  We could also have
cases where we're using both PAuth and MTE.

We could adjust the constant to 48 to cover those cases, but this doesn't
cover the case where GDB needs to sign-extend kernel addresses after removal
of the non-address bits.

This has worked so far because bit 55 is used to select between kernel-space
and user-space addresses.  But trying to clear a range of bits crossing the
bit 55 boundary requires the hook to be smarter.

The following patch renames the gdbarch hook from significant_addr_bit to
remove_non_address_bits and passes a pointer as opposed to the number of
bits.  The hook is now responsible for removing the required non-address bits
and sign-extending the address if needed.

While at it, make GDB and GDBServer share some more code for aarch64 and add a
new arch-specific testcase gdb.arch/aarch64-non-address-bits.exp.

Bug-url: https://sourceware.org/bugzilla/show_bug.cgi?id=28947

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

gas: restore Dwarf info generation after macro diagnostic adjustments

While 6fdb723799e2 ("gas: re-work line number tracking for macros and
their expansions") was meant to leave generated Dwarf as is, it really
didn't (and the testcase intended to catch that wasn't covering the case
which broke). Its adjustment to buffer_and_nest() didn't go far enough,
leading to the "linefile" directive inserted at the top to also be
processed later in the PR gas/16908 workaround (which clearly isn't
intended - it's being put there for processing during macro expansion
only). That unnoticed flaw in turn led me to work around it by a
(suspicious to me already at the time) conditional in as_where().

x86: change representation of extension opcode

Having a "None" field in the vast majority of entries is needlessly
cluttering the overall table. Instead of this being a separate field,
use a representation matching that of Intel SDM and AMD PM for the main
use of the field: Append the value after a / as the separator.

gdbsupport: change xml_escape_text_append's parameter from pointer to reference

The passed in string can't be nullptr, it makes more sense to pass in a
reference.

Change-Id: Idc8bd38abe1d6d9b44aa227d7856956848c233b3

gdb: remove static buffer in command_line_input

[I sent this earlier today, but I don't see it in the archives.
Resending it through a different computer / SMTP.]

The use of the static buffer in command_line_input is becoming
problematic, as explained here [1].  In short, with this patch [2] that
attempt to fix a post-hook bug, when running gdb.base/commands.exp, we
hit a case where we read a "define" command line from a script file
using command_command_line_input.  The command line is stored in
command_line_input's static buffer.  Inside the define command's
execution, we read the lines inside the define using command_line_input,
which overwrites the define command, in command_line_input's static
buffer.  After the execution of the define command, execute_command does
a command look up to see if a post-hook is registered.  For that, it
uses a now stale pointer that used to point to the define command, in
the static buffer, causing a use-after-free.  Note that the pointer in
execute_command points to the dynamically-allocated buffer help by the
static buffer in command_line_input, not to the static object itself,
hence why we see a use-after-free.

Fix that by removing the static buffer.  I initially changed
command_line_input and other related functions to return an std::string,
which is the obvious but naive solution.  The thing is that some callees
don't need to return an allocated string, so this this an unnecessary
pessimization.  I changed it to passing in a reference to an std::string
buffer, which the callee can use if it needs to return
dynamically-allocated content.  It fills the buffer and returns a
pointers to the C string inside.  The callees that don't need to return
dynamically-allocated content simply don't use it.

So, it started with modifying command_line_input as described above, all
the other changes derive directly from that.

One slightly shady thing is in handle_line_of_input, where we now pass a
pointer to an std::string's internal buffer to readline's history_value
function, which takes a `char *`.  I'm pretty sure that this function
does not modify the input string, because I was able to change it (with
enough massaging) to take a `const char *`.

A subtle change is that we now clear a UI's line buffer using a
SCOPE_EXIT in command_line_handler, after executing the command.
This was previously done by this line in handle_line_of_input:

  /* We have a complete command line now.  Prepare for the next
     command, but leave ownership of memory to the buffer .  */
  cmd_line_buffer->used_size = 0;

I think the new way is clearer.

[1] https://inbox.sourceware.org/gdb-patches/becb8438-81ef-8ad8-cc42-fcbfaea8cddd@simark.ca/
[2] https://inbox.sourceware.org/gdb-patches/20221213112241.621889-1-jan.vrany@labware.com/

Change-Id: I8fc89b1c69870c7fc7ad9c1705724bd493596300
Reviewed-By: Tom Tromey <tom@tromey.com>

Automatic date update in version.in

libsframe asan: avoid generating misaligned loads

There are two places where unaligned loads were seen on aarch64:
  - #1. access to the SFrame FRE stack offsets in the in-memory
    representation/abstraction provided by libsframe.
  - #2. access to the SFrame FRE start address in the on-disk representation
    of the frame row entry.

For #1, we can fix this by reordering the struct members of
sframe_frame_row_entry in libsframe/sframe-api.h.

For #2, we need to default to using memcpy instead, and copy out the bytes
to a location for output.

SFrame format is an unaligned on-disk format. As such, there are other blobs
of memory in the on-disk SFrame FRE that are on not on their natural
boundaries.  But that does not pose further problems yet, because the users
are provided access to the on-disk SFrame FRE data via libsframe's
sframe_frame_row_entry, the latter has its' struct members aligned on their
respective natural boundaries (and initialized using memcpy).

PR 29856 libsframe asan: load misaligned at sframe.c:516

ChangeLog:

PR libsframe/29856
* bfd/elf64-x86-64.c: Adjust as the struct members have been
reordered.
* libsframe/sframe.c (sframe_decode_fre_start_address): Use
memcpy to perform 16-bit/32-bit reads.
* libsframe/testsuite/libsframe.encode/encode-1.c: Adjust as the
struct members have been reordered.

include/ChangeLog:

PR libsframe/29856
* sframe-api.h: Reorder fre_offsets for natural alignment.

gdb/testsuite: don't delete command files in gdb.base/commands.exp

Don't delete the runtime-generated command files.  This makes it easier
to reproduce tests by hand.

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

Move streq and compare_cstrings to gdbsupport

It seems to me that streq and compare_cstrings belong near the other
string utility functions in common-utils.h; and furthermore that streq
ought to be inlined.  This patch makes this change.

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

Remove subset_compare

I stumbled across subset_compare today, and after looking at the
callers I realized it could be removed and replaced with calls to
startswith.

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

gdb: use gdb_assert not internal_error

Spotted a couple of places in findvar.c where we use:

  if ( ! CONDITION )
    internal_error ("...");

this commit changes these to be:

  gdb_assert ( CONDITION );

which I think is better.

Unless we happen to hit the internal_error calls (which was bad) there
should be no user visible changes after this commit.

gdb: some int to bool conversion in remote-sim.c

Some obvious int to bool conversion in remote-sim.c, there should be
no user visible changes after this commit.

gdb: make more use of make_target_connection_string

I noticed that we have a function make_target_connection_string which
wraps all the logic for creating a string that describes a target
connection - but in some places we are not calling this function,
instead we duplicate the function's logic.

This commit cleans this up, and calls make_target_connection_string
where possible.

There should be no user visible changes after this commit.

gdb: int to bool conversion in tracefile.c

Some obvious int to bool conversion in tracefile.c.

Should be no user visible changes after this commit.

[gdb/testsuite] Fix gdb.base/condbreak-multi-context.exp with gcc 4.8.5

With gcc 4.8.5, I run into:
...
Running gdb.base/condbreak-multi-context.exp ...
gdb compile failed, condbreak-multi-context.cc:21:11: warning: non-static \
  data member initializers only available with -std=c++11 or -std=gnu++11 \
  [enabled by default]
   int b = 20;
           ^
...

Fix this by making it a static const.

Tested on x86_64-linux, with gcc 4.8.5, 7.5.0 and clang 13.0.1.

Automatic date update in version.in

gdb/maint: add core file name to 'maint info program-spaces' output

Each program space can have an associated core file.  Include this
information in the output of 'maint info program-spaces'.

gdb: ensure all targets are popped before an inferior is destructed

Now that the inferiors target_stack automatically manages target
reference counts, we might think that we don't need to unpush targets
when an inferior is deleted...

...unfortunately that is not the case.  The inferior::unpush function
can do some work depending on the type of target, so it is important
that we still pass through this function.

To ensure that this is the case, in this commit I've added an assert
to inferior::~inferior that ensures the inferior's target_stack is
empty (except for the ever present dummy_target).

I've then added a pop_all_targets call to delete_inferior, otherwise
the new assert will fire in, e.g. the gdb.python/py-inferior.exp test.

gdb: remove the pop_all_targets (and friends) global functions

This commit removes the global functions pop_all_targets,
pop_all_targets_above, and pop_all_targets_at_and_above, and makes
them methods on the inferior class.

As the pop_all_targets functions will unpush each target, which
decrements the targets reference count, it is possible that the target
might be closed.

Right now, closing a target, in some cases, depends on the current
inferior being set correctly, that is, to the inferior from which the
target was popped.

To facilitate this I have used switch_to_inferior_no_thread within the
new methods.  Previously it was the responsibility of the caller to
ensure that the correct inferior was selected.

In a couple of places (event-top.c and top.c) I have been able to
remove a previous switch_to_inferior_no_thread call.

In remote_unpush_target (remote.c) I have left the
switch_to_inferior_no_thread call as it is required for the
generic_mourn_inferior call.

gdb: remove decref_target

The decref_target function is not really needed.  Calling
target_ops::decref will just redirect to decref_target anyway, so why
not just rename decref_target to target_ops::decref?

That's what this commit does.

It's not exactly renaming to target_ops::decref, because the decref
functionality is handled by a policy class, so the new name is now
target_ops_ref_policy::decref.

There should be no user visible change after this commit.

gdb: have target_stack automate reference count handling

This commit changes the target_stack class from using a C style array
of 'target_ops *' to using a C++ std::array<target_ops_ref, ...>.  The
benefit of this change is that some of the reference counting of
target_ops objects is now done automatically.

This commit fixes a crash in gdb.python/py-inferior.exp where GDB
crashes at exit, leaving a core file behind.

The crash occurs in connpy_connection_dealloc, and is actually
triggered by this assert:

gdb_assert (conn_obj->target == nullptr);

Now a little aside...

    ... the assert is never actually printed, instead GDB crashes due
    to calling a pure virtual function.  The backtrace at the point of
    crash looks like this:

      #7  0x00007fef7e2cf747 in std::terminate() () from /lib64/libstdc++.so.6
      #8  0x00007fef7e2d0515 in __cxa_pure_virtual () from /lib64/libstdc++.so.6
      #9  0x0000000000de334d in target_stack::find_beneath (this=0x4934d78, t=0x2bda270 <the_dummy_target>) at ../../s>
      #10 0x0000000000df4380 in inferior::find_target_beneath (this=0x4934b50, t=0x2bda270 <the_dummy_target>) at ../.>
      #11 0x0000000000de2381 in target_ops::beneath (this=0x2bda270 <the_dummy_target>) at ../../src/gdb/target.c:3047
      #12 0x0000000000de68aa in target_ops::supports_terminal_ours (this=0x2bda270 <the_dummy_target>) at ../../src/gd>
      #13 0x0000000000dde6b9 in target_supports_terminal_ours () at ../../src/gdb/target.c:1112
      #14 0x0000000000ee55f1 in internal_vproblem(internal_problem *, const char *, int, const char *, typedef __va_li>

    Notice in frame #12 we called target_ops::supports_terminal_ours,
    however, this is the_dummy_target, which is of type dummy_target,
    and so we should have called dummy_target::supports_terminal_ours.
    I believe the reason we ended up in the wrong implementation of
    supports_terminal_ours (which is a virtual function) is because we
    made the call during GDB's shut-down, and, I suspect, the vtables
    were in a weird state.

    Anyway, the point of this patch is not to fix GDB's ability to
    print an assert during exit, but to address the root cause of the
    assert.  With that aside out of the way, we can return to the main
    story...

Connections are represented in Python with gdb.TargetConnection
objects (or its sub-classes).  The assert in question confirms that
when a gdb.TargetConnection is deallocated, the underlying GDB
connection has itself been removed from GDB.  If this is not true then
we risk creating multiple different gdb.TargetConnection objects for
the same connection, which would be bad.

To ensure that we have one gdb.TargetConnection object for each
connection, the all_connection_objects map exists, this maps the
process_stratum_target object (the connection) to the
gdb.TargetConnection object that represents the connection.

When a connection is removed in GDB the connection_removed observer
fires, which we catch with connpy_connection_removed, this function
then sets conn_obj->target to nullptr, and removes the corresponding
entry from the all_connection_objects map.

The first issue here is that connpy_connection_dealloc is being called
as part of GDB's exit code, which is run after the Python interpreter
has been shut down.  The connpy_connection_dealloc function is used to
deallocate the gdb.TargetConnection Python object.  Surely it is
wrong for us to be deallocating Python objects after the interpreter
has been shut down.

The reason why connpy_connection_dealloc is called during GDB's exit
is that the global all_connection_objects map is still holding a
reference to the gdb.TargetConnection object.  When the map is
destroyed during GDB's exit, the gdb.TargetConnection objects within
the map can finally be deallocated.

The reason why all_connection_objects has contents when GDB exits, and
the reason the assert fires, is that, when GDB exits, there are still
some connections that have not yet been removed from GDB, that is,
they have a non-zero reference count.

If we take a look at quit_force (top.c) you can see that, for each
inferior, we call pop_all_targets before we (later in the function)
call do_final_cleanups.  It is the do_final_cleanups call that is
responsible for shutting down the Python interpreter.  The
pop_all_targets calls should, in theory, cause all the connections to
be removed from GDB.

That this isn't working indicates that some targets have a non-zero
reference count even after this final pop_all_targets call, and
indeed, when I debug GDB, that is what I see.

I tracked the problem down to delete_inferior where we do some house
keeping, and then delete the inferior object, which calls
inferior::~inferior.

In neither delete_inferior or inferior::~inferior do we call
pop_all_targets, and it is this missing call that means we leak some
references to the target_ops objects on the inferior's target_stack.

In this commit I will provide a partial fix for the problem.  I say
partial fix, but this will actually be enough to resolve the crash.
In a later commit I will provide the final part of the fix.

As mentioned at the start of the commit message, this commit changes
the m_stack in target_stack to hold target_ops_ref objects.  This
means that when inferior::~inferior is called, and m_stack is
released, we automatically decrement the target_ops reference count.
With this change in place we no longer leak any references, and now,
in quit_force the final pop_all_targets calls will release the final
references.  This means that the targets will be correctly closed at
this point, which means the connections will be removed from GDB and
the Python objects deallocated before the Python interpreter shuts
down.

There's a slight oddity in target_stack::unpush, where we std::move
the reference out of m_stack like this:

  auto ref = std::move (m_stack[stratum]);

the `ref' isn't used explicitly, but it serves to hold the
target_ops_ref until the end of the scope while allowing the m_stack
entry to be reset back to nullptr.  The alternative would be to
directly set the m_stack entry to nullptr, like this:

  m_stack[stratum] = nullptr;

The problem here is that when we set the m_stack entry to nullptr we
first decrement the target_ops reference count, and then set the array
entry to nullptr.

If the decrement means that the target_ops object reaches a zero
reference count then the target_ops object will be closed by calling
target_close.  In target_close we ensure that the target being closed
is not in any inferiors target_stack.

As we decrement before clearing, then this check in target_close will
fail, and an assert will trigger.

By using std::move to move the reference out of m_stack, this clears
the m_stack entry, meaning the inferior no longer contains the
target_ops in its target_stack.  Now when the REF object goes out of
scope and the reference count is decremented, target_close can run
successfully.

I've made use of the Python connection_removed listener API to add a
test for this issue.  The test installs a listener and then causes
delete_inferior to be called, we can then see that the connection is
then correctly removed (because the listener triggers).

gdb/remote: remove some manual reference count handling

While working on some other target_ops reference count related code, I
spotted that in remote.c we do some manual reference count handling,
i.e. we call target_ops::incref and decref_target (which wraps
target_ops::decref).

I think it would be better to make use of gdb::ref_ptr to automate the
reference count management.

So, this commit updates scoped_mark_target_starting in two ways,
first, I use gdb::ref_ptr to handle the reference counts.  Then,
instead of using the scoped_mark_target_starting constructor and
destructor to set and reset the starting_up flag, I now use a
scoped_restore_tmpl object to set and restore the flag.

The above changes mean that the scoped_mark_target_starting destructor
can be completely removed, and the constructor body is now empty.

I've also fixed a typo in the class comment.

The only change in behaviour after this commit is that previously we
didn't care what the value of starting_up was, we just set it to true
in the constructor and false in the destructor.

Now, I assert that the flag is initially false, then set the flag true
when the scoped_mark_target_starting is created.

As the starting_up flag is initialized to false then, for the assert
to fire, we would need to recursively enter
remote_target::start_remote_1, which I don't think is something we
should be doing, so I think the new assert is an improvement.

Re: ld, gold: remove support for -z bndplt (MPX prefix)

Don't attempt to run gold tests with -z bndplt

* testsuite/Makefile.am (exception_x86_64_bnd_test, bnd_plt_1.sh),
(bnd_ifunc_1.sh, bnd_ifunc_2.sh): Delete rules.
* testsuite/Makefile.in: Regenerate.
* testsuite/bnd_ifunc_1.s: Delete.
* testsuite/bnd_ifunc_1.sh: Delete.
* testsuite/bnd_ifunc_2.s: Delete.
* testsuite/bnd_ifunc_2.sh: Delete.
* testsuite/bnd_plt_1.s: Delete.
* testsuite/bnd_plt_1.sh: Delete.

asan: buffer overflow in sh_reloc

* coff-sh.c (sh_reloc): Use bfd_reloc_offset_in_range.

Fix haiku ld dependencies

I noticed after commit 8ad93045ed, "ld, gold: remove support for -z
bndplt (MPX prefix)", that some of my builds were failing with

eelf_x86_64_haiku.c:650:9: error: no member named 'bndplt' in 'struct elf_linker_x86_params'
        params.bndplt = true;
        ~~~~~~ ^

* emulparams/aarch64haiku.sh: Use "source_sh" rather than ".".
* emulparams/armelf_haiku.sh: Likewise.
* emulparams/elf32ppchaiku.sh: Likewise.
* emulparams/elf_mipsel_haiku.sh: Likewise.
* emulparams/elf_x86_64_haiku.sh: Likewise.