This is the 2.39 release

1 files changed, 68733 insertions, 0 deletions

diff --git a/ChangeLog.git b/ChangeLog.git
new file mode 100644
index 0000000000..5d2aa151b7
--- /dev/null
+++ b/ChangeLog.git
@@ -0,0 +1,68733 @@
+2022-08-05  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-08-04  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-08-03  Ruud van der Pas  <ruud.vanderpas@oracle.com>
+
+	gprofng: fix bug 29410 - Argument "&nbsp;0." isn't numeric in numeric gt (>)
+	gprofng/Changelog:
+	2022-08-02  Ruud van der Pas  <ruud.vanderpas@oracle.com>
+
+		PR gprofng/29410
+		* gp-display-html/gp-display-html.in: Remove non-breaking spaces.
+
+2022-08-03  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-08-02  Matthew Malcomson  <hardenedapple@gmail.com>
+
+	ld: aarch64: Update test linker scripts relocs.ld and relocs-ilp32.ld
+	The updates are to ensure that the .data section exists.  This means
+	that we always have a data section.  That means that we don't create a
+	RWX segment and avoid the corresponding warning.
+
+	We get this warning when testing aarch64-none-elf with -mcmodel=tiny.
+	N.b. this changes quite a few testcases from fail to pass.
+
+2022-08-02  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-08-01  Alan Modra  <amodra@gmail.com>
+
+	libctf: Avoid use of uninitialised variables
+		* ctf-link.c (ctf_link_add_ctf_internal): Don't free uninitialised
+		pointers.
+
+	(cherry picked from commit 9ea6fffe1ebec9bd1929c708e044b765eabea258)
+
+2022-08-01  Alan Modra  <amodra@gmail.com>
+
+	PR29348, BFD_VMA_FMT wrong
+	There is a problem with my commit 0e3c1eebb2, which replaced
+	bfd_uint64_t with uint64_t: Some hosts typedef int64_t to long long
+	even when long is the same size as long long.  That confuses the code
+	choosing one of "l", "ll", or "I64" for BFD_VMA_FMT, and results in
+	warnings.
+
+	Write a direct configure test for the printf int64_t style instead.
+	This removes the last use of BFD_HOST_64BIT_LONG, so delete that.
+	Note that the changes to configure.com are pure guesswork.
+
+		PR 29348
+		* bfd-in.h (BFD_HOST_64BIT_LONG): Don't define.
+		(BFD_VMA_FMT): Define using BFD_INT64_FMT when 64-bit.
+		(bfd_vma, bfd_signed_vma): Move comments to 64-bit typedefs.
+		* configure.ac (BFD_HOST_64BIT_LONG): Delete.
+		(BFD_INT64_FMT): New config test.
+		* configure.com: Update similarly.
+		* Makefile.in: Regenerate.
+		* bfd-in2.h: Regenerate.
+		* configure: Regenerate.
+
+	(cherry picked from commit 1a5178fe284547ef2abd8ae66588c9999d61c524)
+
+2022-08-01  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-31  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-30  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-29  Nick Clifton  <nickc@redhat.com>
+
+	Stop the linker from complaining about unrecognized DW_FORM_rnglistx and DW_FORM_loclistx attribute formats.
+		PR 29424
+		* dwarf2.c (read_attribute_value): Handle DW_FORM_rnglistx and
+		DW_FORM_loclistx.
+
+2022-07-29  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
+
+	ld: Extend ac_default_ld_warn_rwx_segments to all SPARC targets [PR29411]
+	As discussed in PR ld/29411, the ld warning
+
+		[...] has a LOAD segment with RWX permissions
+
+	needs to be disabled on all SPARC targets, not just Solaris/SPARC: the
+	.plt section is required to be RWX by the 32-bit SPARC ELF psABI and the
+	64-bit SPARC Compliance Definition 2.4.1.  Given that ld only supports
+	SPARC ELF targets, this patch implements this.
+
+	Tested on sparc64-unknown-linux-gnu and sparc-sun-solaris2.11.
+
+	2022-07-28  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
+
+		ld:
+		PR ld/29411
+		* configure.tgt (ac_default_ld_warn_rwx_segments): Extend to all
+		sparc targets.  Expand comment.
+
+2022-07-29  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-28  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-27  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-27  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+	gprofng: check for the makeinfo version
+	gprofng/ChangeLog
+	2022-07-25  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+		PR gprofng/29368
+		* configure.ac: Check for the makeinfo version.
+		* configure: Rebuild.
+
+2022-07-26  Nick Clifton  <nickc@redhat.com>
+
+	Stop the linker from complaining about RWX segments on sparc-solaris targets.
+		PR 29411
+		* configure.tgt (ac_default_ld_warn_rwx_segments): Disable for
+		sparc-solaris configurations.
+
+2022-07-26  Alan Modra  <amodra@gmail.com>
+
+	PowerPC32 ld test fails with --enable-targets=all
+	Three pppc32 ld tests fail when spu support is included in the linker
+	due to this snippet in ld/emulparams/elf32ppc.sh.
+
+	if grep -q 'ld_elf32_spu_emulation' ldemul-list.h; then
+	  DATA_START_SYMBOLS="${RELOCATING+*crt1.o(.data .data.* .gnu.linkonce.d.*)
+	    PROVIDE (__spe_handle = .);
+	    *(.data.spehandle)
+	    . += 4 * (DEFINED (__spe_handle) || . != 0);}"
+	fi
+
+		* testsuite/ld-powerpc/tlsexe32.r: Pass with .data section present.
+		* testsuite/ld-powerpc/tlsexe32no.r: Likewise.
+		* testsuite/ld-powerpc/tlsso32.r: Likewise.
+
+	(cherry picked from commit c138af95731c630a78329fd86076992f82099957)
+
+2022-07-26  Nick Clifton  <nickc@redhat.com>
+
+	Updated translations for various sub-directories
+
+2022-07-26  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-25  Ruud van der Pas  <ruud.vanderpas@oracle.com>
+
+	gprofng: fix bug 29356 - Execution fails if gprofng is not included in PATH
+	gprofng/Changelog:
+	2022-07-22  Ruud van der Pas  <ruud.vanderpas@oracle.com>
+
+		PR gprofng/29356
+		* gp-display-html/gp-display-html.in: fixed a problem to execute
+		gp-display-text in case gprofng is not included in the search
+		path.
+
+2022-07-25  Ruud van der Pas  <ruud.vanderpas@oracle.com>
+
+	gprofng: fix bug 29392 - Unexpected line format in summary file
+	gprofng/Changelog:
+	2022-07-22  Ruud van der Pas  <ruud.vanderpas@oracle.com>
+
+		PR gprofng/29392
+		* gp-display-html/gp-display-html.in: modified a regex, plus the
+		code to handle the results; renamed a variable to improve the
+		consistency in naming.
+
+2022-07-25  Ruud van der Pas  <ruud.vanderpas@oracle.com>
+
+	gprofng: fix bug 29353 - Fix a lay-out issue in the html disassembly files
+	gprofng/Changelog:
+	2022-07-22  Ruud van der Pas  <ruud.vanderpas@oracle.com>
+
+		PR gprofng/29353
+		* gp-display-html/gp-display-html.in: fixed a problem in the
+		generation of html for the disassembly where instructions
+		without arguments were not handled correctly.
+
+2022-07-25  Ruud van der Pas  <ruud.vanderpas@oracle.com>
+
+	gprofng: fix bug 29352 - Fix the message Hexadecimal number > 0xffffffff non-portable
+	gprofng/Changelog:
+	2022-07-22  Ruud van der Pas  <ruud.vanderpas@oracle.com>
+
+		PR gprofng/29352
+		* gp-display-html/gp-display-html.in: the hex subroutine from
+		the bigint module is now used.
+
+2022-07-25  Ruud van der Pas  <ruud.vanderpas@oracle.com>
+
+	gprofng: fix bug 29351 - Move dynamic loading of modules to a later stage
+	gprofng/Changelog:
+	2022-07-22  Ruud van der Pas  <ruud.vanderpas@oracle.com>
+
+		PR gprofng/29351
+		* gp-display-html/gp-display-html.in: the dynamic loading of
+		modules occurred too early, resulting in the generation of the
+		man page to fail in case a module is missing; the loading part is
+		now done somewhat later in the execution to avoid this problem.
+
+2022-07-25  H.J. Lu  <hjl.tools@gmail.com>
+
+	x86: Disallow invalid relocations against protected symbols
+	Since glibc 2.36 will issue warnings for copy relocation against
+	protected symbols and non-canonical reference to canonical protected
+	functions, change the linker to always disallow such relocations.
+
+	bfd/
+
+		* elf32-i386.c (elf_i386_scan_relocs): Remove check for
+		elf_has_indirect_extern_access.
+		* elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise.
+		(elf_x86_64_relocate_section): Remove check for
+		elf_has_no_copy_on_protected.
+		* elfxx-x86.c (elf_x86_allocate_dynrelocs): Check for building
+		executable instead of elf_has_no_copy_on_protected.
+		(_bfd_x86_elf_adjust_dynamic_symbol): Disallow copy relocation
+		against non-copyable protected symbol.
+		* elfxx-x86.h (SYMBOL_NO_COPYRELOC): Remove check for
+		elf_has_no_copy_on_protected.
+
+	ld/
+
+		* testsuite/ld-i386/i386.exp: Expect linker error for PR ld/17709
+		test.
+		* testsuite/ld-i386/pr17709.rd: Removed.
+		* testsuite/ld-i386/pr17709.err: New file.
+		* testsuite/ld-x86-64/pr17709.rd: Removed.
+		* testsuite/ld-x86-64/pr17709.err: New file.
+		* testsuite/ld-x86-64/pr28875-func.err: Updated.
+		* testsuite/ld-x86-64/x86-64.exp: Expect linker error for PR
+		ld/17709 test.  Add tests for function pointer against protected
+		function.
+
+	(cherry picked from commit f638657759f5b9b4eb31a1aa6b9fe6e6fb01f4a0)
+
+2022-07-25  Fangrui Song  <i@maskray.me>
+
+	x86: Make protected symbols local for -shared
+	Call _bfd_elf_symbol_refs_local_p with local_protected==true.  This has
+	2 noticeable effects for -shared:
+
+	* GOT-generating relocations referencing a protected data symbol no
+	  longer lead to a GLOB_DAT (similar to a hidden symbol).
+	* Direct access relocations (e.g. R_X86_64_PC32) no longer has the
+	  confusing diagnostic below.
+
+	    __attribute__((visibility("protected"))) void *foo() {
+	      return (void *)foo;
+	    }
+
+	    // gcc -fpic -shared -fuse-ld=bfd
+	    relocation R_X86_64_PC32 against protected symbol `foo' can not be used when making a shared object
+
+	The new behavior matches arm, aarch64 (commit
+	83c325007c5599fa9b60b8d5f7b84842160e1d1b), and powerpc ports, and other
+	linkers: gold and ld.lld.
+
+	Note: if some code tries to use direct access relocations to take the
+	address of foo, the pointer equality will break, but the error should be
+	reported on the executable link, not on the innocent shared object link.
+	glibc 2.36 will give a warning at relocation resolving time.
+
+	With this change, `#define elf_backend_extern_protected_data 1` is no
+	longer effective.  Just remove it.
+
+	Remove the test "Run protected-func-1 without PIE" since -fno-pic
+	address taken operation in the executable doesn't work with protected
+	symbol in a shared object by default.  Similarly, remove
+	protected-data-1a and protected-data-1b.  protected-data-1b can be made
+	working by removing HAVE_LD_PIE_COPYRELOC from GCC
+	(https://sourceware.org/pipermail/gcc-patches/2022-June/596678.html).
+
+	(cherry picked from commit d19a265487eda186b6977d9d15648cda9fad3298)
+
+2022-07-25  Alan Modra  <amodra@gmail.com>
+
+	Re: PowerPC64 .branch_lt address
+	On seeing PR29369 my suspicion was naturally on a recent powerpc64
+	change, commit 0ab80031430e.  Without a reproducer, I spent time
+	wondering what could have gone wrong, and while I doubt this patch
+	would have fixed the PR, there are some improvements that can be made
+	to cater for user silliness.
+
+	I also noticed that when -z relro -z now sections are created out of
+	order, with .got before .plt in the section headers but .got is laid
+	out at a higher address.  That's due to the address expression for
+	.branch_lt referencing SIZEOF(.got) and so calling init_os (which
+	creates a bfd section) for .got before the .plt section is created.
+	Fix that by ignoring SIZEOF in exp_init_os.  Unlike ADDR and LOADADDR
+	which need to reference section vma and lma respectively, SIZEOF can
+	and does cope with a missing bfd section by returning zero for its
+	size, which of course is correct.
+
+		PR 29369
+		* ldlang.c (exp_init_os): Don't create a bfd section for SIZEOF.
+		* emulparams/elf64ppc.sh (OTHER_RELRO_SECTIONS_2): Revise
+		.branch_lt address to take into account possible user sections
+		with alignment larger than 8 bytes.
+
+	(cherry picked from commit 5d471bd907be60e9858b22cdf4fd10ddc0f6ee1a)
+
+2022-07-25  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-24  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-23  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-22  H.J. Lu  <hjl.tools@gmail.com>
+
+	i386: Don't allow GOTOFF relocation against IFUNC symbol for PIC
+	We can't use the PLT entry as the function address for PIC since the PIC
+	register may not be set up properly for indirect call.
+
+	bfd/
+
+		PR ld/27998
+		* elf32-i386.c (elf_i386_relocate_section): Don't allow GOTOFF
+		relocation against IFUNC symbol for PIC.
+
+	ld/
+
+		PR ld/27998
+		* testsuite/ld-i386/pr27998a.d: Replace -shared with -e bar.
+		* testsuite/ld-i386/pr27998b.d: Expect a linker error.
+		* testsuite/ld-ifunc/ifunc-2-i386-now.d: Updated.
+		* testsuite/ld-ifunc/ifunc-2-local-i386-now.d: Likewise.
+		* testsuite/ld-ifunc/ifunc-2-i386.s: Replace @GOTOFF with @GOT.
+		* testsuite/ld-ifunc/ifunc-2-local-i386.s: Likewise.
+
+	(cherry picked from commit 8f29211c3f0a6335c17e0a90396c146facf6dba4)
+
+2022-07-22  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-21  Peter Bergner  <bergner@linux.ibm.com>
+
+	PowerPC: Create new MMA instruction masks and use them
+	The MMA instructions use XX3_MASK|3<<21 as an instruction mask, but that
+	misses the RC bit/bit 31, so if we disassemble a .long that represents an
+	MMA instruction except that it also has bit 31 set, we will erroneously
+	disassemble it to that MMA instruction.  We create new masks defines that
+	contain bit 31 so that doesn't happen anymore.
+
+	opcodes/
+		* ppc-opc.c (XACC_MASK, XX3ACC_MASK): New defines.
+		(P_GER_MASK, xxmfacc, xxmtacc, xxsetaccz, xvi8ger4pp, xvi8ger4,
+		xvf16ger2pp, xvf16ger2, xvf32gerpp, xvf32ger, xvi4ger8pp, xvi4ger8,
+		xvi16ger2spp, xvi16ger2s, xvbf16ger2pp, xvbf16ger2, xvf64gerpp,
+		xvf64ger, xvi16ger2, xvf16ger2np, xvf32gernp, xvi8ger4spp, xvi16ger2pp,
+		xvbf16ger2np, xvf64gernp, xvf16ger2pn, xvf32gerpn, xvbf16ger2pn,
+		xvf64gerpn, xvf16ger2nn, xvf32gernn, xvbf16ger2nn, xvf64gernn: Use them.
+
+	(cherry picked from commit 0a246853439422e12a0ccb9191be638aab3987eb)
+
+2022-07-21  Jan Beulich  <jbeulich@suse.com>
+
+	x86: replace wrong attributes on VCVTDQ2PH{X,Y}
+	A standalone (without SAE) StaticRounding attribute is meaningless, and
+	indeed all other similar insns have ATTSyntax there instead. I can only
+	assume this was some strange copy-and-paste mistake.
+
+	(cherry picked from commit ea09fe92596fbb2a5da4595459bfe8b23789ec8d)
+
+2022-07-21  Jan Beulich  <jbeulich@suse.com>
+
+	x86/Intel: correct AVX512F scatter insn element sizes
+	I clearly screwed up in 6ff00b5e12e7 ("x86/Intel: correct permitted
+	operand sizes for AVX512 scatter/gather") giving all AVX512F scatter
+	insns Dword element size. Update testcases (also their gather parts),
+	utilizing that there previously were two identical lines each (for no
+	apparent reason).
+
+	(cherry picked from commit 987e8a90fa6541d57b42fef95fae0a7da5a2c9bc)
+
+2022-07-21  Alan Modra  <amodra@gmail.com>
+
+	PR29390, DW_CFA_AARCH64_negate_ra_state vs. DW_CFA_GNU_window_save
+		PR 29390
+	binutils/
+		* dwarf.c (is_aarch64, DW_CFA_GNU_window_save_name): New.
+		(display_debug_frames): Use them.
+		(init_dwarf_regnames_aarch64): Set is_aarch64.
+		(init_dwarf_regnames_by_elf_machine_code): Clear is_aarch64.
+		(init_dwarf_regnames_by_bfd_arch_and_mach): Likewise.
+	gas/
+		* testsuite/gas/aarch64/pac_ab_key.d: Adjust expected output.
+		* testsuite/gas/aarch64/pac_negate_ra_state.d: Likewise.
+
+	(cherry picked from commit e4e340a3ff2ccc825f4a40abf947cdf32b3fdbbf)
+
+2022-07-21  Alan Modra  <amodra@gmail.com>
+
+	PR29337, readelf CU/TU mixup in .gdb_index
+	Commit 244e19c79111 changed a number of variables in display_gdb_index
+	to count entries rather than words.
+
+		PR 29337
+		* dwarf.c (display_gdb_index): Correct use of cu_list_elements.
+
+	(cherry picked from commit e82295b23d0e52b0dadffb8c0d0b99462cd20fa8)
+
+2022-07-21  Alan Modra  <amodra@gmail.com>
+
+	PowerPC64: fix build error on 32-bit hosts
+	elf64-ppc.c:11673:33: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘bfd_vma’ {aka ‘long long unsigned int’} [-Werror=format=]
+	11673 |   fprintf (stderr, "offset = %#lx:", stub_entry->stub_offset);
+	      |                              ~~~^    ~~~~~~~~~~~~~~~~~~~~~~~
+	      |                                 |              |
+	      |                                 |              bfd_vma {aka long long unsigned int}
+	      |                                 long unsigned int
+	      |                              %#llx
+
+		* elf64-ppc.c (dump_stub): Use BFD_VMA_FMT.
+
+	(cherry picked from commit 590207aa6ece509eabbc7a51aab87e5d9bcfc869)
+
+2022-07-21  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-20  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-19  H.J. Lu  <hjl.tools@gmail.com>
+
+	x86: Properly check invalid relocation against protected symbol
+	Only check invalid relocation against protected symbol defined in shared
+	object.
+
+	bfd/
+
+		PR ld/29377
+		* elf32-i386.c (elf_i386_scan_relocs): Only check invalid
+		relocation against protected symbol defined in shared object.
+		* elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise.
+
+	ld/
+
+		PR ld/29377
+		* testsuite/ld-elf/linux-x86.exp: Run PR ld/29377 tests.
+		* testsuite/ld-elf/pr29377a.c: New file.
+		* testsuite/ld-elf/pr29377b.c: Likewise.
+
+	(cherry picked from commit bd0736124c20950ac353f01e5029b7cb5d8a7010)
+
+	ld: Pass -nostdlib to compiler with -r
+
+	Pass -nostdlib to compiler with -r to avoid unnecessary .o file and
+	libraries.
+
+		PR ld/29377
+		* testsuite/ld-elf/linux-x86.exp: Pass -nostdlib with -r.
+
+	(cherry picked from commit 76e4fa70e79ee959c0e11eaacd4cf863291b1ddb)
+
+2022-07-19  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-18  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+	gprofng: link libgprofng.so against -lpthread
+	gprofng/ChangeLog
+	2022-07-15  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+		PR gprofng/29364
+		* src/Makefile.am (libgprofng_la_LIBADD): Add -lpthread.
+		* src/Makefile.in: Rebuild.
+
+2022-07-18  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+	gprofng: fix regression in build and a race condition in autoreconf
+	gprofng/ChangeLog
+	2022-07-14  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+		PR gprofng/29338
+		* libcollector/configure.ac (AC_CONFIG_HEADERS): Fix a race condition.
+		* libcollector/configure: Rebuild.
+		* libcollector/Makefile.in: Rebuild.
+		* common/config.h.in: Rebuild.
+		* common/lib-config.h.in: Created by autoreconf.
+
+2022-07-18  Jan Beulich  <jbeulich@suse.com>
+
+	x86: correct VMOVSH attributes
+	Both forms were missing VexW0 (thus allowing Evex.W=1 to be encoded by
+	suitable means, which would cause #UD). The memory operand form further
+	was using the wrong Masking value, thus allowing zeroing-masking to be
+	encoded for the store form (which would again cause #UD).
+
+	(cherry picked from commit 7e864bf71d55626dce94df26ebaf11f65b4d7b65)
+
+2022-07-18  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-17  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-16  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-15  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-14  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-13  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-12  Alan Modra  <amodra@gmail.com>
+
+	PR29355, ld segfaults with -r/-q and custom-named section .rela*
+	The bug testcase uses an output section named .rel or .rela which has
+	input .data sections mapped to it.  The input .data section has
+	relocations.  When counting output relocations SHT_REL and SHT_RELA
+	section reloc_count is ignored, with the justification that reloc
+	sections themselves can't have relocations and some backends use
+	reloc_count in reloc sections.  However, the test wrongly used the
+	output section type (which normally would match input section type).
+	Fix that.  Note that it is arguably wrong for ld to leave the output
+	.rel/.rela section type as SHT_REL/SHT_RELA when non-empty non-reloc
+	sections are written to it, but I'm not going to change that since it
+	might be useful to hand-craft relocs in a data section that is then
+	written to a SHT_REL/SHT_RELA output section.
+
+		PR 29355
+		* elflink.c (bfd_elf_final_link): Use input section type rather
+		than output section type to determine whether to exclude using
+		reloc_count from that section.
+
+	(cherry picked from commit 35c5dcc666082f0edf6dd559e46b98d0e7986a2e)
+
+2022-07-12  Alan Modra  <amodra@gmail.com>
+
+	ppc gas: don't leak ppc_hash memory
+		* config/tc-ppc.c (insn_obstack): New.
+		(insn_calloc): New function.
+		(ppc_setup_opcodes): Use insn_obstack for ppc_hash.
+
+	(cherry picked from commit a887be69963c40ced36e319e5fb14b3de4b6658b)
+	Without ppc_md_end since the infrastructure to call that late isn't
+	available on the branch, and without the multiply overflow check.
+
+2022-07-12  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-11  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-10  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-09  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-08  Andrew Burgess  <aburgess@redhat.com>
+
+	libopcodes/s390: add support for disassembler styling
+	This commit adds disassembler style to the libopcodes s390
+	disassembler.  This conversion was pretty straight forward, I just
+	converted the fprintf_func calls to fprintf_styled_func calls and
+	added an appropriate style.
+
+	For testing the new styling I just assembled then disassembled the
+	source files in gas/testsuite/gas/s390 and manually checked that the
+	styling looked reasonable.
+
+	If the user does not request styled output from objdump, then there
+	should be no change in the disassembler output after this commit.
+
+2022-07-08  Nick Clifton  <nickc@redhat.com>
+
+	Update version number
+
+	Add markers for 2.39 branch
+
+2022-07-08  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-07  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+	gprofng: fix regression in testing for not yet installed version
+	gprofng/ChangeLog
+	2022-07-07  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+		* src/Settings.cc (Settings::read_rc): Read environment variable
+		GPROFNG_SYSCONFDIR.
+		* testsuite/lib/Makefile.skel: Export GPROFNG_SYSCONFDIR.
+		* testsuite/gprofng.display/display.exp: Shorten the list of tests.
+
+2022-07-07  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: fix {rs6000_nat_target,aix_thread_target}::wait to not use inferior_ptid
+	Trying to run a simple program (empty main) on AIX, I get:
+
+	    (gdb) run
+	    Starting program: /scratch/simark/build/gdb/a.out
+	    Child process unexpectedly missing: There are no child processes..
+	    ../../src/binutils-gdb/gdb/inferior.c:304: internal-error: find_inferior_pid: Assertion `pid != 0' failed.
+	    A problem internal to GDB has been detected,
+	    further debugging may prove unreliable.
+	    ----- Backtrace -----
+	    0x10ef12a8 gdb_internal_backtrace_1()
+	            ../../src/binutils-gdb/gdb/bt-utils.c:122
+	    0x10ef1470 gdb_internal_backtrace()
+	            ../../src/binutils-gdb/gdb/bt-utils.c:168
+	    0x1004d368 internal_vproblem(internal_problem*, char const*, int, char const*, char*)
+	            ../../src/binutils-gdb/gdb/utils.c:396
+	    0x1004d8a8 internal_verror(char const*, int, char const*, char*)
+	            ../../src/binutils-gdb/gdb/utils.c:476
+	    0x1004c424 internal_error(char const*, int, char const*, ...)
+	            ../../src/binutils-gdb/gdbsupport/errors.cc:55
+	    0x102ab344 find_inferior_pid(process_stratum_target*, int)
+	            ../../src/binutils-gdb/gdb/inferior.c:304
+	    0x102ab4a4 find_inferior_ptid(process_stratum_target*, ptid_t)
+	            ../../src/binutils-gdb/gdb/inferior.c:318
+	    0x1061bae8 find_thread_ptid(process_stratum_target*, ptid_t)
+	            ../../src/binutils-gdb/gdb/thread.c:519
+	    0x10319e98 handle_inferior_event(execution_control_state*)
+	            ../../src/binutils-gdb/gdb/infrun.c:5532
+	    0x10315544 fetch_inferior_event()
+	            ../../src/binutils-gdb/gdb/infrun.c:4221
+	    0x10952e34 inferior_event_handler(inferior_event_type)
+	            ../../src/binutils-gdb/gdb/inf-loop.c:41
+	    0x1032640c infrun_async_inferior_event_handler(void*)
+	            ../../src/binutils-gdb/gdb/infrun.c:9548
+	    0x10673188 check_async_event_handlers()
+	            ../../src/binutils-gdb/gdb/async-event.c:335
+	    0x1066fce4 gdb_do_one_event()
+	            ../../src/binutils-gdb/gdbsupport/event-loop.cc:214
+	    0x10001a94 start_event_loop()
+	            ../../src/binutils-gdb/gdb/main.c:411
+	    0x10001ca0 captured_command_loop()
+	            ../../src/binutils-gdb/gdb/main.c:471
+	    0x10003d74 captured_main(void*)
+	            ../../src/binutils-gdb/gdb/main.c:1329
+	    0x10003e48 gdb_main(captured_main_args*)
+	            ../../src/binutils-gdb/gdb/main.c:1344
+	    0x10000744 main
+	            ../../src/binutils-gdb/gdb/gdb.c:32
+	    ---------------------
+	    ../../src/binutils-gdb/gdb/inferior.c:304: internal-error: find_inferior_pid: Assertion `pid != 0' failed.
+	    A problem internal to GDB has been detected,
+	    further debugging may prove unreliable.
+	    Quit this debugging session? (y or n)
+
+	This is due to some bit-rot in the AIX port, still relying on the entry
+	value of inferior_ptid in the wait methods.
+
+	Problem #1 is in rs6000_nat_target::wait, here:
+
+	      /* Ignore terminated detached child processes.  */
+	      if (!WIFSTOPPED (status) && pid != inferior_ptid.pid ())
+		pid = -1;
+
+	At this point, waitpid has returned an "exited" status for some pid, so
+	pid is non-zero.  Since inferior_ptid is set to null_ptid on entry, the
+	pid returned by wait is not equal to `inferior_ptid.pid ()`, so we reset
+	pid to -1 and go to waiting again.  Since there are not more children to
+	wait for, waitpid then returns -1 so we get here:
+
+	      if (pid == -1)
+		{
+		  gdb_printf (gdb_stderr,
+			      _("Child process unexpectedly missing: %s.\n"),
+			      safe_strerror (save_errno));
+
+		  /* Claim it exited with unknown signal.  */
+		  ourstatus->set_signalled (GDB_SIGNAL_UNKNOWN);
+		  return inferior_ptid;
+		}
+
+	We therefore return a "signalled" status with a null_ptid (again,
+	inferior_ptid is null_ptid).  This confuses infrun, because if the
+	target returns a "signalled" status, it should be coupled with a ptid
+	for an inferior that exists.
+
+	So, the first step is to fix the snippets above to not use
+	inferior_ptid.  In the first snippet, use find_inferior_pid to see if
+	we know the event process.  If there is no inferior with that pid, we
+	assume it's a detached child process to we ignore the event.  That
+	should be enough to fix the problem, because it should make it so we
+	won't go into the second snippet.  But still, fix the second snippet to
+	return an "ignore" status.  This is copied from inf_ptrace_target::wait,
+	which is where rs6000_nat_target::wait appears to be copied from in the
+	first place.
+
+	These changes, are not sufficient, as the aix_thread_target, which sits
+	on top of rs6000_nat_target, also relies on inferior_ptid.
+	aix_thread_target::wait, by calling pd_update, assumes that
+	rs6000_nat_target has set inferior_ptid to the appropriate value (the
+	ptid of the event thread), but that's not the case.  pd_update
+	returns inferior_ptid - null_ptid - and therefore
+	aix_thread_target::wait returns null_ptid too, and we still hit the
+	assert shown above.
+
+	Fix this by changing pd_activate, pd_update, sync_threadlists and
+	get_signaled_thread to all avoid using inferior_ptid.  Instead, they
+	accept as a parameter the pid of the process we are working on.
+
+	With this patch, I am able to run the program to completion:
+
+	    (gdb) r
+	    Starting program: /scratch/simark/build/gdb/a.out
+	    [Inferior 1 (process 11010794) exited normally]
+
+	As well as break on main:
+
+	    (gdb) b main
+	    Breakpoint 1 at 0x1000036c
+	    (gdb) r
+	    Starting program: /scratch/simark/build/gdb/a.out
+
+	    Breakpoint 1, 0x1000036c in main ()
+	    (gdb) c
+	    Continuing.
+	    [Inferior 1 (process 26083688) exited normally]
+
+	Change-Id: I7c2613bbefe487d75fa1a0c0994423471d961ee9
+
+2022-07-07  Pedro Alves  <pedro@palves.net>
+
+	Fix pedantically invalid DWARF in gdb.trace/unavailable-dwarf-piece.exp
+	The DWARF spec says:
+
+	  Any debugging information entry representing the declaration of an object,
+	  module, subprogram or type may have DW_AT_decl_file, DW_AT_decl_line and
+	  DW_AT_decl_column attributes, each of whose value is an unsigned integer
+								  ^^^^^^^^
+	  constant.
+
+	Grepping around the DWARF-assembler-based testcases, I noticed that
+	gdb.trace/unavailable-dwarf-piece.exp emits decl_line with
+	DW_FORM_sdata, a signed integer form.  This commit tweaks it to use
+	DW_FORM_udata instead.
+
+	Unsurprisingly, this:
+
+	  $ make check \
+	      TESTS="gdb.trace/unavailable-dwarf-piece.exp" \
+	      RUNTESTFLAGS="--target_board=native-gdbserver"
+
+	... still passes cleanly for me after this change.
+
+	I've noticed this because current llvm-dwarfdump crashed on an
+	ROCm-internal DWARF-assembler-based testcase that incorrectly used
+	signed forms for DW_AT_decl_file/DW_AT_decl_line.
+
+	The older llvm-dwarfdump found on Ubuntu 20.04 (LLVM 10) reads the
+	line numbers with signed forms as "0" instead of crashing.  Here's the
+	before/after fix for gdb.trace/unavailable-dwarf-piece.exp with that
+	llvm-dwarfdump version:
+
+	  $ diff -up before.txt after.txt
+	  --- before.txt    2022-07-07 13:21:28.387690334 +0100
+	  +++ after.txt     2022-07-07 13:21:39.379801092 +0100
+	  @@ -18,7 +18,7 @@
+			   DW_AT_name     ("s")
+			   DW_AT_byte_size        (3)
+			   DW_AT_decl_file        (0)
+	  -                DW_AT_decl_line        (0)
+	  +                DW_AT_decl_line        (1)
+
+	   0x0000002f:     DW_TAG_member
+			     DW_AT_name   ("a")
+	  @@ -41,7 +41,7 @@
+			   DW_AT_name     ("t")
+			   DW_AT_byte_size        (3)
+			   DW_AT_decl_file        (0)
+	  -                DW_AT_decl_line        (0)
+	  +                DW_AT_decl_line        (1)
+
+	   0x00000054:     DW_TAG_member
+			     DW_AT_name   ("a")
+
+	Change-Id: I5c866946356da421ff944019d0eca2607b2b738f
+
+2022-07-07  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: LoongArch: Fix typos in code comments
+	"it’s" should be "it's".
+
+2022-07-07  Maciej W. Rozycki  <macro@embecosm.com>
+
+	GDB/testsuite: Add coverage for `print -elements' command
+	We currently have no coverage for the `print -elements ...' command (or
+	`p -elements ...' in the shortened form), so add a couple of test cases
+	mimicking ones using corresponding `set print elements ...' values.
+
+2022-07-07  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: LoongArch: Implement the push_dummy_call gdbarch method
+	According to "Procedure Calling Convention" in "LoongArch ELF ABI
+	specification" [1], implement the push_dummy_call gdbarch method
+	as clear as possible.
+
+	[1] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html#_procedure_calling_convention
+
+2022-07-07  Tsukasa OI  <research_trasio@irq.a4lg.com>
+
+	RISC-V: Added Zfhmin and Zhinxmin.
+	This commit adds Zfhmin and Zhinxmin extensions (subsets of Zfh and
+	Zhinx extensions, respectively).  In the process supporting Zfhmin and
+	Zhinxmin extension, this commit also changes how instructions are
+	categorized considering Zfhmin, Zhinx and Zhinxmin extensions.
+
+	Detailed changes,
+
+	* From INSN_CLASS_ZFH to INSN_CLASS_ZFHMIN:
+
+	flh, fsh, fmv.x.h and fmv.h.x.
+
+	* From INSN_CLASS_ZFH to INSN_CLASS_ZFH_OR_ZHINX:
+
+	fmv.h.
+
+	* From INSN_CLASS_ZFH_OR_ZHINX to INSN_CLASS_ZFH_OR_ZHINX:
+
+	fneg.h, fabs.h, fsgnj.h, fsgnjn.h, fsgnjx.h,
+	fadd.h, fsub.h, fmul.h, fdiv.h, fsqrt.h, fmin.h, fmax.h,
+	fmadd.h, fnmadd.h, fmsub.h, fnmsub.h,
+	fcvt.w.h, fcvt.wu.h, fcvt.h.w, fcvt.h.wu,
+	fcvt.l.h, fcvt.lu.h, fcvt.h.l, fcvt.h.lu,
+	feq.h, flt.h, fle.h, fgt.h, fge.h,
+	fclass.h.
+
+	* From INSN_CLASS_ZFH_OR_ZHINX to INSN_CLASS_ZFHMIN_OR_ZHINXMIN:
+
+	fcvt.s.h and fcvt.h.s.
+
+	* From INSN_CLASS_D_AND_ZFH_INX to INSN_CLASS_ZFHMIN_AND_D:
+
+	fcvt.d.h and fcvt.h.d.
+
+	* From INSN_CLASS_Q_AND_ZFH_INX to INSN_CLASS_ZFHMIN_AND_Q:
+
+	fcvt.q.h and fcvt.h.q.
+
+	bfd/ChangeLog:
+
+		* elfxx-riscv.c (riscv_implicit_subsets): Change implicit
+		subsets.  Zfh->Zicsr is not needed and Zfh->F is replaced with
+		Zfh->Zfhmin and Zfhmin->F.  Zhinx->Zicsr is not needed and
+		Zhinx->Zfinx is replaced with Zhinx->Zhinxmin and
+		Zhinxmin->Zfinx.
+		(riscv_supported_std_z_ext): Added zfhmin and zhinxmin.
+		(riscv_multi_subset_supports):  Rewrite handling for new
+		instruction classes.
+		(riscv_multi_subset_supports_ext): Updated.
+		(riscv_parse_check_conflicts): Change error message to include
+		zfh and zfhmin extensions.
+
+	gas/ChangeLog:
+
+		* testsuite/gas/riscv/zfhmin-d-insn-class-fail.s: New complex
+		error handling test.
+		* testsuite/gas/riscv/zfhmin-d-insn-class-fail-1.d: Likewise.
+		* testsuite/gas/riscv/zfhmin-d-insn-class-fail-1.l: Likewise.
+		* testsuite/gas/riscv/zfhmin-d-insn-class-fail-2.d: Likewise.
+		* testsuite/gas/riscv/zfhmin-d-insn-class-fail-2.l: Likewise.
+		* testsuite/gas/riscv/zfhmin-d-insn-class-fail-3.d: Likewise.
+		* testsuite/gas/riscv/zfhmin-d-insn-class-fail-3.l: Likewise.
+		* testsuite/gas/riscv/zfhmin-d-insn-class-fail-4.d: Likewise.
+		* testsuite/gas/riscv/zfhmin-d-insn-class-fail-4.l: Likewise.
+		* testsuite/gas/riscv/zfhmin-d-insn-class-fail-5.d: Likewise.
+		* testsuite/gas/riscv/zfhmin-d-insn-class-fail-5.l: Likewise.
+		* testsuite/gas/riscv/zhinx.d: Renamed from fp-zhinx-insns.d
+		and refactored.
+		* testsuite/gas/riscv/zhinx.s: Likewise.
+
+	include/ChangeLog:
+
+		* opcode/riscv.h (enum riscv_insn_class): Removed INSN_CLASS_ZFH,
+		INSN_CLASS_D_AND_ZFH_INX and INSN_CLASS_Q_AND_ZFH_INX.  Added
+		INSN_CLASS_ZFHMIN, INSN_CLASS_ZFHMIN_OR_ZHINXMIN,
+		INSN_CLASS_ZFHMIN_AND_D and INSN_CLASS_ZFHMIN_AND_Q.
+
+	opcodes/ChangeLog:
+
+		* riscv-opc.c (riscv_opcodes): Change instruction classes for
+		Zfh and Zfhmin instructions.  Fix `fcvt.h.lu' instruction
+		(two operand variant) mask.
+
+2022-07-07  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+	gprofng: adjust GPROFNG_VARIANT
+	GPROFNG_VARIANT depends on compiler options, not on $(host).
+
+	gprofng/ChangeLog
+	2022-07-06  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+		PR gprofng/29116
+		* libcollector/configure.ac: Adjust GPROFNG_VARIANT.
+		* libcollector/configure: Rebuild.
+
+2022-07-07  Tsukasa OI  <research_trasio@irq.a4lg.com>
+
+	RISC-V: Fix disassembling Zfinx with -M numeric
+	This commit fixes floating point operand register names from ABI ones
+	to dynamically set ones.
+
+	gas/ChangeLog:
+
+		* testsuite/gas/riscv/zfinx-dis-numeric.s: Test new behavior of
+		Zfinx extension and -M numeric disassembler option.
+		* testsuite/gas/riscv/zfinx-dis-numeric.d: Likewise.
+
+	opcodes/ChangeLog:
+
+		* riscv-dis.c (riscv_disassemble_insn): Use dynamically set GPR
+		names to disassemble Zfinx instructions.
+
+2022-07-07  Tsukasa OI  <research_trasio@irq.a4lg.com>
+
+	RISC-V: Fix requirement handling on Zhinx+{D,Q}
+	This commit fixes how instructions are masked on Zhinx+Z{d,q}inx.
+	fcvt.h.d and fcvt.d.h require ((D&&Zfh)||(Zdinx&&Zhinx)) and
+	fcvt.h.q and fcvt.q.h require ((Q&&Zfh)||(Zqinx&&Zhinx)).
+
+	bfd/ChangeLog:
+
+		* elfxx-riscv.c (riscv_multi_subset_supports): Fix feature gate
+		on INSN_CLASS_{D,Q}_AND_ZFH_INX.
+		(riscv_multi_subset_supports_ext): Fix feature gate diagnostics
+		on INSN_CLASS_{D,Q}_AND_ZFH_INX.
+
+	gas/ChangeLog:
+
+		* testsuite/gas/riscv/fp-zhinx-insns.d: Add Zqinx to -march
+		for proper testing.
+
+2022-07-07  Alan Modra  <amodra@gmail.com>
+
+	PR29320, 'struct obstack' declared inside parameter list
+		PR 29320
+		* frags.h: Move declaration of struct obstack..
+		* as.h: ..to here.
+
+2022-07-07  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-06  Ruud van der Pas  <ruud.vanderpas@oracle.com>
+
+	gprofng: implement a functional gp-display-html
+	This patch enables the first support for the "gprofng display html" command.
+	This command works for C/C++ applications on x86_64. Using one or more gprofng
+	experiment directories as input, a new directory with html files is created.
+	Through the index.html file in this directory, the performance results may be
+	viewed in a browser.
+
+	gprofng/Changelog:
+	2022-06-28  Ruud van der Pas  <ruud.vanderpas@oracle.com>
+
+		* gp-display-html/gp-display-html.in: implement first support for x86_64 and C/C++
+
+2022-07-06  H.J. Lu  <hjl.tools@gmail.com>
+
+	elf: Copy p_align of PT_GNU_STACK for stack alignment
+	commit 74e315dbfe5200c473b226e937935fb8ce391489
+	Author: H.J. Lu <hjl.tools@gmail.com>
+	Date:   Mon Dec 13 19:46:04 2021 -0800
+
+	    elf: Set p_align to the minimum page size if possible
+
+	may ignore p_align of PT_GNU_STACK when copying ELF program header if
+	the maximum page size is larger than p_align of PT_LOAD segments.  Copy
+	p_align of PT_GNU_STACK since p_align of PT_GNU_STACK describes stack
+	alignment, not page size,
+
+		PR binutils/29319
+		* elf.c (copy_elf_program_header): Copy p_align of PT_GNU_STACK
+		for stack alignment.
+
+2022-07-06  Jan Beulich  <jbeulich@suse.com>
+
+	x86: make D attribute usable for XOP and FMA4 insns
+	This once again allows to reduce redundancy in (and size of) the opcode
+	table.
+
+	Don't go as far as also making D work on the two 5-operand XOP insns:
+	This would significantly complicate the code, as there the first
+	(immediate) operand would need special treatment in several places.
+
+	Note that the .s suffix isn't being enabled to have any effect, for
+	being deprecated. Whereas neither {load} nor {store} pseudo prefixes
+	make sense here, as the respective operands are inputs (loads) only
+	anyway, regardless of order. Hence there is (as before) no way for the
+	programmer to request the alternative encoding to be used for register-
+	only insns.
+
+	Note further that it is always the first original template which is
+	retained (and altered), to make sure the same encoding as before is
+	used for register-only insns. This has the slightly odd (but pre-
+	existing) effect of XOP register-only insns having XOP.W clear, but FMA4
+	ones having VEX.W set.
+
+2022-07-06  Jan Beulich  <jbeulich@suse.com>
+
+	x86: fold two switch() statements in match_template()
+	I don't see why two of them were introduced (very long ago) using
+	similar fall-through logic.
+
+2022-07-06  Jan Beulich  <jbeulich@suse.com>
+
+	x86: fix 3-operand insn reverse-matching
+	The middle operand would have gone entirely unchecked, allowing e.g.
+
+		vmovss		%xmm0, %esp, %xmm2
+
+	to assemble successfully, or e.g.
+
+		vmovss		%xmm0, $4, %xmm2
+
+	causing an internal error. Alongside dealing with this also drop a
+	related comment, which hasn't been applicable anymore since the
+	introduction of 3-operand patterns with D set (and which perhaps never
+	had been logical to be there, as reverse-matched insns don't make it
+	there in the first place).
+
+2022-07-06  Bhuvanendra Kumar N  <Bhuvanendra.KumarN@amd.com>
+
+	Descriptive DWARF operations dump support for DW_AT_rank
+	DW_AT_rank is a dwarf-5 feature.
+
+2022-07-06  Jan Beulich  <jbeulich@suse.com>
+
+	x86: introduce a state stack for .arch
+	When using just slightly non-trivial combinations of .arch, it can be
+	quite useful to be able to go back to prior state without needing to
+	re-invoke perhaps many earlier directives and without needing to invoke
+	perhaps many "negative" ones. Like some other architectures allow
+	saving (pushing) and restoring (popping) present/prior state.
+
+	For now require the same .code<N> to be in effect for ".arch pop" that
+	was in effect for the corresponding ".arch push".
+
+	Also change the global "no_cond_jump_promotion" to be bool, to match the
+	new struct field.
+
+2022-07-06  Jan Beulich  <jbeulich@suse.com>
+
+	x86: generalize disabling of sub-architectures
+	I never really understood upon what basis ".arch .no*" options were made
+	available. Let's not have any "criteria" at all, and simply allow
+	disabling of all of them. Then we also have all data for a sub-arch in
+	a single place, as we now only need a single table.
+
+2022-07-06  Jan Beulich  <jbeulich@suse.com>
+
+	x86: permit "default" with .arch
+	So far there was no way to reset the architecture to that assembly would
+	start with in the absence of any overrides (command line or directives).
+	Note that for Intel MCU "default" is merely an alias of "iamcu".
+
+	While there also zap a stray @item from the doc section, as noticed
+	when inspecting the generated output (which still has some quirks, but
+	those aren't easy to address without re-flowing almost the entire
+	section).
+
+2022-07-06  Jan Beulich  <jbeulich@suse.com>
+
+	x86: don't leak sub-architecture accumulated strings
+	While it may not be necessary in i386_target_format() (but then setting
+	the variable to NULL also wouldn't be necessary), at least in the other
+	cases strings may already have accumulated.
+
+2022-07-06  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-05  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/exp] Fix internal error when printing C++ pointer-to-member
+	When running the test-case included with this patch, we run into:
+	...
+	(gdb) print ptm^M
+	$1 = gdb/gdbtypes.h:695: internal-error: loc_bitpos: \
+	  Assertion `m_loc_kind == FIELD_LOC_KIND_BITPOS' failed.^M
+	...
+	while printing a c++ pointer-to-member.
+
+	Fix this by skipping static fields in cp_find_class_member, such that we have:
+	...
+	(gdb) print ptm^M
+	$1 = &A::i^M
+	...
+
+	Tested on x86_64-linux.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29294
+
+2022-07-05  Tom Tromey  <tromey@adacore.com>
+
+	Add gdb.Objfile.is_file attribute
+	Sometimes an objfile comes from memory and not from a file.  It can be
+	useful to be able to check this from Python, so this patch adds a new
+	"is_file" attribute.
+
+2022-07-05  Tom Tromey  <tromey@adacore.com>
+
+	Make 'import gdb.events' work
+	Pierre-Marie noticed that, while gdb.events is a Python module, it
+	can't be imported.  This patch changes how this module is created, so
+	that it can be imported, while also ensuring that the module is always
+	visible, just as it was in the past.
+
+	This new approach required one non-obvious change -- when running
+	gdb.base/warning.exp, where --data-directory is intentionally not
+	found, the event registries can now be nullptr.  Consequently, this
+	patch probably also requires
+
+	    https://sourceware.org/pipermail/gdb-patches/2022-June/189796.html
+
+	Note that this patch obsoletes
+
+	    https://sourceware.org/pipermail/gdb-patches/2022-June/189797.html
+
+2022-07-05  Xi Ruoyao  <xry111@xry111.site>
+
+	gdb: LoongArch: add orig_a0 into register set
+	The basic support for LoongArch has been merged into the upstream Linux
+	kernel since 5.19-rc1 on June 5, 2022.  This commit adds orig_a0 which
+	is added into struct user_pt_regs [1] to match the upstream kernel, and
+	then the upstream GDB will work with the upstream kernel.
+
+	Note that orig_a0 was added into struct user_pt_regs in the development
+	cycle for merging LoongArch port into the upstream Linux kernel, so
+	earlier kernels (notably, the product kernel with version 4.19 used in
+	distros like UOS and Loongnix) don't have it.  Inspect
+	arch/loongarch/include/uapi/asm/ptrace.h in the kernel tree to make sure.
+	To build upstream GDB for a kernel lacking orig_a0, it's necessary to
+	revert this commit locally.
+
+	[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/include/uapi/asm/ptrace.h#n24
+
+2022-07-05  Bhuvanendra Kumar N  <Bhuvanendra.KumarN@amd.com>
+
+	Support for location and range lists for split-dwarf and dwarf-5.
+	Adding support for location and range lists for split-dwarf and dwarf-5.
+	Following issues are taken care.
+	1. Display of the index values for DW_FORM_loclistx and DW_FORM_rnglistx.
+	2. Display of .debug_loclists.dwo and .debug_rnglists.dwo sections.
+
+	        * dwarf.c(read_and_display_attr_value): Handle DW_FORM_loclistx
+	        and DW_FORM_rnglistx for .dwo files.
+	        (process_debug_info): Load .debug_loclists.dwo and
+	        .debug_rnglists.dwo if exists.
+	        (load_separate_debug_files): Load .debug_loclists and
+	        .debug_rnglists if exists.
+	        Include 2 entries in debug_displays table.
+	        * dwarf.h (enum dwarf_section_display_enum): Include 2 entries.
+
+2022-07-05  Jan Beulich  <jbeulich@suse.com>
+
+	x86: introduce fake processor type to mark sub-arch entries in cpu_arch[]
+	This is in preparation of dropping the leading . from the strings.
+
+	While there also move PROCESSOR_GENERIC{32,64} from the middle of AMD
+	entries to near the top.
+
+2022-07-05  Jan Beulich  <jbeulich@suse.com>
+
+	x86: macro-ize cpu_arch[] entries
+	Putting individual elements behind macros, besides (imo) improving
+	readability, will make subsequent (and likely also future) changes less
+	intrusive.
+
+	Utilize this right away to pack the table a little more tightly, by
+	converting "skip" to bool and putting it earlier in a group of bitfields
+	together with "len".
+
+2022-07-05  Jan Beulich  <jbeulich@suse.com>
+
+	x86: de-duplicate sub-architecture strings accumulation
+	Introduce a helper function to replace 4 instances of similar code. Use
+	reconcat() to cover the previously explicit free().
+
+2022-07-05  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-04  Nick Clifton  <nickc@redhat.com>
+
+	Fix snafu in rust demangler recursion limit code
+
+2022-07-04  Alan Modra  <amodra@gmail.com>
+
+	alloc gas seginfo on notes obstack
+	Lots of memory used in gas should go on this obstack.  The patch also
+	frees all the gas obstacks on exit, which isn't a completely trivial
+	task.
+
+		* subsegs.c (alloc_seginfo): New function.
+		(subseg_change, subseg_get): Use it.
+		(subsegs_end): New function.
+		* as.h (subsegs_end): Declare.
+		* output-file.c: Include subsegs.h
+		(stash_frchain_obs): New function.
+		(output_file_close): Save obstacks attached to output bfd before
+		closing.  Call subsegs_end with the array of obstacks.
+
+2022-07-04  Alan Modra  <amodra@gmail.com>
+
+	objcopy: bfd_alloc orelocation
+	This fixes an inconsequential objcopy memory leak.  I'd normally
+	ignore reports of leaks like this one, that are merely one block or
+	fewer per section processed, since objcopy soon exits and frees all
+	memory.  However I thought it worth providing support for allocating
+	memory on a bfd objalloc in objcopy and other utils.
+
+		PR 29233
+		* bucomm.c (bfd_xalloc): New function.
+		* bucomm.h (bfd_xalloc): Declare.
+		* objcopy.c (copy_relocations_in_section): Use it to allocate
+		array of reloc pointers.  Rewrite code stripping relocs to do
+		without extra memory allocation.
+
+2022-07-04  Nick Clifton  <nickc@redhat.com>
+
+	Synchronize libbierty sources with gcc.
+
+2022-07-04  Bhuvanendra Kumar N  <Bhuvanendra.KumarN@amd.com>
+
+	Modified changes for split-dwarf and dwarf-5.
+	        * dwarf.c(process_debug_info): Include DW_TAG_skeleton_unit.
+	        (display_debug_str_offsets): While dumping .debug_str_offsets.dwo,
+	        pass proper str_offsets_base to fetch_indexed_string().
+	        (load_separate_debug_files): Skip DWO ID dump for dwarf-5.
+
+2022-07-04  Marcus Nilsson  <brainbomb@gmail.com>
+
+	opcodes/avr: Implement style support in the disassembler
+		* disassemble.c: (disassemble_init_for_target): Set
+		created_styled_output for AVR based targets.
+		* avr-dis.c: (print_insn_avr): Use fprintf_styled_ftype
+		instead of fprintf_ftype throughout.
+		(avr_operand): Pass in and fill disassembler_style when
+		parsing operands.
+
+2022-07-04  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/symtab] Add get/set functions for per_cu->lang/unit_type
+	The dwarf2_per_cu_data fields lang and unit_type both have a dont-know
+	initial value (respectively language_unknown and (dwarf_unit_type)0), which
+	allows us to add certain checks, f.i. checking that that a field is not read
+	before written.
+
+	Add get/set member functions for the two fields as a convenient location to
+	add such checks, make the fields private to enforce using the member
+	functions, and add the m_ prefix.
+
+	Tested on x86_64-linux.
+
+2022-07-04  Jan Beulich  <jbeulich@suse.com>
+
+	gas/testsuite: properly exclude aout in all/weakref1u
+	Use the (wider) predicate rather than a triplet. This eliminates the sole
+	i386-msdos failure in the testsuite.
+
+2022-07-04  Jan Beulich  <jbeulich@suse.com>
+
+	x86: fold Disp32S and Disp32
+	The only case where 64-bit code uses non-sign-extended (can also be
+	considered zero-extended) displacements is when an address size override
+	is in place for a memory operand (i.e. particularly excluding
+	displacements of direct branches, which - if at all - are controlled by
+	operand size, and then are still sign-extended, just from 16 bits).
+	Hence the distinction in templates is unnecessary, allowing code to be
+	simplified in a number of places. The only place where logic becomes
+	more complicated is when signed-ness of relocations is determined in
+	output_disp().
+
+	The other caveat is that Disp64 cannot be specified anymore in an insn
+	template at the same time as Disp32. Unlike for non-64-bit mode,
+	templates don't specify displacements for both possible addressing
+	modes; the necessary adjustment to the expected ones has already been
+	done in match_template() anyway (but of course the logic there needs
+	tweaking now). Hence the single template so far doing so is split.
+
+2022-07-04  Jan Beulich  <jbeulich@suse.com>
+
+	x86: restore masking of displacement kinds
+	Commit 7d5e4556a375 rendered the check near the end of what is now
+	i386_finalize_displacement() entirely dead for AT&T mode, since for
+	operands involving a displacement .unspecified will always be set. But
+	the logic there is bogus anyway - Intel syntax operand size specifiers
+	are of no interest there either. The only thing which matters in the
+	"displacement only" determination is .baseindex.
+
+	Of course when masking displacement kinds we should not at the same time
+	also mask off other attributes.
+
+	Furthermore the type mask returned by lex_got() also needs to be
+	adjusted: The only case where we want Disp32 (rather than Disp32S) is
+	when dealing with 32-bit addressing mode in 64-bit code.
+
+2022-07-04  Jan Beulich  <jbeulich@suse.com>
+
+	x86-64: improve handling of branches to absolute addresses
+	There are two related problems here: The use of "addr32" on a direct
+	branch would, besides causing a warning, result in operands to be
+	permitted which mistakenly are refused without "addr32". Plus at some
+	point not too long ago I'm afraid it may have been me who regressed the
+	relocation addends emitted for such branches. Correct both problems,
+	adding a testcase to guard against regressing this again.
+
+2022-07-04  Tsukasa OI  <research_trasio@irq.a4lg.com>
+
+	RISC-V: Update Zihintpause extension version
+	Because ratified Zihintpause extension has a version number of 2.0
+	(not 1.0), we should update the number.
+
+	bfd/ChangeLog:
+
+		* elfxx-riscv.c (riscv_supported_std_z_ext): Update version
+		number of Zihintpause extension.
+
+2022-07-04  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-03  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-02  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/symtab] Fix data race on per_cu->dwarf_version
+	When building gdb with -fsanitize=thread and gcc 12, and running test-case
+	gdb.dwarf2/dwz.exp, we run into a data race between thread T2 and the main
+	thread in the same write:
+	...
+	Write of size 1 at 0x7b200000300c:^M
+	    #0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \
+	    abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6252 \
+	    (gdb+0x82f3b3)^M
+	...
+	which is here:
+	...
+	         this_cu->dwarf_version = cu->header.version;
+	...
+
+	Both writes are called from the parallel for in dwarf2_build_psymtabs_hard,
+	this one directly:
+	...
+	    #1 process_psymtab_comp_unit gdb/dwarf2/read.c:6774 (gdb+0x8304d7)^M
+	    #2 operator() gdb/dwarf2/read.c:7098 (gdb+0x8317be)^M
+	    #3 operator() gdbsupport/parallel-for.h:163 (gdb+0x872380)^M
+	...
+	and this via the PU import:
+	...
+	    #1 cooked_indexer::ensure_cu_exists(cutu_reader*, dwarf2_per_objfile*, \
+	    sect_offset, bool,  bool) gdb/dwarf2/read.c:17964 (gdb+0x85c43b)^M
+	    #2 cooked_indexer::index_imported_unit(cutu_reader*, unsigned char const*, \
+	    abbrev_info const*) gdb/dwarf2/read.c:18248 (gdb+0x85d8ff)^M
+	    #3 cooked_indexer::index_dies(cutu_reader*, unsigned char const*, \
+	    cooked_index_entry const*, bool) gdb/dwarf2/read.c:18302 (gdb+0x85dcdb)^M
+	    #4 cooked_indexer::make_index(cutu_reader*) gdb/dwarf2/read.c:18443 \
+	    (gdb+0x85e68a)^M
+	    #5 process_psymtab_comp_unit gdb/dwarf2/read.c:6812 (gdb+0x830879)^M
+	    #6 operator() gdb/dwarf2/read.c:7098 (gdb+0x8317be)^M
+	    #7 operator() gdbsupport/parallel-for.h:171 (gdb+0x8723e2)^M
+	...
+
+	Fix this by setting the field earlier, in read_comp_units_from_section.
+
+	The write in cutu_reader::cutu_reader() is still needed, in case
+	read_comp_units_from_section is not used (run the test-case with say, target
+	board cc-with-gdb-index).
+
+	Make the write conditional, such that it doesn't trigger if the field is
+	already set by read_comp_units_from_section.  Instead, verify that the
+	field already has the value that we're trying to set it to.
+
+	Move this logic into into a member function set_version (in analogy to the
+	already present member function version) to make sure it's used consistenly,
+	and make the field private in order to enforce access through the member
+	functions, and rename it to m_dwarf_version.
+
+	While we're at it, make sure that the version is set before read, to avoid
+	say returning true for "per_cu.version () < 5" if "per_cu.version () == 0".
+
+	Tested on x86_64-linux.
+
+2022-07-02  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.base/early-init-file.exp with -fsanitize=thread
+	When building gdb with -fsanitize=thread, I run into:
+	...
+	FAIL: gdb.base/early-init-file.exp: check startup version string has style \
+	  version
+	...
+	due to this:
+	...
+	warning: Found custom handler for signal 7 (Bus error) preinstalled.^M
+	warning: Found custom handler for signal 8 (Floating point exception) \
+	  preinstalled.^M
+	warning: Found custom handler for signal 11 (Segmentation fault) \
+	  preinstalled.^M
+	Some signal dispositions inherited from the environment (SIG_DFL/SIG_IGN)^M
+	won't be propagated to spawned programs.^M
+	...
+	appearing before the "GNU gdb (GDB) $version" line.
+
+	This is similar to the problem fixed by commit f0bbba7886f
+	("gdb.debuginfod/fetch_src_and_symbols.exp: fix when GDB is built with
+	AddressSanitizer").
+
+	In that commit, the problem was fixed by starting gdb with -quiet, but using
+	that would mean the "GNU gdb (GDB) $version" line that we're trying to check
+	would disappear.
+
+	Fix this instead by updating the regexp to allow the message.
+
+	Tested on x86_64-linux.
+
+2022-07-02  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-07-01  Maciej W. Rozycki  <macro@embecosm.com>
+
+	GDB/doc: Remove indentation from `print -elements' completion example
+	Remove indentation from the text of the manual after the example here:
+
+	"  Completion will in some cases guide you with a suggestion of what
+	kind of argument an option expects.  For example:
+
+	     (gdb) print -elements <TAB><TAB>
+	     NUMBER     unlimited
+
+	   Here, the option expects a number (e.g., '100'), not literal
+	'NUMBER'.  Such metasyntactical arguments are always presented in
+	uppercase."
+
+	as this is a continuation of the same paragraph.
+
+2022-07-01  Maciej W. Rozycki  <macro@embecosm.com>
+
+	GDB/doc: Remove extraneous spaces from completion examples
+	Completion results are usually different when the operation is applied
+	to a word that is or is not followed by a space.  In some cases they are
+	equivalent, however a space would not be produced if completion was used
+	earlier on in the word processed.
+
+	However in the manual we have completion examples given using a space
+	that actually prevents the example from working.  E.g.:
+
+	(gdb) info bre <TAB>
+
+	(nothing) and:
+
+	(gdb) info bre <TAB><TAB>
+	Display all 200 possibilities? (y or n)
+
+	as it now goes on to propose the entire symbol table, while:
+
+	(gdb) info bre<TAB>
+	(gdb) info breakpoints
+
+	does the right thing, but is not what is shown in the manual.
+
+	In other cases an extraneous space is used that does not correspond to
+	the actual completion pattern shown, which gives an impression of
+	sloppiness.
+
+	Remove extraneous spaces then from completion examples as appropriate.
+
+2022-07-01  Nick Clifton  <nickc@redhat.com>
+
+	Add newline to the end of the rnglists displsy.
+
+2022-07-01  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-30  Maciej W. Rozycki  <macro@embecosm.com>
+
+	GDB: Add `NUMBER' completion to `set' integer commands
+	Fix a completion consistency issue with `set' commands accepting integer
+	values and the special `unlimited' keyword:
+
+	(gdb) complete print -elements
+	print -elements NUMBER
+	print -elements unlimited
+	(gdb)
+
+	vs:
+
+	(gdb) complete set print elements
+	set print elements unlimited
+	(gdb)
+
+	(there is a space entered at the end of both commands, not shown here)
+	which also means if you strike <Tab> with `set print elements ' input,
+	it will, annoyingly, complete to `set print elements unlimited' right
+	away rather than showing a choice between `NUMBER' and `unlimited'.
+
+	Add `NUMBER' then as an available completion for such `set' commands:
+
+	(gdb) complete set print elements
+	set print elements NUMBER
+	set print elements unlimited
+	(gdb)
+
+	Adjust the testsuite accordingly.  Also document the feature in the
+	Completion section of the manual in addition to the Command Options
+	section already there.
+
+2022-06-30  Bruno Larsen  <blarsen@redhat.com>
+
+	gdb/testsuite: Expand gdb.cp/mb-ctor.exp to test dynamic allocation
+	When testing GDB's ability to stop in constructors, gdb.cp/mb-ctor.exp
+	only tested objects allocated on the stack. This commit adds a couple of
+	dynamic allocations and tests if GDB can stop in it as well.
+
+2022-06-30  Nick Clifton  <nickc@redhat.com>
+
+	Fix implementation of readelf's -wE and -wN options,
+		* dwarf.c (dwarf_select_sections_by_name): If the entry's value is
+		zero then clear the corresponding variable.
+		(dwarf_select_sections_by_letters): Likewise.
+		* testsuite/binutils-all/debuginfo.exp: Expect -WE and -wE
+		debuginfod tests to fail.
+
+2022-06-30  Tom de Vries  <tdevries@suse.de>
+
+	[gdb] Block SIGTERM in worker threads
+	With gdb build with gcc-12 and -fsanitize=thread, and test-case
+	gdb.base/gdb-sigterm.exp, I run into:
+	...
+	WARNING: ThreadSanitizer: data race (pid=9722)^M
+	  Write of size 4 at 0x00000325bc68 by thread T1:^M
+	  #0 handle_sigterm(int) src/gdb/event-top.c:1211 (gdb+0x8ec01f)^M
+	  ...
+	  Previous read of size 4 at 0x00000325bc68 by main thread:^M
+	    [failed to restore the stack]^M
+	^M
+	  Location is global 'sync_quit_force_run' of size 4 at \
+	  0x00000325bc68 (gdb+0x325bc68)^M
+	  ...
+	SUMMARY: ThreadSanitizer: data race gdb/event-top.c:1211 in \
+	  handle_sigterm(int)^M
+	...
+	and 3 more data races involving handle_sigterm and locations:
+	- active_ext_lang
+	- quit_flag
+	- heap block of size 40
+	  (XNEW (async_signal_handler) in create_async_signal_handler)
+
+	This was reported in PR29297.
+
+	The testcase executes a "kill -TERM $gdb_pid", which generates a
+	process-directed signal.
+
+	A process-directed signal can be delivered to any thread, and what we see
+	here is the fallout of the signal being delivered to a worker thread rather
+	than the main thread.
+
+	Fix this by blocking SIGTERM in the worker threads.
+
+	[ I have not been able to reproduce this after it occurred for the first time,
+	so unfortunately I cannot confirm that the patch fixes the problem. ]
+
+	Tested on x86_64-linux, with and without -fsanitize=thread.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29297
+
+2022-06-30  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/doc: fix column widths in MI compatibility table
+	In passing I noticed that the column headings for the table of MI
+	compatibility and breaking changes, were overlapping, at least when
+	the PDF is generated on my machine.
+
+	I propose giving slightly more space to the two version number
+	columns, this prevents the headers overlapping for me.
+
+2022-06-30  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-29  Pedro Alves  <pedro@palves.net>
+
+	Fix GDBserver regression due to change to avoid reading shell registers
+	Simon reported that the recent change to make GDB and GDBserver avoid
+	reading shell registers caused a GDBserver regression, caught with
+	ASan while running gdb.server/non-existing-program.exp:
+
+	 $ /home/smarchi/build/binutils-gdb/gdb/testsuite/../../gdb/../gdbserver/gdbserver stdio non-existing-program
+	 =================================================================
+	 ==127719==ERROR: AddressSanitizer: heap-use-after-free on address 0x60f0000000e9 at pc 0x55bcbfa301f4 bp 0x7ffd238a7320 sp 0x7ffd238a7310
+	 WRITE of size 1 at 0x60f0000000e9 thread T0
+	     #0 0x55bcbfa301f3 in scoped_restore_tmpl<bool>::~scoped_restore_tmpl() /home/smarchi/src/binutils-gdb/gdbserver/../gdbsupport/scoped_restore.h:86
+	     #1 0x55bcbfa2ffe9 in post_fork_inferior(int, char const*) /home/smarchi/src/binutils-gdb/gdbserver/fork-child.cc:120
+	     #2 0x55bcbf9c9199 in linux_process_target::create_inferior(char const*, std::__debug::vector<char*, std::allocator<char*> > const&) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:991
+	     #3 0x55bcbf954549 in captured_main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3941
+	     #4 0x55bcbf9552f0 in main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4084
+	     #5 0x7ff9d663b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x240b2)
+	     #6 0x55bcbf8ef2bd in _start (/home/smarchi/build/binutils-gdb/gdbserver/gdbserver+0x1352bd)
+
+	 0x60f0000000e9 is located 169 bytes inside of 176-byte region [0x60f000000040,0x60f0000000f0)
+	 freed by thread T0 here:
+	     #0 0x7ff9d6c6f0c7 in operator delete(void*) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:160
+	     #1 0x55bcbf910d00 in remove_process(process_info*) /home/smarchi/src/binutils-gdb/gdbserver/inferiors.cc:164
+	     #2 0x55bcbf9c4ac7 in linux_process_target::remove_linux_process(process_info*) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:454
+	     #3 0x55bcbf9cdaa6 in linux_process_target::mourn(process_info*) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:1599
+	     #4 0x55bcbf988dc4 in target_mourn_inferior(ptid_t) /home/smarchi/src/binutils-gdb/gdbserver/target.cc:205
+	     #5 0x55bcbfa32020 in startup_inferior(process_stratum_target*, int, int, target_waitstatus*, ptid_t*) /home/smarchi/src/binutils-gdb/gdbserver/../gdb/nat/fork-inferior.c:515
+	     #6 0x55bcbfa2fdeb in post_fork_inferior(int, char const*) /home/smarchi/src/binutils-gdb/gdbserver/fork-child.cc:111
+	     #7 0x55bcbf9c9199 in linux_process_target::create_inferior(char const*, std::__debug::vector<char*, std::allocator<char*> > const&) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:991
+	     #8 0x55bcbf954549 in captured_main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3941
+	     #9 0x55bcbf9552f0 in main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4084
+	     #10 0x7ff9d663b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x240b2)
+
+	 previously allocated by thread T0 here:
+	     #0 0x7ff9d6c6e5a7 in operator new(unsigned long) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:99
+	     #1 0x55bcbf910ad0 in add_process(int, int) /home/smarchi/src/binutils-gdb/gdbserver/inferiors.cc:144
+	     #2 0x55bcbf9c477d in linux_process_target::add_linux_process_no_mem_file(int, int) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:425
+	     #3 0x55bcbf9c8f4c in linux_process_target::create_inferior(char const*, std::__debug::vector<char*, std::allocator<char*> > const&) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:985
+	     #4 0x55bcbf954549 in captured_main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3941
+	     #5 0x55bcbf9552f0 in main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4084
+	     #6 0x7ff9d663b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x240b2)
+
+	Above we see that in the non-existing-program case, the process gets
+	deleted before the starting_up flag gets restored to false.
+
+	This happens because startup_inferior calls target_mourn_inferior
+	before throwing an error, and in GDBserver, unlike in GDB, mourning
+	deletes the process.
+
+	Fix this by not using a scoped_restore to manage the starting_up flag,
+	since we should only clear it when startup_inferior doesn't throw.
+
+	Change-Id: I67325d6f81c64de4e89e20e4ec4556f57eac7f6c
+
+2022-06-29  Maciej W. Rozycki  <macro@embecosm.com>
+
+	GDB/testsuite: Tighten `set print elements' error check
+	Match the whole error message expected to be given rather than omitting
+	the part about the "unlimited" keyword.  There's no point in omitting
+	the missing part first, and second with an upcoming change the part in
+	parentheses will no longer be a fixed string, so doing a full match will
+	ensure the algorithm correctly builds the message expected here.  Also
+	avoid any wildcard matches.
+
+2022-06-29  Maciej W. Rozycki  <macro@embecosm.com>
+
+	GDB: Remove extraneous full stops from `set' command error messages
+	With errors given for bad commands such as `set annotate' or `set width'
+	we produce an extraneous full stop within parentheses:
+
+	(gdb) set annotate
+	Argument required (integer to set it to.).
+	(gdb) set width
+	Argument required (integer to set it to, or "unlimited".).
+	(gdb)
+
+	This is grammatically incorrect, so remove the full stop and adjust the
+	testsuite accordingly.
+
+2022-06-29  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/doc: improve description of --data-disassemble opcodes output
+	Extend the description of the MI command --data-disassemble.
+	Specifically, expand the description of the 'opcodes' field to explain
+	how the bytes are formatted.
+
+2022-06-29  Yvan Roux  <yvan.roux@foss.st.com>
+
+	gdb/arm: Only stack S16..S31 when FPU registers are secure
+	The FPCCR.TS bit is used to identify if FPU registers are considered
+	non-secure or secure.  If they are secure, then callee saved registers
+	(S16 to S31) are stacked on exception entry or otherwise skipped.
+
+2022-06-29  Andrew Burgess  <aburgess@redhat.com>
+
+	opcodes/aarch64: split off creation of comment text in disassembler
+	The function aarch64_print_operand (aarch64-opc.c) is responsible for
+	converting an instruction operand into the textual representation of
+	that operand.
+
+	In some cases, a comment is included in the operand representation,
+	though this (currently) only happens for the last operand of the
+	instruction.
+
+	In a future commit I would like to enable the new libopcodes styling
+	for AArch64, this will allow objdump and GDB[1] to syntax highlight
+	the disassembler output, however, having operands and comments
+	combined in a single string like this makes such styling harder.
+
+	In this commit, I propose to extend aarch64_print_operand to take a
+	second buffer.  Any comments for the instruction are written into this
+	extra buffer.  The two callers of aarch64_print_operand are then
+	updated to pass an extra buffer, and print any resulting comment.
+
+	In this commit no styling is added, that will come later.  However, I
+	have adjusted the output slightly.  Before this commit some comments
+	would be separated from the instruction operands with a tab character,
+	while in other cases the comment was separated with two single spaces.
+
+	After this commit I use a single tab character in all cases.  This
+	means a few test cases needed updated.  If people would prefer me to
+	move everyone to use the two spaces, then just let me know.  Or maybe
+	there was a good reason why we used a mix of styles, I could probably
+	figure out a way to maintain the old output exactly if that is
+	critical.
+
+	Other than that, there should be no user visible changes after this
+	commit.
+
+	[1] GDB patches have not been merged yet, but have been posted to the
+	GDB mailing list:
+	https://sourceware.org/pipermail/gdb-patches/2022-June/190142.html
+
+2022-06-29  Carl Love  <cel@us.ibm.com>
+	    Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: fix gdb.base/break-idempotent.exp on ppc
+	When running the gdb.base/break-idempotent.exp test on ppc, I was
+	seeing some test failures (or rather errors), that looked like this:
+
+	  (gdb) watch local
+	  Hardware watchpoint 2: local
+
+	  has_hw_wp_support: Hardware watchpoint detected
+	  ERROR: no fileid for gcc2-power8
+	  ERROR: Couldn't send delete breakpoints to GDB.
+	  ERROR OCCURED: can't read "gdb_spawn_id": no such variable
+	      while executing
+	  "expect {
+	  -i 1000 -timeout 100
+	          -re ".*A problem internal to GDB has been detected" {
+	              fail "$message (GDB internal error)"
+	              gdb_internal_erro..."
+	      ("uplevel" body line 1)
+	      invoked from within
+
+	What happens is that in break-idempotent.exp we basically do this:
+
+	    if {[prepare_for_testing "failed to prepare" $binfile $srcfile $opts]} {
+	        continue
+	    }
+
+	    # ....
+
+	    if {![skip_hw_watchpoint_tests]} {
+	        test_break $always_inserted "watch"
+	    }
+
+	The problem with this is that skip_hw_watchpoint_tests, includes this:
+
+	    if { [istarget "i?86-*-*"]
+		 || [istarget "x86_64-*-*"]
+		 || [istarget "ia64-*-*"]
+		 || [istarget "arm*-*-*"]
+		 || [istarget "aarch64*-*-*"]
+		 || ([istarget "powerpc*-*-linux*"] && [has_hw_wp_support])
+		 || [istarget "s390*-*-*"] } {
+		return 0
+	    }
+
+	For powerpc only we call has_hw_wp_support.  This is a caching proc
+	that runs a test within GDB to detect if we have hardware watchpoint
+	support or not.
+
+	Unfortunately, to run this test we restart GDB, and when the test has
+	completed, we exit GDB.  This means that in break-idempotent.exp, when
+	we call skip_hw_watchpoint_tests for the first time on powerpc, GDB
+	will unexpectedly be exited.  When we later call delete_breakpoints we
+	see the errors I reported above.
+
+	The fix is to call skip_hw_watchpoint_tests early, before we start GDB
+	as part of the break-idempotent.exp script, and store the result in a
+	variable, we can then check this variable in the script as needed.
+
+	After this change break-idempotent.exp runs fine on powerpc.
+
+2022-06-29  Jan Beulich  <jbeulich@suse.com>
+
+	x86: drop stray NoRex64 from XBEGIN
+	Presumably this being there was a result of taking CALL as a reference
+	when adding the RTM insns. But with No_qSuf the attribute has no effect.
+
+2022-06-29  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+	gprofng: fix build when BUILD_MAN is false
+	gprofng/ChangeLog
+	2022-06-28  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+		PR gprofng/29131
+		* gp-display-html/Makefile.am: Set man_MANS only when BUILD_MAN is true.
+		* src/Makefile.am: Likewise.
+		* gp-display-html/Makefile.in: Rebuild.
+		* src/Makefile.in: Rebuild.
+
+2022-06-29  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+	gprofng: use $(sysconfdir) instead $(prefix)/etc
+	gprofng/ChangeLog
+	2022-06-28  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+		PR gprofng/29191
+		* src/Makefile.am: Use $(sysconfdir) instead $(prefix)/etc.
+		* src/Settings.cc: Likewise.
+		* src/Makefile.in: Rebuild.
+
+2022-06-29  Alan Modra  <amodra@gmail.com>
+
+	Re: ld/x86: skip p_align-1 tests with unsuitable compiler
+	commit d0e0f9c87a3e results "ERROR: i586-linux-cc does not exist" if
+	cross-building an i586-linux target without a target compiler
+	installed.
+
+		* testsuite/ld-elf/linux-x86.exp (compiler_honours_aligned): New.
+		Use it after first testing check_compiler_available.
+
+2022-06-29  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-28  Pedro Alves  <pedro@palves.net>
+
+	gdb+gdbserver/Linux: avoid reading registers while going through shell
+	For every stop, Linux GDB and GDBserver save the stopped thread's PC,
+	in lwp->stop_pc.  This is done in save_stop_reason, in both
+	gdb/linux-nat.c and gdbserver/linux-low.cc.  However, while we're
+	going through the shell after "run", in startup_inferior, we shouldn't
+	be reading registers, as we haven't yet determined the target's
+	architecture -- the shell's architecture may not even be the same as
+	the final inferior's.
+
+	In gdb/linux-nat.c, lwp->stop_pc is only needed when the thread has
+	stopped for a breakpoint, and since when going through the shell, no
+	breakpoint is going to hit, we could simply teach save_stop_reason to
+	only record the stop pc when the thread stopped for a breakpoint.
+
+	However, in gdbserver/linux-low.cc, lwp->stop_pc is used in more cases
+	than breakpoint hits (e.g., it's used in tracepoints & the
+	"while-stepping" feature).
+
+	So to avoid GDB vs GDBserver divergence, we apply the same approach to
+	both implementations.
+
+	We set a flag in the inferior (process in GDBserver) whenever it is
+	being nursed through the shell, and when that flag is set,
+	save_stop_reason bails out early.  While going through the shell,
+	we'll only ever get process exits (normal or signalled), random
+	signals, and exec events, so nothing is lost.
+
+	Change-Id: If0f01831514d3a74d17efd102875de7d2c6401ad
+
+2022-06-28  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/build] Fix gdb build with -fsanitize=thread and gcc 7
+	When building gdb with system gcc 7.5.0, I run into:
+	...
+	gdb/ia64-tdep.c: In function ‘int is_float_or_hfa_type_recurse(type*, type**)’:
+	gdb/ia64-tdep.c:3362:1: error: control reaches end of non-void function \
+	  [-Werror=return-type]
+	...
+
+	This is due to PR gcc/81275 - "-fsanitize=thread produce incorrect
+	-Wreturn-type warning", which has been fixed in gcc-8.
+
+	Work around this by moving the default return outside the switch.
+
+	Tested on x86_64-linux.
+
+2022-06-28  Clément Chigot  <chigot@adacore.com>
+
+	bfd: handle codepage when opening files on MinGW
+	Even if MS docs say that CP_UTF8 should always be used on newer
+	applications, forcing it might produce undefined filename if the
+	encoding isn't UTF-8.
+	MinGW seems to call ___lc_codepage_func() in order to retrieve the
+	current thread codepage.
+
+	bfd/ChangeLog:
+
+	        * bfdio.c (_bfd_real_fopen): Retrieve codepage with
+	        ___lc_codepage_func() on MinGW.
+
+2022-06-28  Clément Chigot  <chigot@adacore.com>
+
+	windres: add quotes around preprocessor cmd if needed
+	This patch ensures that the gcc binary called by windres is quoted if
+	needed. Otherwise, errors can occur if the gcc is under a folder having
+	a name containing a space (eg "Program Files").
+
+	binutils/
+		* resrc.c (DEFAULT_PREPROCESSOR): Split into...
+		(DEFAULT_PREPROCESSOR_CMD): that...
+		(DEFAULT_PREPROCESSOR_ARGS): and that.
+		(look_for_default): Add quotes around the command if needed.
+		(read_rc_file): Adapt to new defines.
+
+2022-06-28  Nick Clifton  <nickc@redhat.com>
+
+	Fix the display of the idnex values for DW_FORM_loclistx and DW_FORM_rnglistx.  Correct the display of .debug.loclists sections.
+		PR 29267
+		* dwarf.c (display_debug_rnglists): New function, broken out of..
+		(display_debug_ranges): ... here.
+		(read_and_display_attr_value): Correct calculation of index
+		displayed for DW_FORM_loclistx and DW_FORM_rnglistx.
+		* testsuite/binutils-all/x86-64/pr26808.dump: Update expected
+		output.
+
+2022-06-28  Jan Beulich  <jbeulich@suse.com>
+
+	ld/x86: skip p_align-1 tests with unsuitable compiler
+	When the compiler doesn't properly arrange for foo's alignment, there's
+	no point even trying these tests. Report the situation as a single
+	"unsupported" test.
+
+2022-06-28  Alan Modra  <amodra@gmail.com>
+
+	PowerPC64: align plt_branch stubs
+	plt_branch stubs are similar to plt_call stubs in that they branch
+	via bctr.  Align them too.
+
+	bfd/
+		* elf64-ppc.c (ppc_size_one_stub): Align plt_branch stubs as for
+		plt_call stubs.
+	ld/
+		* testsuite/ld-powerpc/elfv2exe.d: Adjust for plt_branch changes.
+		* testsuite/ld-powerpc/notoc.d: Likewise.
+		* testsuite/ld-powerpc/notoc.wf: Likewise.
+		* testsuite/ld-powerpc/notoc3.d: Likewise.
+		* testsuite/ld-powerpc/pr23937.d: Likewise.
+
+2022-06-28  Alan Modra  <amodra@gmail.com>
+
+	PowerPC64: plt_stub_pad
+		* elf64-ppc.c (plt_stub_pad): Simplify parameters and untangle
+		from plt_stub_size.
+		(ppc_size_one_stub): Call plt_stub_size before plt_stub_pad to
+		provide size.  Recalculate size if it might change.
+
+2022-06-28  Alan Modra  <amodra@gmail.com>
+
+	PowerPC64: Tidy stub type changes
+	It made sense before I started using separate fields for main type and
+	sub type to add a difference in main type to the type (thus keeping
+	sub type unchanged).  Not so much now.
+
+		* elf64-ppc.c (ppc_merge_stub): Simplify stub type change.
+		(ppc_size_one_stub): Likewise.
+
+2022-06-28  Jiangshuai Li  <jiangshuai_li@c-sky.com>
+
+	gdb:csky add pseudo regs for float and vector regs
+	In the existing CSKY architecture, there are at most 32 floating
+	and 16 vector registers. Float registers's count can be configured
+	as 16 or 32. In the future, the vector registers's count may be
+	extended to 32.
+
+	The bit width of floating-point register is 64bits, and the bit
+	width of vector register is 128bit.
+
+	Special points: in fr0~fr15 and vr0~vr15, each FRx is the lower
+	64 bits of the corresponding VRx.
+
+	Here, we will split each floating-point and vector register to
+	32bits wide, add the corresponding pseudo registers, and finally
+	use them for the dwarf registers.
+
+	There are 128 pseudo registers in total, s0~s127, including:
+	1. s0 and s1 correspond to fr0, s4 and s5 correspond to fr1, and so on.
+	Every two separated pseudo registers correspond to a float register.
+	2. s0, s1, s2 and s3 correspond to vr0; s4, s5, s6 and s7 correspond to vr1,
+	and so on. Every four pseudo registers corresponds to a vector register.
+
+	Therefore, in s64~s127, there are general registers that are not actually
+	used. This part is to prepare for the expansion of vector registers to 32
+
+	Therefore, in s64~s127, half of the registers are actually unused. This
+	part is to prepare for the expansion of the vector register to 32.
+
+2022-06-28  Pekka Seppänen  <pexu@sourceware.mail.kapsi.fi>
+
+	PR29293, elfnn-aarch64.c: def_protected member unintialized
+		PR 29293
+		* elfnn-aarch64.c (elfNN_aarch64_link_hash_newfunc): Init def_protected.
+
+2022-06-28  Tsukasa OI  <research_trasio@irq.a4lg.com>
+
+	RISC-V: Add 'Sstc' extension and its CSRs
+	This commit adds "stimecmp / vstimecmp" Extension (Sstc) and its CSRs.
+
+	bfd/ChangeLog:
+
+		* elfxx-riscv.c (riscv_supported_std_s_ext): Add 'Sstc'
+		extension to valid 'S' extension list.
+
+	gas/ChangeLog:
+
+		* config/tc-riscv.c (enum riscv_csr_class): Add CSR classes for
+		'Sstc' extension. (riscv_csr_address): Add handling for new CSR
+		classes.
+		* testsuite/gas/riscv/csr-dw-regnums.s: Add new CSRs.
+		* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
+		* testsuite/gas/riscv/csr.s: Add new CSRs.
+		* testsuite/gas/riscv/csr-version-1p9p1.d: Likewise.
+		* testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
+		* testsuite/gas/riscv/csr-version-1p10.d: Likewise.
+		* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
+		* testsuite/gas/riscv/csr-version-1p11.d: Likewise.
+		* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
+		* testsuite/gas/riscv/csr-version-1p12.d: Likewise.
+		* testsuite/gas/riscv/csr-version-1p12.l: Likewise.
+
+	include/ChangeLog:
+
+		* opcode/riscv-opc.h (CSR_STIMECMP, CSR_STIMECMPH,
+		CSR_VSTIMECMP, CSR_VSTIMECMPH): New CSR macros.
+
+2022-06-28  Tsukasa OI  <research_trasio@irq.a4lg.com>
+
+	RISC-V: Add 'Sscofpmf' extension with its CSRs
+	This commit adds Count Overflow and Mode-Based Filtering Extension
+	(Sscofpmf) and its CSRs.
+
+	bfd/ChangeLog:
+
+		* elfxx-riscv.c (riscv_supported_std_s_ext): Add 'Sscofpmf'
+		extension to valid 'S' extension list.
+
+	gas/ChangeLog:
+
+		* config/tc-riscv.c (enum riscv_csr_class): Add CSR classes for
+		'Sscofpmf' extension. (riscv_csr_address): Add handling for new
+		CSR classes.
+		* testsuite/gas/riscv/csr-dw-regnums.s: Add new CSRs.
+		* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
+		* testsuite/gas/riscv/csr.s: Add new CSRs.
+		* testsuite/gas/riscv/csr-version-1p9p1.d: Likewise.
+		* testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
+		* testsuite/gas/riscv/csr-version-1p10.d: Likewise.
+		* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
+		* testsuite/gas/riscv/csr-version-1p11.d: Likewise.
+		* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
+		* testsuite/gas/riscv/csr-version-1p12.d: Likewise.
+		* testsuite/gas/riscv/csr-version-1p12.l: Likewise.
+
+	include/ChangeLog:
+
+		* opcode/riscv-opc.h (CSR_SCOUNTOVF, CSR_MHPMEVENT3H,
+		CSR_MHPMEVENT4H, CSR_MHPMEVENT5H, CSR_MHPMEVENT6H,
+		CSR_MHPMEVENT7H, CSR_MHPMEVENT8H, CSR_MHPMEVENT9H,
+		CSR_MHPMEVENT10H, CSR_MHPMEVENT11H, CSR_MHPMEVENT12H,
+		CSR_MHPMEVENT13H, CSR_MHPMEVENT14H, CSR_MHPMEVENT15H,
+		CSR_MHPMEVENT16H, CSR_MHPMEVENT17H, CSR_MHPMEVENT18H,
+		CSR_MHPMEVENT19H, CSR_MHPMEVENT20H, CSR_MHPMEVENT21H,
+		CSR_MHPMEVENT22H, CSR_MHPMEVENT23H, CSR_MHPMEVENT24H,
+		CSR_MHPMEVENT25H, CSR_MHPMEVENT26H, CSR_MHPMEVENT27H,
+		CSR_MHPMEVENT28H, CSR_MHPMEVENT29H, CSR_MHPMEVENT30H,
+		CSR_MHPMEVENT31H): New CSR macros.
+
+2022-06-28  Tsukasa OI  <research_trasio@irq.a4lg.com>
+
+	RISC-V: Add 'Smstateen' extension and its CSRs
+	This commit adds State Enable Extension (Smstateen) and its CSRs.
+
+	bfd/ChangeLog:
+
+		* elfxx-riscv.c (riscv_supported_std_s_ext): Add 'Smstateen'
+		extension to valid 'S' extension list.
+
+	gas/ChangeLog:
+
+		* config/tc-riscv.c (enum riscv_csr_class): Add CSR classes for
+		'Smstateen' extension. (riscv_csr_address): Add handling for
+		new CSR classes.
+		* testsuite/gas/riscv/csr-dw-regnums.s: Add new CSRs.
+		* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
+		* testsuite/gas/riscv/csr.s: Add new CSRs.
+		* testsuite/gas/riscv/csr-version-1p9p1.d: Likewise.
+		* testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
+		* testsuite/gas/riscv/csr-version-1p10.d: Likewise.
+		* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
+		* testsuite/gas/riscv/csr-version-1p11.d: Likewise.
+		* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
+		* testsuite/gas/riscv/csr-version-1p12.d: Likewise.
+		* testsuite/gas/riscv/csr-version-1p12.l: Likewise.
+
+	include/ChangeLog:
+
+		* opcode/riscv-opc.h (CSR_MSTATEEN0, CSR_MSTATEEN1,
+		CSR_MSTATEEN2, CSR_MSTATEEN3, CSR_SSTATEEN0, CSR_SSTATEEN1,
+		CSR_SSTATEEN2, CSR_SSTATEEN3, CSR_HSTATEEN0, CSR_HSTATEEN1,
+		CSR_HSTATEEN2, CSR_HSTATEEN3, CSR_MSTATEEN0H, CSR_MSTATEEN1H,
+		CSR_MSTATEEN2H, CSR_MSTATEEN3H, CSR_HSTATEEN0H, CSR_HSTATEEN1H,
+		CSR_HSTATEEN2H, CSR_HSTATEEN3H): New CSR macros.
+
+2022-06-28  Tsukasa OI  <research_trasio@irq.a4lg.com>
+
+	RISC-V: Add new CSR feature gate handling (RV32,H)
+	To support feature gate like Smstateen && H, this commit adds certain
+	CSR feature gate handling.  It also changes how RV32-only CSRs are
+	handled for cleanliness.
+
+	gas/ChangeLog:
+
+		* config/tc-riscv.c (riscv_csr_address): Add CSR feature gate
+		handling for H.  Change handling on RV32.
+
+2022-06-28  Alan Modra  <amodra@gmail.com>
+
+	Re: Disable execstack and rwx segments warnings for MIPS targets.
+		PR 29263
+		* configure.ac: Fix typo.
+		* testsuite/ld-elf/elf.exp: Add mips to targets that need
+		--warn-execstack to pass first pr29072 test.
+
+2022-06-28  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-27  Bruno Larsen  <blarsen@redhat.com>
+
+	gdb/testsuite: update bug numbers from Gnats to bugzilla
+	Some tests link to outdated bug numbers when an XFAIL or a KFAIL happen.
+
+	gdb.base/macscp.exp was referencing bug number 555, and the bug 7660
+	mentions that it used to be 555 on the Gnats system and seems to relate
+	to the issue at hand.
+
+	gdb.base/annota1.exp was referencing bug number 1270, and bug 8375
+	mentions being number 1270 on Gnats, and mentions annota1 specifically,
+	so it seemed pretty obvious.
+
+2022-06-27  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/build] Fix build breaker with --enable-shared
+	When building gdb with --enable-shared, I run into:
+	...
+	ld: build/zlib/libz.a(libz_a-inffast.o): relocation R_X86_64_32S against \
+	  `.rodata' can not be used when making a shared object; recompile with -fPIC
+	ld: build/zlib/libz.a(libz_a-inflate.o): warning: relocation against \
+	  `inflateResetKeep' in read-only section `.text'
+	collect2: error: ld returned 1 exit status
+	make[3]: *** [libbfd.la] Error 1
+	...
+
+	This is a regression since commit a08bdb159bb ("[gdb/build] Fix gdbserver
+	build with -fsanitize=thread").
+
+	The problem is that a single case statement in configure is shared to handle
+	special requirements for both the host libiberty and host zlib, which has the
+	effect that only one is handled.
+
+	Fix this by handling libiberty and zlib each in its own case statement.
+
+	Build on x86_64-linux, with and without --enable-shared.
+
+	ChangeLog:
+
+	2022-06-27  Tom de Vries  <tdevries@suse.de>
+
+		* configure.ac: Set extra_host_libiberty_configure_flags and
+		extra_host_zlib_configure_flags in separate case statements.
+		* configure: Regenerate.
+
+2022-06-27  Pedro Alves  <pedro@palves.net>
+
+	Make GDBserver abort on internal error in development mode
+	Currently, if GDBserver hits some internal assertion, it exits with
+	error status, instead of aborting.  This makes it harder to debug
+	GDBserver, as you can't just debug a core file if GDBserver fails an
+	assertion.  I've had to hack the code to make GDBserver abort to debug
+	something several times before.
+
+	I believe the reason it exits instead of aborting, is to prevent
+	potentially littering the filesystem of smaller embedded targets with
+	core files.  I think I recall Daniel Jacobowitz once saying that many
+	years ago, but I can't be sure.  Anyhow, that seems reasonable to me.
+
+	Since we nowadays have a distinction between development and release
+	modes, I propose to make GDBserver abort on internal error if in
+	development mode, while keeping the status quo when in release mode.
+
+	Thus, after this patch, in development mode, you get:
+
+	 $ ../gdbserver/gdbserver
+	 ../../src/gdbserver/server.cc:3711: A problem internal to GDBserver has been detected.
+	 captured_main: Assertion `0' failed.
+	 Aborted (core dumped)
+	 $
+
+	while in release mode, you'll continue to get:
+
+	 $ ../gdbserver/gdbserver
+	 ../../src/gdbserver/server.cc:3711: A problem internal to GDBserver has been detected.
+	 captured_main: Assertion `0' failed.
+	 $ echo $?
+	 1
+
+	I do not think that this requires a separate configure switch.
+
+	A "--target_board=native-extended-gdbserver" run on Ubuntu 20.04 ends
+	up with:
+
+			 === gdb Summary ===
+
+	 # of unexpected core files      29
+	 ...
+
+	for me, of which 8 are GDBserver core dumps, 7 more than without this
+	patch.
+
+	Change-Id: I6861e08ad71f65a0332c91ec95ca001d130b0e9d
+
+2022-06-27  Nick Clifton  <nickc@redhat.com>
+
+	Replace a run-time assertion failure with a warning message when parsing corrupt DWARF data.
+		PR 29289
+		* dwarf.c (display_debug_names): Replace assert with a warning
+		message.
+
+	Fix NULL pointer indirection when parsing corrupt DWARF data.
+		PR 29290
+		* dwarf.c (read_and_display_attr_value): Check that debug_info_p
+		is set before dereferencing it.
+
+	Have gold's File_read::do_read() function check the start parameter
+		PR 23765
+		* fileread.cc (File_read::do_read): Check start parameter before
+		computing number of bytes to read.
+
+2022-06-27  Yvan Roux  <yvan.roux@foss.st.com>
+
+	gdb/arm: Unwind Non-Secure callbacks from Secure
+	Without this changeset, the unwinding doesn't take into account
+	Non-Secure to Secure stack unwinding enablement status and
+	doesn't choose the proper SP to do the unwinding.
+
+	This patch only unwinds the stack when Non-Secure to Secure
+	unwinding is enabled, previous SP is set w/r to the current mode
+	(Handler -> msp_s, Thread -> psp_s) and then the Secure stack is
+	unwound.  Ensure thumb bit is set in PSR when needed.  Also, drop
+	thumb bit from PC if set.
+
+2022-06-27  Nick Clifton  <nickc@redhat.com>
+
+	Stop bogus warnings about DWARF indexed string offsets being too big.
+		* dwarf.c (fetch_indexed_string): Do not use length of first table
+		in string section as the length of every table in the section.
+		* testsuite/binutils-all/pr26112.r: Update expected output.
+
+2022-06-27  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Handle older python in gdb.python/py-send-packet.py
+	With python 3.4, I run into:
+	...
+	Traceback (most recent call last):^M
+	  File "<string>", line 1, in <module>^M
+	  File
+	  "outputs/gdb.python/py-send-packet/py-send-packet.py", line 128, in \
+	    run_set_global_var_test^M
+	    res = conn.send_packet(b"X%x,4:\x02\x02\x02\x02" % addr)^M
+	TypeError: Could not convert Python object: b'X%x,4:\x02\x02\x02\x02'.^M
+	Error while executing Python code.^M
+	...
+	while with python 3.6 this works fine.
+
+	The type of addr is <class 'gdb.Value'>, so the first thing to try is whether
+	changing it into a string works:
+	...
+	    addr_str = "%x" % addr
+	    res = conn.send_packet(b"X%s,4:\x02\x02\x02\x02" % addr_str)
+	...
+	which gets us the more detailed:
+	...
+	TypeError: unsupported operand type(s) for %: 'bytes' and 'str'
+	...
+
+	Fix this by avoiding the '%' operator in the byte literal, and use instead:
+	...
+	def xpacket_header (addr):
+	    return ("X%x,4:" % addr).encode('ascii')
+	  ...
+	    res = conn.send_packet(xpacket_header(addr) + b"\x02\x02\x02\x02")
+	...
+
+	Tested on x86_64-linux, with python 3.4 and 3.6, and a backported version was
+	tested on the gdb-12-branch in combination with python 2.7.
+
+2022-06-27  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.reverse/i387-env-reverse.exp for -pie
+	When running test-case gdb.reverse/i387-env-reverse.exp for x86_64-linux with
+	target board unix/-m32/-fPIE/-pie, we run into:
+	...
+	(gdb) PASS: gdb.reverse/i387-env-reverse.exp: push st0
+	info register eax^M
+	eax            0x56550000          1448411136^M
+	(gdb) FAIL: gdb.reverse/i387-env-reverse.exp: verify eax == 0x8040000
+	...
+
+	The problem is that the tested instruction (fstsw) only sets $ax, not $eax.
+
+	Fix this by verifying $ax instead of $eax.
+
+	Tested on x86_64-linux with target boards unix/-m32 and unix/-m32/-fPIE/-pie.
+
+2022-06-27  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Enable some test-cases for x86_64 -m32
+	When trying to run test-case gdb.reverse/i387-env-reverse.exp for x86_64-linux
+	with target board unix/-m32, it's skipped.
+
+	Fix this by using is_x86_like_target instead of istarget "i?86-*linux*".
+
+	This exposes a number of duplicates, fix those by making the test names unique.
+
+	Likewise in a couple of other test-cases.
+
+	Tested on x86_64-linux with target boards unix/-m32.
+
+2022-06-27  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Workaround unnecessary .s file with gfortran 4.8
+	After running test-case gdb.fortran/namelist.exp with gfortran 4.8.5, I'm left
+	with:
+	...
+	$ git sti
+	On branch master
+	Your branch is up to date with 'origin/master'.
+
+	Untracked files:
+	  (use "git add <file>..." to include in what will be committed)
+	        gdb/testsuite/lib/compiler.s
+
+	nothing added to commit but untracked files present (use "git add" to track)
+	...
+
+	We're running into PR gcc/60447, which was fixed in gcc 4.9.0.
+
+	Workaround this by first copying the source file to the temp dir, such that
+	the .s file is left there instead:
+	...
+	$ ls build/gdb/testsuite/temp/<runtest pid>/
+	compiler.c  compiler.F90  compiler.s
+	...
+
+	Tested on x86_64-linux.
+
+2022-06-27  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Skip gdb.fortran/namelist.exp for gfortran 4.8
+	The test-case gdb.fortran/namelist.exp uses a gfortran feature (emitting
+	DW_TAG_namelist in the debug info) that has been supported since gfortran 4.9,
+	see PR gcc/37132.
+
+	Skip the test for gfortran 4.8 and earlier.  Do this using gcc_major_version,
+	and update it to be able to handle "gcc_major_version {gfortran-*} f90".
+
+	Tested on x86_64-linux, with gfortran 4.8.5, 7.5.0, and 12.1.1.
+
+2022-06-27  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/symtab] Fix parsing of .debug_str_offsets header
+	When running test-case gdb.dwarf2/fission-mix.exp with target board dwarf64
+	and gcc-12 (defaulting to DWARF5), I run into:
+	...
+	(gdb) break func2^M
+	Offset from DW_FORM_GNU_str_index or DW_FORM_strx pointing outside of \
+	  .debug_str.dwo section in CU at offset 0x0 [in module fission-mix]^M
+	(gdb) FAIL: gdb.dwarf2/fission-mix.exp: break func2
+	...
+
+	The .debug_str_offsets section has version 5, so as per the standard it has
+	it's own header, with initial length and version:
+	...
+	Contents of the .debug_str_offsets.dwo section (loaded from fission-mix2.dwo):
+
+	    Length: 0x1c
+	    Version: 0x5
+	       Index   Offset [String]
+	           0        0 build/gdb/testsuite
+	           1       33 GNU C17
+	           2       8f src/gdb/testsuite/gdb.dwarf2/fission-mix-2.c
+	...
+
+	But when trying to read the string offset at index 0 in the table (which
+	is 0), we start reading at offset 8, which points in the header, at the last
+	4 bytes of the initial length (it's 12 bytes because of 64-bit dwarf), as well
+	at the 2-byte version field and 2 bytes of padding, so we get:
+	...
+	(gdb) p /x str_offset
+	$1 = 0x500000000
+	...
+	which indeed is an offset that doesn't fit in the .debug_str section.
+
+	The offset 8 is based on reader->cu->header.addr_size:
+	...
+	static const char *
+	read_dwo_str_index (const struct die_reader_specs *reader, ULONGEST str_index)
+	{
+	 ULONGEST str_offsets_base = reader->cu->header.version >= 5
+	                             ? reader->cu->header.addr_size : 0;
+	...
+	which doesn't in look in agreement with the standard.
+
+	Note that this happens to give the right answer for 32-bit dwarf and
+	addr_size == 8, because then we have header size ==
+	(initial length (4) + version (2) + padding (2)) == 8.
+
+	Conversely, for 32-bit dwarf and addr_size == 4 (target board unix/-m32)
+	we run into a similar problem.  It just happens to not trigger the warning,
+	instead we get the wrong strings, like "func2" for DW_AT_producer and
+	"build/gdb/testsuite" for DW_AT_name of the DW_TAG_compile_unit DIE.
+
+	Fix this by parsing the .debug_str_offsets header in read_dwo_str_index.
+
+	Add a FIXME that we should not parse this for every call.
+
+	Tested on x86_64-linux.
+
+2022-06-27  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/build] Fix gdbserver build with -fsanitize=thread
+	[ Copied from gcc commit 153689603fd ("[gdb/build] Fix gdbserver build with
+	-fsanitize=thread"). ]
+
+	When building gdbserver with -fsanitize=thread (added to CFLAGS/CXXFLAGS) we
+	run into:
+	...
+	ld: ../libiberty/libiberty.a(safe-ctype.o): warning: relocation against \
+	  `__tsan_init' in read-only section `.text'
+	ld: ../libiberty/libiberty.a(safe-ctype.o): relocation R_X86_64_PC32 \
+	  against symbol `__tsan_init' can not be used when making a shared object; \
+	  recompile with -fPIC
+	ld: final link failed: bad value
+	collect2: error: ld returned 1 exit status
+	make[1]: *** [libinproctrace.so] Error 1
+	...
+	which looks similar to what is described in commit 78e49486944 ("[gdb/build]
+	Fix gdbserver build with -fsanitize=address").
+
+	The gdbserver component builds a shared library libinproctrace.so, which uses
+	libiberty and therefore requires the pic variant.  The gdbserver Makefile is
+	setup to use this variant, if available, but it's not there.
+
+	Fix this by listing gdbserver in the toplevel configure alongside libcc1, as a
+	component that needs the libiberty pic variant, setting:
+	...
+	extra_host_libiberty_configure_flags=--enable-shared
+	...
+
+	Tested on x86_64-linux.
+
+	ChangeLog:
+
+	2022-06-27  Tom de Vries  <tdevries@suse.de>
+
+		* configure.ac: Build libiberty pic variant for gdbserver.
+		* configure: Regenerate.
+
+2022-06-27  Nick Clifton  <nickc@redhat.com>
+
+	Disable execstack and rwx segments warnings for MIPS targets.
+		PR 29263
+		* configure.ac: Move HPPA specific code from here...
+		* configure.tgt: ... to here.  Add similar code for MIPS.
+		Move code for CRIS, MIPS and HPPA to block at start of file.
+		* configure: Regenerate.
+
+2022-06-27  Jan Beulich  <jbeulich@suse.com>
+
+	bfd: prune config.bfd's setting of targ_archs
+	The final "match all" case can take care of a few explicit entries:
+	Purge those. Also move s12z* into proper position (the table is
+	otherwise sorted, after all).
+
+2022-06-27  Jan Beulich  <jbeulich@suse.com>
+
+	drop XC16x bits
+	Commit 04f096fb9e25 ("Move the xc16x target to the obsolete list") moved
+	the architecture from the "obsolete but still available" to the
+	"obsolete / support removed" list in config.bfd, making the architecture
+	impossible to enable (except maybe via "enable everything" options").
+
+	Note that I didn't touch */po/*.po{,t} on the assumption that these
+	would be updated by some (half)automatic means.
+
+2022-06-27  Bhuvanendra Kumar N  <Bhuvanendra.KumarN@amd.com>
+
+	Fix location list offset address dump under DW_AT_location (dwarf-5)
+	For clang compiled objects with dwarf-5, location list offset address dump
+	under DW_AT_location is corrected, where DW_FORM_loclistx is used. While
+	dumping the location list offset, the address dumped is wrong where it was
+	refering to .debug_addr instead of .debug_loclists
+
+	      * dwarf.c (fetch_indexed_value): Add base_address as parameter and
+	      use it to access the section offset.
+	      (read_and_display_attr_value): Handle DW_FORM_loclistx form separately.
+	      Pass loclists_base to fetch_indexed_value().
+
+2022-06-27  Alan Modra  <amodra@gmail.com>
+
+	PowerPC64 .branch_lt address
+	.branch_lt is really an extension of .plt, as is .iplt.  We'd like all
+	of the PLT sections to be fixed relative to .TOC. after stub sizing,
+	because changes in offset to PLT entries might mean a change in stub
+	sizes.  When -z relro, the relro layout does this by laying out
+	sections from the end of the relro segment.  So for example, a change
+	in .eh_frame (which happens after stub sizing) will keep the same GOT
+	to PLT offset when -z relro.  Not so when -z norelro, because then the
+	usual forward layout of section is done and .got is more aligned than
+	.branch_lt.
+
+		* emulparams/elf64ppc.sh: Set .branch_lt address fixed relative
+		to .got.
+		* testsuite/ld-powerpc/elfv2exe.d: Adjust to suit.
+
+2022-06-27  Alan Modra  <amodra@gmail.com>
+
+	-z relro relaxation and ld script SIZEOF
+	A number of targets use assignments like:
+	. = DATA_SEGMENT_RELRO_END (SIZEOF (.got.plt) >= 12 ? 12 : 0, .);
+	(from i386) in linker scripts to put the end of the relro segment past
+	the header in .got.plt.  Examination of testcases like those edited by
+	this patch instead sees the end of the relro segment being placed at
+	the start of .got.plt.  For the i386 pie1 test:
+
+	  [ 9] .got.plt          PROGBITS        00002000 001000 00000c 04  WA  0   0  4
+
+	  GNU_RELRO      0x000f90 0x00001f90 0x00001f90 0x00070 0x00070 R   0x1
+
+	A map file shows:
+
+	.dynamic        0x0000000000001f90       0x70
+	 *(.dynamic)
+	 .dynamic       0x0000000000001f90       0x70 tmpdir/pie1.o
+	                0x0000000000001f90                _DYNAMIC
+
+	.got            0x0000000000002000        0x0
+	 *(.got)
+	 .got           0x0000000000002000        0x0 tmpdir/pie1.o
+	 *(.igot)
+	                0x0000000000002ff4                . = DATA_SEGMENT_RELRO_END (., (SIZEOF (.got.plt) >= 0xc)?0xc:0x0)
+
+	.got.plt        0x0000000000002000        0xc
+	 *(.got.plt)
+	 .got.plt       0x0000000000002000        0xc tmpdir/pie1.o
+	                0x0000000000002000                _GLOBAL_OFFSET_TABLE_
+
+	The DATA_SEGMENT_RELRO_END value in the map file is weird too.  All of
+	this is triggered by SIZEOF (.got.plt) being evaluated wrongly as
+	zero.  Fix it by taking into account the action of
+	lang_reset_memory_regions during relaxation.
+
+		* ldexp.c (fold_name <SIZEOF>): Use rawsize if size has been reset.
+		* ldlang.c (lang_size_sections_1): Don't reset processed_vma here.
+		* testsuite/ld-i386/pie1.d: Adjust to suit.
+		* testsuite/ld-x86-64/pr20830a.d: Likewise.
+		* testsuite/ld-x86-64/pr20830b.d: Likewise.
+		* testsuite/ld-x86-64/pr21038a.d: Likewise.
+		* testsuite/ld-x86-64/pr21038b.d: Likewise.
+		* testsuite/ld-x86-64/pr21038c.d: Likewise.
+
+2022-06-27  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-26  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-25  Fangrui Song  <i@maskray.me>
+
+	arm: Define elf_backend_extern_protected_data to 0 [PR 18705]
+	Similar to commit 4fb55bf6a9606eb7b626c30a9f4e71d6c2d4fbb2 for aarch64.
+
+	Commit b68a20d6675f1360ea4db50a9835c073675b9889 changed ld to produce
+	R_ARM_GLOB_DAT but that defeated the purpose of protected visibility
+	as an optimization.  Restore the previous behavior (which matches
+	ld.lld) by defining elf_backend_extern_protected_data to 0.
+
+2022-06-25  Tom Tromey  <tom@tromey.com>
+
+	Fix corrupt DWARF in dw2-double-set-die-type
+	The dw2-double-set-die-type.exp test case caused an AddressSanitizer
+	failure in the new DWARF scanner.
+
+	The immediate cause was bad DWARF in the test -- in particular, the
+	the sibling attribute here:
+
+	     <2><181>: Abbrev Number: 33 (DW_TAG_subprogram)
+		<182>   DW_AT_external    : 1
+		<183>   DW_AT_name        : address
+		<18b>   DW_AT_type        : <0x171>
+		<18f>   DW_AT_declaration : 1
+		<190>   DW_AT_sibling     : <0x1a1>
+	    ...
+	     <1><1a1>: Abbrev Number: 23 (DW_TAG_pointer_type)
+		<1a2>   DW_AT_byte_size   : 4
+		<1a3>   DW_AT_type        : <0x1a7>
+
+	...points to a "sibling" DIE that is at a different child depth.
+
+	Because this test case doesn't really require sibling attributes, this
+	patch fixes the problem by removing them from the test.
+
+	Note that gdb is not generally robust against malformed DWARF.
+	Detecting and compensating for this problem would probably be
+	expensive and, IMO, is better left to some (still hypothetical) DWARF
+	linter.
+
+2022-06-25  Tom Tromey  <tom@tromey.com>
+
+	Fix end of CU calculation in cooked_indexer::index_dies
+	cooked_indexer::index_dies incorrect computes the end of the current
+	CU in the .debug_info.  This isn't readily testable without writing
+	intentionally corrupt DWARF, but it's apparent through observation: it
+	is currently based on 'info_ptr', which does not always point to the
+	start of the CU.  This patch fixes the expression.  Tested on x86-64
+	Fedora 34.
+
+2022-06-25  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: LoongArch: Implement loongarch_linux_syscall_next_pc()
+	When FRAME is at a syscall instruction, return the PC of the next
+	instruction to be executed.
+
+	gdb: LoongArch: Define register numbers and clean up code
+	This commit defines register numbers of various important registers,
+	we can use them directly in the related code, and also clean up some
+	code to make them more clear and readable.
+
+2022-06-25  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-24  Pedro Alves  <pedro@palves.net>
+
+	Eliminate TUI/CLI observers duplication
+	For historical reasons, the CLI and the TUI observers are basically
+	exact duplicates, except for the downcast:
+
+	 cli:
+	       struct cli_interp *cli = as_cli_interp (interp);
+	 tui:
+	       struct interp *tui = as_tui_interp (interp);
+
+	and how they get at the interpreter's ui_out:
+
+	 cli:
+	       cli->cli_uiout
+	 tui:
+	       tui->interp_ui_out ()
+
+	Since interp_ui_out() is a virtual method that also works for the CLI
+	interpreter, and, both the CLI and the TUI interpreters inherit from
+	the same base class (cli_interp_base), we can convert the CLI
+	observers to cast to cli_interp_base instead and use interp_ui_out()
+	too.  With that, the CLI observers will work for the TUI interpreter
+	as well.  This lets us completely eliminate the TUI observers.  That's
+	what this commit does.
+
+	Change-Id: Iaf6cf12dfa200ed3ab203a895a72b69dfedbd6e0
+
+2022-06-24  Pedro Alves  <pedro@palves.net>
+
+	Revert "Delete delete_thread_silent"
+	Turns out we'll be gaining a new use of this function very soon, the
+	incoming AMDGPU port needs it.  Let's add it back, as it isn't really
+	hurting anything.
+
+	This reverts commit 39b8a8090ed7e8967ceca3655aa5f3a2ae91219d.
+
+2022-06-24  Yvan Roux  <yvan.roux@foss.st.com>
+
+	gdb/arm: Update the value of active sp when base sp changes
+	For Arm Cortex-M33 with security extensions, there are 4 different
+	stacks pointers (msp_s, msp_ns, psp_s, psp_ns).
+	When plain "sp" is updated during unwinding of the stack, the active
+	stack pointer of the 4 stack pointers needs to be kept in sync.
+
+2022-06-24  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: remove unneeded calls to get_compiler_info
+	It is not necessary to call get_compiler_info before calling
+	test_compiler_info, and, after recent commits that removed setting up
+	the gcc_compiled, true, and false globals from get_compiler_info,
+	there is now no longer any need for any test script to call
+	get_compiler_info directly.
+
+	As a result every call to get_compiler_info outside of lib/gdb.exp is
+	redundant, and this commit removes them all.
+
+	There should be no change in what is tested after this commit.
+
+2022-06-24  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: remove global gcc_compiled from gdb.exp
+	After this commit the gcc_compiled global is no longer exported from
+	lib/gdb.exp.  In theory we could switch over all uses of gcc_compiled
+	to instead call test_compiler_info directly, however, I have instead
+	added a new proc to gdb.exp: 'is_c_compiler_gcc'.  I've then updated
+	the testsuite to call this proc instead of using the global.
+
+	Having a new proc specifically for this task means that we have a
+	single consistent pattern for detecting gcc.  By wrapping this logic
+	within a proc that calls test_compiler_info, rather than using the
+	global, means that test scripts don't need to call get_compiler_info
+	before they read the global, simply calling the new proc does
+	everything in one go.
+
+	As a result I've been able to remove the get_compiler_info calls from
+	all the test scripts that I've touched in this commit.
+
+	In some of the tests e.g. gdb.dwarf2/*.exp, the $gcc_compiled flag was
+	being checked at the top of the script to decide if the whole script
+	should be skipped or not.  In these cases I've called the new proc
+	directly and removed all uses of gcc_compiled.
+
+	In other cases, e.g. most of the gdb.base scripts, there were many
+	uses of gcc_compiled.  In these cases I set a new global gcc_compiled
+	near the top of the script, and leave the rest of the script
+	unchanged.
+
+	There should be no changes in what is tested after this commit.
+
+2022-06-24  Pedro Alves  <pedro@palves.net>
+
+	Include count of unexpected core files in gdb.sum summary
+	If GDB, GDBserver, a testcase program, Valgrind, etc. unexpectedly
+	crash while running the GDB testsuite, and you've setup your machine
+	such that core files are dumped in the current directory instead of
+	being shoved somewhere by abrt, apport, or similar (as you should for
+	proper GDB testing), you'll end up with an unexpected core file in the
+	$build/gdb/testsuite/ directory.
+
+	It can happen that GDB, GDBserver, etc. even crashes _after_ gdb_exit,
+	during teardown, and thus such a crash won't be noticed by looking at
+	the gdb.sum file at all.  This commit aims at improving that, by
+	including a new "unexpected core files" line in the testrun summary.
+
+	For example, here's what I get on x86-64 Ubuntu 20.04, with this
+	patch:
+
+			 === gdb Summary ===
+
+	 # of unexpected core files      12          << new info
+	 # of expected passes            107557
+	 # of unexpected failures        35
+	 # of expected failures          77
+	 # of unknown successes          2
+	 # of known failures             114
+	 # of untested testcases         31
+	 # of unsupported tests          139
+
+	I have my core pattern setup like this:
+
+	 $ cat /proc/sys/kernel/core_pattern
+	 core.%e.%p.%h.%t
+
+	That's:
+
+	 %e: executable filename
+	 %p: pid
+	 %h: hostname
+	 %t: UNIX time of dump
+
+	and so I get these core files:
+
+	 $ ls -1 testsuite/core.*
+	 testsuite/core.connect-with-no.216191.nelson.1656002431
+	 testsuite/core.connect-with-no.217729.nelson.1656002431
+	 testsuite/core.gdb.194247.nelson.1656002423
+	 testsuite/core.gdb.226014.nelson.1656002435
+	 testsuite/core.gdb.232078.nelson.1656002438
+	 testsuite/core.gdb.352268.nelson.1656002441
+	 testsuite/core.gdb.4152093.nelson.1656002337
+	 testsuite/core.gdb.4154515.nelson.1656002338
+	 testsuite/core.gdb.4156668.nelson.1656002339
+	 testsuite/core.gdb.4158871.nelson.1656002341
+	 testsuite/core.gdb.468495.nelson.1656002444
+	 testsuite/core.vgdb.4192247.nelson.1656002366
+
+	where we can see that GDB crashed a number of times, but also
+	Valgrind's vgdb, and a couple testcase programs.  Neither of which is
+	good.
+
+	If your core_pattern is just "core" (but why??), then I guess that you
+	may end up with just a single core file in testsuite/.  Still, that is
+	one core file too many.
+
+	Above, we see a couple cores for "connect-with-no", which are the
+	result of gdb.server/connect-with-no-symbol-file.exp.  This is a case
+	mentioned above -- while the program crashed, that happens during
+	testcase teardown, and it goes unnoticed (without this commit) by
+	gdb.sum results.  Vis:
+
+	 $ make check TESTS="gdb.server/connect-with-no-symbol-file.exp"
+	 ...
+			 === gdb Summary ===
+
+	 # of unexpected core files      2
+	 # of expected passes            8
+
+	 ...
+	 $
+
+	The tests fully passed, but still the testcase program crashed
+	somehow:
+
+	 $ ls -1 testsuite/core.*
+	 testsuite/core.connect-with-no.941561.nelson.1656003317
+	 testsuite/core.connect-with-no.941682.nelson.1656003317
+
+	Against --target_board=native-extended-gdbserver it's even worse.  I
+	get:
+
+	 # of unexpected core files      26
+
+	and note that when GDBserver hits an assertion failure, it exits with
+	error, instead of crashing with SIGABRT.  I think that should be
+	changed, at least on development builds, but that would be for another
+	patch.  After such patch, I suspect the number of unexpected cores
+	will be higher, as there are likely teardown GDBserver assertions that
+	we're not noticing.
+
+	I decided to put this new info in the "gdb Summary" section, as that's
+	a place people already are used to looking at, either when looking at
+	the tail of gdb.sum, or when diffing gdb.sum files, and we've already
+	extended this section before, to include the count of DUPLICATE and
+	PATH problems, so there's precedent.
+
+	Implementation-wise, the new line is appended after DejaGnu is
+	finished, with a shell script that is invoked by the Makefile.  It is
+	done this way so that serial and parallel testing work the same way.
+	My initial cut at an implementation was in TCL, straight in
+	testsuite/lib/check-test-names.exp, where DUPLICATES and PATH are
+	handled, like so:
+
+	 @@ -148,6 +159,10 @@ namespace eval ::CheckTestNames {
+		     $counts(paths,$which)
+		 maybe_show_count "# of duplicate test names\t" \
+		     $counts(duplicates,$which)
+	 +
+	 +       set cores [glob -nocomplain -directory $::objdir core*]
+	 +       maybe_show_count "# of unexpected core files\t" \
+	 +           [llength $cores]
+	      }
+
+	But that would only work for serial testing, as in parallel testing,
+	the final gdb.sum is generated by aggregating the results of all the
+	individual gdb.sum files, and dg-extract-results.sh doesn't know about
+	our new summary line.  And I don't think that dg-extract-results.sh
+	should be taught about it, since the count of core files is not
+	something that we want to count many times, once per testcase, and
+	then add up the subcounts at the end.  Every time we count the core
+	files, we're already counting the final count.
+
+	I considered using the Tcl implementation in serial mode, and the
+	script approach for parallel testing, but that has the obvious
+	downside of implementing and maintaining the same thing twice.  In the
+	end, I settled on the script approach for serial mode too, which
+	requires making the "check-single" rule print the tail end of the
+	gdb.sum file, with a side effect being that if you look at the
+	terminal after a run (instead of at the gdb.sum file), you'll see the
+	"gdb Summary" section twice, once without the unexpected core lines
+	printed, and then another with.  IMO, this isn't an issue; when
+	testing in parallel mode, if you look at the terminal after "make -jN
+	check", you'll also see multiple "gdb Summary" sections printed.
+
+	Change-Id: I190b8d41856d49ad143854b6e3e6ccd7caa04491
+
+2022-06-24  Pedro Alves  <pedro@palves.net>
+
+	Improve core file path detection & put cores in output dir
+	After a testrun, I noticed that I have some kernel-produced cores for
+	testcase programs, under build/gdb/testsuite/, which shouldn't be
+	there:
+
+	 $ ls -1 testsuite/core.*
+	 testsuite/core.annota1.1274351.nelson.1656004407
+	 testsuite/core.annota3.1288474.nelson.1656004414
+	 testsuite/core.exitsignal.1240674.nelson.1656004391
+
+	I have my core pattern setup like this:
+
+	 $ cat /proc/sys/kernel/core_pattern
+	 core.%e.%p.%h.%t
+
+	That's:
+
+	 %e: executable filename
+	 %p: pid
+	 %h: hostname
+	 %t: UNIX time of dump
+
+	so it's easy to tell which program produced the core from the core
+	file name.
+
+	From above, we can tell that the corresponding testcases are
+	gdb.base/annota1.exp, gdb.base/annota3.exp and
+	gdb.base/exitsignal.exp.
+
+	At least gdb.base/annota1.exp and gdb.base/annota3.exp have code in
+	them to delete the core file.  However, that isn't working for me,
+	because said code only looks for cores named exactly either "core" or
+	"core.PID", and my core_pattern doesn't match that.
+
+	Another issue I noticed, is that I have not been running
+	gdb.base/bigcore.exp, for a similar reason.  I get:
+
+	  Program terminated with signal SIGABRT, Aborted.
+	  The program no longer exists.
+	  (gdb) PASS: gdb.base/bigcore.exp: signal SIGABRT
+	  UNTESTED: gdb.base/bigcore.exp: can't generate a core file
+
+	But I actually have a core file under the testcase's output dir:
+
+	 $ find . -name "core.*"
+	 ./testsuite/outputs/gdb.base/bigcore/core.bigcore.2306705.nelson.1656005213
+	 $
+
+	This commit fixes these things, by adding a find_core_file routine
+	that searches core files in a way that works with my core pattern as
+	well.  This then also adds a convenience remove_core routine as a
+	wrapper around find_core_file that removes the found core file.
+
+	In addition, it changes some testcases that expect to have their
+	program dump core, to switch the inferior's cwd to the testcase's
+	output dir, so that the core is dumped there instead of in
+	build/gdb/testsuite/.  Some testcases were already doing that, but not
+	all.  The idea is that any core file dumped in build/gdb/testsuite/ is
+	an unexpected core file.  The next patch will add a count of such
+	unexpected core files to gdb.sum.
+
+	Another change is that the directory changing is now done with "set
+	cwd" instead of with "cd".  "set cwd" only affects the inferior cwd,
+	while "cd" affects GDB's cwd too.  By using "set cwd" instead of "cd",
+	if GDB dumps core in these testcases, the GDB core dump will still end
+	up in build/gdb/testsuite/, and can thus be detected as an unexpected
+	core.
+
+	Change-Id: I45068f21ffd4814350aaa8a3cc65cad5e3107607
+
+2022-06-24  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: make use of RAII in run_inferior_call
+	In passing I noticed that there are three local variables in
+	run_inferior_call that are used to save, and then restore some state,
+	I think these could all be replaced with a RAII style scoped_restore
+	instead.
+
+	Of the three locals that I've changed, the only one that I believe is
+	now restored in a different location is ui::async, before this commit
+	the async field was restored after a call to either delete_file_handle
+	or ui_register_input_event_handler, and after this commit, the field
+	is restored before these calls.  However, I don't believe that either
+	of these functions depend on the value of the async field, so I
+	believe the commit is fine.
+
+	Tested on x86-64/Linux passes with no regressions.
+
+2022-06-24  Pedro Alves  <pedro@palves.net>
+
+	Delete delete_thread_silent
+	delete_thread_silent is no longer used anywhere.  Delete it.
+
+	Change-Id: Iafcec12339861d5ab2e29c14d7b1f884c9e11c0f
+
+2022-06-24  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-23  Tom Tromey  <tromey@adacore.com>
+
+	Don't declare cli_set_logging
+	cli_set_logging is declared but not defined.  It's probably a leftover
+	from whenever interpreters were changed to use inheritance.  This
+	patch removes the declaration.  Tested by grep and rebuilding.
+
+	Use PyBool_FromLong
+	I noticed a few spots that were explicitly creating new references to
+	Py_True or Py_False.  It's simpler here to use PyBool_FromLong, so
+	this patch changes all the places I found.
+
+2022-06-23  Alan Modra  <amodra@gmail.com>
+
+	PowerPC64: fix assertion in ppc_build_one_stub with -Os code
+	save_res stubs aren't written in ppc_build_one_stub, their offsets
+	(which are zero) should not be checked.
+
+		* elf64-ppc.c (ppc_build_one_stub): Don't check save_res offsets.
+
+2022-06-23  Alan Modra  <amodra@gmail.com>
+
+	Re: PowerPC64: stub debug dump
+	Let's show the current stub as well as the previous one.  Of interest
+	is the current offset and a new field, id.  Check that the build
+	hash table traversal is in the same order as sizing traversal too.
+
+		* elf64-ppc.c (struct ppc_stub_hash_entry): Add id.
+		(struct ppc_link_hash_table): Add stub_id.
+		(stub_hash_newfunc): Init id and symtype.
+		(dump_stub): New function, extracted from..
+		(dump_previous_stub): ..here.  Deleted.
+		(ppc_build_one_stub): Sanity check stub id as well as offset.
+		Show current stub as well as previous.
+		(ppc_size_one_stub): Set stub id.
+		(ppc64_elf_size_stubs): Init stub_id before traversal.
+		(ppc64_elf_build_stubs): Likewise.
+
+2022-06-23  Fangrui Song  <maskray@google.com>
+
+	aarch64: Allow PC-relative relocations against protected STT_FUNC for -shared
+	    __attribute__((visibility("protected"))) void *foo() {
+	      return (void *)foo;
+	    }
+
+	gcc -fpic -shared -fuse-ld=bfd fails with the confusing diagnostic:
+
+	    relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `foo' which may bind externally can not be used when making a shared object; recompile with -fPIC
+
+	Call _bfd_elf_symbol_refs_local_p with local_protected==true to suppress
+	the error.  The new behavior matches gold and ld.lld.
+
+	Note: if some code tries to use direct access relocations to take the
+	address of foo (likely due to -fno-pic), the pointer equality will
+	break, but the error should be reported on the executable link, not on
+	the innocent shared object link.  glibc 2.36 will give a warning at
+	relocation resolving time.
+
+2022-06-23  Fangrui Song  <maskray@google.com>
+
+	aarch64: Define elf_backend_extern_protected_data to 0 [PR 18705]
+	Follow-up to commit 90b7a5df152a64d2bea20beb438e8b81049a5c30
+	("aarch64: Disallow copy relocations on protected data").
+
+	Commit 32f573bcb3aaa1c9defcad79dbb5851fcc02ae2d changed ld to produce
+	R_AARCH64_GLOB_DAT but that defeated the purpose of protected visibility
+	as an optimization.  Restore the previous behavior (which matches
+	ld.lld) by defining elf_backend_extern_protected_data to 0.
+
+2022-06-23  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-22  Tom Tromey  <tromey@adacore.com>
+
+	Use std::string for interpreter_p
+	The global interpreter_p is a manually-managed 'char *'.  This patch
+	changes it to be a std::string instead, and removes some erroneous
+	comments.
+
+	Move mi_interpreter to mi-interp.h
+	I noticed that touching interps.h caused a lot of recompilation.  I
+	tracked this down to mi-common.h including this file.  This patch
+	moves the MI interpreter to mi-interp.h, which cuts down on
+	recompilation when modifying interps.h.
+
+	Use unique_xmalloc_ptr in interp
+	This changes interp::m_name to be a unique_xmalloc_ptr, removing some
+	manual memory management.  It also cleans up the initialization of the
+	'inited' member, and moves the 'private:' and 'public:' keywords to
+	their proper spots.
+
+2022-06-22  Fangrui Song  <i@maskray.me>
+
+	aarch64: Disallow copy relocations on protected data
+	If an executable has copy relocations for extern protected data, that
+	can only work if the shared object containing the definition is built
+	with assumptions (a) the compiler emits GOT-generating relocations (b)
+	the linker produces R_*_GLOB_DAT instead of R_*_RELATIVE.  Otherwise the
+	shared object uses its own definition directly and the executable
+	accesses a stale copy.  Note: the GOT relocations defeat the purpose of
+	protected visibility as an optimization, and it turns out this never
+	worked perfectly.
+
+	glibc 2.36 will warn on copy relocations on protected data.  Let's
+	produce a warning at link time, matching ld.lld which has been used on
+	many aarch64 OSes.
+
+	Note: x86 requires GNU_PROPERTY_NO_COPY_ON_PROTECTED to have the error.
+	This is to largely due to GCC 5's "x86-64: Optimize access to globals in
+	PIE with copy reloc" which started to use direct access relocations for
+	external data symbols in -fpie mode.
+
+	GCC's aarch64 port does not have the change.  Nowadays with most builds
+	switching to -fpie/-fpic, aarch64 mostly doesn't need to worry about
+	copy relocations.  So for aarch64 we simply don't check
+	GNU_PROPERTY_NO_COPY_ON_PROTECTED.
+
+2022-06-22  Kumar N, Bhuvanendra  <Kavitha.Natarajan@amd.com>
+
+	Binutils support for split-dwarf and dwarf-5
+		* dwarf.c (fetch_indexed_string): Added new parameter
+		str_offsets_base to calculate the string offset.
+		(read_and_display_attr_value): Read DW_AT_str_offsets_base
+		attribute.
+		(process_debug_info): While allocating memory and initializing
+		debug_information, do it for do_debug_info also, if its true.
+		(load_separate_debug_files): Load .debug_str_offsets if exists.
+		* dwarf.h (struct debug_info): Add str_offsets_base field.
+
+2022-06-22  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: Reorder the prefixed extensions which are out of order.
+	This patch has been pending for almost a year...  However, I noticed that
+	llvm can already re-order the extensions, even if they are out of orders.
+	Not really sure if they can also re-order the single letter extensions,
+	but at least we can do this for the multi-letter extensions in binutils.
+
+	bfd/
+	    * elfxx-riscv.c (riscv_parse_prefixed_ext): Removed the code which are
+	    used to check the prefixed extension orders.
+	gas/
+	    * testsuite/gas/riscv/march-fail-order-x-z.d: Removed since we will help
+	    tp reorder the prefixed extensions for now.
+	    * testsuite/gas/riscv/march-fail-order-x-z.l: Likewise.
+	    * testsuite/gas/riscv/march-fail-order-x.d: Likewise.
+	    * testsuite/gas/riscv/march-fail-order-x.l: Likewise.
+	    * testsuite/gas/riscv/march-fail-order-z.d: Likewise.
+	    * testsuite/gas/riscv/march-fail-order-z.l: Likewise.
+
+2022-06-22  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: Use single h extension to control hypervisor CSRs and instructions.
+	According to the picture 28.1 in the current ISA spec, h is no larger the
+	multi-letter extension, it is a single extension after v.  Therefore, this
+	patch fix the implementation, and use the single h to control hypervisor
+	CSRs and instructions, which we promised to do before.
+
+	bfd/
+	    * elfxx-riscv.c (riscv_supported_std_ext): Added h with version 1.0 after v.
+	    (riscv_supported_std_h_ext): Removed.
+	    (riscv_all_supported_ext): Updated since riscv_supported_std_h_ext is removed.
+	    (riscv_prefix_ext_class): Removed RV_ISA_CLASS_H.
+	    (parse_config): Updated since riscv_prefix_ext_class is removed.
+	    (riscv_recognized_prefixed_ext): Likewise.
+	    (riscv_get_default_ext_version): Likewise.
+	    (riscv_multi_subset_supports): Handle INSN_CLASS_H for hypervisor instructions.
+	    (riscv_multi_subset_supports_ext): Likewise.
+	gas/
+	    * config/tc-riscv.c (riscv_csr_class): Added CSR_CLASS_H and CSR_CLASS_H_32 for
+	    hypervisor CSRs.
+	    (riscv_csr_address): Likewise.
+	    * testsuite/gas/riscv/csr-version-1p10.d: Updated since hypervisor CSRs are
+	    controlled by single h extension for now.
+	    * testsuite/gas/riscv/csr-version-1p10.l: Likewise.
+	    * testsuite/gas/riscv/csr-version-1p11.d: Likewise.
+	    * testsuite/gas/riscv/csr-version-1p11.l: Likewise.
+	    * testsuite/gas/riscv/csr-version-1p12.d: Likewise.
+	    * testsuite/gas/riscv/csr-version-1p12.l: Likewise.
+	    * testsuite/gas/riscv/csr-version-1p9p1.d: Likewise.
+	    * testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
+	    * testsuite/gas/riscv/h-ext-32.d: Added h to architecture string.
+	    * testsuite/gas/riscv/h-ext-64.d: Likewise.
+	    * testsuite/gas/riscv/march-fail-single-prefix-h: Removed since h is no
+	    longer multi-letter extension.
+	    * testsuite/gas/riscv/march-fail-unknown-h.d: Likewise.
+	include/
+	    * opcode/riscv-opc.h: Control hypervisor CSRs by h extension, rather than
+	    the privileged spec verisons.
+	    * opcode/riscv.h (riscv_insn_class): Added INSN_CLASS_H.
+	opcodes/
+	    * riscv-opc.c (riscv_opcodes): Control hypervisor instructions by h extension.
+
+2022-06-22  Tsukasa OI  <research_trasio@irq.a4lg.com>
+
+	RISC-V: Add 'H' to canonical extension ordering
+	This commit adds 'H' to canonical extension ordering based on current
+	consensus (not officially ratified as a new ISA specification manual
+	but discussion for software compatibility is made).
+
+	bfd/ChangeLog
+
+		* elfxx-riscv.c (riscv_ext_canonical_order): Add 'H' for
+		canonical extension ordering based on current consensus.
+
+2022-06-22  Tsukasa OI  <research_trasio@irq.a4lg.com>
+
+	RISC-V: Prepare i18n for required ISA extensions
+	Some strings returned by the riscv_multi_subset_supports_ext function
+	contain not just extension names but words like "and" and "or".
+	This commit wraps such strings with the gettext macro (_) for
+	internationalization in the future.
+
+	bfd/ChangeLog:
+
+		* elfxx-riscv.c (riscv_multi_subset_supports_ext): Wrap some
+		strings with the gettext macro to prepare future i18n.
+
+2022-06-22  Tsukasa OI  <research_trasio@irq.a4lg.com>
+
+	RISC-V: Fix inconsistent error message (range)
+	This commit fixes inconsistent error message format involving compressed
+	funct<n> fields.  In specific, funct6 had an error message with range
+	0..2^<n> ("0..64") unlike other funct<n> fields with 0..2^<n>-1
+	(e.g. funct4 with "0..15").
+
+	gas/ChangeLog:
+
+		* config/tc-riscv.c (riscv_ip): Fix inconsistent error message.
+
+2022-06-22  Marcus Nilsson  <brainbomb@gmail.com>
+
+	readelf: replace xmalloc with malloc in slurp_relr_relocs
+	Using xmalloc makes the null check redundant since failing allocation
+	will exit the program. Instead use malloc and let the error be
+	conveyed up the call chain.
+
+2022-06-22  Alan Modra  <amodra@gmail.com>
+
+	PowerPC64: stub debug dump
+	powerpc64le-linux-ld is failing the assertion in ppc_build_one_stub,
+	again apparently, which means a stub will overwrite the tail of a
+	previous stub.  The difficulty with debugging these issues is that
+	it's not a problem with the stub that triggers the assertion, but the
+	previous stub in that section.  This patch keeps track of the last
+	stub and adds a debug dump.  Hopefully that will help.
+
+		* elf64-ppc.c (enum _ppc64_sec_type): Add sec_stub.
+		(struct _ppc64_elf_section_data): Add u.last_ent.
+		(dump_previous_stub): New function.
+		(ppc_build_one_stub): Keep track of previous stub, and dump it
+		when finding an overlapping stub.
+
+2022-06-22  Alan Modra  <amodra@gmail.com>
+
+	PR29270, DW_FORM_udata signed output
+		PR 29270
+		* dwarf.c (read_and_display_attr_value): Output DW_FORM_udata
+		as unsigned.
+
+2022-06-22  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-21  Nick Alcock  <nick.alcock@oracle.com>
+
+	ld: regenerate configure after recent misgeneration
+	Things work again after this.
+
+	ld/ChangeLog:
+
+		* configure: Regenerate.
+
+2022-06-21  Nick Alcock  <nick.alcock@oracle.com>
+
+	libctf: tests: prune warnings from compiler output
+	We were failing to call prune_warnings appropriately, leading to
+	false-positive test failures on some platforms (observed on
+	sparclinux).
+
+	libctf/ChangeLog:
+
+		* testsuite/lib/ctf-lib.exp: Prune warnings from compiler and
+		linker output.
+		* testsuite/libctf-regression/libctf-repeat-cu.exp: Likewise,
+		and ar output too.
+
+2022-06-21  Nick Alcock  <nick.alcock@oracle.com>
+
+	libctf: avoid mingw warning
+	A missing paren led to an intended cast to avoid dependence on the size
+	of size_t in one argument of ctf_err_warn applying to the wrong type by
+	mistake.
+
+	libctf/ChangeLog:
+
+		* ctf-serialize.c (ctf_write_mem): Fix cast.
+
+2022-06-21  Nick Alcock  <nick.alcock@oracle.com>
+
+	libctf: fix linking together multiple objects derived from the same source
+	Right now, if you compile the same .c input repeatedly with CTF enabled
+	and different compilation flags, then arrange to link all of these
+	together, then things misbehave in various ways.  libctf may conflate
+	either inputs (if the .o files have the same name, say if they are
+	stored in different .a archives), or per-CU outputs when conflicting
+	types are found: the latter can lead to entirely spurious errors when
+	it tries to produce multiple per-CU outputs with the same name
+	(discarding all but the last, but then looking for types in the earlier
+	ones which have just been thrown away).
+
+	Fixing this is multi-pronged.  Both inputs and outputs need to be
+	differentiated in the hashtables libctf keeps them in: inputs with the
+	same cuname and filename need to be considered distinct as long as they
+	have different associated CTF dicts, and per-CU outputs need to be
+	considered distinct as long as they have different associated input
+	dicts.  Right now there is nothing tying the two together other than the
+	CU name: fix this by introducing a new field in the ctf_dict_t named
+	ctf_link_in_out, which (for input dicts) points to the associated per-CU
+	output dict (if any), and for output dicts points to the associated
+	input dict.  At creation time the name used is completely arbitrary:
+	it's only important that it be distinct if CTF dicts are distinct.  So,
+	when a clash is found, adjust the CU name by sticking the number of
+	elements in the input on the end.  At output time, the CU name will
+	appear in the linked object, so it matters a little more that it look
+	slightly less ugly: in conflicting cases, append an incrementing
+	integer, starting at 0.
+
+	This naming scheme is not very helpful, but it's hard to see what else
+	we can do.  The input .o name may be the same.  The input .a name is not
+	even visible to ctf_link, and even *that* might be the same, because
+	.a's can contain many members with the same name, all of which
+	participate in the link.  All we really know is that the two have
+	distinct dictionaries with distinct types in them, and at least this way
+	they are all represented, any any symbols, variables etc referring to
+	those types are accurately stored.
+
+	(As a side-effect this also fixes a use-after-free and double-free when
+	errors are found during variable or symbol emission.)
+
+	Use the opportunity to prevent a couple of sources of problems, to wit
+	changing the active CU mappings when a link has already been done
+	(no effect on ld, which doesn't use CU mappings at all), and causing
+	multiple consecutive ctf_link's to have the same net effect as just
+	doing the last one (no effect on ld, which only ever does one
+	ctf_link) rather than having the links be a sort of half-incremental
+	not-really-intended mess.
+
+	libctf/ChangeLog:
+
+		PR libctf/29242
+		* ctf-impl.h (struct ctf_dict) [ctf_link_in_out]: New.
+		* ctf-dedup.c (ctf_dedup_emit_type): Set it.
+		* ctf-link.c (ctf_link_add_ctf_internal): Set the input
+		CU name uniquely when clashes are found.
+		(ctf_link_add): Document what repeated additions do.
+		(ctf_new_per_cu_name): New, come up with a consistent
+		name for a new per-CU dict.
+		(ctf_link_deduplicating): Use it.
+		(ctf_create_per_cu): Use it, and ctf_link_in_out, and set
+		ctf_link_in_out properly.  Don't overwrite per-CU dicts with
+		per-CU dicts relating to different inputs.
+		(ctf_link_add_cu_mapping): Prevent per-CU mappings being set up
+		if we already have per-CU outputs.
+		(ctf_link_one_variable): Adjust ctf_link_per_cu call.
+		(ctf_link_deduplicating_one_symtypetab): Likewise.
+		(ctf_link_empty_outputs): New, delete all the ctf_link_outputs
+		and blank out ctf_link_in_out on the corresponding inputs.
+		(ctf_link): Clarify the effect of multiple ctf_link calls.
+		Empty ctf_link_outputs if it already exists rather than
+		having the old output leak into the new link.  Fix a variable
+		name.
+		* testsuite/config/default.exp (AR): Add.
+		(OBJDUMP): Likewise.
+		* testsuite/libctf-regression/libctf-repeat-cu.exp: New test.
+		* testsuite/libctf-regression/libctf-repeat-cu*: Main program,
+		library, and expected results for the test.
+
+2022-06-21  Kevin Buettner  <kevinb@redhat.com>
+
+	Document how GDB searches for files when using -s, -e, and -se options
+	GDB's documentation of the 'file' command says:
+
+	    If you do not specify a directory and the file is not found in the
+	    GDB working directory, GDB uses the environment variable PATH as a
+	    list of directories to search, just as the shell does when looking
+	    for a program to run.
+
+	The same is true for files specified via commandline options -s, -e,
+	and -se.
+
+	This commit adds a cross reference to the file command for these options.
+
+2022-06-21  Nick Clifton  <nickc@redhat.com>
+
+	Binutils support for dwarf-5 (location and range lists related)
+		* dwarf.h (struct debug_info): Add rnglists_base field.
+		* dwarf.c (read_and_display_attr_value): Read attribute DW_AT_rnglists_base.
+		(display_debug_rnglists_list): While handling DW_RLE_base_addressx,
+	  	DW_RLE_startx_endx, DW_RLE_startx_length items, pass the proper parameter
+		value to fetch_indexed_addr(), i.e. fetch the proper entry in .debug_addr section.
+		(display_debug_ranges): Add rnglists_base to the .debug_rnglists base address.
+		(load_separate_debug_files): Load .debug_addr section, if exists.
+
+	Default to disabling the linker warnings about execstack and RWX segments if the target is the HPPA architecture.
+		PR 29263
+		* configure.ac (ac_default_ld_warn_execstack): Default to 'no' for
+		HPPA targets.
+		(ac_default_ld_warn_rwx_segments): Likewise.
+		* configure: Regenerate.
+		* testsuite/ld-elf/elf.exp: Add the --warn-execstack command line
+		option to the command line when running execstack tests for the
+		HPPA target.
+
+2022-06-21  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-20  Tom Tromey  <tromey@adacore.com>
+
+	Move finish_print out of value_print_options
+	'finish_print' does not really belong in value_print_options -- this
+	is consulted only when deciding whether or not to print a value, and
+	never during the course of printing.  This patch removes it from the
+	structure and makes it a static global in infcmd.c instead.
+
+	Tested on x86-64 Fedora 34.
+
+2022-06-20  Alan Modra  <amodra@gmail.com>
+
+	PR29262, memory leak in pr_function_type
+		PR 29262
+		* prdbg.c (pr_function_type): Free "s" on failure path.
+
+	PR29261, memory leak in parse_stab_struct_fields
+		PR 29261
+		* stabs.c (parse_stab_struct_fields): Free "fields" on failure path.
+
+2022-06-20  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-19  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-18  Tom Tromey  <tom@tromey.com>
+
+	Fix assertion failure in copy_type
+	PR exp/20630 points out a simple way to cause an assertion failure in
+	copy_type -- but this was found in the wild a few times as well.
+
+	copy_type only works for objfile-owned types, but there isn't a deep
+	reason for this.  This patch fixes the bug by updating copy_type to
+	work for any sort of type.
+
+	Better would perhaps be to finally implement type GC, but I still
+	haven't attempted this.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20630
+
+2022-06-18  Tomoaki Kawada  <kawada@kmckk.co.jp>
+
+	Fix the sorting algorithm for reloc entries
+	The optimized insertion sort algorithm in `elf_link_adjust_relocs`
+	incorrectly assembled "runs" from unsorted entries and inserted them to an
+	already-sorted prefix, breaking the loop invariants of insertion sort.
+	This commit updates the run assembly loop to break upon encountering a
+	non-monotonic change in the sort key.
+
+		PR 29259
+	bfd/
+		* elflink.c (elf_link_adjust_relocs): Ensure run being inserted
+		is sorted.
+	ld/
+		* testsuite/ld-elf/pr29259.d,
+		* testsuite/ld-elf/pr29259.s,
+		* testsuite/ld-elf/pr29259.t: New test.
+
+2022-06-18  Enze Li  <enze.li@hotmail.com>
+
+	gdb/python: Export nibbles to python layer
+	This patch makes it possible to allow Value.format_string() to return
+	nibbles output.
+
+	When we set the parameter of nibbles to True, we can achieve the
+	displaying binary values in groups of every four bits.
+
+	Here's an example:
+	  (gdb) py print (gdb.Value (1230).format_string (format='t', nibbles=True))
+	  0100 1100 1110
+	  (gdb)
+
+	Note that the parameter nibbles is only useful if format='t' is also used.
+
+	This patch also includes update to the relevant testcase and
+	documentation.
+
+	Tested on x86_64 openSUSE Tumbleweed.
+
+2022-06-18  Enze Li  <enze.li@hotmail.com>
+
+	gdb/doc: Documentation for the new print command
+	Document the new command "print nibbles" and add a NEWS entry.
+
+2022-06-18  Enze Li  <enze.li@hotmail.com>
+
+	gdb: Add new 'print nibbles' feature
+	Make an introduction of a new print setting that can be set by 'set
+	print nibbles [on|off]'.  The default value if OFF, which can be changed
+	by user manually.  Of course, 'show print nibbles' is also included in
+	the patch.
+
+	The new feature displays binary values by group, with four bits per
+	group.  The motivation for this work is to enhance the readability of
+	binary values.
+
+	Here's a GDB session before this patch is applied.
+	  (gdb) print var_a
+	  $1 = 1230
+	  (gdb) print/t var_a
+	  $2 = 10011001110
+
+	With this patch applied, we can use the new print setting to display the
+	new form of the binary values.
+	  (gdb) print var_a
+	  $1 = 1230
+	  (gdb) print/t var_a
+	  $2 = 10011001110
+	  (gdb) set print nibbles on
+	  (gdb) print/t var_a
+	  $3 = 0100 1100 1110
+
+	Tested on x86_64 openSUSE Tumbleweed.
+
+2022-06-18  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-17  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: NEWS: Move LoongArch gdbserver to the correct section
+	commit e5ab6af52d38 ("gdbserver: Add LoongArch/Linux support")
+	was merged into the master since GDB 12, so we should put the
+	news in the "Changes since GDB 12" section.
+
+	Thanks Tom Tromey for your correction [1], sorry for that.
+
+	[1] https://sourceware.org/pipermail/gdb-patches/2022-June/190122.html
+
+2022-06-17  Alan Modra  <amodra@gmail.com>
+
+	PR29256, memory leak in obj_elf_section_name
+	When handling section names in quotes obj_elf_section_name calls
+	demand_copy_C_string, which puts the name on the gas notes obstack.
+	Such strings aren't usually freed, since obstack_free frees all more
+	recently allocated objects as well as its arg.  When handling
+	non-quoted names, obj_elf_section_name mallocs the name.  Due to the
+	mix of allocation strategies it isn't possible for callers to free
+	names, if that was desirable.  Partially fix this by always creating
+	names on the obstack, which is more efficient anyway.  (You still
+	can't obstack_free on error paths due to the xtensa
+	tc_canonicalize_section_name.)  Also remove a couple of cases where
+	the name is dup'd for no good reason as far as I know.
+
+		PR 29256
+		* config/obj-elf.c (obj_elf_section_name): Create name on notes
+		obstack.
+		(obj_elf_attach_to_group): Don't strdup group name.
+		(obj_elf_section): Likewise.
+		(obj_elf_vendor_attribute): Use xmemdup0 rather than xstrndup.
+
+2022-06-17  Alan Modra  <amodra@gmail.com>
+
+	PR29255, memory leak in make_tempdir
+		PR 29255
+		* bucomm.c (make_tempdir, make_tempname): Free template on all
+		failure paths.
+
+	PR29254, memory leak in stab_demangle_v3_arg
+		PR 29254
+		* stabs.c (stab_demangle_v3_arg): Free dt on failure path.
+
+2022-06-17  Pedro Alves  <pedro@palves.net>
+
+	Fix GDB build with GCC 4.8 & 4.9
+	With gcc 4.8/4.9, we run into this build failure (and other similar
+	ones):
+
+	  /home/palves/gdb/binutils-gdb/src/gdb/location.h:224:59: error: could not convert ‘{0, LINE_OFFSET_UNKNOWN}’ from ‘<brace-enclosed initializer list>’ to ‘line_offset’
+	     struct line_offset line_offset = {0, LINE_OFFSET_UNKNOWN};
+								     ^
+
+	The issue is that at around the GCC 4.8/4.9 era, a default member
+	initializer prevented the struct from being an aggregate, so you
+	cannot use aggregate initialization on them.  That rule changed after
+	GCC 4.9 and GCC 5 & later uses new rules.
+
+	Fix this by not using aggregate initialization for struct line_offset.
+	The default member initization already leaves line_offset as {0,
+	LINE_OFFSET_UNKNOWN}, so initialization to those values can just go
+	away.  The remaining cases are of the form {0, LINE_OFFSET_NONE}, and
+	those cases can be better rewritten to delay setting the sign field
+	until we know we have a valid offset.
+
+	Change-Id: I0506ea4a83c5fa2f15e159569db68b3b0a7509b4
+
+2022-06-17  Pedro Alves  <pedro@palves.net>
+
+	Convert set_location_spec_string to a method
+	This converts set_location_spec_string to a method of location_spec,
+	and makes the location_spec::as_string field protected, renaming it to
+	m_as_string along the way.
+
+	Change-Id: Iccfb1654e9fa7808d0512df89e775f9eacaeb9e0
+
+2022-06-17  Pedro Alves  <pedro@palves.net>
+
+	Convert location_spec_to_string to a method
+	This converts location_spec_to_string to a method of location_spec,
+	simplifying the code using it, as it no longer has to use
+	std::unique_ptr::get().
+
+	Change-Id: I621bdad8ea084470a2724163f614578caf8f2dd5
+
+2022-06-17  Pedro Alves  <pedro@palves.net>
+
+	Convert location_spec_type to a method
+	This converts location_spec_type to location_spec::type().
+
+	Change-Id: Iff4cbfafb1cf3d22adfa142ff939b4a148e52273
+
+2022-06-17  Pedro Alves  <pedro@palves.net>
+
+	Convert location_spec_empty_p to a method
+	This converts location_spec_empty_p to a method of location_spec,
+	simplifying users, as they no longer have to use
+	std::unique_ptr::get().
+
+	Change-Id: I83381a729896f12e1c5a1b4d6d4c2eb1eb6582ff
+
+2022-06-17  Pedro Alves  <pedro@palves.net>
+
+	Eliminate copy_location_spec
+	copy_location_spec is just a wrapper around location_spec::clone(), so
+	remove it and call clone() directly.  This simplifies users, as they
+	no longer have to use std::unique_ptr::get().
+
+	Change-Id: I8ce8658589460b98888283b306b315a5b8f73976
+
+2022-06-17  Pedro Alves  <pedro@palves.net>
+
+	Eliminate the two-level data structures behind location_specs
+	Currently, there's the location_spec hierarchy, and then some
+	location_spec subclasses have their own struct type holding all their
+	data fields.
+
+	I.e., there is this:
+
+	 location_spec
+	   explicit_location_spec
+	   linespec_location_spec
+	   address_location_spec
+	   probe_location_spec
+
+	and then these separate types:
+
+	  explicit_location
+	  linespec_location
+
+	where:
+
+	  explicit_location_spec
+	     has-a explicit_location
+	  linespec_location_spec
+	     has-a linespec_location
+
+	This patch eliminates explicit_location and linespec_location,
+	inlining their members in the corresponding location_spec type.
+
+	The location_spec subclasses were the ones currently defined in
+	location.c, so they are moved to the header.  Since the definitions of
+	the classes are now visible, we no longer need location_spec_deleter.
+
+	Some constructors that are used for cloning location_specs, like:
+
+	  explicit explicit_location_spec (const struct explicit_location *loc)
+
+	... were converted to proper copy ctors.
+
+	In the process, initialize_explicit_location is eliminated, and some
+	functions that returned the "data type behind a locspec", like
+	get_linespec_location are converted to downcast functions, like
+	as_linespec_location_spec.
+
+	Change-Id: Ia31ccef9382b25a52b00fa878c8df9b8cf2a6c5a
+
+2022-06-17  Pedro Alves  <pedro@palves.net>
+
+	event_location -> location_spec
+	Currently, GDB internally uses the term "location" for both the
+	location specification the user input (linespec, explicit location, or
+	an address location), and for actual resolved locations, like the
+	breakpoint locations, or the result of decoding a location spec to
+	SaLs.  This is expecially confusing in the breakpoints module, as
+	struct breakpoint has these two fields:
+
+	  breakpoint::location;
+	  breakpoint::loc;
+
+	"location" is the location spec, and "loc" is the resolved locations.
+
+	And then, we have a method called "locations()", which returns the
+	resolved locations as range...
+
+	The location spec type is presently called event_location:
+
+	  /* Location we used to set the breakpoint.  */
+	  event_location_up location;
+
+	and it is described like this:
+
+	  /* The base class for all an event locations used to set a stop event
+	     in the inferior.  */
+
+	  struct event_location
+	  {
+
+	and even that is incorrect...  Location specs are used for finding
+	actual locations in the program in scenarios that have nothing to do
+	with stop events.  E.g., "list" works with location specs.
+
+	To clean all this confusion up, this patch renames "event_location" to
+	"location_spec" throughout, and then all the variables that hold a
+	location spec, they are renamed to include "spec" in their name, like
+	e.g., "location" -> "locspec".  Similarly, functions that work with
+	location specs, and currently have just "location" in their name are
+	renamed to include "spec" in their name too.
+
+	Change-Id: I5814124798aa2b2003e79496e78f95c74e5eddca
+
+2022-06-17  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+	gprofng: fix build with -Werror=format-truncation
+	gprofng/ChangeLog
+	2022-06-16  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+		* configure.ac: Remove -Wno-format-truncation.
+		* src/Makefile.am: Likewise.
+		* configure: Rebuild.
+		* src/Makefile.in: Rebuild.
+		* common/hwctable.c: Fix -Werror=format-truncation errors.
+		* src/ipc.cc: Likewise.
+		* src/parse.cc: Likewise.
+
+2022-06-17  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-16  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix have_mpx test
+	When testing on openSUSE Leap 15.4 I ran into this FAIL:
+	...
+	FAIL: gdb.arch/i386-mpx-map.exp: NULL address of the pointer
+	...
+	and likewise for all the other mpx tests.
+
+	The problem is that have_mpx is supposed to return 0, but it doesn't because
+	it tries to match this output:
+	...
+	builtin_spawn -ignore SIGHUP temp/20294/have_mpx-2-20294.x^M
+	No MPX support^M
+	No MPX support^M
+	...
+	using:
+	...
+	                   && ![string equal $output "No MPX support\r\n"]]
+	...
+
+	Fix this by matching using a regexp instead.
+
+	Tested on x86_64-linux.
+
+2022-06-16  Alan Modra  <amodra@gmail.com>
+
+	use of uninitialised value in input_file_open
+	Triggered by a file containing just "#N" or "#A".  fgets when hitting
+	EOF before reading anything returns NULL and does not write to buf.
+	strchr (buf, '\n') then is reading from uninitialised memory.
+
+		* input-file.c (input_file_open): Don't assume buf contains
+		zero string terminator when fgets returns NULL.
+
+2022-06-16  Alan Modra  <amodra@gmail.com>
+
+	Always free matching vector from bfd_check_format_matches
+	At least one place calling list_matching_formats failed to free the
+	"matching" vector from bfd_check_format_matches afterwards.  Fix that
+	by calling free inside list_matching_formats.
+
+	binutils/
+		* bucomm.c (list_matching_formats): Free arg.
+		* addr2line.c (process_file): Adjust to suit.
+		* ar.c (open_inarch, ranlib_touch): Likewise.
+		* coffdump.c (main): Likewise.
+		* nm.c (display_archive, display_file): Likewise.
+		* objcopy.c (copy_file): Likewise.
+		* objdump.c (display_object_bfd): Likewise.
+		* size.c (display_bfd): Likewise.
+		* srconv.c (main): Likewise.
+	ld/
+		* ldlang.c (load_symbols): Free "matching".
+
+2022-06-16  Alan Modra  <amodra@gmail.com>
+
+	Revert "Revert "Fix fbsd core matching""
+	This reverts commit 476288fa2bddecf0f0e13dee826a076309bf01fe.
+
+2022-06-16  Alan Modra  <amodra@gmail.com>
+
+	Restore readelf -wF
+	Commit 94585d6d4495 resulted in readelf -wF failing with
+	Unrecognized debug letter option 'F'
+
+	binutils/
+		* dwarf.c (debug_dump_long_opts): Add letter.
+		(debug_option_table): New, replacing..
+		(opts_table, letter_table): ..these.
+		(dwarf_select_sections_by_names): Adjust to suit.  Set
+		do_debug_frames outside of loop.
+		(dwarf_select_sections_by_letters): Similarly.
+	gas/
+		* testsuite/gas/i386/ehinterp.d: Use readelf -wF.
+
+2022-06-16  Alan Modra  <amodra@gmail.com>
+
+	PR29250, readelf erases CIE initial register state
+		PR 29250
+	binutils/
+		* dwarf.c (display_debug_frames): Set col_type[reg] on sizing
+		pass over FDE to cie->col_type[reg] if CIE specifies reg.
+		Handle DW_CFA_restore and DW_CFA_restore_extended on second
+		pass using the same logic.  Remove unnecessary casts.  Don't
+		call frame_need_space on second pass over FDE.
+	gas/
+		* testsuite/gas/i386/ehinterp.d,
+		* testsuite/gas/i386/ehinterp.s: New test.
+		* testsuite/gas/i386/i386.exp: Run it.
+
+2022-06-16  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-15  Sergei Trofimovich  <siarheit@google.com>
+
+	sim: fix BFD_VMA format arguments on 32-bit hosts [PR gdb/29184]
+	Noticed format mismatch when attempted to build gdb on i686-linux-gnu
+	in --enable-64-bit-bfd mode:
+
+	    sim/../../sim/cris/sim-if.c:576:28:
+	        error: format '%lx' expects argument of type 'long unsigned int',
+	        but argument 4 has type 'bfd_size_type' {aka 'long long unsigned int'} [-Werror=format=]
+	      576 |       sim_do_commandf (sd, "memory region 0x%" BFD_VMA_FMT "x,0x%lx",
+	          |                            ^~~~~~~~~~~~~~~~~~~
+	      577 |          interp_load_addr, interpsiz);
+	          |                            ~~~~~~~~~
+	          |                            |
+	          |                            bfd_size_type {aka long long unsigned int}
+
+	While at it fixed format string for time-related types.
+
+2022-06-15  Tom Tromey  <tromey@adacore.com>
+
+	Check for listeners in emit_exiting_event
+	I noticed that emit_exiting_event does not check whether there are any
+	listeners before creating the event object.  All other event emitters
+	do this, so this patch updates this one as well.
+
+2022-06-15  Tom Tromey  <tom@tromey.com>
+
+	Add to documentation of Python 'dont_repeat' method
+	PR python/28533 points out that the Python 'dont_repeat' documentation
+	is a bit ambiguous about when the method ought to be called.  This
+	patch spells it out.
+
+2022-06-15  Yvan Roux  <yvan.roux@foss.st.com>
+
+	gdb/arm: Make sp alias for one of the other stack pointers
+	For Cortex-M targets, SP register is never detached from msp or
+	psp, it always has the same value as one of them.  Let GDB treat
+	ARM_SP_REGNUM as an alias similar to what is done in hardware.
+
+2022-06-15  Yvan Roux  <yvan.roux@foss.st.com>
+
+	gdb/arm: Track msp and psp
+	For Arm Cortex-M33 with security extensions, there are 4 different
+	stack pointers (msp_s, msp_ns, psp_s, psp_ns).  To be compatible
+	with earlier Cortex-M derivates, the msp and psp registers are
+	aliases for one of the 4 real stack pointer registers.
+
+	These are the combinations that exist:
+	sp -> msp -> msp_s
+	sp -> msp -> msp_ns
+	sp -> psp -> psp_s
+	sp -> psp -> psp_ns
+
+	This means that when the GDB client is to show the value of "msp",
+	the value should always be equal to either "msp_s" or "msp_ns".
+	Same goes for "psp".
+
+	To add a bit more context; GDB does not really use the register msp
+	(or psp) internally, but they are part of the set of registers which
+	are provided by the target.xml file.  As a result, they will be part
+	of the set of registers printed by the "info r" command.
+
+	Without this particular patch, GDB will hit the assert in the bottom
+	of arm_cache_get_sp_register function.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29121
+
+2022-06-15  Yvan Roux  <yvan.roux@foss.st.com>
+
+	gdb/arm: Fetch initial sp value prior to compare
+	For Arm Cortex-M33 with security extensions, there are 4 different
+	stack pointers (msp_s, msp_ns, psp_s, psp_ns).  In order to
+	identify the active one, compare the values of the different
+	stacks. The value of the initial sp register needs to be fetched to
+	perform this comparison.
+
+2022-06-15  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: unify two dis_asm_read_memory functions in disasm.c
+	After the recent restructuring of the disassembler code, GDB has ended
+	up with two identical class static functions, both called
+	dis_asm_read_memory, with identical implementations.
+
+	My first thought was to move these out of their respective classes,
+	and just make them global functions, then I'd only need a single
+	copy.
+
+	And maybe that's the right way to go.  But I disliked that by doing
+	that I loose the encapsulation of the method with the corresponding
+	disassembler class.
+
+	So, instead, I placed the static method into its own class, and had
+	both the gdb_non_printing_memory_disassembler and gdb_disassembler
+	classes inherit from this new class as an additional base-class.
+
+	In terms of code generated, I don't think there's any significant
+	difference with this approach, but I think this better reflects how
+	the function is closely tied to the disassembler.
+
+	There should be no user visible changes after this commit.
+
+2022-06-15  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: refactor the non-printing disassemblers
+	This commit started from an observation I made while working on some
+	other disassembler patches, that is, that the function
+	gdb_buffered_insn_length, is broken ... sort of.
+
+	I noticed that the gdb_buffered_insn_length function doesn't set up
+	the application data field if the disassemble_info structure.
+
+	Further, I noticed that some architectures, for example, ARM, require
+	that the application_data field be set, see gdb_print_insn_arm in
+	arm-tdep.c.
+
+	And so, if we ever use gdb_buffered_insn_length for ARM, then GDB will
+	likely crash.  Which is why I said only "sort of" broken.  Right now
+	we don't use gdb_buffered_insn_length with ARM, so maybe it isn't
+	broken yet?
+
+	Anyway to prove to myself that there was a problem here I extended the
+	disassembler self tests in disasm-selftests.c to include a test of
+	gdb_buffered_insn_length.  As I run the test for all architectures, I
+	do indeed see GDB crash for ARM.
+
+	To fix this we need gdb_buffered_insn_length to create a disassembler
+	that inherits from gdb_disassemble_info, but we also need this new
+	disassembler to not print anything.
+
+	And so, I introduce a new gdb_non_printing_disassembler class, this is
+	a disassembler that doesn't print anything to the output stream.
+
+	I then observed that both ARC and S12Z also create non-printing
+	disassemblers, but these are slightly different.  While the
+	disassembler in gdb_non_printing_disassembler reads the instruction
+	from a buffer, the ARC and S12Z disassemblers read from target memory
+	using target_read_code.
+
+	And so, I further split gdb_non_printing_disassembler into two
+	sub-classes, gdb_non_printing_memory_disassembler and
+	gdb_non_printing_buffer_disassembler.
+
+	The new selftests now pass, but otherwise, there should be no user
+	visible changes after this commit.
+
+2022-06-15  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb/python: implement the print_insn extension language hook
+	This commit extends the Python API to include disassembler support.
+
+	The motivation for this commit was to provide an API by which the user
+	could write Python scripts that would augment the output of the
+	disassembler.
+
+	To achieve this I have followed the model of the existing libopcodes
+	disassembler, that is, instructions are disassembled one by one.  This
+	does restrict the type of things that it is possible to do from a
+	Python script, i.e. all additional output has to fit on a single line,
+	but this was all I needed, and creating something more complex would,
+	I think, require greater changes to how GDB's internal disassembler
+	operates.
+
+	The disassembler API is contained in the new gdb.disassembler module,
+	which defines the following classes:
+
+	  DisassembleInfo
+
+	      Similar to libopcodes disassemble_info structure, has read-only
+	  properties: address, architecture, and progspace.  And has methods:
+	  __init__, read_memory, and is_valid.
+
+	      Each time GDB wants an instruction disassembled, an instance of
+	  this class is passed to a user written disassembler function, by
+	  reading the properties, and calling the methods (and other support
+	  methods in the gdb.disassembler module) the user can perform and
+	  return the disassembly.
+
+	  Disassembler
+
+	      This is a base-class which user written disassemblers should
+	  inherit from.  This base class provides base implementations of
+	  __init__ and __call__ which the user written disassembler should
+	  override.
+
+	  DisassemblerResult
+
+	      This class can be used to hold the result of a call to the
+	  disassembler, it's really just a wrapper around a string (the text
+	  of the disassembled instruction) and a length (in bytes).  The user
+	  can return an instance of this class from Disassembler.__call__ to
+	  represent the newly disassembled instruction.
+
+	The gdb.disassembler module also provides the following functions:
+
+	  register_disassembler
+
+	      This function registers an instance of a Disassembler sub-class
+	  as a disassembler, either for one specific architecture, or, as a
+	  global disassembler for all architectures.
+
+	  builtin_disassemble
+
+	      This provides access to GDB's builtin disassembler.  A common
+	  use case that I see is augmenting the existing disassembler output.
+	  The user code can call this function to have GDB disassemble the
+	  instruction in the normal way.  The user gets back a
+	  DisassemblerResult object, which they can then read in order to
+	  augment the disassembler output in any way they wish.
+
+	      This function also provides a mechanism to intercept the
+	  disassemblers reads of memory, thus the user can adjust what GDB
+	  sees when it is disassembling.
+
+	The included documentation provides a more detailed description of the
+	API.
+
+	There is also a new CLI command added:
+
+	  maint info python-disassemblers
+
+	This command is defined in the Python gdb.disassemblers module, and
+	can be used to list the currently registered Python disassemblers.
+
+2022-06-15  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: add extension language print_insn hook
+	This commit is setup for the next commit.
+
+	In the next commit I will add a Python API to intercept the print_insn
+	calls within GDB, each print_insn call is responsible for
+	disassembling, and printing one instruction.  After the next commit it
+	will be possible for a user to write Python code that either wraps
+	around the existing disassembler, or even, in extreme situations,
+	entirely replaces the existing disassembler.
+
+	This commit does not add any new Python API.
+
+	What this commit does is put the extension language framework in place
+	for a print_insn hook.  There's a new callback added to 'struct
+	extension_language_ops', which is then filled in with nullptr for Python
+	and Guile.
+
+	Finally, in the disassembler, the code is restructured so that the new
+	extension language function ext_lang_print_insn is called before we
+	delegate to gdbarch_print_insn.
+
+	After this, the next commit can focus entirely on providing a Python
+	implementation of the new print_insn callback.
+
+	There should be no user visible change after this commit.
+
+2022-06-15  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: add new base class to gdb_disassembler
+	The motivation for this change is an upcoming Python disassembler API
+	that I would like to add.  As part of that change I need to create a
+	new disassembler like class that contains a disassemble_info and a
+	gdbarch.  The management of these two objects is identical to how we
+	manage these objects within gdb_disassembler, so it might be tempting
+	for my new class to inherit from gdb_disassembler.
+
+	The problem however, is that gdb_disassembler has a tight connection
+	between its constructor, and its print_insn method.  In the
+	constructor the ui_file* that is passed in is replaced with a member
+	variable string_file*, and then in print_insn, the contents of the
+	member variable string_file are printed to the original ui_file*.
+
+	What this means is that the gdb_disassembler class has a tight
+	coupling between its constructor and print_insn; the class just isn't
+	intended to be used in a situation where print_insn is not going to be
+	called, which is how my (upcoming) sub-class would need to operate.
+
+	My solution then, is to separate out the management of the
+	disassemble_info and gdbarch into a new gdb_disassemble_info class,
+	and make this class a parent of gdb_disassembler.
+
+	In arm-tdep.c and mips-tdep.c, where we used to cast the
+	disassemble_info->application_data to a gdb_disassembler, we can now
+	cast to a gdb_disassemble_info as we only need to access the gdbarch
+	information.
+
+	Now, my new Python disassembler sub-class will still want to print
+	things to an output stream, and so we will want access to the
+	dis_asm_fprintf functionality for printing.
+
+	However, rather than move this printing code into the
+	gdb_disassemble_info base class, I have added yet another level of
+	hierarchy, a gdb_printing_disassembler, thus the class structure is
+	now:
+
+	  struct gdb_disassemble_info {};
+	  struct gdb_printing_disassembler : public gdb_disassemble_info {};
+	  struct gdb_disassembler : public gdb_printing_disassembler {};
+
+	In a later commit my new Python disassembler will inherit from
+	gdb_printing_disassembler.
+
+	The reason for adding the additional layer to the class hierarchy is
+	that in yet another commit I intend to rewrite the function
+	gdb_buffered_insn_length, and to do this I will be creating yet more
+	disassembler like classes, however, these will not print anything,
+	thus I will add a gdb_non_printing_disassembler class that also
+	inherits from gdb_disassemble_info.  Knowing that that change is
+	coming, I've gone with the above class hierarchy now.
+
+	There should be no user visible changes after this commit.
+
+2022-06-15  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/python: convert gdbpy_err_fetch to use gdbpy_ref
+	Convert the gdbpy_err_fetch class to make use of gdbpy_ref, this
+	removes the need for manual reference count management, and allows the
+	destructor to be removed.
+
+	There should be no functional change after this commit.
+
+	I think this cleanup is worth doing on its own, however, in a later
+	commit I will want to copy instances of gdbpy_err_fetch, and switching
+	to using gdbpy_ref means that I can rely on the default copy
+	constructor, without having to add one that handles the reference
+	counts, so this is good preparation for that upcoming change.
+
+2022-06-15  Jan Beulich  <jbeulich@suse.com>
+
+	x86: drop print_operand_value()'s "hex" parameter
+	For quite some  time all callers have been passing 1 / true. While there
+	fold the final oappend_with_style() calls.
+
+2022-06-15  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/build] Fix build for gcc < 11
+	When building trunk on openSUSE Leap 15.3 with system gcc 7.5.0, I run into:
+	...
+	In file included from ../bfd/bfd.h:46:0,
+	                 from gdb/defs.h:37,
+	                 from gdb/debuginfod-support.c:19:
+	gdb/debuginfod-support.c: In function ‘bool debuginfod_is_enabled()’:
+	gdb/../include/diagnostics.h:42:3: error: unknown option after \
+	  ‘#pragma GCC diagnostic’ kind [-Werror=pragmas]
+	   _Pragma (DIAGNOSTIC_STRINGIFY (GCC diagnostic ignored option))
+	   ^
+	gdb/../include/diagnostics.h:80:3: note: in expansion of macro \
+	  ‘DIAGNOSTIC_IGNORE’
+	   DIAGNOSTIC_IGNORE ("-Wstringop-overread")
+	   ^~~~~~~~~~~~~~~~~
+	gdb/debuginfod-support.c:201:4: note: in expansion of macro \
+	  ‘DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD’
+	    DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD
+	    ^
+	...
+
+	The problem is that the warning -Wstringop-overread has been introduced for
+	gcc 11, and we can only tell gcc to ignore if it knows about it.
+
+	Fix this by guarding the DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD definition in
+	diagnostics.c with '#if __GNUC__ >= 11'.
+
+	Tested on x86_64-linux, by completing a build.
+
+2022-06-15  Alan Modra  <amodra@gmail.com>
+
+	PR29230, segv in lookup_symbol_in_variable_table
+	The PR23230 testcase uses indexed strings without specifying
+	SW_AT_str_offsets_base.  In this case we left u.str with garbage (from
+	u.val) which then led to a segfault when attempting to access the
+	string.  Fix that by clearing u.str.  The patch also adds missing
+	sanity checks in the recently committed read_indexed_address and
+	read_indexed_string functions.
+
+		PR 29230
+		* dwarf2.c (read_indexed_address): Return uint64_t.  Sanity check idx.
+		(read_indexed_string): Use uint64_t for str_offset.  Sanity check idx.
+		(read_attribute_value): Clear u.str for indexed string forms when
+		DW_AT_str_offsets_base is not yet read or missing.
+
+2022-06-15  Mark Wielaard  <mark@klomp.org>
+
+	gdb: Always suppress stringop-overread warning in debuginfod-support.c
+	Just like on s390x with g++ 11.2.1 and ppc64le with g++ 11.3.1 g++ 11
+	on hppa produces a spurious warning for stringop-overread in
+	debuginfod_is_enabled for url_view. Just always suppress it on all
+	arches.
+
+	https://sourceware.org/bugzilla/show_bug.cgi?id=29198
+
+	gdb/ChangeLog:
+
+		* debuginfod-support.c (debuginfod_is_enabled): Always use
+		DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD.
+
+2022-06-15  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-14  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+	gprofng docs: provide help for <rate> == <interval>
+	The help message from 'gprofng collect app -h', in
+	the section on <rate> == <interval>, had a dangling
+	reference to a non-existent manpage. Provide basic
+	info, including reasons for caution.
+
+	gprofng docs: mention HTML / PDF in the gprofng README
+	The HTML and PDF formats are described in the gprofng tutorial (info
+	topic "Other Document Formats"). In addition, describe them in the
+	README because: they are important; they are easily searchable; and the
+	README is primarily oriented to the person who is installing gprofng,
+	who may differ from the person who follows a user tutorial.
+
+2022-06-14  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+	gprofng: fix build with -Werror=format-security
+	gprofng/ChangeLog
+	2022-06-13  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+		PR gprofng/28968
+		* src/src/Hist_data.cc (print_row): Make param const.
+		* src/src/Hist_data.h (print_row): Likewise.
+		* src/src/Print.h: Remove unused functions and variables.
+		* src/Print.cc: Fix -Werror=format-security errors.
+		* src/parse.cc: Likewise.
+
+2022-06-14  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Handle unordered dict in gdb.python/py-mi-cmd.exp
+	When running test-case gdb.python/py-mi-cmd.exp on openSUSE Leap 42.3 with
+	python 3.4, I occasionally run into:
+	...
+	Expecting: ^(-pycmd dct[^M
+	]+)?(\^done,result={hello="world",times="42"}[^M
+	]+[(]gdb[)] ^M
+	[ ]*)
+	-pycmd dct^M
+	^done,result={times="42",hello="world"}^M
+	(gdb) ^M
+	FAIL: gdb.python/py-mi-cmd.exp: -pycmd dct (unexpected output)
+	...
+
+	The problem is that the data type used here in py-mi-cmd.py:
+	...
+	        elif argv[0] == "dct":
+	            return {"result": {"hello": "world", "times": 42}}
+	...
+	is a dictionary, and only starting version 3.6 are dictionaries insertion
+	ordered, so using PyDict_Next in serialize_mi_result doesn't guarantee a
+	fixed order.
+
+	Fix this by allowing the alternative order.
+
+	Tested on x86_64-linux.
+
+2022-06-14  Tom Tromey  <tromey@adacore.com>
+
+	Implement lazy FPU initialization for ravenscar
+	Some ravenscar runtimes implement lazy FPU handling.  On these
+	runtimes, the FPU is only initialized when a task tries to use it.
+	Furthermore, the FP registers aren't automatically saved on a task
+	switch -- instead, the save is deferred until the new task tries to
+	use the FPU.  Furthermore, each task's context area has a flag
+	indicating whether the FPU has been initialized for this task.
+
+	This patch teaches GDB to understand this implementation.  When
+	fetching or storing registers, GDB now checks to see whether the live
+	FP registers should be used.  If not, the task's saved FP registers
+	will be used if the task has caused FPU initialization.
+
+	Currently only AArch64 uses this code.  bb-runtimes implements this
+	for ARM as well, but GDB doesn't yet have an arm-ravenscar-thread.c.
+
+2022-06-14  Tom Tromey  <tromey@adacore.com>
+
+	Reimplement ravenscar registers using tables
+	Currently, the ravenscar-thread implementation for each architecture
+	is written by hand.  However, these are actually written by
+	copy-paste.  It seems better to switch to a table-driven approach.
+
+	The previous code also fetched all registers whenever any register was
+	requested.  This is corrected in the new implementation.
+
+2022-06-14  Tom Tromey  <tromey@adacore.com>
+
+	Fix bugs in aarch64-ravenscar-thread.c
+	We found a few bugs in aarch64-ravenscar-thread.c.
+
+	First, some of the register offsets were incorrect.  The "bb-runtimes"
+	file for this runtime had the wrong offsets in comments, which GDB
+	took to be correct.  However, those comments didn't account for
+	alignment.  This patch adjusts the offsets.
+
+	Next, the "FPU Saved field" is not a register -- it is an
+	implementation detail of the runtime.  This is removed.
+
+	Finally, I think the FP registers are actually named V0-V31, and the
+	"Q" names are pseudo-registers.  This patch fixes the comment.
+
+2022-06-14  Tom Tromey  <tromey@adacore.com>
+
+	Allow 'interrupt -a' in all-stop mode
+	PR gdb/17160 points out that "interrupt -a" errors in all-stop mode,
+	but there's no good reason for this.  This patch removes the error.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17160
+
+2022-06-14  Youling Tang  <tangyouling@loongson.cn>
+
+	gdbserver: Add LoongArch/Linux support
+	Implement LoongArch/Linux support, including XML target description
+	handling based on features determined, GPR regset support, and software
+	breakpoint handling.
+
+	In the Linux kernel code of LoongArch, ptrace implements PTRACE_POKEUSR
+	and PTRACE_PEEKUSR in the arch_ptrace function, so srv_linux_usrregs is
+	set to yes.
+
+	With this patch on LoongArch:
+
+	  $ make check-gdb TESTS="gdb.server/server-connect.exp"
+	  [...]
+	  # of expected passes		18
+	  [...]
+
+2022-06-14  Tom de Vries  <tdevries@suse.de>
+
+	Revert "Fix fbsd core matching"
+	This reverts commit a7e29f797cecd5a2f73c27838b09eae1f1b6c657.
+
+	I accidentally pushed this, so revert.
+
+2022-06-14  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix regexp in gdb.ada/mi_var_access.exp
+	With gcc-12 and target board unix/-m32, we run into:
+	...
+	(gdb) ^M
+	Expecting: ^(-var-create A_String_Access \* A_String_Access[^M
+	]+)?(\^done,name="A_String_Access",numchild="1",.*[^M
+	]+[(]gdb[)] ^M
+	[ ]*)
+	-var-create A_String_Access * A_String_Access^M
+	^error,msg="Value out of range."^M
+	(gdb) ^M
+	FAIL: gdb.ada/mi_var_access.exp: Create varobj (unexpected output)
+	...
+
+	What happens is easier to understand if we take things out of the mi context:
+	...
+	$ gdb -q -batch \
+	    outputs/gdb.ada/mi_var_access/mi_access \
+	    -ex "b mi_access.adb:19" \
+	    -ex run \
+	    -ex "p A_String_Access"
+	  ...
+	Breakpoint 1, mi_access () at mi_access.adb:19
+	19         A_String : String (3 .. 5) := "345"; -- STOP
+	$1 = (pck.string_access) <error reading variable: Value out of range.>
+	...
+	while with target board unix we have instead:
+	...
+	$1 = (pck.string_access) 0x431b40 <ada_main.sec_default_sized_stacks>
+	...
+
+	The var-create command samples the value of the variable at a location where
+	the variable is not yet initialized, and with target board unix we
+	accidentally hit a valid address, but with target board unix/-m32 that's not
+	the case.
+
+	Fix the FAIL by accepting the error message.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28464
+
+2022-06-14  Alan Modra  <amodra@gmail.com>
+
+	Fix fbsd core matching
+	On Thu, Jun 09, 2022 at 08:59:37AM -0700, John Baldwin wrote:
+	> On 6/9/22 1:58 AM, Tom de Vries via Gdb-patches wrote:
+	> > Hi,
+	> >
+	> > With an --enable-targets=all build and target board unix/-m32 I run into a
+	> > FAIL in test-case gdb.base/corefile.exp:
+	> > ...
+	> > (gdb) file outputs/gdb.base/corefile/corefile^M
+	> > Reading symbols from outputs/gdb.base/corefile/corefile...^M
+	> > (gdb) core-file outputs/gdb.base/corefile/corefile.core^M
+	> > warning: core file may not match specified executable file.^M
+	> > [New LWP 12011]^M
+	> > Core was generated by `outputs/gdb.base/corefile/co'.^M
+	> > Program terminated with signal SIGABRT, Aborted.^M
+	> > (gdb) FAIL: gdb.base/corefile.exp: core-file warning-free
+	> > ...
+	> >
+	> > The warning is there because of this mismatch between core and exec:
+	> > ...
+	> > (gdb) p core_bfd->xvec
+	> > $3 = (const struct bfd_target *) 0x20112a0 <i386_elf32_fbsd_vec>
+	> > (gdb) p exec_bfd->xvec
+	> > $4 = (const struct bfd_target *) 0x2010b00 <i386_elf32_vec>
+	> > ...
+	> >
+	> > In the exec case, the detected architecture is i386_elf32_vec because this bit
+	> > of code in elfcode.h:elf_object_p():
+	> > ...
+	> >    if (ebd->elf_machine_code != EM_NONE
+	> >        && i_ehdrp->e_ident[EI_OSABI] != ebd->elf_osabi
+	> >        && ebd->elf_osabi != ELFOSABI_NONE)
+	> >      goto got_wrong_format_error;
+	> > ...
+	> > prevents i386_elf32_fbsd from matching.
+	> >
+	> > Fix the core matching by copying that code to elfcore.h:elf_core_file_p().
+	> >
+	> > Tested on x86_64-linux.
+	> >
+	> > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29227
+	> >
+	> > Any comments?
+
+	Looks good.
+
+	> Looking at elfcore.h, it seems to have not gotten changes made to elfcode.h over
+	> time and is a bit rotted.  I suspect that all of changes made in commit 0aabe54e6222
+	> that added these lines in elfcode.h (along with several other changes) need to
+	> be applied to this function in elfcore.h, not just adding these lines.
+
+	Yes, the commit 0aabe54e6222 changes likely should go in too.  I'm a
+	little wary of adding all the sanity checks to elf_core_file_p since
+	that might result in some core files not being recognised at all.  For
+	example, despite the FIXME I'd guess leaving out the EI_VERSION check
+	was deliberate.  The following seems reasonable to me.  Please test.
+
+2022-06-14  Kavitha Natarajan  <kavitha.natarajan@amd.com>
+
+	Debug support for global alias variable
+	Starting with (future) Clang 15 (since
+	https://reviews.llvm.org/D120989), Clang emits the DWARF information
+	of global alias variables as DW_TAG_imported_declaration.  However,
+	GDB does not handle it.  It incorrectly always reads this tag as
+	C++/Fortran imported declaration (type alias, namespace alias and
+	Fortran module).  This commit adds support to handle this tag as an
+	alias variable.
+
+	This change fixes the failures in the gdb.base/symbol-alias.exp
+	testcase with current git Clang.  This testcase is also updated to
+	test nested (recursive) aliases.
+
+2022-06-14  Alan Modra  <amodra@gmail.com>
+
+	BFD_RELOC_MIPS_16
+	MIPS should not be using BFD_RELOC_16 for its R_MIPS_16 relocation,
+	since R_MIPS_16 specifies a 16-bit field in a 32-bit word.
+	BFD_RELOC_16, emitted by generic code to handle fixups on 16-bit data
+	directives, expects fixups to operate on the whole of a 16-bit word.
+
+	This patch corrects the problem by using BFD_RELOC_MIPS_16, a new bfd
+	reloc that is used to generate R_MIPS_16.  BFD_RELOC_16 is handled in
+	md_apply_fix for cases where the fixup can be applied at assembly
+	time.  Like BFD_RELOC_8, BFD_RELOC_16 now has no corresponding object
+	file relocation, and thus .half, .hword, .short and .dc.w must be
+	resolved at assembly time.  BFD_RELOC_MIPS_REL16 is removed by this
+	patch since it isn't used.
+
+		PR 3243
+		PR 26542
+		* reloc.c (BFD_RELOC_MIPS_16): Rename from BFD_RELOC_MIPS_REL16.
+		* elf32-mips.c (mips_reloc_map): Map BFD_RELOC_MIPS_16 to R_MIPS_16.
+		* elf64-mips.c (mips_reloc_map): Likewise, delete BFD_RELOC_MIPS_REL16.
+		* elfn32-mips.c (mips_reloc_map): Likewise.
+		* libbfd.h: Regenerate.
+		* bfd-in2.h: Regenerate.
+	gas/
+		* config/tc-mips.c (append_insn): Handle BFD_RELOC_MIPS_16.
+		(macro_build): Likewise.
+		(mips_percent_op <%half>): Generate BFD_RELOC_MIPS_16.
+		(md_apply_fix): Handle BFD_RELOC_16 and BFD_RELOC_MIPS_16 when fx_done.
+	ld/
+		* testsuite/ld-mips-elf/reloc-local-overflow.d,
+		* testsuite/ld-mips-elf/reloc-local-overflow.s: Rewrite.
+
+2022-06-14  Alan Modra  <amodra@gmail.com>
+
+	Correct R_MIPS_16 n32 howto
+	If the howto is actually used, an all-zero dst_mask will result in
+	unchanged section contents on attempting to apply R_MIPS_16.
+
+		* elfn32-mips.c (elf_mips_howto_table_rela <R_MIPS_16>): Correct
+		dst_mask.
+
+2022-06-14  Alan Modra  <amodra@gmail.com>
+
+	asan: applying zero offset to NULL pointer
+		* dwarf.c (fetch_indexed_string): Move initialisation of "curr"
+		and "end" after checking for missing section.
+
+2022-06-14  Alan Modra  <amodra@gmail.com>
+
+	gas dwarf2dbg.c tidy
+	Make it a little more obvious that remap_debug_filename returns an
+	allocated string (that should be freed) by returning a char * rather
+	than const char *.  Free a few missed cases in dwarf2dbg.c, and free
+	other memory allocated in dwarf2dbg.c.  Also remove static
+	initialisation of variables and initialise in dwarf2_init instead,
+	in order to ensure gas state is saner for oss-fuzz.
+
+		* remap.c (remap_debug_filename): Remove const from return.
+		* as.h (remap_debug_filename): Update prototype.
+		* config/obj-elf.c (obj_elf_ident): Simplify free of
+		remap_debug_filename output.
+		* stabs.c (stabs_generate_asm_file): Likewise.
+		* dwarf2dbg.c (dirs, dirs_in_use, dirs_allocated, current): Don't
+		initialise statically..
+		(dwarf2_init): ..do so here, along with most other static vars.
+		(assign_file_to_slot): Don't set files_allocated until we
+		succeed in allocating memory.
+		(purge_generated_debug): Add bool param, free more stuff if true.
+		(dwarf2_directive_filename): Adjust purge_generated_debug call.
+		(process_entries): Don't free line_entry here..
+		(dwarf2_cleanup): ..do so here instead, new function.
+		(dwarf2_finish): Call dwarf2_cleanup.  When chaining together
+		subseg line entries, unhook entries from old subseg list.
+		(dwarf2_directive_loc): Free remap_debug_filename string.
+		(out_dir_and_file_list): Likewise.
+		(out_debug_str): Likewise.
+
+2022-06-14  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-13  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.reverse/test_ioctl_TCSETSW.exp with libc debuginfo
+	When running test-case gdb.reverse/test_ioctl_TCSETSW.exp with glibc debuginfo
+	installed, I run into:
+	...
+	(gdb) PASS: gdb.reverse/test_ioctl_TCSETSW.exp: at TCSETSW call
+	step^M
+	__tcsetattr (fd=0, optional_actions=1, termios_p=0x7fffffffcf50) at \
+	  ../sysdeps/unix/sysv/linux/tcsetattr.c:45^M
+	45      {^M
+	(gdb) FAIL: gdb.reverse/test_ioctl_TCSETSW.exp: handle TCSETSW
+	...
+
+	The problem is that the step is expected to step over the call to tcsetattr,
+	but due to glibc debuginfo being installed, we step into the call.
+
+	Fix this by using next instead of step.
+
+	Tested on x86_64-linux.
+
+2022-06-13  Tom de Vries  <tdevries@suse.de>
+
+	[gdb] Avoid warnings in cooked_{read,write}_test for m68hc11
+	With --enable-targets=all we have:
+	...
+	$ gdb -q -batch -ex "maint selftest"
+	  ...
+	Running selftest regcache::cooked_read_test::m68hc11.
+	warning: No frame soft register found in the symbol table.
+	Stack backtrace will not work.
+	Running selftest regcache::cooked_read_test::m68hc12.
+	warning: No frame soft register found in the symbol table.
+	Stack backtrace will not work.
+	Running selftest regcache::cooked_read_test::m68hc12:HCS12.
+	warning: No frame soft register found in the symbol table.
+	Stack backtrace will not work.
+	...
+
+	Likewise for regcache::cooked_write_test.
+
+	The warning has no use in the selftest context.
+
+	Fix this by skipping the specific selftests.
+
+	Tested on x86_64-linux.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29224
+
+2022-06-13  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: LoongArch: Deal with atomic sequence
+	We can't put a breakpoint in the middle of a ll/sc atomic sequence,
+	so look for the end of the sequence and put the breakpoint there.
+
+2022-06-13  Sam James  <sam@gentoo.org>
+
+	gdb: don't use bashism in configure test
+	Results in configure output like:
+	```
+	checking for X... no
+	/var/tmp/portage/sys-devel/gdb-12.1/work/gdb-12.1/gdb/configure: 18837: test: yes: unexpected operator
+	checking whether to use babeltrace... auto
+	```
+
+	... when /bin/sh is provided by a POSIX-compliant shell, like dash,
+	instead of bash.
+
+2022-06-13  Jiangshuai Li  <jiangshuai_li@c-sky.com>
+
+	gdb:csky add support target-descriptions for CSKY arch
+	Registers in CSKY architecture included:
+	1. 32 gprs
+	2. 16 ars (alternative gprs used for quick interrupt)
+	3. hi, lo, pc
+	4. fr0~fr31, fcsr, fid, fesr
+	5. vr0~vr15
+	6. ((32 banks) * 32) cr regs (max 32 banks, 32 control regs a bank)
+
+	For register names:
+	Except over control registers, other registers, like gprs, hi, lo ...
+	are fixed names. Among the 32*32 control registers, some used registers
+	will have fixed names, others will have a default name "cpxcry". 'x'
+	refers to bank, y refers index in the bank(a control register in bank
+	4 with index 14 will has a default name cp4cr14).
+
+	For register numbers in GDB:
+	We assign a fixed number to each register in GDB, like:
+	r0~r31 with 0~31
+	hi, lo with 36, 37
+	fpu/vpu with 40~71
+	...
+	described in function csky_get_supported_register_by_index().
+
+	Function csky_get_supported_tdesc_registers_count():
+	To calculate the total number of registers that GDB can analyze,
+	including those with fixed names and those with default register names.
+
+	Function csky_get_supported_register_by_index():
+	To find a supported struct csky_supported_tdesc_register, return a
+	struct include name with regnum via index.
+
+	Arrays csky_supported_tdesc_feature_names[]:
+	Include all supported feature names in tdesc-xmls.
+
+	We use the information described above to load the register description
+	file of the target from the stub. When loading, do a little check that
+	whether the register description file contains SP, LR and PC.
+
+2022-06-13  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Handle quotes in gdb_py_module_available
+	On openSUSE Leap 42.3 with python 3.4, I run into:
+	...
+	(gdb) python import pygments^M
+	Traceback (most recent call last):^M
+	  File "<string>", line 1, in <module>^M
+	ImportError: No module named 'pygments'^M
+	Error while executing Python code.^M
+	(gdb) FAIL: gdb.base/style.exp: python import pygments
+	ERROR: unexpected output from python import
+	...
+	because gdb_py_module_available doesn't handle the single quotes around the
+	module name in the ImportError.
+
+	Fix this by allowing the single quotes.
+
+	Tested on x86_64-linux.
+
+2022-06-13  Jan Beulich  <jbeulich@suse.com>
+
+	x86: fix incorrect indirection
+	Commit 384e201e5aec ("x86: properly initialize struct instr_info
+	instance(s)") was based on an improperly refreshed patch. Correct the
+	oversight.
+
+2022-06-13  Jan Beulich  <jbeulich@suse.com>
+
+	x86: replace global scratch buffer
+	With its movement to the stack, and with the subsequent desire to
+	initialize the entire instr_info instances, this has become doubly
+	inefficient. Individual users have better knowledge of how big a buffer
+	they need, and in a number of cases going through an intermediate buffer
+	can be avoided altogether.
+
+	Having got confirmation that it wasn't intentional to print memory
+	operand displacements with inconsistent style, print_displacement() is
+	now using dis_style_address_offset consistently (eliminating the need
+	for callers to pass in a style).
+
+	While touching print_operand_value() also convert its "hex" parameter to
+	bool. And while altering (and moving) oappend_immediate(), fold
+	oappend_maybe_intel_with_style() into its only remaining caller. Finally
+	where doing adjustments, use snprintf() in favor of sprintf().
+
+2022-06-13  Jan Beulich  <jbeulich@suse.com>
+
+	x86: avoid string copy when swapping Vex.W controlled operands
+	Now that op_out[] is an array of pointers, there's no need anymore to
+	copy strings. Simply swap the pointers.
+
+2022-06-13  Jan Beulich  <jbeulich@suse.com>
+
+	x86: shrink prefix related disassembler state fields
+	By changing the values used for "artificial" prefix values,
+	all_prefixes[] can be shrunk to array of unsigned char. All that
+	additionally needs adjusting is the printing of possible apparently
+	standalone prefixes when recovering from longjmp(): Simply check
+	whether any prefixes were successfully decoded, to avoid converting
+	opcode bytes matching the "artificial" values to prefix mnemonics.
+
+	Similarly by re-arranging the bits assigned to PREFIX_* mask values
+	we can fit all segment register masks in a byte and hence shrink
+	active_seg_prefix to unsigned char.
+
+	Somewhat similarly with last_*_prefix representing offsets into the
+	opcode being disassembled, signed char is sufficient to hold all possible
+	values.
+
+2022-06-13  Jan Beulich  <jbeulich@suse.com>
+
+	x86: properly initialize struct instr_info instance(s)
+	Commit 39fb369834a3 ("opcodes: Make i386-dis.c thread-safe") introduced
+	a lot of uninitialized data. Alan has in particular observed ubsan
+	taking issue with the loop inverting the order of operands, where
+	op_riprel[] - an array of bool - can hold values other than 0 or 1.
+
+	Move instantiation of struct instr_info into print_insn() (thus having
+	just a single central point), and make use of C99 dedicated initializers
+	to fill fields right in the initializer where possible. This way all
+	fields not explicitly initialized will be zero-filled, which in turn
+	allows dropping of some other explicit initialization later in the
+	function or in ckprefix(). Additionally this removes a lot of
+	indirection, as all "ins->info" uses can simply become "info".
+
+	Make one further arrangement though, to limit the amount of data needing
+	(zero)initializing on every invocation: Convert the op_out structure
+	member to just an array of pointers, with the actual arrays living
+	inside print_insn() (and, as befoe, having just their 1st char filled
+	with nul).
+
+	While there, instead of adjusting print_insn()'s forward declaration,
+	arrange for no such declaration to be needed in the first place.
+
+2022-06-13  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-12  Tom Tromey  <tom@tromey.com>
+
+	Fix self-test failure in addrmap
+	Mark pointed out that my recent addrmap C++-ficiation changes caused a
+	regression in the self-tests.  This patch fixes the problem by
+	updating this test not to allocate the mutable addrmap on an obstack.
+
+	Remove psymtab_addrmap
+	While working on addrmaps, I noticed that psymtab_addrmap is no longer
+	needed now.  It was introduced in ancient times as an optimization for
+	DWARF, but no other symbol reader was ever updated to use it.  Now
+	that DWARF does not use psymtabs, it can be deleted.
+
+	Use malloc for mutable addrmaps
+	Mutable addrmaps currently require an obstack.  This was probably done
+	to avoid having to call splay_tree_delete, but examination of the code
+	shows that all mutable obstacks have a limited lifetime -- now it's
+	simple to treat them as ordinary C++ objects, in some cases
+	stack-allocating them, and have a destructor to make the needed call.
+	This patch implements this change.
+
+	Remove addrmap::create_fixed
+	addrmap::create_fixed is just a simple wrapper for 'new', so remove it
+	in favor of uses of 'new'.
+
+	Remove addrmap_create_mutable
+	This removes addrmap_create_mutable in favor of using 'new' at the
+	spots where the addrmap is created.
+
+	Remove addrmap wrapper functions
+	This removes the various addrmap wrapper functions in favor of simple
+	method calls on the objects themselves.
+
+	Move addrmap classes to addrmap.h
+	This moves the addrmap class definitions to addrmap.h.  This is safe
+	to do now that the contents are private.
+
+	Privacy for addrmap_mutable
+	This changes addrmap_mutable so that its data members are private.
+
+	Privacy for addrmap_fixed
+	This changes addrmap_fixed so that its data members are private.
+	It also makes struct addrmap_transition private as well.
+
+	Use inheritance for addrmap
+	This is a simply C++-ification of the basics of addrmap: it uses
+	virtual methods rather than a table of function pointers, and it
+	changes the concrete implementations to be subclasses.
+
+2022-06-12  Jon Turney  <jon.turney@dronecode.org.uk>
+
+	Trivial fixes to Cygwin build after 8fea1a81
+	* Remove a stray semicolon
+	* Restore dropped nullptr program argument in use of create_process() under CYGWIN
+
+	Simplify __USEWIDE
+	Prior to c6ca3dab dropping support for Cygwin 1.5, __USEWIDE was not
+	defined for Cygwin 1.5.  After that, it's always defined if __CYGWIN__
+	is, so remove __USEWIDE conditionals inside __CYGWIN__ conditionals.
+
+	Simplify cygwin_buf_t
+	Prior to c6ca3dab dropping support for Cygwin 1.5, cygwin_buf_t was
+	defined as char for Cygwin 1.5.  After that, it's always wchar_t, so
+	just use that.
+
+2022-06-12  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-11  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-10  Tom Tromey  <tom@tromey.com>
+
+	Fix warning-avoidance initialization in xcoffread.c
+	With the registry rewrite series, on Fedora 34, I started seeing this
+	error in xcoffread.c:
+
+	../../binutils-gdb/gdb/xcoffread.c: In function ‘void read_xcoff_symtab(objfile*, legacy_psymtab*)’:
+	../../binutils-gdb/gdb/xcoffread.c:948:25: error: ‘main_aux’ is used uninitialized [-Werror=uninitialized]
+	  948 |   union internal_auxent fcn_aux_saved = main_aux;
+	      |                         ^~~~~~~~~~~~~
+	../../binutils-gdb/gdb/xcoffread.c:933:25: note: ‘main_aux’ declared here
+	  933 |   union internal_auxent main_aux;
+	      |                         ^~~~~~~~
+
+	I don't know why this error started suddenly... that seems weird,
+	because it's not obviously related to the changes I made.
+
+	Looking into it, it seems this line was intended to avoid a similar
+	warning -- but since 'main_aux' is uninitialized at the point where it
+	is used, this fix was incomplete.
+
+	This patch avoids the warning by initializing using "{}".  I'm
+	checking this in.
+
+2022-06-10  Carl Love  <cel@us.ibm.com>
+
+	Fix comparison of unsigned long int to int in record_linux_system_call.
+	The if statement in case gdb_sys_ioctl in function
+	record_linux_system_call in file gdb/linux-record.c is as follows:
+
+	   if (tmpulongest == tdep->ioctl_FIOCLEX
+	      || tmpulongest == tdep->ioctl_FIONCLEX
+	    ....
+	      || tmpulongest == tdep->ioctl_TCSETSW
+	     ...
+	   }
+
+	The PowerPC ioctl value for ioctl_TCSETW is 0x802c7415.  The variable
+	ioctl_TCSETW is defined in gdb/linux-record.h as an int.  The TCSETW value
+	has the MSB set to one so it is a negative integer.  The comparison of the
+	unsigned long value tmpulongest to a negative integer value for
+	ioctl_TCSETSW fails.
+
+	This patch changes the declarations for the ioctl_* values in struct
+	linux_record_tdep to unsigned long to fix the comparisons between
+	tmpulongest and the tdep->ioctl_* values.
+
+	An additional test gdb.reverse/test_ioctl_TCSETSW.exp is added to verify
+	the gdb record_linux_system_call() if statement for the ioctl TCSETSW
+	succeeds.
+
+	This patch has been tested on Power 10 and Intel with no test failures.
+
+2022-06-10  Carl Love  <cel@us.ibm.com>
+
+	PowerPC, correct the gdb ioctl values for TCGETS, TCSETS, TCSETSW and TCSETSF.
+	Some of the ioctl numbers are based on the size of kernel termios structure.
+	Currently the PowerPC GDB definitions are "hard coded" into the ioctl
+	number.
+
+	The current PowerPC values for TCGETS, TCSETS, TCSETSW and TCSETSF are
+	defined in gdb/ppc-linux-tdep.c as:
+
+	  record_tdep->ioctl_TCGETS = 0x403c7413;
+	  record_tdep->ioctl_TCSETS = 0x803c7414;
+	  record_tdep->ioctl_TCSETSW = 0x803c7415;
+	  record_tdep->ioctl_TCSETSF = 0x803c7416;
+
+	Where the termios structure size is in hex digits [5:4] as 0x3c.
+
+	The definition for the PowerPC termios structure is given in:
+	  arch/powerpc/include/uapi/asm/termbits.h
+
+	The size of the termios data structure in this file is 0x2c not 0x3c.
+
+	This patch changes the hex digits for the size of the PowerPC termios size
+	in the ioctl values for TCGETS, TCSETS, TCSETSW and TCSETSF to 0x2c.
+	This patch also changes the hard coding to generate the number based on a
+	it easier to update the ioctl numbers.
+
+2022-06-10  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: remove definition of true/false from gdb_compiler_info
+	Since pretty much forever the get_compiler_info function has included
+	these lines:
+
+	    # Most compilers will evaluate comparisons and other boolean
+	    # operations to 0 or 1.
+	    uplevel \#0 { set true 1 }
+	    uplevel \#0 { set false 0 }
+
+	These define global variables true (to 1) and false (to 0).
+
+	It seems odd to me that these globals are defined in
+	get_compiler_info, I guess maybe the original thinking was that if a
+	compiler had different true/false values then we would detect it there
+	and define true/false differently.
+
+	I don't think we should be bundling this logic into get_compiler_info,
+	it seems weird to me that in order to use $true/$false a user needs to
+	first call get_compiler_info.
+
+	It would be better I think if each test script that wants these
+	variables just defined them itself, if in the future we did need
+	different true/false values based on compiler version then we'd just
+	do:
+
+	  if { [test_compiler_info "some_pattern"] } {
+	    # Defined true/false one way...
+	  } else {
+	    # Defined true/false another way...
+	  }
+
+	But given the current true/false definitions have been in place since
+	at least 1999, I suspect this will not be needed any time soon.
+
+	Given that the definitions of true/false are so simple, right now my
+	suggestion is just to define them in each test script that wants
+	them (there's not that many).  If we ever did need more complex logic
+	then we can always add a function in gdb.exp that sets up these
+	globals, but that seems overkill for now.
+
+	There should be no change in what is tested after this commit.
+
+2022-06-10  Luis Machado  <luis.machado@arm.com>
+
+	Document the ARM_CC_FOR_TARGET testsuite variable
+	This variable is useful when exercising AArch64 multi-arch support (debugging
+	32-bit AArch32 executables).
+
+	Unfortunately it isn't well documented. This patch adds information about it
+	and explains how to use it.
+
+2022-06-10  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix XPASS with gcc-12 in gdb.base/vla-struct-fields.exp
+	With gcc-12, I get for test-case gdb.base/vla-struct-fields.exp:
+	...
+	(gdb) print inner_vla_struct_object_size == sizeof(inner_vla_struct_object)^M
+	$7 = 1^M
+	(gdb) XPASS: gdb.base/vla-struct-fields.exp: size of inner_vla_struct_object
+	...
+
+	Fix this by limiting the xfailing to gcc-11 and earlier.  Also, limit the
+	xfailing to the equality test.
+
+	Tested on x86_64-linux.
+
+2022-06-10  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix timeout in gdb.ada/ghost.exp
+	On openSUSE Tumbleweed with gcc-12, I run into a timeout:
+	...
+	(gdb) print value^M
+	Multiple matches for value^M
+	[0] cancel^M
+	[1] ada.strings.maps.value (<ref> ada.strings.maps.character_mapping; \
+	    character) return character at a-strmap.adb:599^M
+	[2] pck.value at src/gdb/testsuite/gdb.ada/ghost/pck.ads:17^M
+	[3] system.object_reader.value (<ref> system.object_reader.object_symbol) \
+	    return system.object_reader.uint64 at s-objrea.adb:2279^M
+	[4] system.traceback.symbolic.value (system.address) return string at \
+	    s-trasym.adb:200^M
+	> FAIL: gdb.ada/ghost.exp: print value (timeout)
+	print ghost_value^M
+	Argument must be choice number^M
+	(gdb) FAIL: gdb.ada/ghost.exp: print ghost_value
+	...
+
+	Fix this by prefixing value (as well as the other printed values) with the
+	package name:
+	...
+	(gdb) print pck.value^M
+	...
+
+	Tested on x86_64-linux.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29055
+
+2022-06-10  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-09  Tom Tromey  <tromey@adacore.com>
+
+	Minor fix to Python breakpoint event documentation
+	I noticed that the Python event documentation referred to the event's
+	"breakpoint" field as a function, whereas it is actually an attribute.
+	This patch fixes the error.
+
+2022-06-09  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/aarch64: fix 32-bit arm compatibility
+	GDB's ability to run 32-bit ARM processes on an AArch64 native target
+	is currently broken.  The test gdb.multi/multi-arch.exp currently
+	fails with a timeout.
+
+	The cause of these problems is the following three functions:
+
+	  aarch64_linux_nat_target::thread_architecture
+	  aarch64_linux_nat_target::fetch_registers
+	  aarch64_linux_nat_target::store_registers
+
+	What has happened, over time, is that these functions have been
+	modified, forgetting that any particular thread (running on the native
+	target) might be an ARM thread, or might be an AArch64 thread.
+
+	The problems always start with a line similar to this:
+
+	  aarch64_gdbarch_tdep *tdep
+	    = (aarch64_gdbarch_tdep *) gdbarch_tdep (inf->gdbarch);
+
+	The problem with this line is that if 'inf->gdbarch' is an ARM
+	architecture, then gdbarch_tdep will return a pointer to an
+	arm_gdbarch_tdep object, not an aarch64_gdbarch_tdep object.  The
+	result of the above cast will, as a consequence, be undefined.
+
+	In aarch64_linux_nat_target::thread_architecture, after the undefined
+	cast we then proceed to make use of TDEP, like this:
+
+	  if (vq == tdep->vq)
+	    return inf->gdbarch;
+
+	Obviously at this point the result is undefined, but, if this check
+	returns false we then proceed with this code:
+
+	  struct gdbarch_info info;
+	  info.bfd_arch_info = bfd_lookup_arch (bfd_arch_aarch64, bfd_mach_aarch64);
+	  info.id = (int *) (vq == 0 ? -1 : vq);
+	  return gdbarch_find_by_info (info);
+
+	As a consequence we will return an AArch64 gdbarch object for our ARM
+	thread!  Things go downhill from there on.
+
+	There are similar problems, with similar undefined behaviour, in the
+	fetch_registers and store_registers functions.
+
+	The solution is to make use of a check like this:
+
+	  if (gdbarch_bfd_arch_info (inf->gdbarch)->bits_per_word == 32)
+
+	If the word size is 32 then we know we have an ARM architecture.  We
+	just need to make sure that we perform this check before trying to
+	read the tdep field.
+
+	In aarch64_linux_nat_target::thread_architecture a little reordering,
+	and the addition of the above check allows us to easily avoid the
+	undefined behaviour.
+
+	For fetch_registers and store_registers I made the decision to split
+	each of the functions into two new helper functions, and so
+	aarch64_linux_nat_target::fetch_registers now calls to either
+	aarch64_fetch_registers or aarch32_fetch_registers, and there's a
+	similar change for store_registers.
+
+	One thing I had to decide was whether to place the new aarch32_*
+	functions into the aarch32-linux-nat.c file.  In the end I decided to
+	NOT place the functions there, but instead leave them in
+	aarch64-linux-nat.c, my reasoning was this:
+
+	The existing functions in that file are shared from arm-linux-nat.c
+	and aarch64-linux-nat.c, this generic code to support 32-bit ARM
+	debugging from either native target.
+
+	In contrast, the two new aarch32 functions I have added _only_ make
+	sense when debugging on an AArch64 native target.  These function
+	shouldn't be called from arm-linux-nat.c at all, and so, if we places
+	the functions into aarch32-linux-nat.c, the functions would be built
+	into a 32-bit ARM GDB, but never used.
+
+	With that said, there's no technical reason why they couldn't go in
+	aarch32-linux-nat.c, so if that is preferred I'm happy to move them.
+
+	After this commit the gdb.multi/multi-arch.exp passes.
+
+2022-06-09  Yvan Roux  <yvan.roux@foss.st.com>
+
+	gdb/arm: Document and fix exception stack offsets
+	Add a description of exception entry context stacking and fix next
+	frame offset (at 0xA8 relative to R0 location) as well as FPU
+	registers ones (starting at 0x68 relative to R0).
+
+	gdb/arm: Simplify logic for updating addresses
+	Small performance improvement by fetching previous SP value only
+	once before the loop and reuse it to avoid fetching at every
+	iteration.
+
+2022-06-09  Pedro Alves  <pedro@palves.net>
+
+	Fix ARM_CC_FOR_TARGET handling
+	The previous patch that introduced the arm_cc_for_target procedure
+	moved the ARM_CC_FOR_TARGET global check to that procedure, but forgot
+	to tell tcl that ARM_CC_FOR_TARGET is a global.  As a result,
+	specifying ARM_CC_FOR_TARGET on the command line actually does
+	nothing.  This fixes it.
+
+	Change-Id: I4e33b7633fa665e2f7b8f8c9592a949d74a19153
+
+2022-06-09  Yvan Roux  <yvan.roux@foss.st.com>
+
+	gdb/arm: Terminate unwinding when LR is 0xffffffff
+	ARMv7-M Architecture Reference "A2.3.1 Arm core registers" states
+	that LR is set to 0xffffffff on reset.
+
+	ARMv8-M Architecture Reference "B3.3 Registers" states that LR is set
+	to 0xffffffff on warm reset if Main Extension is implemented,
+	otherwise the value is unknown.
+
+2022-06-09  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: solve problems with compiler_info caching
+	After this commit:
+
+	  commit 44d469c5f85a4243462b8966722dafa62b602bf5
+	  Date:   Tue May 31 16:43:44 2022 +0200
+
+	      gdb/testsuite: add Fortran compiler identification to GDB
+
+	Some regressions were noticed:
+
+	  https://sourceware.org/pipermail/gdb-patches/2022-May/189673.html
+
+	The problem is associated with how compiler_info variable is cached
+	between calls to get_compiler_info.
+
+	Even before the above commit, get_compiler_info supported two
+	language, C and C++.  Calling get_compiler_info would set the global
+	compiler_info based on the language passed as an argument to
+	get_compiler_info, and, in theory, compiler_info would not be updated
+	for the rest of the dejagnu run.
+
+	This obviously is slightly broken behaviour.  If the first call to
+	get_compiler_info was for the C++ language then compiler_info would be
+	set based on the C++ compiler in use, while if the first call to
+	get_compiler_info was for the C language then compiler_info would be
+	set based on the C compiler.
+
+	This probably wasn't very noticable, assuming a GCC based test
+	environment then in most cases the C and C++ compiler would be the
+	same version.
+
+	However, if the user starting playing with CC_FOR_TARGET or
+	CXX_FOR_TARGET, then they might not get the behaviour they expect.
+
+	Except, to make matters worse, most of the time, the user probably
+	would get the behaviour they expected .... except when they didn't!
+	I'll explain:
+
+	In gdb.exp we try to avoid global variables leaking between test
+	scripts, this is done with the help of the two procs
+	gdb_setup_known_globals and gdb_cleanup_globals.  All known globals
+	are recorded before a test script starts, and then, when the test
+	script ends, any new globals are deleted.
+
+	Normally, compiler_info is only set as a result of a test script
+	calling get_compiler_info or test_compiler_info.  This means that the
+	compiler_info global will not exist when the test script starts, but
+	will exist when the test script end, and so, the compiler_info
+	variable is deleted at the end of each test.
+
+	This means that, in reality, the compiler_info is recalculated once
+	for each test script, hence, if a test script just checks on the C
+	compiler, or just checks on the C++ compiler, then compiler_info will
+	be correct and the user will get the behaviour they expect.
+
+	However, if a single test script tries to check both the C and C++
+	compiler versions then this will not work (even before the above
+	commit).
+
+	The situation is made worse be the behaviour or the load_lib proc.
+	This proc (provided by dejagnu) will only load each library once.
+	This means that if a library defines a global, then this global would
+	normally be deleted at the end of the first test script that includes
+	the library.
+
+	As future attempts to load the library will not actually reload it,
+	then the global will not be redefined and would be missing for later
+	test scripts that also tried to load that library.
+
+	To work around this issue we override load_lib in gdb.exp, this new
+	version adds all globals from the newly loaded library to the list of
+	globals that should be preserved (not deleted).
+
+	And this is where things get interesting for us.  The library
+	trace-support.exp includes calls, at the file scope, to things like
+	is_amd64_regs_target, which cause get_compiler_info to be called.
+	This means that after loading the library the compiler_info global is
+	defined.
+
+	Our override of load_lib then decides that this new global has to be
+	preserved, and adds it to the gdb_persistent_globals array.
+
+	From that point on compiler_info will never be recomputed!
+
+	This commit addresses all the caching problems by doing the following:
+
+	Change the compiler_info global into compiler_info_cache global.  This
+	new global is an array, the keys of this array will be each of the
+	supported languages, and the values will be the compiler version for
+	that language.
+
+	Now, when we call get_compiler_info, if the compiler information for
+	the specific language has not been computed, then we do that, and add
+	it to the cache.
+
+	Next, compiler_info_cache is defined by calling
+	gdb_persistent_global.  This automatically adds the global to the list
+	of persistent globals.  Now the cache will not be deleted at the end
+	of each test script.
+
+	This means that, for a single test run, we will compute the compiler
+	version just once for each language, this result will then be cached
+	between test scripts.
+
+	Finally, the legacy 'gcc_compiled' flag is now only set when we call
+	get_compiler_info with the language 'c'.  Without making this change
+	the value of 'gcc_compiled' would change each time a new language is
+	passed to get_compiler_info.  If the last language was e.g. Fortran,
+	then gcc_compiled might be left false.
+
+2022-06-09  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: handle errors better in test_compiler_info
+	Now that get_compiler_info might actually fail (if the language is not
+	handled), then we should try to handle this failure better in
+	test_compiler_info.
+
+	After this commit, if get_compiler_info fails then we will return a
+	suitable result depending on how the user called test_compiler_info.
+
+	If the user does something like:
+
+	  set version [test_compiler_info "" "unknown-language"]
+
+	Then test_compiler_info will return an empty string.  My assumption is
+	that the user will be trying to match 'version' against something, and
+	the empty string hopefully will not match.
+
+	If the user does something like:
+
+	  if { [test_compiler_info "some_pattern" "unknown-language"] } {
+	    ....
+	  }
+
+	Then test_compiler_info will return false which seems the obvious
+	choice.
+
+	There should be no change in the test results after this commit.
+
+2022-06-09  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: make 'c' default language for get/test compiler info
+	This commit is a minor cleanup for the two functions (in gdb.exp)
+	get_compiler_info and test_compiler_info.
+
+	Instead of using the empty string as the default language, and just
+	"knowing" that this means the C language.  Make this explicit.  The
+	language argument now defaults to "c" if not specified, and the if
+	chain in get_compiler_info that checks the language not explicitly
+	handles "c" and gives an error for unknown languages.
+
+	This is a good thing, now that the API appears to take a language, if
+	somebody does:
+
+	  test_compiler_info "xxxx" "rust"
+
+	to check the version of the rust compiler then we will now give an
+	error rather than just using the C compiler and leaving the user
+	having to figure out why they are not getting the results they
+	expect.
+
+	After a little grepping, I think the only place we were explicitly
+	passing the empty string to either get_compiler_info or
+	test_compiler_info was in gdb_compile_shlib_1, this is now changed to
+	pass "c" as the default language.
+
+	There should be no changes to the test results after this commit.
+
+2022-06-09  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: remove get_compiler_info calls from gdb.exp and dwarf.exp
+	We don't need to call get_compiler_info before calling
+	test_compiler_info; test_compiler_info includes a call to
+	get_compiler_info.
+
+	This commit cleans up lib/gdb.exp and lib/dwarf.exp a little by
+	removing some unneeded calls to get_compiler_info.  We could do the
+	same cleanup throughout the testsuite, but I'm leaving that for
+	another day.
+
+	There should be no change in the test results after this commit.
+
+2022-06-09  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	gdb/testsuite: use test_compiler_info in gcc_major_version
+	The procedure gcc_major_version was earlier using the global variable
+	compiler_info to retrieve gcc's major version.  This is discouraged and
+	(as can be read in a comment in compiler.c) compiler_info should be
+	local to get_compiler_info and test_compiler_info.
+
+	The preferred way of getting the compiler string is via calling
+	test_compiler_info without arguments.  Gcc_major_version was changed to
+	do that.
+
+2022-06-09  Yvan Roux  <yvan.roux@foss.st.com>
+
+	gdb: add Yvan Roux to gdb/MAINTAINERS
+
+2022-06-09  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: resolve duplicate test names in gdb.threads/tls.exp
+	While running the gdb.threads/tls.exp test with a GDB configured
+	without Python, I noticed some duplicate test names.
+
+	This is caused by a call to skip_python_tests that is within a proc
+	that is called multiple times by the test script.  Each call to
+	skip_python_tests results in a call to 'unsupported', and this causes
+	the duplicate test names.
+
+	After this commit we now call skip_python_tests just once and place
+	the result into a variable.  Now, instead of calling skip_python_tests
+	multiple times, we just check the variable.
+
+	There should be no change in what is tested after this commit.
+
+2022-06-09  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: resolve duplicate test name in gnu_vector.exp
+	While testing on AArch64 I spotted a duplicate test name in the
+	gdb.base/gnu_vector.exp test.
+
+	This commit adds a 'with_test_prefix' to resolve the duplicate.
+
+	While I was in the area I updated a 'gdb_test_multiple' call to make
+	use of $gdb_test_name.
+
+	There should be no change in what is tested after this commit.
+
+2022-06-09  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-08  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: make throw_perror_with_name static
+	The throw_perror_with_name function is not used outside of utils.c
+	right now.  And as perror_with_name is just a wrapper around
+	throw_perror_with_name, then any future calls would be to
+	perror_with_name.
+
+	Lets make throw_perror_with_name static.
+
+	There should be no user visible changes after this commit.
+
+2022-06-08  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: remove trailing '.' from perror_with_name calls
+	I ran into this error while working on AArch64 GDB:
+
+	  Unable to fetch VFP registers.: Invalid argument.
+
+	Notice the '.:' in the middle of this error message.
+
+	This is because of this call in aarch64-linux-nat.c:
+
+	  perror_with_name (_("Unable to fetch VFP registers."));
+
+	The perror_with_name function take a string, and adds ': <message>' to
+	the end the string, so I don't think the string that we pass to
+	perror_with_name should end in '.'.
+
+	This commit removes all of the trailing '.' characters from
+	perror_with_name calls, which give more readable error messages.
+
+	I don't believe that any of these errors are tested in the
+	testsuite (after a little grepping).
+
+2022-06-08  Tom Tromey  <tom@tromey.com>
+
+	Move CU queue to dwarf2_per_objfile
+	The CU queue is a member of dwarf2_per_bfd, but it is only used when
+	expanding CUs.  Also, the dwarf2_per_objfile destructor checks the
+	queue -- however, if the per-BFD object is destroyed first, this will
+	not work.  This was pointed out Lancelot as fallout from the patch to
+	rewrite the registry system.
+
+	This patch avoids this problem by moving the queue to the per-objfile
+	object.
+
+2022-06-08  Tom Tromey  <tom@tromey.com>
+
+	Change allocation of m_dwarf2_cus
+	m_dwarf2_cus manually manages the 'dwarf2_cu' pointers it owns.  This
+	patch simplifies the code by changing it to use unique_ptr.
+
+2022-06-08  Andrew Burgess  <aburgess@redhat.com>
+
+	libopcodes: extend the styling within the i386 disassembler
+	The i386 disassembler is pretty complex.  Most disassembly is done
+	indirectly; operands are built into buffers within a struct instr_info
+	instance, before finally being printed later in the disassembly
+	process.
+
+	Sometimes the operand buffers are built in a different order to the
+	order in which they will eventually be printed.
+
+	Each operand can contain multiple components, e.g. multiple registers,
+	immediates, other textual elements (commas, brackets, etc).
+
+	When looking for how to apply styling I guess the ideal solution would
+	be to move away from the operands being a single string that is built
+	up, and instead have each operand be a list of "parts", where each
+	part is some text and a style.  Then, when we eventually print the
+	operand we would loop over the parts and print each part with the
+	correct style.
+
+	But it feels like a huge amount of work to move from where we are
+	now to that potentially ideal solution.  Plus, the above solution
+	would be pretty complex.
+
+	So, instead I propose a .... different solution here, one that works
+	with the existing infrastructure.
+
+	As each operand is built up, piece be piece, we pass through style
+	information.  This style information is then encoded into the operand
+	buffer (see below for details).  After this the code can continue to
+	operate as it does right now in order to manage the set of operand
+	buffers.
+
+	Then, as each operand is printed we can split the operand buffer into
+	chunks at the style marker boundaries, with each chunk being printed
+	with the correct style.
+
+	For encoding the style information I use a single character, currently
+	\002, followed by the style encoded as a single hex digit, followed
+	again by the \002 character.
+
+	This of course relies on there not being more than 16 styles, but that
+	is currently true, and hopefully will remain true for the foreseeable
+	future.
+
+	The other major concern that has arisen around this work is whether
+	the escape character could ever be encountered in output naturally
+	generated by the disassembler.  If this did happen then the escape
+	characters would be stripped from the output, and the wrong styling
+	would be applied.
+
+	However, I don't believe that this is currently a problem.
+	Disassembler content comes from a number of sources.  First there's
+	content that copied directly from the i386-dis.c file, this is things
+	like register names, and other syntax elements (brackets, commas,
+	etc).  We can easily check that the i386-dis.c file doesn't contain
+	our special character.
+
+	The next source of content are immediate operands.  The text for these
+	operands is generated by calls into libc.  By selecting a
+	non-printable character we can be confident that this is not something
+	that libc will generate as part of an immediate representation.
+
+	The other output that appears to be from the disassembler is operands
+	that contain addresses and (possibly) symbol names.  It is quite
+	possible that a symbol name might contain any special character we
+	could imagine, so is this a problem?
+
+	I don't think it is, we don't actually print address and symbol
+	operands through the disassembler, instead, the disassembler calls
+	back to the user (objdump, gdb, etc) to print the address and symbol
+	on its behalf.  This content is printed directly to the output stream,
+	it does not pass through the i386 disassembler output buffers.  As a
+	result, we never check this particular output for styling escape
+	characters.
+
+	In some (not very scientific) benchmarking on my machine,
+	disassembling a reasonably large (142M) shared library, I'm not seeing
+	any significant slow down in disassembler speed with this change.
+
+	Most instructions are now being fully syntax highlighted when I
+	disassemble using the --disassembler-color=extended-color option.  I'm
+	sure that there are probably still a few corner cases that need fixing
+	up, but we can come back to them later I think.
+
+	When disassembler syntax highlighting is not being used, then there
+	should be no user visible changes after this commit.
+
+2022-06-08  Carl Love  <cel@us.ibm.com>
+
+	Fix gdb.arch/powerpc-power7.exp isel disassembly output.
+	The following commit changes the output format for the isel instruction on
+	PowerPC.
+
+	   commit dd4832bf3efc1bd1797a6b9188260692b8b0db52     Introduces error in test
+	   Author: Dmitry Selyutin <ghostmansd@gmail.com>
+	   Date:   Tue May 24 13:46:35 2022 +0000
+
+	       opcodes: introduce BC field; fix isel
+
+	       Per Power ISA Version 3.1B 3.3.12, isel uses BC field rather than CRB
+	       field present in binutils sources. Also, per 1.6.2, BC has the same
+	       semantics as BA and BB fields, so this should keep the same flags and
+	       mask, only with the different offset.
+
+	       opcodes/
+	               * ppc-opc.c
+	               (BC): Define new field, with the same definition as CRB field,
+	               but with the PPC_OPERAND_CR_BIT flag present.
+	       gas/
+	               * testsuite/gas/ppc/476.d: Update.
+	               * testsuite/gas/ppc/a2.d: Update.
+	               * testsuite/gas/ppc/e500.d: Update.
+	               * testsuite/gas/ppc/power7.d: Update.
+	  <snip>
+	   --- a/gas/testsuite/gas/ppc/476.d
+	   +++ b/gas/testsuite/gas/ppc/476.d
+	   @@ -209,7 +209,7 @@ Disassembly of section \.text:
+	    .*:    (7c 20 07 8c|8c 07 20 7c)       ici     1
+	    .*:    (7c 03 27 cc|cc 27 03 7c)       icread  r3,r4
+	    .*:    (50 83 65 36|36 65 83 50)       rlwimi  r3,r4,12,20,27
+	    -.*:    (7c 43 27 1e|1e 27 43 7c)       isel    r2,r3,r4,28
+	    +.*:    (7c 43 27 1e|1e 27 43 7c)       isel    r2,r3,r4,4\*cr7\+lt
+
+	The above change breaks the gdb regression test gdb.arch/powerpc-power7.exp
+	on Power 7, Power 8, Power 9 and Power 10.
+
+	This patch updates the regression test gdb.arch/powerpc-power7.exp with
+	the new expected output for the isel instruction.
+
+	The patch has been tested on Power 7 and Power 10 to verify the patch fixes
+	the test.
+
+2022-06-08  Pedro Alves  <pedro@palves.net>
+
+	aarch64: Add fallback if ARM_CC_FOR_TARGET not set
+	On Aarch64, you can set ARM_CC_FOR_TARGET to point to the 32-bit
+	compiler to use when testing gdb.multi/multi-arch.exp and
+	gdb.multi/multi-arch-exec.exp.  If you don't set it, then those
+	testcases don't run.
+
+	I guess that approximately nobody remembers to set ARM_CC_FOR_TARGET.
+
+	This commit adds a fallback.  If ARM_CC_FOR_TARGET is not set, and
+	testing for Linux, try arm-linux-gnueabi-gcc,
+	arm-none-linux-gnueabi-gcc, arm-linux-gnueabihf-gcc as 32-bit
+	compilers, making sure that the produced executable runs on the target
+	machine before claiming that the compiler produces useful executables.
+
+	Change-Id: Iefe5865d5fc84b4032eaff7f4c5c61582bf75c39
+
+2022-06-08  Alan Modra  <amodra@gmail.com>
+
+	Don't encode reloc.size
+	I expect the encoded reloc.size field originally came from aout
+	r_length ecoding, but somehow went wrong for 64-bit relocs (which
+	should have been encoded as 3).  Toss all that out, just use a byte
+	size instead.  The changes outside of reloc.c in this patch should
+	make the code independent of how reloc.size is encoded.
+
+		* reloc.c (struct reloc_howto_struct): Increase size field by
+		one bit.  Comment.
+		(HOWTO_RSIZE): Don't encode size.
+		(bfd_get_reloc_size): Adjust, and make it an inline function.
+		(read_reloc, write_reloc): Adjust.
+		* bfd-in2.h: Regenerate.
+		* aout-ns32k.c: Include libbfd.h.
+		(put_reloc): Don't use howto->size directly.  Calculate r_length
+		using bfd_log2 and bfd_get_reloc_size.
+		* aoutx.h (swap_std_reloc_out): Likewise.
+		(aout_link_reloc_link_order): Likewise.
+		* i386lynx.c (swap_std_reloc_out
+		* mach-o-i386.c (bfd_mach_o_i386_swap_reloc_out
+		* pdp11.c (aout_link_reloc_link_order
+		* coff-arm.c (coff_arm_reloc): Don't use howto->size directly,
+		use bfd_get_reloc_size instead and adjust switch cases.
+		* coff-i386.c (coff_i386_reloc): Similarly.
+		* coff-x86_64.c (coff_amd64_reloc): Likewise.
+		* cpu-ns32k.c (do_ns32k_reloc): Likewise.
+		* elf32-arc.c (arc_do_relocation): Likewise.
+		* elf32-arm.c (elf32_arm_final_link_relocate): Likewise.
+		* elf32-bfin.c (bfin_bfd_reloc): Likewise.
+		* elf32-cr16.c (cr16_elf_final_link_relocate): Likewise.
+		* elf32-cris.c (cris_elf_pcrel_reloc): Likewise.
+		* elf32-crx.c (crx_elf_final_link_relocate): Likewise.
+		* elf32-csky.c (csky_elf_relocate_section): Likewise.
+		* elf32-d10v.c (extract_rel_addend, insert_rel_addend): Likewise.
+		* elf32-i386.c (elf_i386_relocate_section): Likewise.
+		* elf32-m32r.c (m32r_elf_generic_reloc): Likewise.
+		* elf32-nds32.c (nds32_elf_generic_reloc): Likewise.
+		* syms.c (_bfd_stab_section_find_nearest_line): Likewise.
+		* coff-rs6000.c (xcoff_ppc_relocate_section): Adjust howto.size.
+		* coff64-rs6000.c (xcoff64_ppc_relocate_section): Likewise.
+
+2022-06-08  Alan Modra  <amodra@gmail.com>
+
+	bfin reloc offset checks
+	These all ought to use bfd_reloc_offset_in_range.  In particular, replace
+	the check using howto->size + 1u.
+
+		* elf32-bfin.c (bfin_pcrel24_reloc): Use bfd_reloc_offset_in_range.
+		(bfin_imm16_reloc, bfin_byte4_reloc, bfin_bfd_reloc),
+		(bfin_final_link_relocate): Likewise.
+
+2022-06-08  Alan Modra  <amodra@gmail.com>
+
+	Revert reloc howto nits
+	The "HOWTO size encoding" patch put 1 as the HOWTO size arg for
+	numerous howtos that are unused, describe dynamic relocs, are markers,
+	or otherwise are special purpose reloc howtos that don't care about
+	the size.  The idea was to ensure no howto changed by inspecting
+	object files.  Revert those changes, making them zero size.
+
+		* coff-alpha.c: Give special purpose reloc howtos a size of zero.
+		* coff-mcore.c, * elf-hppa.h, * elf-m10300.c, * elf32-arm.c,
+		* elf32-csky.c, * elf32-m32c.c, * elf32-m68k.c, * elf32-mep.c,
+		* elf32-mips.c, * elf32-ppc.c, * elf32-rx.c, * elf32-s390.c,
+		* elf32-spu.c, * elf32-tic6x.c, * elf32-tilepro.c, *elf32-vax.c,
+		* elf32-xtensa.c, * elf64-alpha.c, * elf64-mips.c,
+		* elf64-mmix.c, * elf64-ppc.c, * elf64-s390.c, * elfn32-mips.c,
+		* elfxx-loongarch.c, * elfxx-riscv.c, * elfxx-sparc.c,
+		* elfxx-tilegx.c, * som.c, * vms-alpha.c: Likewise.
+
+2022-06-08  Alan Modra  <amodra@gmail.com>
+
+	HOWTO size encoding
+	This changes the HOWTO macro to encode the howto.size field from a
+	value given in bytes.  This of course requires editing all target
+	uses of HOWTO, a major pain, but makes it a little nicer to specify
+	new target HOWTOs.  Object files before/after this patch are
+	unchanged in .data and .rodata.
+
+	bfd/
+		* reloc.c (HOWTO_RSIZE): Encode size in bytes.
+		(EMPTY_HOWTO): Adjust to keep it all zero.
+		* aout-ns32k.c, * aoutx.h, * coff-alpha.c, * coff-arm.c,
+		* coff-i386.c, * coff-mcore.c, * coff-mips.c, * coff-rs6000.c,
+		* coff-sh.c, * coff-tic30.c, * coff-tic4x.c, * coff-tic54x.c,
+		* coff-x86_64.c, * coff-z80.c, * coff-z8k.c, * coff64-rs6000.c,
+		* elf-hppa.h, * elf-m10200.c, * elf-m10300.c, * elf32-arc.c,
+		* elf32-arm.c, * elf32-avr.c, * elf32-bfin.c, * elf32-cr16.c,
+		* elf32-cris.c, * elf32-crx.c, * elf32-csky.c, * elf32-d10v.c,
+		* elf32-d30v.c, * elf32-dlx.c, * elf32-epiphany.c,
+		* elf32-fr30.c, * elf32-frv.c, * elf32-ft32.c, * elf32-gen.c,
+		* elf32-h8300.c, * elf32-i386.c, * elf32-ip2k.c, * elf32-iq2000.c,
+		* elf32-lm32.c, * elf32-m32c.c, * elf32-m32r.c, * elf32-m68hc11.c,
+		* elf32-m68hc12.c, * elf32-m68k.c, * elf32-mcore.c, * elf32-mep.c,
+		* elf32-metag.c, * elf32-microblaze.c, * elf32-mips.c,
+		* elf32-moxie.c, * elf32-msp430.c, * elf32-mt.c, * elf32-nds32.c,
+		* elf32-nios2.c, * elf32-or1k.c, * elf32-pj.c, * elf32-ppc.c,
+		* elf32-pru.c, * elf32-rl78.c, * elf32-rx.c, * elf32-s12z.c,
+		* elf32-s390.c, * elf32-score.c, * elf32-score7.c,
+		* elf32-sh-relocs.h, * elf32-spu.c, * elf32-tic6x.c,
+		* elf32-tilepro.c, * elf32-v850.c, * elf32-vax.c,
+		* elf32-visium.c, * elf32-wasm32.c, * elf32-xc16x.c,
+		* elf32-xgate.c, * elf32-xstormy16.c, * elf32-xtensa.c,
+		* elf32-z80.c, * elf64-alpha.c, * elf64-bpf.c, * elf64-gen.c,
+		* elf64-mips.c, * elf64-mmix.c, * elf64-nfp.c, * elf64-ppc.c,
+		* elf64-s390.c, * elf64-x86-64.c, * elfn32-mips.c,
+		* elfnn-aarch64.c, * elfxx-ia64.c, * elfxx-loongarch.c,
+		* elfxx-mips.c, * elfxx-riscv.c, * elfxx-sparc.c,
+		* elfxx-tilegx.c, * mach-o-aarch64.c, * mach-o-arm.c,
+		* mach-o-i386.c, * mach-o-x86-64.c, * pdp11.c, * reloc.c,
+		* som.c, * vms-alpha.c: Adjust all uses of HOWTO.
+		* bfd-in2.h: Regenerate.
+	include/
+		* elf/arc-reloc.def: Adjust all uses of HOWTO.
+
+2022-06-08  Alan Modra  <amodra@gmail.com>
+
+	HOWTO_RSIZE
+	Define a helper macro for HOWTO.
+
+	       * reloc.c (HOWTO_RSIZE): Define.
+	       (HOWTO): Use it.
+	       * bfd-in2.h: Regenerate.
+
+2022-06-08  Alan Modra  <amodra@gmail.com>
+
+	elf64-nfp reloc fix
+	These are all dummy howtos, there is no reason one of them should
+	have partial_inplace true.
+
+		* elf64-nfp.c (elf_nfp_howto_table <R_NFP_IMMED_LO16_I_B>): Don't
+		set partial_inplace.
+
+2022-06-08  Alan Modra  <amodra@gmail.com>
+
+	coff-z80 reloc howto fixes
+	Mostly cosmetic unless attempting to link coff-z80 into another output
+	format.
+
+		* coff-z80.c (howto_table <R_IMM24, R_WORD0, R_WORD1>): Correct size.
+		(extra_case): Use bfd_{get,put}_24 when applying R_IMM24.
+
+2022-06-08  Alan Modra  <amodra@gmail.com>
+
+	NONE reloc fixes
+	Make them all zero size standard do-nothing howtos.
+
+		* elf32-csky.c (csky_elf_howto_table <R_CKCORE_NONE>): Correct howto.
+		* elf32-ft32.c (ft32_elf_howto_table <R_FT32_NONE>): Likewise.
+		* elf32-gen.c (dummy): Likewise.
+		* elf32-nds32.c (none_howto): Likewise.
+		* elf32-nios2.c (elf_nios2_r2_howto_table_rel <R_NIOS2_NONE>):
+		Likewise.
+		* elf32-pru.c (elf_pru_howto_table_rel <R_PRU_NONE>): Likewise.
+		* elf32-v850.c (v800_elf_howto_table <R_V810_NONE>): Likewise.
+		* elf64-gen.c (dummy): Likewise.
+		* elfn32-mips.c (elf_mips_howto_table_rela <R_MIPS_NONE): Likewise.
+		* elfxx-mips.c (none_howto): Likewise.
+		* reloc.c (none_howto): Likewise.
+
+2022-06-08  Alan Modra  <amodra@gmail.com>
+
+	asan: double free sb_kill
+	oss-fuzz hits a flaky crash with a double-free.  I think this is due
+	to gas static state not being reinitialised between testcases, a bug
+	with oss-fuzz not gas.  Anyway, this patch should avoid the problem.
+
+		* input-scrub.c (input_scrub_push): Move init of sb_index..
+		(input_scrub_reinit): ..to here.
+
+2022-06-08  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-07  Tom Tromey  <tromey@adacore.com>
+
+	Use subclasses of windows_process_info
+	This changes windows_process_info to use virtual methods for its
+	callbacks, and then changes the two clients of this code to subclass
+	this class to implement the methods.
+
+	I considered using CRTP here, but that would require making the new
+	structures visible to the compilation of of nat/windows-nat.c.  This
+	seemed like a bit of a pain, so I didn't do it.
+
+	This change then lets us change all the per-inferior globals to be
+	members of the new subclass.  Note that there can still only be a
+	single inferior -- currently there's a single global of the new type.
+	This is just another step toward possibly implementing multi-inferior
+	for Windows.
+
+	It's possible this could be cleaned up further... ideally I'd like to
+	move more of the data into the base class.  However, because gdb
+	supports Cygwin and gdbserver does not, and because I don't have a way
+	to build or test Cygwin, larger refactorings are difficult.
+
+2022-06-07  Tom Tromey  <tromey@adacore.com>
+
+	Turn some windows-nat.c static functions into methods
+	This patch turns some windows-nat.c static functions into methods on
+	windows_nat_target.  This avoids having to reference the
+	windows_nat_target singleton in some more spots -- a minor code
+	cleanup.
+
+	Allow ASLR to be disabled on Windows
+	On Windows, it is possible to disable ASLR when creating a process.
+	This patch adds code to do this, and hooks it up to gdb's existing
+	disable-randomization feature.  Because the Windows documentation
+	cautions that this isn't available on all versions of Windows, the
+	CreateProcess wrapper function is updated to make the attempt, and
+	then fall back to the current approach if it fails.
+
+	Introduce wrapper for CreateProcess
+	This is a small refactoring that introduces a wrapper for the Windows
+	CreateProcess function.  This is done to make the next patch a bit
+	simpler.
+
+2022-06-07  Enze Li  <enze.li@hotmail.com>
+
+	Update my email address in gdb/MAINTAINERS
+
+2022-06-07  Tom Tromey  <tromey@adacore.com>
+
+	Constify solib_name_from_address
+	I noticed that solib_name_from_address returned a non-const string,
+	but it's more appropriate to return const.  This patch implements
+	this.  Tested by rebuilding.
+
+2022-06-07  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/rust] Add missing _() for error call
+	In commit 1390b65a1b9 ("[gdb/rust] Fix literal truncation") I forgot to add
+	_() around a string using in an error call.
+
+	Fix this by adding the missing _().
+
+	Tested on x86_64-linux.
+
+2022-06-07  Tom de Vries  <tdevries@suse.de>
+
+	[gdb] Allow frv::fr300 in selftests
+	In skip_arch in gdb/selftest-arch.c we skip architecture fr300 because of
+	PR20946, but the PR has been fixed by commit 0ae60c3ef45 ("Prevent an abort in
+	the FRV disassembler if the target bfd name is unknown.") in Januari 2017.
+
+	Remove the skipping of frv::fr300.
+
+	Tested on x86_64-linux.
+
+2022-06-07  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-06  Tom Tromey  <tromey@adacore.com>
+
+	Consolidate "Python API" sections in NEWS
+	I noticed that the gdb NEWS file had two "Python API" sections in
+	"Changes since GDB 12".  This patch consolidates the two.  I chose to
+	preserve the second one, first because it is longer, and second
+	because I felt that user command changes should come before API
+	changes.
+
+	Simplify varobj "change" logic
+	varobj used to store 'print_value' as a C string, where NULL was a
+	valid value, and so it had logic to handle this situation.  However,
+	at some point this was changed to be a std::string, and so the code
+	can be simplified in this spot.
+
+2022-06-06  Tom Tromey  <tromey@adacore.com>
+
+	Remove "-break-insert -r" tests
+	PR mi/14270 points out that mi-break.exp has some tests for an
+	unimplemented "-r" switch for "-break-insert".  This switch was never
+	implemented, and is not documented -- though it is mentioned in a
+	comment in the documentation.  This patch removes the test and the doc
+	comment.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14270
+
+2022-06-06  Tom de Vries  <tdevries@suse.de>
+
+	[gdb] Name arch selftests more clearly
+	When running some all archs selftest I get:
+	...
+	$ gdb -q -batch -ex "maint selftest unpack_field_as_long"
+	Running selftest unpack_field_as_long::A6.
+	...
+
+	By now I know that A6 is an arc architecture, but for others that's less
+	clear.
+
+	Fix this by using unpack_field_as_long::arc::A6 instead.
+
+	This then introduces redundant names like arm::arm, so try to avoid those,
+	though I'm not entirely convinced that that's worth the trouble.
+
+	This introduces the following new names:
+	...
+	+Running selftest unpack_field_as_long::am33_2::am33-2.
+	+Running selftest unpack_field_as_long::arc::A6.
+	+Running selftest unpack_field_as_long::arc::A7.
+	+Running selftest unpack_field_as_long::arc::EM.
+	+Running selftest unpack_field_as_long::arc::HS.
+	+Running selftest unpack_field_as_long::arm::ep9312.
+	+Running selftest unpack_field_as_long::arm::iwmmxt.
+	+Running selftest unpack_field_as_long::arm::iwmmxt2.
+	+Running selftest unpack_field_as_long::arm::xscale.
+	+Running selftest unpack_field_as_long::bpf::xbpf.
+	+Running selftest unpack_field_as_long::frv::fr400.
+	+Running selftest unpack_field_as_long::frv::fr450.
+	+Running selftest unpack_field_as_long::frv::fr500.
+	+Running selftest unpack_field_as_long::frv::fr550.
+	+Running selftest unpack_field_as_long::frv::simple.
+	+Running selftest unpack_field_as_long::frv::tomcat.
+	+Running selftest unpack_field_as_long::iq2000::iq10.
+	+Running selftest unpack_field_as_long::m32c::m16c.
+	+Running selftest unpack_field_as_long::mep::c5.
+	+Running selftest unpack_field_as_long::mep::h1.
+	+Running selftest unpack_field_as_long::nds32::n1.
+	+Running selftest unpack_field_as_long::nds32::n1h.
+	+Running selftest unpack_field_as_long::nds32::n1h_v2.
+	+Running selftest unpack_field_as_long::nds32::n1h_v3.
+	+Running selftest unpack_field_as_long::nds32::n1h_v3m.
+	+Running selftest unpack_field_as_long::z80::ez80-adl.
+	+Running selftest unpack_field_as_long::z80::ez80-z80.
+	+Running selftest unpack_field_as_long::z80::gbz80.
+	+Running selftest unpack_field_as_long::z80::r800.
+	+Running selftest unpack_field_as_long::z80::z180.
+	...
+
+	Tested on x86_64-linux.
+
+2022-06-06  Tom de Vries  <tdevries@suse.de>
+
+	[gdb] Enable some more print_one_insn selftests
+	In print_one_insn_test we have this cluster of skipped tests:
+	...
+	    case bfd_arch_ia64:
+	    case bfd_arch_mep:
+	    case bfd_arch_mips:
+	    case bfd_arch_tic6x:
+	    case bfd_arch_xtensa:
+	      return;
+	...
+
+	Enable some of these, and document in more detail why they're enabled or
+	skipped.
+
+	Likewise, document bfd_arch_or1k because it's an odd case.
+
+	Tested on x86_64-linux.
+
+2022-06-06  Tom de Vries  <tdevries@suse.de>
+
+	[gdb] Fix maint selftest -v print_one_insn
+	When running the print_one_insn selftests with -v, I get:
+	...
+	$ gdb -q -batch -ex "maint selftest -v print_one_insn"
+	Running selftest print_one_insn::A6.
+	.shor   0x783eRunning selftest print_one_insn::A7.
+	trap_s  0x1Running selftest print_one_insn::ARC600.
+	.shor   0x783eRunning selftest print_one_insn::ARC601.
+	Running selftest print_one_insn::ARC700.
+	trap_s  0x1Running selftest print_one_insn::ARCv2.
+	trap_s  0x1Running selftest print_one_insn::EM.
+	trap_s  0x1Running selftest print_one_insn::HS.
+	trap_s  0x1Running selftest print_one_insn::Loongarch32.
+	...
+
+	The insn is written to gdb_stdout, and there is code in the selftest to add a
+	newline after the insn, which writes to stream().
+
+	The stream() ui_file points into a string buffer, which the disassembler uses
+	before writing to gdb_stdout, so writing into it after the disassembler has
+	finished has no effect.
+
+	Fix this by using gdb_stdlog and debug_printf (which is what the unit test
+	infrastructure itself uses) instead, such that we have:
+	...
+	Running selftest print_one_insn::A6.
+	.shor   0x783e
+	Running selftest print_one_insn::A7.
+	trap_s  0x1
+	Running selftest print_one_insn::ARC600.
+	.shor   0x783e
+	Running selftest print_one_insn::ARC601.
+	Running selftest print_one_insn::ARC700.
+	trap_s  0x1
+	Running selftest print_one_insn::ARCv2.
+	trap_s  0x1
+	Running selftest print_one_insn::Loongarch32.
+	...
+
+	Note: I've also removed the printing of arch_name, which would give
+	us otherwise the redundant:
+	...
+	Running selftest print_one_insn::A6.
+	arc .shor       0x783e
+	Running selftest print_one_insn::A7.
+	arc trap_s      0x1
+	...
+
+	Tested on x86_64-linux.
+
+2022-06-06  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: add missing skip_python_tests call in py-doc-reformat.exp
+	In commit:
+
+	  commit 51e8dbe1fbe7d8955589703140ca5eba7b4f1bd7
+	  Date:   Mon May 16 19:26:54 2022 +0100
+
+	      gdb/python: improve formatting of help text for user defined commands
+
+	the test that was added (gdb.python/py-doc-reformat.exp) was missing a
+	call to skip_python_tests.  As a result, this test would fail for any
+	GDB built within Python support.
+
+	This commit adds a call to skip_python_tests.
+
+2022-06-06  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-05  Tom Tromey  <tom@tromey.com>
+
+	Remove obsolete Python 2 comment
+	I found a comment that referred to Python 2, but that is now obsolete
+	-- the code it refers to is gone.  I'm checking in this patch to
+	remove the comment.
+
+	There's a similar comment elsewhere, but I plan to remove that one in
+	another patch I'm going to submit shortly.
+
+2022-06-05  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-04  Alan Modra  <amodra@gmail.com>
+
+	asan: null dereference in coff_count_linenumbers
+		* coffgen.c (coff_count_linenumbers): Don't segfault when asymbol
+		the_bfd is NULL.
+
+	asan: uninitialised write in bfd_mach_o_write_contents
+		* mach-o.c (bfd_mach_o_write_contents): Always set
+		bfd_mach_o_dyld_info_command *_off fields.
+
+2022-06-04  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/ada] Fix literal truncation
+	Make sure we error out on overflow instead of truncating in all cases.
+
+	Tested on x86_64-linux, with a build with --enable-targets=all.
+
+2022-06-04  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/m2] Fix UB and literal truncation
+	Rewrite parse_number to use ULONGEST instead of LONGEST, to fix UB errors as
+	mentioned in PR29163.
+
+	Furthermore, make sure we error out on overflow instead of truncating in all
+	cases.
+
+	Tested on x86_64-linux, with a build with --enable-targets=all.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29163
+
+2022-06-04  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/rust] Fix literal truncation
+	Make sure we error out on overflow instead of truncating in all cases.
+
+	I've used as overflow string: "Integer literal is too large", based
+	on what I found at
+	<rust-lang/rust>/src/test/ui/parser/int-literal-too-large-span.rs
+	but perhaps someone has a better idea.
+
+	Tested on x86_64-linux, with a build with --enable-targets=all.
+
+2022-06-04  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/pascal] Fix literal truncation
+	Make sure we error out on overflow instead of truncating in all cases.
+
+	The current implementation of parse_number contains a comment about PR16377,
+	but that's related to C-like languages.  In absence of information of whether
+	the same fix is needed for pascal, take the conservative approach and keep
+	behaviour for decimals unchanged.
+
+	Tested on x86_64-linux, with a build with --enable-targets=all.
+
+2022-06-04  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/go] Fix literal truncation
+	Make sure we error out on overflow instead of truncating in all cases.
+
+	The current implementation of parse_number contains a comment about PR16377,
+	but that's related to C-like languages.  In absence of information of whether
+	the same fix is needed for go, take the conservative approach and keep
+	behaviour for decimals unchanged.
+
+	Tested on x86_64-linux, with a build with --enable-targets=all.
+
+2022-06-04  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/fortran] Fix literal truncation
+	As mentioned in commit 5b758627a18 ("Make gdb.base/parse_number.exp test all
+	architectures"):
+	...
+	    There might be a bug that 32-bit fortran truncates 64-bit values to
+	    32-bit, given "p/x 0xffffffffffffffff" returns "0xffffffff".
+	...
+
+	More concretely, we have:
+	...
+	$ for arch in i386:x86-64 i386; do \
+	    gdb -q -batch -ex "set arch $arch" -ex "set lang fortran" \
+	      -ex "p /x 0xffffffffffffffff"; \
+	  done
+	The target architecture is set to "i386:x86-64".
+	$1 = 0xffffffffffffffff
+	The target architecture is set to "i386".
+	$1 = 0xffffffff
+	...
+
+	Fix this by adding a range check in parse_number in gdb/f-exp.y.
+
+	Furthermore, make sure we error out on overflow instead of truncating in all
+	other cases.
+
+	Tested on x86_64-linux.
+
+2022-06-04  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/c] Fix type of 2147483648 and literal truncation
+	[ Assuming arch i386:x86-64, sizeof (int) == 4,
+	sizeof (long) == sizeof (long long) == 8. ]
+
+	Currently we have (decimal for 0x80000000):
+	...
+	(gdb) ptype 2147483648
+	type = unsigned int
+	...
+
+	According to C language rules, unsigned types cannot be used for decimal
+	constants, so the type should be long instead (reported in PR16377).
+
+	Fix this by making sure the type of 2147483648 is long.
+
+	The next interesting case is (decimal for 0x8000000000000000):
+	...
+	(gdb) ptype 9223372036854775808
+	type = unsigned long
+	...
+
+	According to the same rules, unsigned long is incorrect.
+
+	Current gcc uses __int128 as type, which is allowed, but we don't have that
+	available in gdb, so the strict response here would be erroring out with
+	overflow.
+
+	Older gcc without __int128 support, as well as clang use an unsigned type, but with
+	a warning.  Interestingly, clang uses "unsigned long long" while gcc uses
+	"unsigned long", which seems the better choice.
+
+	Given that the compilers allow this as a convience, do the same in gdb
+	and keep type "unsigned long", and make this explicit in parser and test-case.
+
+	Furthermore, make sure we error out on overflow instead of truncating in all
+	cases.
+
+	Tested on x86_64-linux with --enable-targets=all.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16377
+
+2022-06-04  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Test more values in gdb.base/parse_numbers.exp
+	Currently we only test value 0xffffffffffffffff in test-case
+	gdb.base/parse_numbers.exp.
+
+	Test more interesting values, both in decimal and hex format, as well as
+	negative decimals for language modula-2.
+
+	This results in an increase in total tests from 15572 to 847448 (55 times
+	more tests).
+
+	Balance out the increase in runtime by reducing the number of architectures
+	tested: only test one architecture per sizeof longlong/long/int/short
+	combination, while keeping the possibility intact to run with all
+	architectures (through setting a variable in the test-case)
+
+	Results in slight reduction of total tests: 15572 -> 13853.
+
+	Document interesting cases in the expected results:
+	- wrapping from unsigned to signed
+	- truncation
+	- PR16377: using unsigned types to represent decimal constants in C
+
+	Running the test-case with a gdb build with -fsanitize=undefined, we trigger
+	two UB errors in the modula-2 parser, filed as PR29163.
+
+	Tested on x86_64-linux with --enable-targets=all.
+
+2022-06-04  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix ERROR in gdb.ctf/funcreturn.exp
+	On openSUSE Tumbleweed (with gcc-12, enabling ctf tests) I run into:
+	...
+	ERROR: tcl error sourcing src/gdb/testsuite/gdb.ctf/funcreturn.exp.
+	ERROR: tcl error code NONE
+	ERROR: Unexpected arguments: \
+	  {print v_double_func} \
+	  {[0-9]+ = {double \(\)} 0x[0-9a-z]+.*} \
+	  {print double function} \
+	  }
+	...
+
+	The problem is a curly brace as fourth argument to gdb_test, which errors out
+	due to recently introduced more strict argument checking in gdb_test.
+
+	Fix the error by removing the brace.
+
+	Though this fixes the error for me, due to PR29160 I get only FAILs, so I can't
+	claim proper testing on x86_64-linux.
+
+2022-06-04  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.threads/manythreads.exp with check-read1
+	When running test-case gdb.threads/manythreads.exp with check-read1, I ran
+	into this hard-to-reproduce FAIL:
+	...
+	[New Thread 0x7ffff7318700 (LWP 31125)]^M
+	[Thread 0x7ffff7321700 (LWP 31124) exited]^M
+	[New T^C^M
+	^M
+	Thread 769 "manythreads" received signal SIGINT, Interrupt.^M
+	[Switching to Thread 0x7ffff6d66700 (LWP 31287)]^M
+	0x00007ffff7586a81 in clone () from /lib64/libc.so.6^M
+	(gdb) FAIL: gdb.threads/manythreads.exp: stop threads 1
+	...
+
+	The matching in the failing gdb_test_multiple is done in an intricate way,
+	trying to pass on some order and fail on another order.
+
+	Fix this by rewriting the regexps to match one line at most, and detecting
+	invalid order by setting and checking state variables.
+
+	Tested on x86_64-linux.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29177
+
+2022-06-04  Tom de Vries  <tdevries@suse.de>
+
+	[gdb] Fix warning in print_one_insn::ez80-adl
+	When running selftest print_one_insn::ez80-adl we run into this warning:
+	...
+	Running selftest print_one_insn::ez80-adl.
+	warning: Unable to determine inferior's software breakpoint type: couldn't
+	  find `_break_handler' function in inferior. Will be used default software \
+	  breakpoint instruction RST 0x08.
+	...
+
+	Fix this by explicitly handling bfd_arch_z80 in print_one_insn_test.
+
+	Tested on x86_64-linux.
+
+2022-06-04  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-03  Tom Tromey  <tromey@adacore.com>
+
+	Use bool for evregpy_no_listeners_p
+	I noticed that evregpy_no_listeners_p should return a bool.  This
+	patch makes this change.  I'm checking it in.
+
+2022-06-03  Alan Modra  <amodra@gmail.com>
+
+	asan: heap buffer overflow in _bfd_mips_elf_section_from_shdr
+		* elfxx-mips.c (_bfd_mips_elf_section_from_shdr): Sanity check
+		intopt.size and remaining bytes in section for reginfo.
+
+2022-06-03  Alan Modra  <amodra@gmail.com>
+
+	Re: ubsan: undefined shift in frag_align_code
+	This one needs the same fix too.
+
+		* config/tc-i386.h (MAX_MEM_FOR_RS_ALIGN_CODE): Avoid signed
+		integer overflow.
+
+2022-06-03  Tom de Vries  <tdevries@suse.de>
+
+	[gdb] Fix warning in foreach_arch selftests
+	When running the selftests, I run into:
+	...
+	$ gdb -q -batch -ex "maint selftest"
+	  ...
+	Running selftest execute_cfa_program::aarch64:ilp32.
+	warning: A handler for the OS ABI "GNU/Linux" is not built into this
+	configuration of GDB.  Attempting to continue with the default aarch64:ilp32
+	settings.
+	...
+	and likewise for execute_cfa_program::i8086 and
+	execute_cfa_program::ia64-elf32.
+
+	The warning can easily be reproduced outside the selftests by doing:
+	...
+	$ gdb -q -batch -ex "set arch aarch64:ilp32"
+	...
+	and can be prevented by first doing "set osabi none".
+
+	Fix the warning by setting osabi to none while doing selftests that iterate
+	over all architectures.
+
+	This causes a regression in the print_one_insn selftests for the ARC
+	architecture.
+
+	The problem is pre-existing, and can be demonstrated (already without this
+	patch) using:
+	...
+	$ gdb -q -batch -ex "set osabi none" -ex "maint selftest print_one_insn::A6"
+	Running selftest print_one_insn::A6.
+	Self test failed: Cannot access memory at address 0x0
+	Ran 1 unit tests, 1 failed
+	$
+	...
+
+	For ARC, we use the generic case in print_one_insn_test, containing this code:
+	...
+	       int kind = gdbarch_breakpoint_kind_from_pc (gdbarch, &pc);
+	       ...
+	       insn = gdbarch_sw_breakpoint_from_kind (gdbarch, kind, &bplen);
+	...
+
+	The problem is that with osabi linux we trigger:
+	...
+	static int
+	arc_linux_breakpoint_kind_from_pc (struct gdbarch *gdbarch, CORE_ADDR *pcptr)
+	{
+	  return trap_size;
+	}
+	...
+	but with osabi none:
+	...
+	arc_breakpoint_kind_from_pc (struct gdbarch *gdbarch, CORE_ADDR *pcptr)
+	{
+	  size_t length_with_limm = gdb_insn_length (gdbarch, *pcptr);
+	...
+	which needs access to memory, and will consequently fail.
+
+	Fix this in print_one_insn_test, in the default case, by iterating over
+	supported osabi's to makes sure we trigger arc_linux_breakpoint_kind_from_pc
+	which will give us a usable instruction to disassemble.
+
+	Tested on x86_64-linux.
+
+2022-06-03  Tom de Vries  <tdevries@suse.de>
+
+	Revert "[gdb] Fix warning in foreach_arch selftests"
+	This reverts commit fc18b1c5afd ("[gdb] Fix warning in foreach_arch
+	selftests").
+
+	The commit introduced regressions for an --enable-targets=all build:
+	...
+	Running selftest print_one_insn::A6.^M
+	Self test failed: Cannot access memory at address 0x0^M
+	...
+	and while investigating those I realized that the commit fc18b1c5afd
+	complicates things by trying to set the current osabi.
+
+	So, revert the patch in preparation for a simpler solution.
+
+	Tested on x86_64-linux.
+
+2022-06-03  Jan Beulich  <jbeulich@suse.com>
+
+	x86: exclude certain ISA extensions from v3/v4 ISA
+	Like TBM and LWP, XOP and FMA4 also shouldn't be included in v3.
+
+	Like AVX512-4VNNIW, AVX512-4FMAPS also shouldn't be included in v4.
+
+2022-06-03  Roland McGrath  <mcgrathr@google.com>
+
+	gdb: LoongArch: Remove nonportable #include
+	Don't use gregset.h in *-tdep.c since it's not usable on
+	hosts that don't have <sys/procfs.h>.  It's not needed by
+	this file, and should only be needed by *-nat.c files.
+
+2022-06-03  Alan Modra  <amodra@gmail.com>
+
+	Re: asan: mips_gprel_reloc segfault
+	Similarly for the elf mips support.
+
+		* elf32-mips.c (mips_elf_final_gp): Don't segfault on symbols
+		in any of the bfd_is_const_section sections.
+		* elf64-mips.c (mips_elf64_final_gp): Likewise.
+		* elfn32-mips.c (mips_elf_final_gp): Likewise.
+
+2022-06-03  Alan Modra  <amodra@gmail.com>
+
+	asan: mips_gprel_reloc segfault
+	Not just the undefined section has a NULL owner, the absolute section
+	has too.  Which means we can't find output_bfd for __gp.  Also, may as
+	well test directly for output_bfd == NULL.
+
+		* coff-mips.c (mips_gprel_reloc): Don't segfault on any of
+		bfd_is_const_section sections.
+
+2022-06-03  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-02  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Detect change instead of init in gdb.mi/mi-var-block.exp
+	On openSUSE Tumbleweed with target board unix/-m32, I run into:
+	...
+	PASS: gdb.mi/mi-var-block.exp: step at do_block_test 2
+	Expecting: ^(-var-update \*[^M
+	]+)?(\^done,changelist=\[{name="foo",in_scope="true",type_changed="false",has_more="0"},
+	{name="cb",in_scope="true",type_changed="false",has_more="0"}\][^M
+	]+[(]gdb[)] ^M
+	[ ]*)
+	-var-update *^M
+	^done,changelist=[{name="foo",in_scope="true",type_changed="false",has_more="0"}]^M
+	(gdb) ^M
+	FAIL: gdb.mi/mi-var-block.exp: update all vars: cb foo changed (unexpected output)
+	...
+
+	The problem is that the test-case attempts to detect a change in the cb
+	variable caused by this initialization:
+	...
+	void
+	do_block_tests ()
+	{
+	  int cb = 12;
+	...
+	but that only works if the stack location happens to be unequal to 12 before
+	the initialization.
+
+	Fix this by first initializing to 0, and then changing the value to 12:
+	...
+	-  int cb = 12;
+	+  int cb = 0;
+	+  cb = 12;
+	...
+	and detecting that change.
+
+	Tested on x86_64-linux.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29195
+
+2022-06-02  Eli Zaretskii  <eliz@gnu.org>
+
+	Rearrange and slightly reword the "Location Specification" section
+	This rearranges and changes the wording of the "Location
+	Specification" section of the GDB manual in minor ways.
+
+2022-06-02  Tom Tromey  <tromey@adacore.com>
+
+	ODR warning for "main"
+	"main" is redeclared with a different type in maint.c.  I think this
+	might have come from my first gdb patch, many many years ago.  While I
+	wonder if this profiling code is actually useful at all any more, in
+	the meantime it's simple to fix the declaration.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02  Tom Tromey  <tromey@adacore.com>
+
+	ODR warnings for "struct coff_symbol"
+	"struct coff_symbol" is defined in multiple .c files, causing ODR
+	warnings.  This patch renames just the xcoffread.c type.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02  Tom Tromey  <tromey@adacore.com>
+
+	ODR warnings for "struct insn_decode_record_t"
+	"struct insn_decode_record_t" is defined in multiple .c files, causing
+	ODR warnings.  This patch renames the types, and removes the use of
+	"typedef" here -- this is a C-ism that's no longer needed.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02  Tom Tromey  <tromey@adacore.com>
+
+	ODR warnings for "struct insn_info"
+	"struct insn_info" is defined in multiple .c files, causing ODR
+	warnings.  This patch renames the type in z80-tdep.c, leaving the
+	other one alone.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02  Tom Tromey  <tromey@adacore.com>
+
+	ODR warnings from overlay constants
+	Some overlay-related constants are duplicated in z80-tdep.c, causing
+	ODR warnings.  This patch renames just the z80-specific ones.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02  Tom Tromey  <tromey@adacore.com>
+
+	ODR warning for "enum string_repr_result"
+	"enum string_repr_result" is defined in multiple .c files, causing ODR
+	warnings.  This patch renames the types.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02  Tom Tromey  <tromey@adacore.com>
+
+	ODR warning for "struct find_targ_sec_arg"
+	"struct find_targ_sec_arg" is defined in multiple .c files, causing
+	ODR warnings.  This patch renames the types.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02  Tom Tromey  <tromey@adacore.com>
+
+	ODR warning for "struct stack_item"
+	"struct stack_item" is defined in multiple .c files, causing ODR
+	warnings.  This patch renames these types.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02  Tom Tromey  <tromey@adacore.com>
+
+	ODR warning for "struct instruction_type"
+	"struct instruction_type" is defined in multiple .c files, causing an
+	ODR warning.  This patch renames the types.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02  Tom Tromey  <tromey@adacore.com>
+
+	ODR warning for struct ext_link_map
+	This renames the solib-dsbt.c copy of "struct ext_link_map" to avoid
+	an ODR warning.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02  Tom Tromey  <tromey@adacore.com>
+
+	ODR warning for struct field_info
+	This renames one of the instance of "struct field_info" to avoid an
+	ODR warning.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02  Tom Tromey  <tromey@adacore.com>
+
+	ODR warnings for struct nextfield
+	"struct nextfield" is defined in multiple places in GDB.  This patch
+	renames just the stabs one, leaving the DWARF one untouched.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02  Tom Tromey  <tromey@adacore.com>
+
+	ODR warnings for struct symloc
+	"struct symloc" is defined in multiple spots in gdb, causing ODR
+	warnings.  This patch renames these.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02  Tom Tromey  <tromey@adacore.com>
+
+	Fix ODR warning in observable.h
+	observable.h triggers an ODR warning because this line:
+
+	    extern observable<struct target_ops */* target */> target_changed;
+
+	... may be the only declaration of "struct target_ops" in scope
+	(depending on the particular .c file) -- and this declares it in a
+	namespace, resulting in confusion.
+
+	This patch fixes the problem by adding a forward declaration.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
+
+2022-06-02  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: LoongArch: Implement the software_single_step gdbarch method
+	When execute the following command on LoongArch:
+
+	  make check-gdb TESTS="gdb.base/branch-to-self.exp"
+
+	there exist the following failed testcases:
+
+	  FAIL: gdb.base/branch-to-self.exp: single-step: si (timeout)
+	  FAIL: gdb.base/branch-to-self.exp: break-cond: side=host: continue to breakpoint: continue to break (timeout)
+	  FAIL: gdb.base/branch-to-self.exp: break-cond: side=host: p counter (timeout)
+
+	Implement the software_single_step gdbarch method to decode the current
+	branch instruction and determine the address of the next instruction on
+	LoongArch to fix the above failed testcases.
+
+2022-06-02  Ilya Leoshkevich  <iii@linux.ibm.com>
+
+	gdb: Do not add empty sections to the section map
+	From: Ulrich Weigand <ulrich.weigand@de.ibm.com>
+
+	build_objfile_section_table () creates four synthetic sections per
+	objfile, which are collected by update_section_map () and passed to
+	std::sort ().  When there are a lot of objfiles, for example, when
+	debugging JITs, the presence of these sections slows down the sorting
+	significantly.
+
+	The output of update_section_map () is used by find_pc_section (),
+	which can never return any of these sections: their size is 0, so they
+	cannot be accepted by bsearch_cmp ().
+
+	Filter them (and all the other empty sections) out in
+	insert_section_p (), which is used only by update_section_map ().
+
+2022-06-02  Jon Turney  <jon.turney@dronecode.org.uk>
+
+	Fix a new warning on Cygwin
+	> ../../gdb/windows-nat.c: In function ‘windows_solib* windows_make_so(const char*, LPVOID)’:
+	> ../../gdb/windows-nat.c:714:12: error: declaration of ‘char name [512]’ shadows a parameter [-Werror=shadow=compatible-local]
+	>   714 |       char name[SO_NAME_MAX_PATH_SIZE];
+	>       |            ^~~~
+	> ../../gdb/windows-nat.c:655:30: note: shadowed declaration is here
+	>   655 | windows_make_so (const char *name, LPVOID load_addr)
+	>       |                  ~~~~~~~~~~~~^~~~
+
+	Fix Cygwin build after 85b25bd9
+	Fix Cygwin build after 85b25bd9 ("Simplify windows-nat.c solib handling").
+
+	Fix Cygwin build after 0578e87f
+	Fix Cygwin build after 0578e87f ("Remove some globals from
+	nat/windows-nat.c").  Update code under ifdef __CYGWIN__ for globals
+	moved to members of struct windows_process_info.
+
+	Fix Cygwin build after fcab5839
+	Fix Cygwin build after fcab5839 ("Implement pid_to_exec_file for Windows
+	in gdbserver"). That change moves code from gdb/windows-nat.c to
+	gdb/nat/windows-nat.c, but doesn't add the required typedefs and
+	includes for parts of that code under ifdef __CYGWIN__.
+
+2022-06-02  Alan Modra  <amodra@gmail.com>
+
+	Re: ubsan: signed integer overflow in atof_generic
+	Oops.
+
+		* atof-generic.c: Include limits.h.
+
+2022-06-02  Alan Modra  <amodra@gmail.com>
+
+	ubsan: signed integer overflow in atof_generic
+	Fix the signed overflows by using unsigned variables and detect
+	overflow at BUG! comment.
+
+		* atof-generic.c (atof_generic): Avoid signed integer overflow.
+		Return ERROR_EXPONENT_OVERFLOW if exponent overflows a long.
+
+2022-06-02  Alan Modra  <amodra@gmail.com>
+
+	asan: uninit write _bfd_ecoff_write_object_contents
+		* ecoff.c (_bfd_ecoff_write_object_contents): zalloc reloc_buff.
+
+	asan: null deref in coff_write_relocs
+		* coffcode.h (coff_write_relocs): Don't deref NULL howto.
+
+	ubsan: undefined shift in frag_align_code
+		* frags.c (MAX_MEM_FOR_RS_ALIGN_CODE): Avoid signed integer
+		overflow.
+
+2022-06-02  Alan Modra  <amodra@gmail.com>
+
+	gas read_a_source_file #APP processing
+	This fixes some horrible code using do_scrub_chars.  What we had ran
+	text through do_scrub_chars twice, directly in read_a_source_file and
+	again via the input_scrub_include_sb call.  That's silly, and since
+	do_scrub_chars is a state machine, possibly wrong.  More silliness is
+	evident in the temporary malloc'd buffer for do_scrub_chars output,
+	which should have been written directly to sbuf.
+
+	So, get rid of the do_scrub_chars call and support functions, leaving
+	scrubbing to input_scrub_include_sb.  I did wonder about #NO_APP
+	overlapping input_scrub_next_buffer buffers, but that should only
+	happen if the string starts in one file and finishes in another.
+
+		* read.c (scrub_string, scrub_string_end): Delete.
+		(scrub_from_string): Delete.
+		(read_a_source_file): Rewrite #APP processing.
+
+2022-06-02  Alan Modra  <amodra@gmail.com>
+
+	sb_scrub_and_add_sb not draining input string buffer
+	It is possible for sb_scrub_and_add_sb to not consume all of the input
+	string buffer.  If this happens for reasons explained in the comment,
+	do_scrub_chars can leave pointers to the string buffer for the next
+	call.  This patch fixes that by ensuring the input is drained.  Note
+	that the behaviour for an empty string buffer is also changed,
+	avoiding another do_scrub_chars bug where empty input and single char
+	sized output buffers could result in a write past the end of the
+	output.
+
+		sb.c (sb_scrub_and_add_sb): Loop until all of input sb is
+		consumed.
+
+2022-06-02  Alan Modra  <amodra@gmail.com>
+
+	asan: heap buffer overflow in dwarf2_directive_filename
+	Seen with .file 4294967289 "xxx.c"
+
+		* dwarf2dbg.c (assign_file_to_slot): Catch more cases of integer
+		overflow.  Make param i an unsigned int.
+
+2022-06-02  Alan Modra  <amodra@gmail.com>
+
+	asan: NULL deref in scan_unit_for_symbols
+	Since commit b43771b045 it has been possible to look up addresses
+	that match a unit with errors, since ranges are added to a trie while
+	the unit is being parsed.  On error, parse_comp_unit leaves
+	first_child_die_ptr NULL which results in a NULL info_ptr being passed
+	to scan_unit_for_symbols.  Fix this by setting unit->error.
+
+	Also wrap some overlong lines, and fix some formatting errors.
+
+		* dwarf2.c: Formatting.
+		(parse_comp_unit): Set unit->error on err_exit path.
+
+2022-06-02  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-01  Tom de Vries  <tdevries@suse.de>
+
+	[gdb] Fix warning in foreach_arch selftests
+	When running the selftests, I run into:
+	...
+	$ gdb -q -batch -ex "maint selftest"
+	  ...
+	Running selftest execute_cfa_program::aarch64:ilp32.
+	warning: A handler for the OS ABI "GNU/Linux" is not built into this
+	configuration of GDB.  Attempting to continue with the default aarch64:ilp32
+	settings.
+	...
+	and likewise for execute_cfa_program::i8086 and
+	execute_cfa_program::ia64-elf32.
+
+	The warning can easily be reproduced outside the selftests by doing:
+	...
+	$ gdb -q -batch -ex "set arch aarch64:ilp32"
+	...
+	and can be prevented by first doing "set osabi none".
+
+	Fix the warning by setting osabi to none while doing selftests that iterate
+	over all architectures.
+
+	Tested on x86_64-linux.
+
+2022-06-01  Tom Tromey  <tromey@adacore.com>
+
+	Add gdb.current_language and gdb.Frame.language
+	This adds the gdb.current_language function, which can be used to find
+	the current language without (1) ever having the value "auto" or (2)
+	having to parse the output of "show language".
+
+	It also adds the gdb.Frame.language, which can be used to find the
+	language of a given frame.  This is normally preferable if one has a
+	Frame object handy.
+
+2022-06-01  Yvan Roux  <yvan.roux@foss.st.com>
+
+	[arm] Don't use special treatment for PC
+	In an exception frame the PC register is extracted from the stack
+	just like other base registers, so there is no need for a special
+	treatment.
+
+	[arm] Add support for FPU registers in prologue unwinder
+	The prologue unwinder had support for FPU registers, but only to
+	calculate the correct offset on the stack, the values were not saved.
+
+2022-06-01  Yvan Roux  <yvan.roux@foss.st.com>
+
+	[arm] d0..d15 are 64-bit each, not 32-bit
+	When unwinding the stack, the floating point registers d0 to d15
+	need to be handled as double words, not words.
+
+	Only the first 8 registers have been confirmed fixed with this patch
+	on a STM32F407-DISC0 board, but the upper 8 registers on Cortex-M33
+	should be handled in the same way.
+
+	The test consisted of running a program compiled with float-abi=hard.
+	In the main function, a function taking a double as an argument was
+	called. After the function call, a hardware timer was used to
+	trigger an interrupt.
+
+	In the debug session, a breakpoint was set in the function called
+	from main to verify the content of the registers using "info float"
+	and another breakpoint in the interrupt handler was used to check
+	the same registers using "info float" on frame 2 (the frame just
+	before the dummy frame created for the signal handler in gdb).
+
+2022-06-01  Yvan Roux  <yvan.roux@foss.st.com>
+
+	[arm] Cleanup: use hex for offsets
+	Changed offset from decimal to hex to match architecture reference
+	manual terminology and keep coherency with the rest of the code.
+
+2022-06-01  Jiangshuai Li  <jiangshuai_li@c-sky.com>
+
+	gdb:csky save fpu and vdsp info to struct csky_gdbarch_tdep
+	First, add three variables fpu_abi, fpu_hardfp and vdsp_version
+	to csky_gdbarch_tdep. They will be initialized from info.abfd in
+	cskg_gdbarch_init.
+
+	Now, they are just used to find a candidate among the list of pre-declared
+	architectures
+
+	Later, they will be used in gdbarch_return_value and gdbarch_push_dummy_call
+	for funtions described below:
+	fpu_abi: to check if the bfd is using VAL_CSKY_FPU_ABI_HARD or
+	VAL_CSKY_FPU_ABI_SOFT
+	fpu_hardfp: to check if the bfd is using VAL_CSKY_FPU_HARDFP_SINGLE
+	or VAL_CSKY_FPU_HARDFP_DOUBLE
+	vdsp_version: to check if a function is returned with CSKY_VRET_REGNUM
+
+2022-06-01  Alan Modra  <amodra@gmail.com>
+
+	Re: use libiberty xmalloc in bfd/doc/chew.c
+	We can't use libiberty.a in chew.  libiberty is a host library, chew
+	a build program.  Partly revert commit 7273d78f3f7a, instead define
+	local versions of the libiberty functions.  ansidecl.h also isn't
+	needed.
+
+		* doc/chew.c: Don't include libiberty.h or ansidecl.h.
+		(xmalloc, xrealloc, xstrdup): New functions.
+		* doc/local.mk (LIBIBERTY): Don't define or use.
+		* Makefile.in: Regenerate.
+
+2022-06-01  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-06-01  H.J. Lu  <hjl.tools@gmail.com>
+
+	x86: Properly handle IFUNC function pointer reference
+	Update
+
+	commit 68c4956b1401de70173848a6bdf620cb42fa9358
+	Author: H.J. Lu <hjl.tools@gmail.com>
+	Date:   Tue Apr 26 09:08:54 2022 -0700
+
+	    x86: Properly handle function pointer reference
+
+	to properly handle IFUNC function pointer reference.  Since IFUNC symbol
+	value is only known at run-time, set pointer_equality_needed for IFUNC
+	function pointer reference in PDE so that it will be resolved to its PLT
+	entry directly.
+
+	bfd/
+
+		PR ld/29216
+		* elf32-i386.c (elf_i386_scan_relocs): Set pointer_equality_needed
+		for IFUNC function pointer reference in PDE.
+		* elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise.
+
+	ld/
+
+		PR ld/29216
+		* testsuite/ld-ifunc/ifunc.exp: Run PR ld/29216 test.
+		* testsuite/ld-ifunc/pr29216.c: New file.
+
+2022-05-31  H.J. Lu  <hjl.tools@gmail.com>
+
+	i386: Ajdust more tests for opcodes/i386: remove trailing whitespace
+	This fixes:
+
+	FAIL: Build ifunc-1a with -z ibtplt
+	FAIL: Build ifunc-1a with PIE -z ibtplt
+	FAIL: Build libno-plt-1b.so
+	FAIL: No PLT (dynamic 1a)
+	FAIL: No PLT (dynamic 1b)
+	FAIL: No PLT (dynamic 1c)
+	FAIL: No PLT (static 1d)
+	FAIL: No PLT (PIE 1e)
+	FAIL: No PLT (PIE 1f)
+	FAIL: No PLT (PIE 1g)
+	FAIL: No PLT (dynamic 1h)
+	FAIL: No PLT (dynamic 1i)
+	FAIL: No PLT (static 1j)
+
+		* ld-i386/libno-plt-1b.dd: Remove trailing whitespaces.
+		* ld-i386/no-plt-1a.dd: Likewise.
+		* ld-i386/no-plt-1b.dd: Likewise.
+		* ld-i386/no-plt-1c.dd: Likewise.
+		* ld-i386/no-plt-1d.dd: Likewise.
+		* ld-i386/no-plt-1e.dd: Likewise.
+		* ld-i386/no-plt-1f.dd: Likewise.
+		* ld-i386/no-plt-1g.dd: Likewise.
+		* ld-i386/no-plt-1h.dd: Likewise.
+		* ld-i386/no-plt-1i.dd: Likewise.
+		* ld-i386/no-plt-1j.dd: Likewise.
+		* ld-i386/plt-main-ibt.dd: Likewise.
+		* ld-i386/plt-pie-ibt.dd: Likewise.
+
+2022-05-31  Tom Tromey  <tom@tromey.com>
+
+	Use unique_ptr for objfiles
+	A while back, I changed objfiles to be held via a shared_ptr.  The
+	idea at the time was that this was a step toward writing to the index
+	cache in the background, and this would let gdb keep a reference alive
+	to do so.  However, since then we've rewritten the DWARF reader, and
+	the new index can do this without requiring a shared pointer -- in
+	fact there are patches pending to implement this.
+
+	This patch switches objfile management to unique_ptr, which makes more
+	sense now.
+
+	Regression tested on x86-64 Fedora 34.
+
+2022-05-31  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	gdb/testsuite: fixup common-block.exp for intel compilers
+	The order in which the variables in info common and info locals are
+	displayed is compiler (and dwarf) dependent.  While all symbols should
+	be displayed the order is not fixed.
+
+	I added a gdb_test_multiple that lets ifx and ifort pass in cases where
+	only the order differs.
+
+2022-05-31  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	gdb, testsuite, fortran: fixup mixed-lang-stack for Intel/LLVM compilers
+	When value-printing a pointer within GDB by default GDB will look for
+	defined symbols residing at the address of the pointer.  For the given
+	test the Intel/LLVM compiler stacks both display a symbol associated
+	with a printed pointer while the gnu stack does not.  This leads to
+	failures in the test when running the test with CC_FOR_TARGET='clang'
+	CXX_FOR_TARGET='clang' F90_FOR_TARGET='flang'"
+
+	  (gdb) b 37
+	  (gdb) r
+	  (gdb) f 6
+	  (gdb) info args
+	  a = 1
+	  b = 2
+	  c = 3
+	  d = 4 + 5i
+	  f = 0x419ed0 "abcdef"
+	  g = 0x4041a0 <.BSS4>
+
+	or CC_FOR_TARGET='icx' CXX_FOR_TARGET='icpx' F90_FOR_TARGET='ifx'"
+
+	  (gdb) b 37
+	  (gdb) r
+	  (gdb) f 6
+	  (gdb) info args
+	  a = 1
+	  b = 2
+	  c = 3
+	  d = 4 + 5i
+	  f = 0x52eee0 "abcdef"
+	  g = 0x4ca210 <mixed_func_1a_$OBJ>
+
+	For the compiled binary the Intel/LLVM compilers both decide to move the
+	local variable g into the .bss section of their executable.  The gnu
+	stack will keep the variable locally on the stack and not define a
+	symbol for it.
+
+	Since the behavior for Intel/LLVM is actually expected I adapted the
+	testcase at this point to be a bit more allowing for other outputs.
+	I added the optional "<SYMBOLNAME>" to the regex testing for g.
+
+	The given changes reduce the test fails for Intel/LLVM stack by 4 each.
+
+2022-05-31  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	gdb, testsuite, fortran: fix double free in mixed-lang-stack.exp
+	While testing mixed-lang-stack I realized that valgrind actually
+	complained about a double free in the test.
+
+	   All done
+	  ==2503051==
+	  ==2503051== HEAP SUMMARY:
+	  ==2503051==     in use at exit: 0 bytes in 0 blocks
+	  ==2503051==   total heap usage: 26 allocs, 27 frees, 87,343 bytes allocated
+	  ==2503051==
+	  ==2503051== All heap blocks were freed -- no leaks are possible
+	  ==2503051==
+	  ==2503051== For lists of detected and suppressed errors, rerun with: -s
+	  ==2503051== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
+
+	Reason for this is that in mixed-lang-stack.cpp in mixed_func_1f an
+	object "derived_type obj" goes on the stack which is then passed-by-value
+	(so copied) to mixed_func_1g.  The default copy-ctor will be called but,
+	since derived_type contains a heap allocated string and the copy
+	constructor is not implemented it will only be able to shallow copy the
+	object.  Right after each of the functions the object gets freed - on the
+	other hand the d'tor of derived_type actually is implemented and calls
+	free on the heap allocated string which leads to a double free.  Instead
+	of obeying the rule of 3/5 I just got rid of all that since it does not
+	serve the test.  The string is now just a const char* = ".." object
+	member.
+
+2022-05-31  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	testsuite, fortran: allow additional completions in module.exp
+	For ifort, ifx, and flang the tests "complete modm" and "complete
+	modmany" fail.  This is because all three emit additional completion
+	suggestions.  These additional suggestions have their origin in symbols
+	emitted by the compilers which can also be completed from the respective
+	incomplete word (modm or modmany).  For this specific example gfortran
+	does not emit any additional symbols.
+
+	For example, in this test the linkage name for var_a in ifx is
+	"modmany_mp_var_a_" while gfortran uses "__modmany_MOD_var_a" instead.
+	Since modmany_mp_var_a can be completed from modm and also modmany they
+	will get displayed, while gfortran's symbol starts with "__" and thus will
+	be ignored (it cannot be a completion of a word starting with "m").
+
+	Similar things happen in flang and ifort.  Some example output is shown
+	below:
+
+	FLANG
+	  (gdb) complete p modm
+	  p modmany
+	  p modmany::var_a
+	  p modmany::var_b
+	  p modmany::var_c
+	  p modmany::var_i
+	  p modmany_
+
+	IFX/IFORT
+	  (gdb) complete p modm
+	  p modmany
+	  p modmany._
+	  p modmany::var_a
+	  p modmany::var_b
+	  p modmany::var_c
+	  p modmany::var_i
+	  p modmany_mp_var_a_
+	  p modmany_mp_var_b_
+	  p modmany_mp_var_c_
+	  p modmany_mp_var_i_
+
+	GFORTRAN
+	  (gdb) complete p modm
+	  p modmany
+	  p modmany::var_a
+	  p modmany::var_b
+	  p modmany::var_c
+	  p modmany::var_i
+
+	I want to emphasize: for Fortran (and also C/C++) the complete command
+	does not actually check whether its suggestions make sense - all it does
+	is look for any symbol (in the minimal symbols, partial symbols etc.)
+	that a given substring can be completed to (meaning that the given substring
+	is the beginning of the symbol).  One can easily produce a similar
+	output for the gfortran compiled executable.  For this look at the
+	slightly modified "complete p mod" in gfortran:
+
+	  (gdb) complete p mod
+	  p mod1
+	  p mod1::var_const
+	  ...
+	  p mod_1.c
+	  p modcounter
+	  p mode_t
+	  p modf
+	  ...
+	  p modify_ldt
+	  p modmany
+	  p modmany::var_a
+	  p modmany::var_b
+	  p modmany::var_c
+	  p modmany::var_i
+	  p module
+	  p module.f90
+	  p module_entry
+	  p moduse
+	  p moduse::var_x
+	  p moduse::var_y
+
+	Many of the displayed symbols do not actually work with print:
+
+	  (gdb) p mode_t
+	  Attempt to use a type name as an expression
+	  (gdb) p mod_1.c
+	  No symbol "mod_1" in current context.
+	  (gdb)
+
+	I think that in the given test the output for gfortran only looks nice
+	"by chance" rather than is actually expected.  Expected is any output
+	that also contains the completions
+
+	  p modmany
+
+	  p modmany::var_a
+	  p modmany::var_b
+	  p modmany::var_c
+	  p modmany::var_i
+
+	while anythings else can be displayed as well (depending on the
+	compiler and its emitted symbols).
+
+	This, I'd consider all three outputs as valid and expected - one is just
+	somewhat lucky that gfortran does not produce any additional symbols that
+	got matched.
+
+	The given patch improves test performance for all three compilers
+	by allowing additional suggested completions inbetween and after
+	the two given blocks in the test.  I did not allow additional print
+	within the modmany_list block since the output is ordered alphabetically
+	and there should normally not appear any additional symbols there.
+
+	For flang/ifx/ifort I each see 2 failures less (which are exactly the two
+	complete tests).
+
+	As a side note and since I mentioned C++ in the beginning: I also tried
+	the gdb.cp/completion.exp.  The output seems a bit more reasonable,
+	mainly since C++ actually has a demangler in place and linkage symbols
+	do not appear in the output of complete.  Still, with a poor enough
+	to-be-completed string one can easily produce similar results:
+
+	  (gdb) complete p t
+	  ...
+	  p typeinfo name for void
+	  p typeinfo name for void const*
+	  p typeinfo name for void*
+	  p typeinfo name for wchar_t
+	  p typeinfo name for wchar_t const*
+	  p typeinfo name for wchar_t*
+	  p t *** List may be truncated, max-completions reached. ***
+	  (gdb) p typeinfo name for void*
+	  No symbol "typeinfo" in current context.
+	  (gdb) complete p B
+	  p BACK_SLASH
+	  p BUF_FIRST
+	  p BUF_LAST
+	  ...
+	  p Base
+	  p Base::Base()
+	  p Base::get_foo()
+	  p bad_key_err
+	  p buf
+	  p buffer
+	  p buffer_size
+	  p buflen
+	  p bufsize
+	  p build_charclass.isra
+	  (gdb) p bad_key_err
+	  No symbol "bad_key_err" in current context.
+
+	(compiled with gcc/g++ and breaking at main).
+
+	This patch is only about making the referenced test more 'fair' for the
+	other compilers.  Generally, I find the behavior of complete a bit
+	confusing and maybe one wants to change this at some point but this
+	would be a bigger task.
+
+2022-05-31  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	testsuite, fortran: fix info-types for intel compilers
+	This info-types.exp test case had a few issues that this patch fixes.
+
+	First, the emitted symbol character(kind=1)/character*1 (different
+	compilers use different naming converntions here) which is checkedin the
+	test is not actually expected given the test program.  There is no
+	variable of that type in the test.  Still, gfortran emits it for every
+	Fortran program there is.  The reason is the way gfortran handles Fortran's
+	named main program.  It generates a wrapper around the Fortran program
+	that is quite similar to a C main function.  This C-like wrapper has
+	argc and argv arguments for command line argument passing and the argv
+	pointer type has a base type character(kind=1) DIE emitted at CU scope.
+
+	Given the program
+
+	  program prog
+	  end program prog
+
+	the degbug info gfortran emits looks somewhat like
+
+	   <0><c>: Abbrev Number: 3 (DW_TAG_compile_unit)
+	      ...
+	   <1><2f>: Abbrev Number: 4 (DW_TAG_subprogram)
+	      <30>   DW_AT_external    : 1
+	      <30>   DW_AT_name        : (indirect string, ...): main
+	      ...
+	   <2><51>: Abbrev Number: 1 (DW_TAG_formal_parameter)
+	      <52>   DW_AT_name        : (indirect string, ...): argc
+	      ...
+	   <2><5d>: Abbrev Number: 1 (DW_TAG_formal_parameter)
+	      <5e>   DW_AT_name        : (indirect string, ...): argv
+	      ...
+	      <62>   DW_AT_type        : <0x77>
+	      ...
+	   <2><6a>: Abbrev Number: 0
+	   ...
+	   <1><77>: Abbrev Number: 6 (DW_TAG_pointer_type)
+	      <78>   DW_AT_byte_size   : 8
+	      <79>   DW_AT_type        : <0x7d>
+	   <1><7d>: Abbrev Number: 2 (DW_TAG_base_type)
+	      <7e>   DW_AT_byte_size   : 1
+	      <7f>   DW_AT_encoding    : 8        (unsigned char)
+	      <80>   DW_AT_name        : (indirect string, ...): character(kind=1)
+	   <1><84>: Abbrev Number: 7 (DW_TAG_subprogram)
+	      <85>   DW_AT_name        : (indirect string, ...): prog
+	   ...
+
+	Ifx and flang do not emit any debug info for a wrapper main method so
+	the type is missing here.  There was the possibility of actually adding
+	a character*1 type variable to the Fortran executable, but both, ifx and
+	gfortran chose to emit this variable's type as a DW_TAG_string_type of
+	length one (instead of a character(kind=1), or whatever the respective
+	compiler naming convention is).  While string types are printed as
+	character*LENGHT in the fortran language part (e.g. when issuing a
+	'ptype') they do not generate any symbols inside GDB.  In read.c it says
+
+	   /* These dies have a type, but processing them does not create
+	      a symbol or recurse to process the children.  Therefore we can
+	      read them on-demand through read_type_die.  */
+
+	So they did not add any output to 'info types'.  Only flang did emit a
+	character type here.
+	As adding a type would have a) not solved the problem for ifx and would
+	have b) somehow hidden the curious behavior of gfortran, instead, the
+	check for this character type was chagened to optional with the
+	check_optional_entry to allow for the symbols's absence and to allow
+	flang and ifx to pass this test as well.
+
+	Second, the line checked for s1 was hardcoded as 37 in the test.  Given
+	that the type is actually defined on line 41 (which is what is emitted by
+	ifx) it even seems wrong.  The line check for s1 was changed to actually
+	check for 41 and a gfortran bug has been filed here
+
+	   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105454
+
+	The test is now marked as xfail for gfortran.
+
+	Third, the whole test of checking for the 'Type s1' in info types seemed
+	questionable.  The type s1 is declared iside the scope of the Fortran
+	program info_types_test.  Its DIE however is emitted as a child of the
+	whole compilation unit making it visible outside of the program's scope.
+	The 'info types' command checks for types stored in the GLOBAL_BLOCK,
+	or STATIC_BLOCKm wgucm according to block.h
+
+	   The GLOBAL_BLOCK contains all the symbols defined in this compilation
+	   whose scope is the entire program linked together.
+	   The STATIC_BLOCK contains all the symbols whose scope is the
+	   entire compilation excluding other separate compilations.
+
+	so for gfortran, the type shows up in the output of 'info types'.  For
+	flang and ifx on the other hand this is not the case.  The two compilers
+	emit the type (correctly) as a child of the Fortran program, thus not
+	adding it to either, the GLOBAL_BLOCK nor the LOCAL_BLOCK.  A bug has
+	been opened for the gfortran scoping issue:
+
+	   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105454
+
+	While the most correct change might have been removing the check for s1,
+	the change made here was to only check for this type in case of gfortran
+	being used as the compiler, as this check also covers the declaration
+	line issue mentioned above.  A comment was added to maybe remove this
+	check once the scoping issue is resolved (and it starts to fail with
+	newer gfortran versions).  The one used to test these changes was 13.0.
+
+2022-05-31  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	testsuite/lib: add check_optional_entry for GDBInfoSymbols
+	There was already a similar functionality for the GDBInfoModuleSymbols.
+	This just extends the GDBInfoSymbols.  We will use this feature in a
+	later commit to make a testcase less GNU specific and more flexible for
+	other compilers.
+
+	Namely, in gdb.fortran/info-types.exp currenlty
+	GDBInfoSymbols::check_entry is used to verify and test the output of the
+	info symbols command.  The test, however was written with gfortran as a
+	basis and some of the tests are not fair with e.g. ifx and ifort as
+	they test for symbols that are not actually required to be emitted.  The
+	lines
+	   GDBInfoSymbols::check_entry "${srcfile}" "" "${character1}"
+	and
+	   GDBInfoSymbols::check_entry "${srcfile}" "37" "Type s1;"
+
+	check for types that are either not used in the source file (character1)
+	or should not be emitted by the compiler at global scope (s1) thus no
+	appearing in the info symbols command.  In order to fix this we will
+	later use the newly introduced check_optional_entry over check_entry.
+
+2022-05-31  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	testsuite, fortran: Add '-debug-parameters all' when using ifx/ifort
+	In order for ifx and ifort to emit all debug entries, even for unused
+	parameters in modules we have to define the '-debug-parameters all' flag.
+
+	This commit adds it to the ifx-*/ifort-* specific flags in gdb.exp.
+
+2022-05-31  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	testsuite, fortran: add compiler dependent types to dynamic-ptype-whatis
+	The test was earlier not using the compiler dependent type print system
+	in fortran.exp.  I changed this.  It should generally improve the test
+	performance for different compilers.  For ifx and gfortran I do not see
+	any failures.
+
+2022-05-31  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	testsuite, fortran: add required external keyword
+	Currenlty, ifx/ifort cannot compile the given executable as it is not
+	valid Fortran.  It is missing the external keyword on the
+	no_arg_subroutine.  Gfortran compiles the example but this is actually
+	a bug and there is an open gcc ticket for this here:
+
+	   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50377
+
+	Adding the keyword does not change the gfortran compiling of the example.
+	It will, however, prevent a future fail once 50377 has been addressed.
+
+2022-05-31  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	gdb/testsuite: disable charset.exp for intel compilers
+	The test specifically tests for the Fortran CHARACTER(KIND=4) which is
+	not available in ifx/ifort.
+
+	Since the other characters are also printed elsewhere, we disable this
+	test for the unsupported compilers.
+
+2022-05-31  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	gdb/testsuite: rename intel next gen c/cpp compilers
+	The name for icx and icpx in the testsuite was earlier set to 'intel-*'
+	by the compiler identification.  This commit changes this to 'icx-*'.
+
+	Note, that currently these names are not used within the testsuite so no
+	tests have to be adapted here.
+
+2022-05-31  Cristian Sandu  <cristian.sandu@intel.com>
+	    Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	gdb/testsuite: add Fortran compiler identification to GDB
+	This commit adds a separate Fortran compiler identification mechanism to
+	the testsuite, similar to the existing one for C/C++.  Before this
+	change, the options and version for the Fortran compiler specified when
+	running the testsuite with F90_FOR_TARGET set, was detected via its
+	respective C compiler.  So running the testsuite as
+
+	  make check TEST=gdb.fortran/*.exp CC_FOR_TARGET=gcc F90_FOR_TARGET=ifx
+
+	or even
+
+	  make check TEST=gdb.fortran/*.exp F90_FOR_TARGET=ifx
+
+	would use the gcc compiler inside the procedures get_compiler_info and
+	test_compiler_info to identify compiler flags and the compiler version.
+	This could sometimes lead to unpredictable outputs.  It also limited
+	testsuite execution to combinations where C and Fortran compiler would
+	come from the same family of compiers (gcc/gfortran, icc/ifort, icx/ifx,
+	clang/flang ..).  This commit enables GDB to detect C and Fortran
+	compilers independently of each other.
+
+	As most/nearly all Fortran compilers have a mechanism for preprocessing
+	files in a C like fashion we added the exact same meachnism that already
+	existed for C/CXX.  We let GDB preprocess a file with the compilers
+	Fortran preprocessor and evaluate the preprocessor defined macros in that
+	file.
+
+	This enables GDB to properly run heterogeneous combinations of C and
+	Fortran compilers such as
+
+	  CC_FOR_TARGET='gcc' and F90_FOR_TARGET='ifort'
+
+	or enables one to run the testsuite without specifying a C compiler as in
+
+	  make check TESTS=gdb.fortran/*.exp F90_FOR_TARGET='ifx'
+	  make check TESTS=gdb.fortran/*.exp F90_FOR_TARGET='flang'
+
+	On the other hand this also requires one to always specify a
+	identification mechanism for Fortran compilers in the compiler.F90 file.
+
+	We added identification for GFORTRAN, FLANG (CLASSIC and LLVM) IFX,
+	IFORT, and ARMFLANG for now.
+
+	Classic and LLVM flang were each tested with their latest releases on
+	their respective release pages.  Both get recognized by the new compiler
+	identification and we introduced the two names flang-classic and
+	flang-llvm to distinguish the two.  While LLVM flang is not quite mature
+	enough yet for running the testsuite we still thought it would be a good
+	idea to include it already.  For this we added a case for the fortran_main
+	procedure.  LLVM flang uses 'MAIN__' as opposed to classic flang which
+	uses 'MAIN_' here.
+
+	We did not have the possibility to test ARMFLANG - the versioning scheme
+	here was extracted from its latest online documentation.
+
+	We changed the test_compiler_info procedure to take another optional
+	argument, the language string, which will be passed though to the
+	get_compiler_info procedure.  Passing 'f90' or 'c++' here will then
+	trigger the C++/Fortran compiler identification within
+	get_compiler_info.  The latter procedure was extended to also handle
+	the 'f90' argument (similarly to the already existing 'c++' one).
+
+2022-05-31  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	gdb/testsuite: move getting_compiler_info to front of gdb_compile
+	The procedure gdb_compile queries its options via
+
+	   [lsearch -exact $options getting_compiler_info]
+
+	to check whether or not it was called in with the option
+	getting_compiler_info.  If it was called with this option it would
+	preprocess some test input to try and figure out the actual compiler
+	version of the compiler used.  While doing this we cannot again try to
+	figure out the current compiler version via the 'getting_compiler_info'
+	option as this would cause infinite recursion.  As some parts of the
+	procedure do recursively test for the compiler version to e.g. set
+	certain flags, at several places gdb_compile there are checks for the
+	getting_compiler_info option needed.
+
+	In the procedure, there was already a variable 'getting_compiler_info'
+	which was set to the result of the 'lsearch' query and used instead of
+	again and again looking for getting_compiler_info in the procedure
+	options.  But, this variable was actually set too late within the code.
+	This lead to a mixture of querying 'getting_compiler_info' or
+	doing an lserach on the options passed to the procedure.
+
+	I found this inconsistent and instead moved the variable
+	getting_compiler_info to the front of the procedure.  It is set to true
+	or false depending on whether or not the argument is found in the
+	procedure's options (just as before) and queried instead of doing an
+	lsearch on the procedure options in the rest of the procedure.
+
+2022-05-31  Felix Willgerodt  <felix.willgerodt@intel.com>
+	    Abdul Basit Ijaz  <abdul.b.ijaz@intel.com>
+	    Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	gdb/testsuite: Fix fortran types for Intel compilers.
+	Newer Intel compilers emit their dwarf type name in a slightly different
+	format.  Therefore, this needs adjustment to make more tests pass in the
+	Fortran testsuite.
+
+2022-05-31  Abdul Basit Ijaz  <abdul.b.ijaz@intel.com>
+
+	gdb/testsuite: Use -module option for Intel Fortran compilers
+	The '-J' option is not supported in Intel compilers (ifx and ifort).
+	The Intel version of the flag is '-module' which serves the same purpose.
+
+2022-05-31  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	gdb/testsuite: remove F77_FOR_TARGET support
+	The last uses of the F77_FOR_TARGET via passing f77 to GDB's compile
+	procedure were removed in this commit
+
+	   commit 0ecee54cfd04a60e7ca61ae07c72b20e21390257
+	   Author: Tom Tromey <tromey@redhat.com>
+	   Date:   Wed Jun 29 17:50:47 2011 +0000
+
+	over 10 years ago.  The last .f files in the testsuite by now are all
+	being compiled by passing 'f90' to the GDB compile, thus only actually
+	using F90_FOR_TARGET (array-element.f, block-data.f, subarray.f).
+	Gfortran in this case is backwards compatible with most f77 code as
+	claimed on gcc.gnu.org/fortran.
+
+	The reason we'd like to get rid of this now is, that we'll be
+	implementing a Fortran compiler identification mechanism, similar to the
+	C/Cpp existing ones.  It would be using the Fortran preprocessor macro
+	defines to identify the Fortran compiler version at hand.  We found it
+	inconsequent to only implement this for f90 but, on the other hand, f77
+	seems deprecated.  So, with this commit we remove the remaining lines for
+	its support.
+
+2022-05-31  Pedro Alves  <pedro@palves.net>
+
+	Improve clear command's documentation
+	Co-Authored-By: Eli Zaretskii <eliz@gnu.org>
+
+	Change-Id: I9440052fd28f795d6f7c93a4576beadd21f28885
+
+2022-05-31  Pedro Alves  <pedro@palves.net>
+
+	Clarify why we unit test matching symbol names with 0xff characters
+	In the name matching unit tests in gdb/dwarf2/read.c, explain better
+	why we test symbols with \377 / 0xff characters (Latin1 'ÿ').
+
+	Change-Id: I517f13adfff2e4d3cd783fec1d744e2b26e18b8e
+
+2022-05-31  Pedro Alves  <pedro@palves.net>
+
+	Improve break-range's documentation
+	Change-Id: Iac26e1d2e7d8dc8a7d9516e6bdcc5c3fc4af45c8
+
+	Explicitly mention yet-unloaded shared libraries in location spec examples
+	Change-Id: I05639ddb3bf620c7297b57ed286adc3aa926b7b6
+
+2022-05-31  Alan Modra  <amodra@gmail.com>
+
+	sparc64 segfault in finish_dynamic_symbol
+	SYMBOL_REFERENCES_LOCAL can return true for undefined symbols.  This
+	can result in a segfault when running sparc64 ld/testsuite/ld-vsb
+	tests that expect a failure.
+
+		* elfxx-sparc.c (_bfd_sparc_elf_finish_dynamic_symbol): Don't
+		access u.def.section on non-default visibility undefined symbol.
+
+2022-05-31  Alan Modra  <amodra@gmail.com>
+
+	ia64 gas: Remove unnecessary init
+	The whole struct is cleared by alloc_record.
+
+		* config/tc-ia64.c (output_prologue, output_prologue_gr): Don't
+		zero r.record.r.mask.
+
+2022-05-31  Alan Modra  <amodra@gmail.com>
+
+	v850_elf_set_note prototype
+	v850_elf_set_note is declared using an unsigned int note param in
+	elf32-v850.h but defined with enum c850_notes note in elf32-v850.c.
+	Current mainline gcc is warning about this.  Huh.
+
+		* elf32-v850.c (v850_elf_set_note): Make "note" param an
+		unsigned int.
+
+2022-05-31  Alan Modra  <amodra@gmail.com>
+
+	Import libiberty from gcc
+		PR 29200
+	include/
+		* ansidecl.h,
+		* demangle.h: Import from gcc.
+	libiberty/
+		* cp-demangle.c,
+		* testsuite/demangle-expected: Import from gcc.
+
+2022-05-31  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: resolve duplicate test name in gdb.trace/signal.exp
+	Spotted a duplicate test name in gdb.trace/signal.exp, resolved in
+	this commit by making use of 'with_test_prefix'.
+
+2022-05-31  Alan Modra  <amodra@gmail.com>
+
+	Ajdust more tests for opcodes/i386: remove trailing whitespace
+	git commit 202be274a4 also missed adjusting a few testsuite files.
+	This fixes
+	i686-vxworks  +FAIL: VxWorks shared library test 1
+	i686-vxworks  +FAIL: VxWorks executable test 1 (dynamic)
+
+2022-05-31  Alan Modra  <amodra@gmail.com>
+
+	Trailing spaces in objdump -r header
+	git commit 202be274a4 went a little wild in removing trailing spaces
+	in gas/testsuite/gas/i386/{secidx.d,secrel.d}, causing
+	x86_64-w64-mingw32  +FAIL: i386 secrel reloc
+	x86_64-w64-mingw32  +FAIL: i386 secidx reloc
+
+	I could have just replaced the trailing space, but let's fix the
+	objdump output instead.  Touches lots of testsuite files.
+
+2022-05-31  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-30  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb/testsuite: fix gdb.trace/signal.exp on x86
+	Patch
+
+	  202be274a41a ("opcodes/i386: remove trailing whitespace from insns with zero operands")
+
+	causes this regression:
+
+	  FAIL: gdb.trace/signal.exp: find syscall insn in kill
+
+	It's because the test still expects to match a whitespace after the
+	instruction, which the patch mentioned above removed.  Remove the
+	whitespaces for the regexp.
+
+	Change-Id: Ie194273cc942bfd91332d4035f6eec55b7d3a428
+
+2022-05-30  Pedro Alves  <pedro@palves.net>
+
+	gdb/manual: Introduce location specs
+	The current "Specify Location" section of the GDB manual starts with:
+
+	 "Several @value{GDBN} commands accept arguments that specify a location
+	 of your program's code."
+
+	And then, such commands are documented as taking a "location"
+	argument.  For example, here's a representative subset:
+
+	 @item break @var{location}
+	 @item clear @var{location}
+	 @item until @var{location}
+	 @item list @var{location}
+	 @item edit @var{location}
+	 @itemx info line @var{location}
+	 @item info macros @var{location}
+	 @item trace @var{location}
+	 @item info scope @var{location}
+	 @item maint agent @r{[}-at @var{location}@r{,}@r{]} @var{expression}
+
+	The issue here is that "location" isn't really correct for most of
+	these commands.  Instead, the "location" argument is really a
+	placeholder that represent an umbrella term for all of the
+	"linespecs", "explicit location", and "address location" input
+	formats.  GDB parses these and then finds the actual code locations
+	(plural) in the program that match.  For example, a "location"
+	specified like "-function func" will actually match all the code
+	locations in the program that correspond to the address/file/lineno of
+	all the functions named "func" in all the loaded programs and shared
+	libraries of all the inferiors.  A location specified like "-function
+	func -label lab" matches all the addresses of C labels named "lab" in
+	all functions named "func".  Etc.
+
+	This means that several of the commands that claim they accept a
+	"location", actually end up working with multiple locations, and the
+	manual doesn't explain that all that well.  In some cases, the command
+	will work with all the resolved locations.  In other cases, the
+	command aborts with an error if the location specification resolves to
+	multiple locations in the program.  In other cases, GDB just
+	arbitrarily and silently picks whatever is the first resolved code
+	location (which sounds like should be improved).
+
+	To clarify this, I propose we use the term "Location Specification",
+	with shorthand "locaction spec", when we're talking about the user
+	input, the argument or arguments that is/are passed to commands to
+	instruct GDB how to find locations of interest.  This is distinct from
+	the actual code locations in the program, which are what GDB finds
+	based on the user-specified location spec.  Then use "location
+	specification or the shorter "location spec" thoughout instead of
+	"location" when we're talking about the user input.
+
+	Thus, this commit does the following:
+
+	- renames the "Specify Location" section of the manual to "Location
+	  Specifications".
+
+	- It then introduces the term "Location Specification", with
+	  corresponding shorthand "location spec", as something distinct from
+	  an actual code location in the program.  It explains what a concrete
+	  code location is.  It explains that a location specification may be
+	  incomplete, and that may match multiple code locations in the
+	  program, or no code location at all.  It gives examples.  Some
+	  pre-existing examples were moved from the "Set Breaks" section, and
+	  a few new ones that didn't exist yet were added.  I think it is
+	  better to have these centralized in this "Location Specification"
+	  section, since all the other commands that accept a location spec
+	  have an xref that points there.
+
+	- Goes through the manual, and where "@var{location}" was used for a
+	  command argument, updated it to say "@var{locspec}" instead.  At the
+	  same time, tweaks the description of the affected commands to
+	  describe what happens when the location spec resolves to more than
+	  one location.  Most commands just did not say anything about that.
+
+	  One command -- "maint agent -at @var{location}" -- currently says it
+	  accepts a "location", suggesting it can accept address and explicit
+	  locations too, but that's incorrect.  In reality, it only accepts
+	  linespecs, so fix it accordingly.
+
+	  One MI command -- "-trace-find line" -- currently says it accepts a
+	  "line specification", but it can accept address and explicit
+	  locations too, so fix it accordingly.
+
+	Special thanks goes to Eli Zaretskii for reviews and rewording
+	suggestions.
+
+	Change-Id: Ic42ad8565e79ca67bfebb22cbb4794ea816fd08b
+
+2022-05-30  Luis Machado  <luis.machado@arm.com>
+
+	Move 64-bit BFD files from ALL_TARGET_OBS to ALL_64_TARGET_OBS
+	Doing a 32-bit build with "--enable-targets=all --disable-sim" fails to link
+	properly.
+
+	--
+
+	loongarch-tdep.o: In function `loongarch_gdbarch_init':
+	binutils-gdb/gdb/loongarch-tdep.c:443: undefined reference to `loongarch_r_normal_name'
+	loongarch-tdep.o: In function `loongarch_fetch_instruction':
+	binutils-gdb/gdb/loongarch-tdep.c:37: undefined reference to `loongarch_insn_length'
+	loongarch-tdep.o: In function `loongarch_scan_prologue(gdbarch*, unsigned long long, unsigned long long, frame_info*, trad_frame_cache*) [clone .isra.4]':
+	binutils-gdb/gdb/loongarch-tdep.c:87: undefined reference to `loongarch_insn_length'
+	binutils-gdb/gdb/loongarch-tdep.c:88: undefined reference to `loongarch_decode_imm'
+	binutils-gdb/gdb/loongarch-tdep.c:89: undefined reference to `loongarch_decode_imm'
+	binutils-gdb/gdb/loongarch-tdep.c:90: undefined reference to `loongarch_decode_imm'
+	binutils-gdb/gdb/loongarch-tdep.c:91: undefined reference to `loongarch_decode_imm'
+	binutils-gdb/gdb/loongarch-tdep.c:92: undefined reference to `loongarch_decode_imm'
+
+	--
+
+	Given the list of 64-bit BFD files in
+	opcodes/Makefile.am:TARGET64_LIBOPCODES_CFILES, it looks like GDB's
+	ALL_TARGET_OBS list is including files that should be included in
+	ALL_64_TARGET_OBS instead.
+
+	This patch accomplishes this and enables a 32-bit build with
+	"--enable-targets=all --disable-sim" to complete.
+
+	Moving the bpf, tilegx and loongarch files to the correct list means GDB can
+	find the correct disassembler function instead of finding a null pointer.
+
+	We still need the "--disable-sim" switch (or "--enable-64-bit-bfd") to
+	make a 32-bit build with "--enable-targets=all" complete correctly
+
+2022-05-30  Luis Machado  <luis.machado@arm.com>
+
+	Fix failing test for armeb-gnu-eabi
+	The following test fails on the armeb-gnu-eabi target:
+
+	FAIL: Unwind information for Armv8.1-M.Mainline PACBTI extension
+
+	This patch adjusts the expected output for big endian.
+
+2022-05-30  Alan Modra  <amodra@gmail.com>
+
+	Use a union to avoid casts in bfd/doc/chew.c
+	This fixes -Wpedantic warnings in chew.c.  Conversion between function
+	and object pointers is not guaranteed.  They can even be different
+	sizes, not that we're likely to encounter build machines like that
+	nowadays.
+
+		PR 29194
+		* doc/chew.c (pcu): New union typedef.
+		(dict_type, pc): Use it here.  Adjust uses of pc.
+		(add_to_definition): Make "word" param a pcu.  Adjust all uses
+		of function.
+		(stinst_type): Delete.
+
+2022-05-30  Alan Modra  <amodra@gmail.com>
+
+	use libiberty xmalloc in bfd/doc/chew.c
+	Catch out of memory.
+
+		* doc/chew.c: Include libibery.h.
+		(init_string_with_size, nextword): Replace malloc with xmalloc.
+		(newentry, add_to_definition): Likewise.
+		(catchar, catbuf): Replace realloc with xrealloc.
+		(add_intrinsic): Replace strdup with xstrdup.
+		* doc/local.mk (LIBIBERTY): Define.
+		(chew): Link against libiberty.
+		* Makefile.in: Regenerate.
+
+2022-05-30  Alan Modra  <amodra@gmail.com>
+
+	Update K&R functions in bfd/doc/chew.c
+		* doc/chew.c: Update function definitions to ISO C, remove
+		now unnecessary prototypes.
+
+2022-05-30  Alan Modra  <amodra@gmail.com>
+
+	Reorganise bfd/doc/chew.c a little
+	This also removes some unused variables, and deletes support for the
+	"var" keyword which isn't used and was broken.  (No means to set
+	variables, and add_var used push_number inconsistent with its use
+	elsewhere.)
+
+		* doc/chew.c: Move typedefs before variables, variables before
+		functions.
+		(die): Move earlier.
+		(word_type, sstack, ssp): Delete.
+		(dict_type): Delete var field.
+		(add_var): Delete.
+		(compile): Remove "var" support.
+
+2022-05-30  jiawei  <jiawei@iscas.ac.cn>
+
+	RISC-V: Add zhinx extension supports.
+	The zhinx extension is a sub-extension in zfinx, corresponding to
+	zfh extension but use GPRs instead of FPRs.
+
+	This patch expanded the zfh insn class define, since zfh and zhinx
+	use the same opcodes, thanks for Nelson's works.
+
+	changelog in V2: Add missing classes of 'zfh' and 'zhinx' in
+	"riscv_multi_subset_supports_ext".
+
+	bfd/ChangeLog:
+
+	        * elfxx-riscv.c (riscv_multi_subset_supports): New extensions.
+	        (riscv_multi_subset_supports_ext): New extensions.
+
+	gas/ChangeLog:
+
+	        * testsuite/gas/riscv/fp-zhinx-insns.d: New test.
+	        * testsuite/gas/riscv/fp-zhinx-insns.s: New test.
+
+	include/ChangeLog:
+
+	        * opcode/riscv.h (enum riscv_insn_class): New INSN classes.
+
+	opcodes/ChangeLog:
+
+	        * riscv-opc.c: Modify INSN_CLASS.
+
+2022-05-30  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-29  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-28  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/python: improve formatting of help text for user defined commands
+	Consider this command defined in Python (in the file test-cmd.py):
+
+	  class test_cmd (gdb.Command):
+	    """
+	    This is the first line.
+	      Indented second line.
+	    This is the third line.
+	    """
+
+	    def __init__ (self):
+	      super ().__init__ ("test-cmd", gdb.COMMAND_OBSCURE)
+
+	    def invoke (self, arg, from_tty):
+	      print ("In test-cmd")
+
+	  test_cmd()
+
+	Now, within a GDB session:
+
+	  (gdb) source test-cmd.py
+	  (gdb) help test-cmd
+
+	    This is the first line.
+	      Indented second line.
+	    This is the third line.
+
+	  (gdb)
+
+	I think there's three things wrong here:
+
+	  1. The leading blank line,
+	  2. The trailing blank line, and
+	  3. Every line is indented from the left edge slightly.
+
+	The problem of course, is that GDB is using the Python doc string
+	verbatim as its help text.  While the user has formatted the help text
+	so that it appears clear within the .py file, this means that the text
+	appear less well formatted when displayed in the "help" output.
+
+	The same problem can be observed for gdb.Parameter objects in their
+	set/show output.
+
+	In this commit I aim to improve the "help" output for commands and
+	parameters.
+
+	To do this I have added gdbpy_fix_doc_string_indentation, a new
+	function that rewrites the doc string text following the following
+	rules:
+
+	  1. Leading blank lines are removed,
+	  2. Trailing blank lines are removed, and
+	  3. Leading whitespace is removed in a "smart" way such that the
+	  relative indentation of lines is retained.
+
+	With this commit in place the above example now looks like this:
+
+	  (gdb) source ~/tmp/test-cmd.py
+	  (gdb) help test-cmd
+	  This is the first line.
+	    Indented second line.
+	  This is the third line.
+	  (gdb)
+
+	Which I think is much neater.  Notice that the indentation of the
+	second line is retained.  Any blank lines within the help text (not
+	leading or trailing) will be retained.
+
+	I've added a NEWS entry to note that there has been a change in
+	behaviour, but I didn't update the manual.  The existing manual is
+	suitably vague about how the doc string is used, so I think the new
+	behaviour is covered just as well by the existing text.
+
+2022-05-28  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: use gdb::unique_xmalloc_ptr<char> for docs in cmdpy_init
+	Make use of gdb::unique_xmalloc_ptr<char> to hold the documentation
+	string in cmdpy_init (when creating a custom GDB command in Python).
+	I think this is all pretty straight forward, the only slight weirdness
+	is the removal of the call to free toward the end of this function.
+
+	Prior to this commit, if an exception was thrown after the GDB command
+	was created then we would (I think) end up freeing the documentation
+	string even though the command would remain registered with GDB, which
+	would surely lead to undefined behaviour.
+
+	After this commit we release the doc string at the point that we hand
+	it over to the command creation routines.  If we throw _after_ the
+	command has been created within GDB then the doc string will be left
+	live.  If we throw during the command creation itself (either from
+	add_prefix_cmd or add_cmd) then it is up to those functions to free
+	the doc string (I suspect we don't, but I think in general the
+	commands are pretty bad at cleaning up after themselves, so I don't
+	think this is a huge problem).
+
+2022-05-28  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+	gprofng: fix build with -mx32
+	gprofng/ChangeLog
+	2022-05-27  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+		PR gprofng/28983
+		PR gprofng/29143
+		* src/Experiment.cc (write_header): Fix argument for ctime.
+		Fix -Wformat= warnings.
+		* src/Dbe.cc: Likewise.
+		* src/DwarfLib.h: Fix [-Wsign-compare] warnings.
+		* src/Experiment.h: Likewise.
+		* src/ipc.cc: Fix -Wformat= warnings.
+
+2022-05-28  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-27  Tom Tromey  <tom@tromey.com>
+
+	Fix crash with "maint print arc"
+	Luis noticed that "maint print arc" would crash, because the command
+	handler did not find "show" in the command name, violating an
+	invariant.  This patch fixes the bug by changing the registration to
+	use add_basic_prefix_cmd instead.
+
+2022-05-27  Andrew Burgess  <aburgess@redhat.com>
+
+	opcodes/i386: remove trailing whitespace from insns with zero operands
+	While working on another patch[1] I had need to touch this code in
+	i386-dis.c:
+
+	  ins->obufp = ins->mnemonicendp;
+	  for (i = strlen (ins->obuf) + prefix_length; i < 6; i++)
+	    oappend (ins, " ");
+	  oappend (ins, " ");
+	  (*ins->info->fprintf_styled_func)
+	    (ins->info->stream, dis_style_mnemonic, "%s", ins->obuf);
+
+	What this code does is add whitespace after the instruction mnemonic
+	and before the instruction operands.
+
+	The problem I ran into when working on this code can be seen by
+	assembling this input file:
+
+	    .text
+	    nop
+	    retq
+
+	Now, when I disassemble, here's the output.  I've replaced trailing
+	whitespace with '_' so that the issue is clearer:
+
+	    Disassembly of section .text:
+
+	    0000000000000000 <.text>:
+	       0:	90                   	nop
+	       1:	c3                   	retq___
+
+	Notice that there's no trailing whitespace after 'nop', but there are
+	three spaces after 'retq'!
+
+	What happens is that instruction mnemonics are emitted into a buffer
+	instr_info::obuf, then instr_info::mnemonicendp is setup to point to
+	the '\0' character at the end of the mnemonic.
+
+	When we emit the whitespace, this is then added starting at the
+	mnemonicendp position.  Lets consider 'retq', first the buffer is
+	setup like this:
+
+	  'r' 'e' 't' 'q' '\0'
+
+	Then we add whitespace characters at the '\0', converting the buffer
+	to this:
+
+	  'r' 'e' 't' 'q' ' ' ' ' ' ' '\0'
+
+	However, 'nop' is actually an alias for 'xchg %rax,%rax', so,
+	initially, the buffer is setup like this:
+
+	  'x' 'c' 'h' 'g' '\0'
+
+	Then in NOP_Fixup we spot that we have an instruction that is an alias
+	for 'nop', and adjust the buffer to this:
+
+	  'n' 'o' 'p' '\0' '\0'
+
+	The second '\0' is left over from the original buffer contents.
+	However, when we rewrite the buffer, we don't afjust mnemonicendp,
+	which still points at the second '\0' character.
+
+	Now, when we insert whitespace we get:
+
+	  'n' 'o' 'p' '\0' ' ' ' ' ' ' ' ' '\0'
+
+	Notice the whitespace is inserted after the first '\0', so, when we
+	print the buffer, the whitespace is not printed.
+
+	The fix for this is pretty easy, I can change NOP_Fixup to adjust
+	mnemonicendp, but now a bunch of tests start failing, we now produce
+	whitespace after the 'nop', which the tests don't expect.
+
+	So, I could update the tests to expect the whitespace....
+
+	...except I'm not a fan of trailing whitespace, so I'd really rather
+	not.
+
+	Turns out, I can pretty easily update the whitespace emitting code to
+	spot instructions that have zero operands and just not emit any
+	whitespace in this case.  So this is what I've done.
+
+	I've left in the fix for NOP_Fixup, I think updating mnemonicendp is
+	probably a good thing, though this is not really required any more.
+
+	I've then updated all the tests that I saw failing to adjust the
+	expected patterns to account for the change in whitespace.
+
+	[1] https://sourceware.org/pipermail/binutils/2022-April/120610.html
+
+2022-05-27  Alan Modra  <amodra@gmail.com>
+
+	Replace bfd_hostptr_t with uintptr_t
+	bfd_hostptr_t is defined as a type large enough to hold either a long
+	or a pointer.  It mostly appears in the coff backend code in casts.
+	include/coff/internal.h struct internal_syment and union
+	internal_auxent have the only uses in data structures, where
+	comparison with include/coff/external.h and other code reveals that
+	the type only needs to be large enough for a 32-bit integer or a
+	pointer.  That should mean replacing with uintptr_t is OK.
+
+	Remove much of BFD_HOST configury
+	This patch removes the definition of bfd_uint64_t and bfd_int64_t as
+	well as most BFD_HOST_* which are now unused.
+
+	Remove use of bfd_uint64_t and similar
+	Requiring C99 means that uses of bfd_uint64_t can be replaced with
+	uint64_t, and similarly for bfd_int64_t, BFD_HOST_U_64_BIT, and
+	BFD_HOST_64_BIT.  This patch does that, removes #ifdef BFD_HOST_*
+	and tidies a few places that print 64-bit values.
+
+2022-05-27  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+	gprofng: fix build with --disable-shared
+	gprofng/ChangeLog
+	2022-05-26  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+		* libcollector/configure.ac: Use AC_MSG_WARN instead of AC_MSG_ERROR
+		* libcollector/configure: Rebuild.
+
+2022-05-27  Jan Beulich  <jbeulich@suse.com>
+
+	x86/Intel: allow MASM representation of embedded rounding / SAE
+	MASM doesn't support the separate operand form; the modifier belongs
+	after the instruction instead. Accept this form alongside the original
+	(now legacy) one. Short of having access to a MASM version to actually
+	check in how far "after the instruction" is a precise statement in their
+	documentation, allow both that and the SDM mandated form where the
+	modifier is on the last register operand (with a possible immediate
+	operand following).
+
+	Sadly the split out function, at least for the time being, needs to cast
+	away constness at some point, as the two callers disagree in this
+	regard.
+
+	Adjust some, but not all of the testcases.
+
+2022-05-27  Jan Beulich  <jbeulich@suse.com>
+
+	x86: re-work AVX512 embedded rounding / SAE
+	As a preparatory step to allowing proper non-operand forms of specifying
+	embedded rounding / SAE, convert the internal representation to non-
+	operand form. While retaining properties (and in a few cases perhaps
+	providing more meaningful diagnostics), this means doing away with a few
+	hundred standalone templates, thus - as a nice side effect - reducing
+	memory consumption / cache occupancy.
+
+	x86/Intel: adjust representation of embedded rounding / SAE
+	MASM doesn't consider {sae} and alike a separate operand; it is attached
+	to the last register operand instead, just like spelled out by the SDM.
+	Make the disassembler follow this first, before also adjusting the
+	assembler (such that it'll be easy to see that the assembler change
+	doesn't alter generated code).
+
+2022-05-27  Jan Beulich  <jbeulich@suse.com>
+
+	x86/Intel: allow MASM representation of embedded broadcast
+	MASM doesn't support the {1to<n>} form; DWORD BCST (paralleling
+	DWORD PTR) and alike are to be used there instead. Accept these forms
+	alongside the original (now legacy) ones.
+
+	Acceptance of the original {1to<n>} operand suffix is retained both for
+	backwards compatibility and to disambiguate VFPCLASSP{S,D,H} and vector
+	conversions with shrinking element sizes. I have no insight (yet) into
+	how MASM expects those to be disambiguated.
+
+	Adjust some, but not all of the testcases.
+
+2022-05-27  Jan Beulich  <jbeulich@suse.com>
+
+	x86/Intel: adjust representation of embedded broadcast
+	MASM doesn't support the {1to<n>} form; DWORD BCST (paralleling
+	DWORD PTR) and alike are to be used there instead. Make the disassembler
+	follow this first, before also adjusting the assembler (such that it'll
+	be easy to see that the assembler change doesn't alter generated code).
+
+	For VFPCLASSP{S,D,H} and vector conversions with shrinking element sizes
+	the original {1to<n>} operand suffix is retained, to disambiguate
+	output. I have no insight (yet) into how MASM expects those to be
+	disambiguated.
+
+2022-05-27  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+	gprofng: fix build with -mx32
+	gprofng/ChangeLog
+	2022-05-26  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+		PR gprofng/28983
+		* libcollector/libcol_util.h (__collector_getsp, __collector_getfp,
+		__collector_getpc): Adapt for build with -mx32
+		* libcollector/heaptrace.c: Fix -Wpointer-to-int-cast warnings.
+		* libcollector/hwprofile.h: Likewise.
+		* libcollector/mmaptrace.c: Likewise.
+		* libcollector/synctrace.c: Likewise.
+		* libcollector/unwind.c: Likewise.
+
+2022-05-27  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-27  Hans-Peter Nilsson  <hp@axis.com>
+
+	ld: cris*-elf: Default to --no-warn-rwx-segment
+	ld:
+		configure.tgt (cris-*-*, crisv32-*-* sans *-aout and *-linux): Unless
+		specified through the --enable-* -option, default to
+		--no-warn-rwx-segment.
+
+	Change-Id: I846bcd3e6762da807b17215a9fe337461ea0d710
+
+2022-05-27  Hans-Peter Nilsson  <hp@axis.com>
+
+	cris: bfd: Correct default to no execstack
+	In the now-historical CRIS glibc port, the default stack permission
+	was no-exec as in "#define DEFAULT_STACK_PERMS (PF_R|PF_W)", and the
+	gcc port only emits the executable-stack marker when needed; when
+	emitting code needing it.  In other words, the binutils setting
+	mismatches.  It doesn't matter much, except being confusing and
+	defaulting to "off" is more sane.
+
+	ld:
+
+		* testsuite/ld-elf/elf.exp (target_defaults_to_execstack): Switch to 0
+		for cris*-*-*.
+
+	bfd:
+		* elf32-cris.c (elf_backend_default_execstack): Define to 0.
+
+	Change-Id: I52f37598f119b19111c7a6546c00a627fca0f396
+
+2022-05-26  John Baldwin  <jhb@FreeBSD.org>
+
+	aarch64-fbsd-nat: Move definition of debug_regs_probed under HAVE_DBREG.
+	This fixes the build on older FreeBSD systems without support for
+	hardware breakpoints/watchpoints.
+
+2022-05-26  Lancelot SIX  <lancelot.six@amd.com>
+
+	gdb: Change psymbol_functions::require_partial_symbols to partial_symbols
+	The previous patch ensured that partial symbols are read before calling
+	most of the quick_function's methods.
+
+	The psymbol_functions class has the require_partial_symbols method which
+	serves this exact purpose, and does not need to do it anymore.
+
+	This patch renames this method to partial_symbols and makes it an accessor
+	which asserts that partial symbols have been read at this point.
+
+	Regression tested on x86_64-linux.
+
+2022-05-26  Lancelot SIX  <lancelot.six@amd.com>
+
+	gdb: Require psymtab before calling quick_functions in objfile
+	The recent DWARF indexer rewrite introduced a regression when debugging
+	a forking program.
+
+	Here is a way to reproduce the issue (there might be other ways, but one
+	is enough and this one mimics the situation we encountered).  Consider a
+	program which forks, and the child loads a shared library and calls a
+	function in this shared library:
+
+	    if (fork () == 0)
+	      {
+	        void *solib = dlopen (some_solib, RTLD_NOW);
+	        void (*foo) () = dlsym (some_solib, "foo");
+	        foo ();
+	      }
+
+	Suppose that this program is compiled without debug info, but the shared
+	library it loads has debug info enabled.
+
+	When debugging such program with the following options:
+
+	  - set detach-on-fork off
+	  - set follow-fork-mode child
+
+	we see something like:
+
+	    (gdb) b foo
+	    Function "foo" not defined.
+	    Make breakpoint pending on future shared library load? (y or [n]) y
+	    Breakpoint 1 (foo) pending.
+	    (gdb) run
+	    Starting program: a.out
+	    [Attaching after process 19720 fork to child process 19723]
+	    [New inferior 2 (process 19723)]
+	    [Switching to process 19723]
+
+	    Thread 2.1 "a.out" hit Breakpoint 1, 0x00007ffff7fc3101 in foo () from .../libfoo.so
+	    (gdb) list
+
+	    Fatal signal: Segmentation fault
+	    ----- Backtrace -----
+	    0x55a278f77d76 gdb_internal_backtrace_1
+	            ../../gdb/bt-utils.c:122
+	    0x55a278f77f83 _Z22gdb_internal_backtracev
+	            ../../gdb/bt-utils.c:168
+	    0x55a27940b83b handle_fatal_signal
+	            ../../gdb/event-top.c:914
+	    0x55a27940bbb1 handle_sigsegv
+	            ../../gdb/event-top.c:987
+	    0x7effec0343bf ???
+	            /build/glibc-sMfBJT/glibc-2.31/nptl/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
+	    0x55a27924c9d3 _ZNKSt15__uniq_ptr_implI18dwarf2_per_cu_data26dwarf2_per_cu_data_deleterE6_M_ptrEv
+	            /usr/include/c++/9/bits/unique_ptr.h:154
+	    0x55a279248bc9 _ZNKSt10unique_ptrI18dwarf2_per_cu_data26dwarf2_per_cu_data_deleterE3getEv
+	            /usr/include/c++/9/bits/unique_ptr.h:361
+	    0x55a2792ae718 _ZN27dwarf2_base_index_functions23find_last_source_symtabEP7objfile
+	            ../../gdb/dwarf2/read.c:3164
+	    0x55a279afb93e _ZN7objfile23find_last_source_symtabEv
+	            ../../gdb/symfile-debug.c:139
+	    0x55a279aa3040 _Z20select_source_symtabP6symtab
+	            ../../gdb/source.c:365
+	    0x55a279aa22a1 _Z34set_default_source_symtab_and_linev
+	            ../../gdb/source.c:268
+	    0x55a27903c44c list_command
+	            ../../gdb/cli/cli-cmds.c:1185
+	    0x55a279051233 do_simple_func
+	            ../../gdb/cli/cli-decode.c:95
+	    0x55a27905f221 _Z8cmd_funcP16cmd_list_elementPKci
+	            ../../gdb/cli/cli-decode.c:2514
+	    0x55a279c3b0ba _Z15execute_commandPKci
+	            ../../gdb/top.c:660
+	    0x55a27940a6c3 _Z15command_handlerPKc
+	            ../../gdb/event-top.c:598
+	    0x55a27940b032 _Z20command_line_handlerOSt10unique_ptrIcN3gdb13xfree_deleterIcEEE
+	            ../../gdb/event-top.c:797
+	    0x55a279caf401 tui_command_line_handler
+	            ../../gdb/tui/tui-interp.c:278
+	    0x55a279409098 gdb_rl_callback_handler
+	            ../../gdb/event-top.c:230
+	    0x55a279ed5df2 rl_callback_read_char
+	            ../../../readline/readline/callback.c:281
+	    0x55a279408bd8 gdb_rl_callback_read_char_wrapper_noexcept
+	            ../../gdb/event-top.c:188
+	    0x55a279408de7 gdb_rl_callback_read_char_wrapper
+	            ../../gdb/event-top.c:205
+	    0x55a27940a061 _Z19stdin_event_handleriPv
+	            ../../gdb/event-top.c:525
+	    0x55a27a23771e handle_file_event
+	            ../../gdbsupport/event-loop.cc:574
+	    0x55a27a237f5f gdb_wait_for_event
+	            ../../gdbsupport/event-loop.cc:700
+	    0x55a27a235d81 _Z16gdb_do_one_eventv
+	            ../../gdbsupport/event-loop.cc:237
+	    0x55a2796c2ef0 start_event_loop
+	            ../../gdb/main.c:418
+	    0x55a2796c3217 captured_command_loop
+	            ../../gdb/main.c:478
+	    0x55a2796c717b captured_main
+	            ../../gdb/main.c:1340
+	    0x55a2796c7217 _Z8gdb_mainP18captured_main_args
+	            ../../gdb/main.c:1355
+	    0x55a278d0b381 main
+	            ../../gdb/gdb.c:32
+	    ---------------------
+	    A fatal error internal to GDB has been detected, further
+	    debugging is not possible.  GDB will now terminate.
+
+	    This is a bug, please report it.  For instructions, see:
+	    <https://www.gnu.org/software/gdb/bugs/>.
+
+	The first issue observed is in the message printed when hitting the
+	breakpoint.  It says that there was a break in the .so file as if there
+	was no debug info associated with it, but there is.  Later, if we try to
+	display the source where the execution stopped, we have a segfault.
+
+	Note that not having the debug info on the main binary is not strictly
+	required to encounter some issues, it only is to encounter the segfault.
+	If the main binary has debug information, GDB shows some source form the
+	main binary, unrelated to where we stopped.
+
+	The core of the issue is that GDB never loads the psymtab for the
+	library.  It is not loaded when we first see the .so because in case of
+	detach-on-fork off, follow-fork-mode child, infrun.c sets
+	child_inf->symfile_flags = SYMFILE_NO_READ to delay the psymtab loading
+	as much as possible.  If we compare to what was done to handle this
+	before the new indexer was activated, the psymatb construction for the
+	shared library was done under
+	psymbol_functions::expand_symtabs_matching:
+
+	    bool
+	    psymbol_functions::expand_symtabs_matching (...)
+	    {
+	        for (partial_symtab *ps : require_partial_symbols (objfile))
+	        ...
+	    }
+
+	The new indexer's expand_symtabs_matching callback does not have a call
+	to the objfile's require_partial_symbols, so if the partial symbol table
+	is not loaded at this point, there is no mechanism to fix this.
+
+	Instead of requiring each implementation of the quick_functions to check
+	that partial symbols have been read, I think it is safer to enforce this
+	when calling the quick functions.  The general pattern for calling the
+	quick functions is:
+
+	    for (auto *iter : qf)
+	      iter->the_actual_method_call (...)
+
+	This patch proposes to wrap the access of the `qf` field with an accessor
+	which ensures that partial symbols have been read before iterating:
+	qf_require_partial_symbols.  All calls to quick functions are updated
+	except:
+
+	- quick_functions::dump
+	- quick_functions::read_partial_symbols (from
+	  objfile::require_partial_symbols)
+	- quick_functions::can_lazily_read_symbols and quick_functions::has_symbols
+	  (from objfile::has_partial_symbols)
+
+	Regression tested on x86_64-gnu-linux.
+
+	Change-Id: I39a13a937fdbaae613a5cf68864b021000554546
+
+2022-05-26  Tom Tromey  <tom@tromey.com>
+
+	Fix crash in new DWARF indexer
+	PR gdb/29128 points out a crash in the new DWARF index code.  This
+	happens if the aranges for a CU claims a PC, but the symtab that is
+	created during CU expansion does not actually contain the PC.  This
+	can only occur due to bad debuginfo, but at the same time, gdb should
+	not crash.
+
+	This patch fixes the bug and further merges some code into
+	dwarf2_base_index_functions.  This merger helps prevent the same issue
+	from arising from the other index implementations.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29128
+
+2022-05-26  Tom Tromey  <tromey@adacore.com>
+
+	Finalize each cooked index separately
+	After DWARF has been scanned, the cooked index code does a
+	"finalization" step in a worker thread.  This step combines all the
+	index entries into a single master list, canonicalizes C++ names, and
+	splits Ada names to synthesize package names.
+
+	While this step is run in the background, gdb will wait for the
+	results in some situations, and it turns out that this step can be
+	slow.  This is PR symtab/29105.
+
+	This can be sped up by parallelizing, at a small memory cost.  Now
+	each index is finalized on its own, in a worker thread.  The cost
+	comes from name canonicalization: if a given non-canonical name is
+	referred to by multiple indices, there will be N canonical copies (one
+	per index) rather than just one.
+
+	This requires changing the users of the index to iterate over multiple
+	results.  However, this is easily done by introducing a new "chained
+	range" class.
+
+	When run on gdb itself, the memory cost seems rather low -- on my
+	current machine, "maint space 1" reports no change due to the patch.
+
+	For performance testing, using "maint time 1" and "file" will not show
+	correct results.  That approach measures "time to next prompt", but
+	because the patch only affects background work, this shouldn't (and
+	doesn't) change.  Instead, a simple way to make gdb wait for the
+	results is to set a breakpoint.
+
+	Before:
+
+	    $ /bin/time -f%e ~/gdb/install/bin/gdb -nx -q -batch \
+	        -ex 'break main' /tmp/gdb
+	    Breakpoint 1 at 0x43ec30: file ../../binutils-gdb/gdb/gdb.c, line 28.
+	    2.00
+
+	After:
+
+	    $ /bin/time -f%e ./gdb/gdb -nx -q -batch \
+	        -ex 'break main' /tmp/gdb
+	    Breakpoint 1 at 0x43ec30: file ../../binutils-gdb/gdb/gdb.c, line 28.
+	    0.65
+
+	Regression tested on x86-64 Fedora 34.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29105
+
+2022-05-26  Alan Modra  <amodra@gmail.com>
+
+	bit-rot in target before_parse function
+	Copy initialisation over from the elf.em before_parse.  Commit
+	ba951afb999 2022-05-03 changed behaviour on arm and score regarding
+	exec stack.  This patch restores the previous behaviour.
+
+		* emultempl/aarch64elf.em (before_parse): Init separate_code,
+		warn_execstack, no_warn_rwx_segments and default_execstack.
+		* emultempl/armelf.em (before_parse): Likewise.
+		* emultempl/scoreelf.em (before_parse): Likewise.
+		* testsuite/ld-elf/elf.exp (target_defaults_to_execstack): Return
+		true for arm and nacl.
+
+2022-05-26  Richard Earnshaw  <rearnsha@arm.com>
+
+	 arm: avoid use of GNU builtin function in s_arm_unwind_save_mixed
+	Whilst reviewing Luis' proposed change to s_arm_unwind_save_mixed
+	yesterday I noticed that we were making use of __builting_clzl
+	directly within the main function, which is not guaranteed to be
+	portable.  Whilst studying the code further, I also realized that it
+	could be rewritten without using it and also reworked to remove a lot
+	of unnecessary iterations steps.  So this patch does that (and also
+	removes the source of the warning that Luis was trying to fix).
+	Finally, with the rewrite we can also simplify the caller of this
+	routine as the new version can handle all the cases directly.
+
+		* config/tc-arm.c (s_arm_unwind_save_mixed): Rewrite without
+		using __builtin_clzl.
+		(s_arm_unwind_save): Simplify logic for simple/mixed register saves.
+
+2022-05-26  Lancelot SIX  <lancelot.six@amd.com>
+
+	gdb/linux-nat: xfer_memory_partial return E_IO on error
+	When accessing /proc/PID/mem, if pread64/pwrite64/read/write encounters
+	an error and return -1, linux_proc_xfer_memory_partial return
+	TARGET_XFER_EOF.
+
+	I think it should return TARGET_XFER_E_IO in this case.  TARGET_XFER_EOF
+	is returned when pread64/pwrite64/read/frite returns 0, which indicates
+	that the address space is gone and the whole process has exited or
+	execed.
+
+	This patch makes this change.
+
+	Regression tested on x86_64-linux-gnu.
+
+	Change-Id: I6030412459663b8d7933483fdda22a6c2c5d7221
+
+2022-05-26  Lancelot SIX  <lancelot.six@amd.com>
+
+	gdb/testsuite: prefer gdb_test in gdb.dwarf2/calling-convention
+	Since ed01945057c "Make gdb_test's question non-optional if specified",
+	if the question and response parameters are given to gdb_test, the
+	framework enforces that GDB asks the question.  Before this patch, tests
+	needed to use gdb_test_multiple to enforce this.
+
+	This patch updates the gdb.dwarf2/calling-convention.exp testcase to use
+	gdb_test to check that GDB asks a question.  This replaces the more
+	complicated gdb_test_multiple based implementation.
+
+	Tested on x86_64-gnu-linux.
+
+	Change-Id: I7216e822ca68f2727e0450970097d74c27c432fe
+
+2022-05-26  Potharla, Rupesh  <Rupesh.Potharla@amd.com>
+
+	bfd: Add Support for DW_FORM_strx* and DW_FORM_addrx*
+
+2022-05-26  Luca Boccassi  <bluca@debian.org>
+
+	ld: add --package-metadata
+	Generate a .note.package FDO package metadata ELF note, following
+	the spec: https://systemd.io/ELF_PACKAGE_METADATA/
+
+	If the jansson library is available at build time (and it is explicitly
+	enabled), link ld to it, and use it to validate that the input is
+	correct JSON, to avoid writing garbage to the file. The
+	configure option --enable-jansson has to be used to explicitly enable
+	it (error out when not found). This allows bootstrappers (or others who
+	are not interested) to seamlessly skip it without issues.
+
+2022-05-26  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-26  Natarajan, Kavitha  <Kavitha.Natarajan@amd.com>
+
+	Re: Add bionutils support for DWARF v5's DW_OP_addrx
+	Testsuite files belonging to commit 3ac9da49378c.
+
+2022-05-25  Pedro Alves  <pedro@palves.net>
+
+	Show enabled locations with disabled breakpoint parent as "y-"
+	Currently, breakpoint locations that are enabled while their parent
+	breakpoint is disabled are displayed with "y" in the Enb colum of
+	"info breakpoints":
+
+	 (gdb) info breakpoints
+	 Num     Type           Disp Enb Address            What
+	 1       breakpoint     keep n   <MULTIPLE>
+	 1.1                         y   0x00000000000011b6 in ...
+	 1.2                         y   0x00000000000011c2 in ...
+	 1.3                         n   0x00000000000011ce in ...
+
+	Such locations won't trigger a break, so to avoid confusion, show "y-"
+	instead.  For example:
+
+	 (gdb) info breakpoints
+	 Num     Type           Disp Enb Address            What
+	 1       breakpoint     keep n   <MULTIPLE>
+	 1.1                         y-  0x00000000000011b6 in ...
+	 1.2                         y-  0x00000000000011c2 in ...
+	 1.3                         n   0x00000000000011ce in ...
+
+	The "-" sign is inspired on how the TUI represents breakpoints on the
+	left side of the source window, with "b-" for a disabled breakpoint.
+
+	Change-Id: I9952313743c51bf21b4b380c72360ef7d4396a09
+
+2022-05-25  Natarajan, Kavitha  <Kavitha.Natarajan@amd.com>
+
+	Add bionutils support for DWARF v5's DW_OP_addrx.
+
+2022-05-25  Pedro Alves  <pedro@palves.net>
+
+	gdb: Fix DUPLICATE and PATH regressions throughout
+	The previous patch to add -prompt/-lbl to gdb_test introduced a
+	regression: Before, you could specify an explicit empty message to
+	indicate you didn't want to PASS, like so:
+
+	  gdb_test COMMAND PATTERN ""
+
+	After said patch, gdb_test no longer distinguishes
+	no-message-specified vs empty-message, so tests that previously would
+	be silent on PASS, now started emitting PASS messages based on
+	COMMAND.  This in turn introduced a number of PATH/DUPLICATE
+	violations in the testsuite.
+
+	This commit fixes all the regressions I could see.
+
+	This patch uses the new -nopass feature introduced in the previous
+	commit, but tries to avoid it if possible.  Most of the patch fixes
+	DUPLICATE issues the usual way, of using with_test_prefix or explicit
+	unique messages.
+
+	See previous commit's log for more info.
+
+	In addition to looking for DUPLICATEs, I also looked for cases where
+	we would now end up with an empty message in gdb.sum, due to a
+	gdb_test being passed both no message and empty command.  E.g., this
+	in gdb.ada/bp_reset.exp:
+
+	 gdb_run_cmd
+	 gdb_test "" "Breakpoint $decimal, foo\\.nested_sub \\(\\).*"
+
+	was resulting in this in gdb.sum:
+
+	 PASS: gdb.ada/bp_reset.exp:
+
+	I fixed such cases by passing an explicit message.  We may want to
+	make such cases error out.
+
+	Tested on x86_64 GNU/Linux, native and native-extended-gdbserver.  I
+	see zero PATH cases now.  I get zero DUPLICATEs with native testing
+	now.  I still see some DUPLICATEs with native-extended-gdbserver, but
+	those were preexisting, unrelated to the gdb_test change.
+
+	Change-Id: I5375f23f073493e0672190a0ec2e847938a580b2
+
+2022-05-25  Pedro Alves  <pedro@palves.net>
+
+	Add -nopass option to gdb_test/gdb_test_multiple
+	The previous patch to add -prompt/-lbl to gdb_test introduced a
+	regression: Before, you could specify an explicit empty message to
+	indicate you didn't want to PASS, like so:
+
+	  gdb_test COMMAND PATTERN ""
+
+	After said patch, gdb_test no longer distinguishes
+	no-message-specified vs empty-message, so tests that previously would
+	be silent on PASS, now started emitting PASS messages based on
+	COMMAND.  This in turn introduced a number of PATH/DUPLICATE
+	violations in the testsuite.
+
+	I think that not issuing a PASS should be restricted to only a few
+	cases -- namely in shared routines exported by gdb.exp, which happen
+	to use gdb_test internally.  In tests that iterate an unknown number
+	of tests exercising some racy scenario.  In the latter case, if we
+	emit PASSes for each iteration, we run into the situation where
+	different testsuite runs emit a different number of PASSes.
+
+	Thus, this patch preserves the current behavior, and, instead, adds a
+	new "-nopass" option to gdb_test and gdb_test_no_output.  Compared to
+	the old way of supressing PASS with an empty message, this has the
+	advantage that you can specify a FAIL message that is distinct from
+	the command string, and, it's also more explicit.
+
+	Change-Id: I5375f23f073493e0672190a0ec2e847938a580b2
+
+2022-05-25  Tsukasa OI  <research_trasio@irq.a4lg.com>
+
+	RISC-V: Fix RV32Q conflict
+	This commit makes RV32 + 'Q' extension (version 2.2 or later) not
+	conflicting since this combination is no longer prohibited by the
+	specification.
+
+	bfd/ChangeLog:
+
+		* elfxx-riscv.c (riscv_parse_check_conflicts): Remove conflict
+		detection that prohibits RV32Q on 'Q' version 2.2 or later.
+
+	gas/ChangeLog:
+
+		* testsuite/gas/riscv/march-fail-rv32iq.d: Removed.
+		* testsuite/gas/riscv/march-fail-rv32iq.l: Likewise.
+		* testsuite/gas/riscv/march-fail-rv32iq2p0.d: New test
+		showing RV32IQ fails on 'Q' extension version 2.0.
+		* testsuite/gas/riscv/march-fail-rv32iq2p0.l: Likewise.
+		* testsuite/gas/riscv/march-fail-rv32iq2.d: Likewise.
+		* testsuite/gas/riscv/march-fail-rv32iq-isa-2p2.d: New test
+		showing RV32IQ fails on ISA specification version 2.2.
+		* testsuite/gas/riscv/march-ok-rv32iq2p2.d: New test
+		showing RV32IQ succesds on 'Q' extension version 2.2.
+		* testsuite/gas/riscv/march-ok-rv32iq-isa-20190608.d: New test
+		showing RV32IQ succesds on ISA specification 20190608.
+
+2022-05-25  Dmitry Selyutin  <ghostmansd@gmail.com>
+
+	opcodes: introduce BC field; fix isel
+	Per Power ISA Version 3.1B 3.3.12, isel uses BC field rather than CRB
+	field present in binutils sources. Also, per 1.6.2, BC has the same
+	semantics as BA and BB fields, so this should keep the same flags and
+	mask, only with the different offset.
+
+	opcodes/
+	        * ppc-opc.c
+	        (BC): Define new field, with the same definition as CRB field,
+	        but with the PPC_OPERAND_CR_BIT flag present.
+	gas/
+	        * testsuite/gas/ppc/476.d: Update.
+	        * testsuite/gas/ppc/a2.d: Update.
+	        * testsuite/gas/ppc/e500.d: Update.
+	        * testsuite/gas/ppc/power7.d: Update.
+
+2022-05-25  Dmitry Selyutin  <ghostmansd@gmail.com>
+
+	ppc: extend opindex to 16 bits
+	With the upcoming SVP64 extension[0] to PowerPC architecture, it became
+	evident that PowerPC operand indices no longer fit 8 bits. This patch
+	switches the underlying type to uint16_t, also introducing a special
+	typedef so that any future extension goes even smoother.
+
+	[0] https://libre-soc.org
+
+	include/
+		* opcode/ppc.h (ppc_opindex_t): New typedef.
+		(struct powerpc_opcode): Use it.
+		(PPC_OPINDEX_MAX): Define.
+	gas/
+		* write.h (struct fix): Increase size of fx_pcrel_adjust.
+		Reorganise.
+		* config/tc-ppc.c (insn_validate): Use ppc_opindex_t for operands.
+		(md_assemble): Likewise.
+		(md_apply_fix): Likewise.  Mask fx_pcrel_adjust with PPC_OPINDEX_MAX.
+		(ppc_setup_opcodes): Adjust opcode index assertion.
+	opcodes/
+		* ppc-dis.c (skip_optional_operands): Use ppc_opindex_t for
+		operand pointer.
+		(lookup_powerpc, lookup_prefix, lookup_vle, lookup_spe2): Likewise.
+		(print_insn_powerpc): Likewise.
+
+2022-05-25  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-24  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.opt/clobbered-registers-O2.exp with clang
+	When running test-case gdb.opt/clobbered-registers-O2.exp with clang 12.0.1, I
+	get:
+	...
+	(gdb) run ^M
+	Starting program: clobbered-registers-O2 ^M
+	^M
+	Program received signal SIGSEGV, Segmentation fault.^M
+	gen_movsd (operand0=<optimized out>, operand1=<optimized out>) at \
+	  clobbered-registers-O2.c:31^M
+	31              return *start_sequence(operand0, operand1);^M
+	(gdb) FAIL: gdb.opt/clobbered-registers-O2.exp: runto: run to start_sequence
+	...
+
+	The problem is that the breakpoint in start_sequence doesn't trigger, because:
+	- the call to start_sequence in gen_movsd is optimized away, despite the
+	  __attribute__((noinline)), so the actual function start_sequence doesn't get
+	  called, and
+	- the debug info doesn't contain inlined function info, so there's only one
+	  breakpoint location.
+
+	Adding noclone and noipa alongside the noinline attribute doesn't fix this.
+
+	Adding the clang-specific attribute optnone in start_sequence does, but since
+	it inhibits all optimization, that's not a preferred solution in a gdb.opt
+	test-case, and it would work only for clang and not other compilers that
+	possibly have the same issue.
+
+	Fix this by moving functions start_sequence and gen_movsd into their own
+	files, as a way of trying harder to enforce noinline/noipa/noclone.
+
+	Tested on x86_64-linux.
+
+2022-05-24  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.opt/clobbered-registers-O2.exp with gcc-12
+	When running test-case gdb.opt/clobbered-registers-O2.exp with gcc-12, I run
+	into:
+	...
+	(gdb) PASS: gdb.opt/clobbered-registers-O2.exp: backtracing
+	print operand0^M
+	$1 = (unsigned int *) 0x7fffffffd070^M
+	(gdb) print *operand0^M
+	$2 = 4195541^M
+	(gdb) FAIL: gdb.opt/clobbered-registers-O2.exp: print operand0
+	...
+
+	The problem is that starting gcc-12, the assignments to x and y in main are
+	optimized away:
+	...
+	int main(void)
+	{
+	  unsigned x, y;
+
+	  x = 13;
+	  y = 14;
+	  return (int)gen_movsd (&x, &y);
+	...
+
+	Fix this by making x and y volatile.
+
+	Note that the test-case intends to check the handling of debug info for
+	optimized code in function gen_movsd, so inhibiting optimization in main
+	doesn't interfere with that.
+
+	Tested on x86_64-linux.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29161
+
+2022-05-24  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: LoongArch: Define LOONGARCH_LINUX_NUM_GREGSET as 45
+	LOONGARCH_LINUX_NUM_GREGSET should be defined as 45 (32 + 1 + 1 + 11)
+	due to reserved 11 for extension in glibc, otherwise when execute:
+
+	  make check-gdb TESTS="gdb.base/corefile.exp"
+
+	there exists the following failed testcase:
+
+	  (gdb) core-file /home/loongson/build.git/gdb/testsuite/outputs/gdb.base/corefile/corefile.core
+	  [New LWP 7742]
+	  warning: Unexpected size of section `.reg/7742' in core file.
+	  Core was generated by `/home/loongson/build.git/gdb/testsuite/outputs/gdb.base/corefile/corefile'.
+	  Program terminated with signal SIGABRT, Aborted.
+	  warning: Unexpected size of section `.reg/7742' in core file.
+	  #0  0x000000fff76f4e24 in raise () from /lib/loongarch64-linux-gnu/libc.so.6
+	  (gdb) FAIL: gdb.base/corefile.exp: core-file warning-free
+
+2022-05-24  Christophe Lyon  <christophe.lyon@arm.com>
+
+	AArch64: add support for DFP (Decimal Floating point)
+	This small patch adds support for TYPE_CODE_DECFLOAT in
+	aapcs_is_vfp_call_or_return_candidate_1 and pass_in_v_vfp_candidate,
+	so that GDB for AArch64 knows how to pass DFP parameters and how to
+	read DFP results when calling a function.
+
+	Tested on aarch64-linux-gnu, with a GCC with DFP support in the PATH,
+	all of GDB's DFP tests pass.
+
+2022-05-24  Christophe Lyon  <christophe.lyon@arm.com>
+
+	Merge config/ changes from GCC, to enable DFP on AArch64
+	2022-04-28  Christophe Lyon  <christophe.lyon@arm.com>
+
+		config/
+		* dfp.m4 (enable_decimal_float): Enable BID for AArch64.
+
+		libdecnumber/
+		* configure: Regenerate.
+
+2022-05-24  Alan Modra  <amodra@gmail.com>
+
+	PR29171, invalid read causing SIGSEGV
+	The fix here is to pass "section" down to read_and_display_attr_value.
+	The test in read_and_display_attr_value is a little bit of hardening.
+
+		PR 29171
+		* dwarf.c (display_debug_macro, display_debug_names): Pass section
+		to read_and_display_attr_value2.
+		(read_and_display_attr_value): Don't attempt to check for .dwo
+		section name when section is NULL.
+
+2022-05-24  Alan Modra  <amodra@gmail.com>
+
+	PR29170, divide by zero displaying fuzzed .debug_names
+		PR 29170
+		* dwarf.c (display_debug_names): Don't attempt to display bucket
+		clashes when bucket count is zero.
+
+	PR29169, invalid read displaying fuzzed .gdb_index
+		PR 29169
+		* dwarf.c (display_gdb_index): Combine sanity checks.  Calculate
+		element counts, not word counts.
+
+2022-05-24  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-23  John Baldwin  <jhb@FreeBSD.org>
+
+	Tweak the std::hash<> specialization for aarch64_features.
+	Move the specialization into an explicit std namespace to workaround a
+	bug in older compilers.  GCC 6.4.1 at least fails to compile the previous
+	version with the following error:
+
+	gdb/arch/aarch64.h:48:13: error: specialization of 'template<class _Tp> struct std::hash' in different namespace [-fpermissive]
+
+	  struct std::hash<aarch64_features>
+
+2022-05-23  John Baldwin  <jhb@FreeBSD.org>
+
+	Fix loongarch_iterate_over_regset_sections for non-native targets.
+	Define a constant for the number of registers stored in a register set
+	and use this with register_size to compute the size of the
+	general-purpose register set in core dumps.
+
+	This also fixes the build on hosts such as FreeBSD that do not define
+	an elf_gregset_t type.
+
+2022-05-23  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: LoongArch: Implement the iterate_over_regset_sections gdbarch method
+	When execute the following command on LoongArch:
+
+	  make check-gdb TESTS="gdb.base/auxv.exp"
+
+	there exist the following unsupported and failed testcases:
+
+	  UNSUPPORTED: gdb.base/auxv.exp: gcore
+	  FAIL: gdb.base/auxv.exp: load core file for info auxv on native core dump
+	  FAIL: gdb.base/auxv.exp: info auxv on native core dump
+	  FAIL: gdb.base/auxv.exp: matching auxv data from live and core
+	  UNSUPPORTED: gdb.base/auxv.exp: info auxv on gcore-created dump
+	  UNSUPPORTED: gdb.base/auxv.exp: matching auxv data from live and gcore
+
+	we can see the following messages in gdb/testsuite/gdb.log:
+
+	  gcore /home/loongson/build.git/gdb/testsuite/outputs/gdb.base/auxv/auxv.gcore
+	  Target does not support core file generation.
+	  (gdb) UNSUPPORTED: gdb.base/auxv.exp: gcore
+
+	In order to fix the above issues, implement the iterate_over_regset_sections
+	gdbarch method to iterate over core file register note sections on LoongArch.
+
+	By the way, with this patch, the failed testcases in gdb.base/corefile.exp
+	and gdb.base/gcore.exp can also be fixed.
+
+2022-05-23  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix -prompt handling in gdb_test
+	With check-read1 I run into:
+	...
+	   [infrun] maybe_set_commit_resumed_all_targets: not requesting
+	commit-resumed for target native, no resumed threads^M
+	(gdb) FAIL: gdb.base/ui-redirect.exp: debugging: continue
+	[infrun] fetch_inferior_event: exit^M
+	...
+
+	The problem is that proc gdb_test doesn't pass down the -prompt option to proc
+	gdb_test_multiple, due to a typo making this lappend without effect:
+	...
+	    set opts {}
+	    lappend "-prompt $prompt"
+	...
+
+	Fix this by actually appending to opts.
+
+	Tested on x86_64-linux.
+
+2022-05-23  Tom de Vries  <tdevries@suse.de>
+
+	[gdbsupport] Fix UB in print-utils.cc:int_string
+	When building gdb with -fsanitize=undefined, I run into:
+	...
+	(gdb) PASS: gdb.ada/access_to_packed_array.exp: set logging enabled on
+	maint print symbols^M
+	print-utils.cc:281:29:runtime error: negation of -9223372036854775808 cannot \
+	  be represented in type 'long int'; cast to an unsigned type to negate this \
+	  value to itself
+	(gdb) FAIL: gdb.ada/access_to_packed_array.exp: maint print symbols
+	...
+
+	By running in a debug session, we find that this happens during printing of:
+	...
+	   typedef system.storage_elements.storage_offset: \
+	     range -9223372036854775808 .. 9223372036854775807;
+	...
+	Possibly, an ada test-case could be created that exercises this in isolation.
+
+	The problem is here in int_string, where we negate a val with type LONGEST:
+	...
+	         return decimal2str ("-", -val, width);
+	...
+
+	Fix this by, as recommend, using "-(ULONGEST)val" instead.
+
+	Tested on x86_64-linux.
+
+2022-05-23  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/exp] Fix UB in scalar_binop
+	When building gdb with -fsanitize=undefined, I run into:
+	...
+	$ gdb -q -batch -ex "p -(-0x7fffffffffffffff - 1)"
+	src/gdb/valarith.c:1385:10: runtime error: signed integer overflow: \
+	  0 - -9223372036854775808 cannot be represented in type 'long int'
+	$1 = -9223372036854775808
+	...
+
+	Fix this by performing the substraction in scalar_binop using unsigned types.
+
+	Tested on x86_64-linux.
+
+2022-05-23  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/ada] Fix gdb.ada/dynamic-iface.exp with gcc 7
+	This test in test-case gdb.ada/dynamic-iface.exp passes with gcc 8:
+	...
+	(gdb) print obj^M
+	$1 = (n => 3, a => "ABC", value => 93)^M
+	(gdb) PASS: gdb.ada/dynamic-iface.exp: print local as interface
+	...
+	but fails with gcc 7:
+	...
+	(gdb) print obj^M
+	$1 = ()^M
+	(gdb) FAIL: gdb.ada/dynamic-iface.exp: print local as interface
+	...
+
+	More concretely, we have trouble finding the type of obj.  With gcc 8:
+	...
+	$ gdb -q -batch main -ex "b concrete.adb:20" -ex run -ex "ptype obj"
+	  ...
+	type = <ref> new concrete.intermediate with record
+	    value: integer;
+	end record
+	...
+	and with gcc 7:
+	...
+	type = <ref> tagged record null; end record
+	...
+
+	The translation from tagged type to "full view" type happens in
+	ada_tag_value_at_base_address, where we hit this code:
+	...
+	  /* Storage_Offset'Last is used to indicate that a dynamic offset to
+	     top is used.  In this situation the offset is stored just after
+	     the tag, in the object itself.  */
+	  if (offset_to_top == last)
+	    {
+	      struct value *tem = value_addr (tag);
+	      tem = value_ptradd (tem, 1);
+	      tem = value_cast (ptr_type, tem);
+	      offset_to_top = value_as_long (value_ind (tem));
+	    }
+	...
+	resulting in an offset_to_top for gcc 8:
+	...
+	(gdb) p offset_to_top
+	$1 = -16
+	...
+	and for gcc 7:
+	...
+	(gdb) p offset_to_top
+	$1 = 16
+	...
+
+	The difference is expected, it bisects to gcc commit d0567dc0dbf ("[multiple
+	changes]") which mentions this change.
+
+	There's some code right after the code quoted above that deals with this
+	change:
+	...
+	  else if (offset_to_top > 0)
+	    {
+	      /* OFFSET_TO_TOP used to be a positive value to be subtracted
+		 from the base address.  This was however incompatible with
+		 C++ dispatch table: C++ uses a *negative* value to *add*
+		 to the base address.  Ada's convention has therefore been
+		 changed in GNAT 19.0w 20171023: since then, C++ and Ada
+		 use the same convention.  Here, we support both cases by
+		 checking the sign of OFFSET_TO_TOP.  */
+	      offset_to_top = -offset_to_top;
+	    }
+	...
+	but it's not activated because of the 'else'.
+
+	Fix this by removing the 'else'.
+
+	Tested on x86_64-linux, with gcc 7.5.0.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29057
+
+2022-05-23  Mark Harmstone  <mark@harmstone.com>
+
+	ld: use definitions in generate_reloc rather than raw literals
+
+2022-05-23  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Skip language auto in gdb.base/parse_number.exp
+	In test-case gdb.base/parse_number.exp, we skip architecture auto in the
+	$supported_archs loop, to prevent duplicate testing.
+
+	Likewise, skip language auto and its alias local in the $::all_languages
+	loop.  This reduces the number of tests from 17744 to 15572.
+
+	Tested on x86_64-linux, with a build with --enable-targets=all.
+
+2022-05-23  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-22  Alok Kumar Sharma  <AlokKumar.Sharma@amd.com>
+
+	Accept functions with DW_AT_linkage_name present
+	Currently GDB is not able to debug (Binary generated with Clang) variables
+	present in shared/private clause of OpenMP Task construct. Please note that
+	LLVM debugger LLDB is able to debug.
+
+	In case of OpenMP, compilers generate artificial functions which are not
+	present in actual program. This is done to apply parallelism to block of
+	code.
+
+	For non-artifical functions, DW_AT_name attribute should contains the name
+	exactly as present in actual program.
+	(Ref# http://wiki.dwarfstd.org/index.php?title=Best_Practices)
+	Since artificial functions are not present in actual program they not having
+	DW_AT_name and having DW_AT_linkage_name instead should be fine.
+
+	Currently GDB is invalidating any function not havnig DW_AT_name which is why
+	it is not able to debug OpenMP (Clang).
+
+	It should be fair to fallback to check DW_AT_linkage_name in case DW_AT_name
+	is absent.
+
+2022-05-22  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-21  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-20  Pedro Alves  <pedro@palves.net>
+
+	Rename base_breakpoint -> code_breakpoint
+	Even after the previous patches reworking the inheritance of several
+	breakpoint types, the present breakpoint hierarchy looks a bit
+	surprising, as we have "breakpoint" as the superclass, and then
+	"base_breakpoint" inherits from "breakpoint".  Like so, simplified:
+
+	   breakpoint
+	       base_breakpoint
+	          ordinary_breakpoint
+		  internal_breakpoint
+		  momentary_breakpoint
+		  ada_catchpoint
+		  exception_catchpoint
+	       tracepoint
+	       watchpoint
+	       catchpoint
+		  exec_catchpoint
+		  ...
+
+	The surprising part to me is having "base_breakpoint" being a subclass
+	of "breakpoint".  I'm just refering to naming here -- I mean, you'd
+	expect that it would be the top level baseclass that would be called
+	"base".
+
+	Just flipping the names of breakpoint and base_breakpoint around
+	wouldn't be super great for us, IMO, given we think of every type of
+	*point as a breakpoint at the user visible level.  E.g., "info
+	breakpoints" shows watchpoints, tracepoints, etc.  So it makes to call
+	the top level class breakpoint.
+
+	Instead, I propose renaming base_breakpoint to code_breakpoint.  The
+	previous patches made sure that all code breakpoints inherit from
+	base_breakpoint, so it's fitting.  Also, "code breakpoint" contrasts
+	nicely with a watchpoint also being typically known as a "data
+	breakpoint".
+
+	After this commit, the resulting hierarchy looks like:
+
+	   breakpoint
+	       code_breakpoint
+	          ordinary_breakpoint
+		  internal_breakpoint
+		  momentary_breakpoint
+		  ada_catchpoint
+		  exception_catchpoint
+	       tracepoint
+	       watchpoint
+	       catchpoint
+		  exec_catchpoint
+		  ...
+
+	... which makes a lot more sense to me.
+
+	I've left this patch as last in the series in case people want to
+	bikeshed on the naming.
+
+	"code" has a nice property that it's exactly as many letters as
+	"base", so this patch didn't require any reindentation.  :-)
+
+	Change-Id: Id8dc06683a69fad80d88e674f65e826d6a4e3f66
+
+2022-05-20  Pedro Alves  <pedro@palves.net>
+
+	Test "set multiple-symbols on" creating multiple breakpoints
+	To look for code paths that lead to create_breakpoints_sal creating
+	multiple breakpoints, I ran the whole testsuite with this hack:
+
+	  --- a/gdb/breakpoint.c
+	  +++ b/gdb/breakpoint.c
+	  @@ -8377,8 +8377,7 @@ create_breakpoints_sal (struct gdbarch *gdbarch,
+				  int from_tty,
+				  int enabled, int internal, unsigned flags)
+	   {
+	  -  if (canonical->pre_expanded)
+	  -    gdb_assert (canonical->lsals.size () == 1);
+	  +  gdb_assert (canonical->lsals.size () == 1);
+
+	surprisingly, the assert never failed...
+
+	The way to get to create_breakpoints_sal with multiple lsals is to use
+	"set multiple-symbols ask" and then select multiple options from the
+	menu, like so:
+
+	 (gdb) set multiple-symbols ask
+	 (gdb) b overload1arg
+	 [0] cancel
+	 [1] all
+	 [2] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg()
+	 [3] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(char)
+	 [4] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(double)
+	 [5] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(float)
+	 [6] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(int)
+	 [7] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(long)
+	 [8] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(short)
+	 [9] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(signed char)
+	 [10] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(unsigned char)
+	 [11] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(unsigned int)
+	 [12] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(unsigned long)
+	 [13] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(unsigned short)
+	 > 2-3
+	 Breakpoint 2 at 0x1532: file /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc, line 107.
+	 Breakpoint 3 at 0x154b: file /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc, line 110.
+	 warning: Multiple breakpoints were set.
+	 Use the "delete" command to delete unwanted breakpoints.
+
+	... which would trigger the assert.
+
+	This commit makes gdb.cp/ovldbreak.exp test this scenario.  It does
+	that by making set_bp_overloaded take a list of expected created
+	breakpoints rather than just one breakpoint.  It converts the
+	procedure to use gdb_test_multiple instead of send_gdb/gdb_expect
+	along the way.
+
+	Change-Id: Id87d1e08feb6670440d926f5344e5081f5e37c8e
+
+2022-05-20  Pedro Alves  <pedro@palves.net>
+
+	Make sure momentary breakpoints are always thread-specific
+	This adds a new ctor to momentary_breakpoints with a few parameters
+	that are always necessary for momentary breakpoints.
+
+	In particular, I noticed that set_std_terminate_breakpoint doesn't
+	make the breakpoint be thread specific, which looks like a bug to me.
+
+	The point of that breakpoint is to intercept std::terminate calls that
+	happen as result of the called thread throwing an exception that won't
+	be caught by the dummy frame.  If some other thread calls
+	std::terminate, IMO, it's no different from some other thread calling
+	exit/_exit, for example.
+
+	Change-Id: Ifc5ff4a6d6e58b8c4854d00b86725382d38a1a02
+
+2022-05-20  Pedro Alves  <pedro@palves.net>
+
+	Momentary breakpoints should have no breakpoint number
+	Momentary breakpoints have no breakpoint number, their breakpoint
+	number should be always 0, to avoid constantly incrementing (or
+	decrementing) the internal breakpoint count.
+
+	Indeed, set_momentary_breakpoint installs the created breakpoint
+	without a number.
+
+	However, momentary_breakpoint_from_master incorrectly gives an
+	internal breakpoint number to the new breakpoint.  This commit fixes
+	that.
+
+	Change-Id: Iedcae5432cdf232db9e9a6e1a646d358abd34f95
+
+2022-05-20  Pedro Alves  <pedro@palves.net>
+
+	Add/tweak intro comments of struct breakpoint and several subclasses
+	This tweaks the intro comments of the following classes:
+
+	 internal_breakpoint
+	 momentary_breakpoint
+	 breakpoint
+	 base_breakpoint
+	 watchpoint
+	 catchpoint
+
+	Change-Id: If6b31f51ebbb81705fbe5b8435f60ab2c88a98c8
+
+2022-05-20  Pedro Alves  <pedro@palves.net>
+
+	Move add_location(sal) to base_breakpoint
+	After the previous patches, only base_breakpoint subclasses use
+	add_location(sal), so we can move it to base_breakpoint (a.k.a. base
+	class for code breakpoints).
+
+	This requires a few casts here and there, but always at spots where
+	you can see from context what the breakpoint's type actually is.
+
+	I inlined new_single_step_breakpoint into its only caller exactly for
+	this reason.
+
+	I did try to propagate more use of base_breakpoint to avoid casts, but
+	that turned out unwieldy for this patch.
+
+	Change-Id: I49d959322b0fdce5a88a216bb44730fc5dd7c6f8
+
+2022-05-20  Pedro Alves  <pedro@palves.net>
+
+	Move common bits of catchpoint/exception_catchpoint to breakpoint's ctor
+	Move common bits of catchpoint and exception_catchpoint to
+	breakpoint's ctor, to avoid duplicating code.
+
+	Change-Id: I3a115180f4d496426522f1d89a3875026aea3cf2
+
+2022-05-20  Pedro Alves  <pedro@palves.net>
+
+	Make catchpoint inherit breakpoint, eliminate init_raw_breakpoint
+	struct catchpoint's ctor currently calls init_raw_breakpoint, which is
+	a bit weird, as that ctor-like function takes a sal argument, but
+	catchpoints don't have code locations.
+
+	Instead, make struct catchpoint's ctor add the catchpoint's dummy
+	location using add_dummy_location.
+
+	init_raw_breakpoint uses add_location under the hood, and with a dummy
+	sal it would ultimately use the breakpoint's gdbarch for the
+	location's gdbarch, so replace the references to loc->gdbarch (which
+	is now NULL) in syscall_catchpoint to references to the catchpoint's
+	gdbarch.
+
+	struct catchpoint's ctor was the last user of init_raw_breakpoint, so
+	this commit eliminates the latter.
+
+	Since catchpoint locations aren't code locations, make struct
+	catchpoint inherit struct breakpoint instead of base_breakpoint.  This
+	let's us delete the tracepoint::re_set override too.
+
+	Change-Id: Ib428bf71efb09fdaf399c56e4372b0f41d9c5869
+
+2022-05-20  Pedro Alves  <pedro@palves.net>
+
+	Make breakpoint_address_bits look at the location kind
+	Software watchpoints allocate a special dummy location using
+	software_watchpoint_add_no_memory_location, and then
+	breakpoint_address_bits checks whether the location is that special
+	location to decide whether the location has a meaninful address to
+	print.
+
+	Introduce a new bp_loc_software_watchpoint location kind, and make
+	breakpoint_address_bits use bl_address_is_meaningful instead, which
+	returns false for bp_loc_other, which is in accordance with we
+	document for bp_location::address:
+
+	  /* (... snip ...)  Valid for all types except
+	     bp_loc_other.  */
+	  CORE_ADDR address = 0;
+
+	Rename software_watchpoint_add_no_memory_location to
+	add_dummy_location, and simplify it.  This will be used by catchpoints
+	too in a following patch.
+
+	Note that neither "info breakpoints" nor "maint info breakpoints"
+	actually prints the addresses of watchpoints, but I think it would be
+	useful to do so in "maint info breakpoints".  This approach let's us
+	implement that in the future.
+
+	Change-Id: I50e398f66ef618c31ffa662da755eaba6295aed7
+
+2022-05-20  Pedro Alves  <pedro@palves.net>
+
+	Make exception_catchpoint inherit base_breakpoint instead of catchpoint
+	exception_catchpoint is really a code breakpoint, with locations set
+	by sals, re-set like other code breakpoints, etc., so make it inherit
+	base_breakpoint.
+
+	This adds a bit of duplicated code to exception_catchpoint's ctor
+	(copied from struct catchpoint's ctor), but it will be eliminated in a
+	following patch.
+
+	Change-Id: I9fbb2927491120e9744a4f5e5cb5e6870ca07009
+
+2022-05-20  Pedro Alves  <pedro@palves.net>
+
+	Refactor momentary breakpoints, eliminate set_raw_breakpoint{,_without_location}
+	This commit makes set_momentary_breakpoint allocate the breakpoint
+	type without relying on set_raw_breakpoint, and similarly,
+	momentary_breakpoint_from_master not rely on
+	set_raw_breakpoint_without_location.  This will let us convert
+	init_raw_breakpoint to a ctor in a following patch.
+
+	The comment about set_raw_breakpoint being used in gdbtk sources is
+	stale.  gdbtk no longer uses it.
+
+	Change-Id: Ibbf77731e4b22e18ccebc1b5799bbec0aff28c8a
+
+2022-05-20  Pedro Alves  <pedro@palves.net>
+
+	Refactor set_internal_breakpoint / internal_breakpoint ctor
+	This moves initialization of internal_breakpoint's breakpoint fields
+	to internal_breakpoint's ctor, and stops using
+	new_breakpoint_from_type for internal_breakpoint breakpoints.
+
+	Change-Id: I898ed0565f47cb00e4429f1c6446e6f9a385a78d
+
+2022-05-20  Pedro Alves  <pedro@palves.net>
+
+	Convert init_ada_exception_catchpoint to a ctor
+	Currently, init_ada_exception_catchpoint is defined in breakpoint.c, I
+	presume so it can call the static describe_other_breakpoints function.
+	I think this is a dependency inversion.
+	init_ada_exception_catchpoint, being code specific to Ada catchpoints,
+	should be in ada-lang.c, and describe_other_breakpoints, a core
+	function, should be exported.
+
+	And then, we can convert init_ada_exception_catchpoint to an
+	ada_catchpoint ctor.
+
+	Change-Id: I07695572dabc5a75d3d3740fd9b95db1529406a1
+
+2022-05-20  Pedro Alves  <pedro@palves.net>
+
+	Make ada_catchpoint_location's owner ctor parameter be ada_catchpoint
+	This commit changes ada_catchpoint_location's ctor from:
+
+	  ada_catchpoint_location (breakpoint *owner)
+
+	to:
+
+	  ada_catchpoint_location (ada_catchpoint *owner)
+
+	just to make the code better document intention.
+
+	To do this, we need to move the ada_catchpoint_location type's
+	definition to after ada_catchpoint is defined, otherwise the compiler
+	doesn't know that ada_catchpoint is convertible to struct breakpoint.
+
+	Change-Id: Id908b2e38bde30b262381e00c5637adb9bf0129d
+
+2022-05-20  Pedro Alves  <pedro@palves.net>
+
+	init_breakpoint_sal -> base_breakpoint::base_breakpoint
+	This converts init_breakpoint_sal to a base_breakpoint constructor.
+
+	It removes a use of init_raw_breakpoint.
+
+	To avoid manually adding a bunch of parameters to
+	new_breakpoint_from_type, and manually passing them down to the
+	constructors of a number of different base_breakpoint subclasses, make
+	new_breakpoint_from_type a variable template function.
+
+	Change-Id: I4cc24133ac4c292f547289ec782fc78e5bbe2510
+
+2022-05-20  Pedro Alves  <pedro@palves.net>
+
+	Remove "internal" parameter from a couple functions
+	None of init_breakpoint_sal, create_breakpoint_sal, and
+	strace_marker_create_breakpoints_sal make use of their "internal"
+	parameter, so remove it.
+
+	Change-Id: I943f3bb44717ade7a7b7547edf8f3ff3c37da435
+
+2022-05-20  Pedro Alves  <pedro@palves.net>
+
+	More breakpoint_ops parameter elimination
+	Remove breakpoint_ops parameters from a few functions that don't need
+	it.
+
+	Change-Id: Ifcf5e1cc688184acbf5e19b8ea60138ebe63cf28
+
+2022-05-20  Pedro Alves  <pedro@palves.net>
+
+	Make a few functions work with base_breakpoint instead of breakpoint
+	This makes tracepoints inherit from base_breakpoint, since their
+	locations are code locations.  If we do that, then we can eliminate
+	tracepoint::re_set and tracepoint::decode_location, as they are doing
+	the same as the base_breakpoint implementations.
+
+	With this, all breakpoint types created by new_breakpoint_from_type
+	are code breakpoints, i.e., base_breakpoint subclasses, and thus we
+	can make it return a base_breakpoint pointer.
+
+	Finally, init_breakpoint_sal can take a base_breakpoint pointer as
+	"self" pointer too.  This will let us convert this function to a
+	base_breakpoint ctor in a following patch.
+
+	Change-Id: I3a4073ff1a4c865f525588095c18dc42b744cb54
+
+2022-05-20  Pedro Alves  <pedro@palves.net>
+
+	ranged_breakpoint: move initialization to ctor
+	Move initialization of ranged_breakpoint's fields to its ctor.
+
+	Change-Id: If7b842861f3cc6a429ea329d45598b5852283ba3
+
+2022-05-20  Pedro Alves  <pedro@palves.net>
+
+	ranged_breakpoint: use install_breakpoint
+	This commit replaces a chunk of code in break_range_command by an
+	equivalent call to install_breakpoint.
+
+	Change-Id: I31c06cabd36f5be91740aab029265f678aa78e35
+
+2022-05-20  Pedro Alves  <pedro@palves.net>
+
+	ranged_breakpoint: don't use init_raw_breakpoint
+	ranged_breakpoint's ctor already sets the breakpoint's type to
+	bp_hardware_breakpoint.
+
+	Since this is a "regular" breakpoint, b->pspace should remain NULL.
+
+	Thus, the only thing init_raw_breakpoint is needed for, is to add the
+	breakpoint's location.  Do that directly.
+
+	Change-Id: I1505de94c3919881c2b300437e2c0da9b05f76bd
+
+2022-05-20  Pedro Alves  <pedro@palves.net>
+
+	Make structs breakpoint/base_breakpoint/catchpoint be abstract
+	You should never instanciate these types directly.
+
+	Change-Id: I8086c74c415eadbd44924bb0ef20f34b5b97ee6f
+
+2022-05-20  Pedro Alves  <pedro@palves.net>
+
+	add_location_to_breakpoint -> breakpoint::add_location
+	Make add_location_to_breakpoint be a method of struct breakpoint.
+
+	A patch later in the series will move this to base_breakpoint, but for
+	now, it needs to be here.
+
+	Change-Id: I5bdc2ec1a7c2d66f26f51bf6f6adc8384a90b129
+
+2022-05-20  Carl Love  <cel@us.ibm.com>
+
+	PowerPC: Make test gdb.arch/powerpc-power10.exp Endian independent.
+	The .quad statement stores the 64-bit hex value in Endian order.  When used
+	to store a 64-bit prefix instructions on Big Endian (BE) systems, the .quad
+	statement stores the 32-bit suffix followed by the 32-bit prefix rather
+	than the expected order of prefix word followed by the suffix word.  GDB
+	fetches 32-bits at a time when disassembling instructions.  The disassembly
+	on BE gets messed up since GDB fetches the suffix first and interprets it
+	as a word instruction not a prefixed instruction.  When gdb fetches the
+	prefix part of the instruction, following the initial suffix word, gdb
+	associates the prefix word incorrectly with the following 32-bits as the
+	suffix for the instruction when in fact it is the following instruction.
+
+	For example on BE we have two prefixed instructions stored using the
+	.quad statement as follows:
+
+	 addr    word                GDB action
+	---------------------------------------------
+	  1      suffix inst A   <- GDB interprets as a word instruction
+	  2      prefix inst A   <- GDB uses this prefix with
+
+	  3      suffix inst B   <- this suffix rather than the suffix at addr 1.
+	  4      prefix inst B
+
+	This patch changes the .quad statement into two .longs to explicitly store
+	the prefix followed by the suffix of the instruction.
+
+	The patch rearranges the instructions to put all of the word instructions
+	together followed by the prefix instructions for clarity.
+
+	The patch has been tested on Power 10 and Power 7 BE and LE to verify
+	the change works as expected.
+
+2022-05-20  Tom Tromey  <tromey@adacore.com>
+
+	Remove obsolete text from documentation
+	The documentation says that -enable-pretty-printing is experimental in
+	7.0 and may change -- that's long enough ago that I think we can say
+	that this text is no longer correct or useful.
+
+2022-05-20  Nick Clifton  <nickc@redhat.com>
+
+	Stop readekf and objdump from aggressively following links.
+		* dwarf.c (dwarf_select_sections_by_names): Return zero if no
+		sections were selected.
+		(dwarf_select_sections_by_letters): Likewise.
+		* dwarf.h: (dwarf_select_sections_by_names): Update prototype.
+		(dwarf_select_sections_by_letters): Update prototype.
+		* objdump.c (might_need_separate_debug_info): New function.
+		(dump_bfd): Call new function before attempting to load separate
+		debug info files.
+		(main): Do not enable dwarf section dumping for -WK or -WN.
+		* readelf.c (parse_args): Do not enable dwarf section dumping for
+		-wK or -wN.
+		(might_need_separate_debug_info): New function.
+		(process_object): Call new function before attempting to load
+		separate debug info files.
+		* testsuite/binutils-all/debuginfo.exp: Expect -WE and -wE
+		debuginfod tests to pass.
+		* testsuite/binutils-all/objdump.Wk: Add extra regexps.
+		* testsuite/binutils-all/readelf.k: Add extra regexps.
+
+2022-05-20  Jia-Wei Chen  <jiawei@iscas.ac.cn>
+
+	RISC-V: Update zfinx implement with zicsr.
+	Update zfinx implement with zicsr, fix missing fcsr use by zfinx.
+	add zicsr imply by zfinx.
+
+	bfd/ChangeLog:
+
+	        * elfxx-riscv.c: New imply.
+
+	gas/ChangeLog:
+
+	        * testsuite/gas/riscv/csr-insns-pseudo-zfinx.d: New test.
+
+	opcodes/ChangeLog:
+
+	        * riscv-opc.c: Update insn class.
+
+2022-05-20  Tsukasa OI  <research_trasio@irq.a4lg.com>
+
+	RISC-V: Remove RV128-only fmv instructions
+	As fmv.x.q and fmv.q.x instructions are RV128-only (not RV64-only),
+	it should be removed until RV128 support for GNU Binutils is required
+	again.
+
+	gas/ChangeLog:
+
+		* testsuite/gas/riscv/fmv.x.q-rv64-fail.d: New failure test.
+		* testsuite/gas/riscv/fmv.x.q-rv64-fail.l: Likewise.
+		* testsuite/gas/riscv/fmv.x.q-rv64-fail.s: Likewise.
+
+	include/ChangeLog:
+
+		* opcode/riscv-opc.h (MATCH_FMV_X_Q, MASK_FMV_X_Q,
+		MATCH_FMV_Q_X, MASK_FMV_Q_X): Remove RV128-only instructions.
+
+	opcodes/ChangeLog:
+
+		* riscv-opc.c (riscv_opcodes): Remove RV128-only instructions.
+
+2022-05-20  Aditya Vidyadhar Kamath  <ADITYA.VIDYADHAR.KAMATH@ibm.com>
+
+	Fix non-pointer type compilation error in aix-thread.c
+	In aix-thread.c we use ms->value_address () to get the symbol address.
+	This triggers the following compiler error...
+
+	     base operand of '->'  has non-pointer type 'bound_minimal_symbol'
+
+	... because ms is not a pointer.
+
+	This commit fixes this error by using ms.value_address () instead.
+
+2022-05-20  Steinar H. Gunderson  <sesse@google.com>
+
+	add a trie to map quickly from address range to compilation unit
+	When using perf to profile large binaries, _bfd_dwarf2_find_nearest_line()
+	becomes a hotspot, as perf wants to get line number information
+	(for inline-detection purposes) for each and every sample. In Chromium
+	in particular (the content_shell binary), this entails going through
+	475k address ranges, which takes a long time when done repeatedly.
+
+	Add a radix-256 trie over the address space to quickly map address to
+	compilation unit spaces; for content_shell, which is 1.6 GB when some
+	(but not full) debug information turned is on, we go from 6 ms to
+	0.006 ms (6 µs) for each lookup from address to compilation unit, a 1000x
+	speedup.
+
+	There is a modest RAM increase of 180 MB in this binary (the existing
+	linked list over ranges uses about 10 MB, and the entire perf job uses
+	between 2–3 GB for a medium-size profile); for smaller binaries with few
+	ranges, there should be hardly any extra RAM usage at all.
+
+2022-05-20  Alan Modra  <amodra@gmail.com>
+
+	Tidy warn-execstack handling
+	Make ld and bfd values consistent by swapping values 0 and 2 in
+	link_info.warn_execstack.  This has the benefit of making the value an
+	"extended" boolean, with 0 meaning no warning, 1 meaning warn, other
+	values a conditional warning.
+
+	Yes, this patch introduces fails on arm/aarch64.  Not a problem with
+	this patch but an arm/aarch64 before_parse problem.
+
+	bfd/
+		* elflink.c (bfd_elf_size_dynamic_sections): Adjust
+		warn_execstack test.
+	include/
+		* bfdlink.h (warn_execstack): Swap 0 and 2 meaning.
+	ld/
+		* configure.ac (DEFAULT_LD_WARN_EXECSTACK): Use values of 0,
+		1, 2 consistent with link_info.warn_execstack.
+		* ld.texi: Typo fixes.
+		* lexsup.c (parse_args): Adjust setting of link_info.warn_execstack.
+		(elf_static_list_options): Adjust help message conditions.
+		* configure: Regenerate.
+
+2022-05-20  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-19  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>
+
+	arm: Fix system register fpcxt_ns and fpcxt_s naming convention.
+	The current assembler accepts system registers FPCXTNS and FPCXTS for Armv8.1-M
+	Mainline Instructions VSTR, VLDR, VMRS and VMSR.
+	Assembler should be also allowing FPCXT_NS, fpcxt_ns, fpcxtns, FPCXT_S, fpcxt_s
+	and fpcxts. This patch fixes the issue.
+
+2022-05-19  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/doc: use @value{GDBP} in 'info pretty-printer' example
+	Update the 'info pretty-printer' example in the manual to make use of
+	@value{GDBP} instead of hard-coding '(gdb)'.
+
+2022-05-19  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/doc: make use of group/end group in 'info pretty-printers' example
+	The 'info pretty-printers' example is pretty long and consists of many
+	commands and their output.
+
+	Currently, when the pdf manual is generated this example spans a
+	page-break, with the page-break falling part way through some example
+	output from GDB.
+
+	This commit breaks up the example using @group .... @end group, within
+	each group is a single GDB command and all its output.
+
+	Now, when the pdf manual is created, the page-break is placed after
+	the output of one GDB command, and before the subsequent command, this
+	looks much nicer.
+
+2022-05-19  Nikolaos Chatzikonstantinou  <nchatz314@gmail.com>
+
+	gdb/doc: fix inconsistent info pretty-printer example
+	The example for 'info pretty-printer' in the manual passes an
+	object-regexp in some cases, but presents output as though no
+	object-regexp was passed.
+
+	This commit fixes the two mistakes, in one case, fixing the output to
+	filter based on object-regexp, and in the other, to remove the
+	object-regexp from the command and leave all the output.
+
+2022-05-19  Nick Clifton  <nickc@redhat.com>
+
+	Fix potentially uninitialised variables in the Windows tools
+
+2022-05-19  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: testsuite: Support displaced stepping on LoongArch
+	When execute the following command on LoongArch:
+
+	  make check-gdb TESTS="gdb.base/async-shell.exp"
+
+	we can see the following message in gdb/testsuite/gdb.sum:
+
+	  UNSUPPORTED: gdb.base/async-shell.exp: displaced stepping
+
+	modify support_displaced_stepping to support displaced stepping
+	on LoongArch.
+
+	With this patch:
+
+	  PASS: gdb.base/async-shell.exp: run &
+	  PASS: gdb.base/async-shell.exp: shell echo foo
+	  PASS: gdb.base/async-shell.exp: interrupt
+	  PASS: gdb.base/async-shell.exp: process stopped
+
+	I did the following tests that use support_displaced_stepping
+	with this patch on LoongArch, there is no failed testcases.
+
+	loongson@linux:~/gdb.git$ grep -r support_displaced_stepping gdb/testsuite/gdb.*
+	gdb/testsuite/gdb.arch/disp-step-insn-reloc.exp:if { ![support_displaced_stepping] } {
+	gdb/testsuite/gdb.base/step-over-no-symbols.exp:    if { $displaced != "off" && ![support_displaced_stepping] } {
+	gdb/testsuite/gdb.base/moribund-step.exp:if { ![support_displaced_stepping] } {
+	gdb/testsuite/gdb.base/async-shell.exp:if { ![support_displaced_stepping] } {
+	gdb/testsuite/gdb.base/inferior-died.exp:if { ![support_displaced_stepping] } {
+	gdb/testsuite/gdb.base/step-over-syscall.exp:        if {$displaced == "on" && ![support_displaced_stepping]} {
+	gdb/testsuite/gdb.mi/mi-watch-nonstop.exp:if { ![support_displaced_stepping] } {
+	gdb/testsuite/gdb.mi/mi-ns-stale-regcache.exp:if { ![support_displaced_stepping] } {
+	gdb/testsuite/gdb.mi/mi-nonstop.exp:if { ![support_displaced_stepping] } {
+	gdb/testsuite/gdb.mi/mi-nsmoribund.exp:if { ![support_displaced_stepping] } {
+	gdb/testsuite/gdb.mi/mi-nsintrall.exp:if { ![support_displaced_stepping] } {
+	gdb/testsuite/gdb.mi/mi-nsthrexec.exp:if { ![support_displaced_stepping] } {
+	gdb/testsuite/gdb.mi/mi-nonstop-exit.exp:if { ![support_displaced_stepping] } {
+	gdb/testsuite/gdb.multi/watchpoint-multi.exp:if [support_displaced_stepping] {
+	gdb/testsuite/gdb.python/py-evthreads.exp:if { ![support_displaced_stepping] } {
+	gdb/testsuite/gdb.threads/step-over-lands-on-breakpoint.exp:    if { $displaced != "off" && ![support_displaced_stepping] } {
+	gdb/testsuite/gdb.threads/interrupt-while-step-over.exp:    if { ${displaced-stepping} != "off" && ![support_displaced_stepping] } {
+	gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.exp:    if { $displaced != "off" && ![support_displaced_stepping] } {
+
+2022-05-19  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdbsupport: fix path_join crash with -std=c++17 and -D_GLIBCXX_DEBUG
+	When building GDB with -std=c++17 and -D_GLIBCXX_DEBUG=1, I get:
+
+	  $ ./gdb -nx --data-directory=data-directory -q -ex "maint selftest path_join"
+	  /usr/include/c++/11.2.0/string_view:233: constexpr const value_type& std::basic_string_view<_CharT, _Traits>::operator[](std::basic_string_view<_CharT, _Traits>::size_type) const [with _CharT = char; _Traits = std::char_traits<char>; std::basic_string_view<_CharT, _Traits>::const_reference = const char&; std::basic_string_view<_CharT, _Traits>::size_type = long unsigned int]: Assertion  '__pos < this->_M_len' failed.
+
+	The problem is that we're passing an empty string_view to
+	IS_ABSOLUTE_PATH.  IS_ABSOLUTE_PATH accesses [0] on that string_view,
+	which is out-of-bounds.
+
+	The reason this is not seen with -std less than c++17 is that our local
+	copy of string_view (used with C++ < 17) does not have the assert in
+	operator[], as that wouldn't work in a constexpr method:
+
+	  https://gitlab.com/gnutools/binutils-gdb/-/blob/5890af36e5112bcbb8d7555e63570f68466e6944/gdbsupport/gdb_string_view.h#L180
+
+	IS_ABSOLUTE_PATH is normally used with null-terminated string.  It's
+	fine to pass an empty null-terminated string to IS_ABSOLUTE_PATH,
+	because index 0 in such a string is valid.  But not with an empty
+	string_view.
+
+	Fix that by avoiding the "call" to IS_ABSOLUTE_PATH if the string_view
+	is empty.
+
+	Change-Id: Idf4df961b63f513b3389235e93814c02b89ea32e
+
+2022-05-19  Jan Beulich  <jbeulich@suse.com>
+
+	Arm64: force emission of ILP32-dependent relocs
+	Like the placeholder types added in 04dfe7aa5217 ("Arm64: follow-on to
+	PR gas/27217 fix"), these are also placeholders which are subsequently
+	resolved (albeit later, hence this being a separate issue). As for the
+	resolved types 1 is returned, these pseudo-relocs should also have 1
+	returned to force retaining of the [eventual] relocations. This is also
+	spelled out individually for each of them in md_apply_fix().
+
+2022-05-19  Jan Beulich  <jbeulich@suse.com>
+
+	COFF: use hash for string table also when copying / stripping
+	Otherwise the string table may grow and hence e.g. change a final binary
+	(observed with PE/COFF ones) even if really there's no change. Doing so
+	in fact reduces the overall amount of code, and in particular the number
+	of places which need to remain in sync.
+
+	Afaics there's no real equivalent to the "traditional_format" field used
+	when linking, so hashing is always enabled when copying / stripping.
+
+2022-05-19  Jan Beulich  <jbeulich@suse.com>
+
+	COFF/PE: keep linker version during objcopy / strip
+	Neither of the tools is really a linker, so whatever was originally
+	recorded should be retained rather than being overwritten by these
+	tools' versions.
+
+	COFF/PE: don't leave zero timestamp after objcopy / strip
+	Fill the timestamp field suitably for _bfd_XXi_only_swap_filehdr_out().
+	Instead of re-arranging the present if(), fold this logic with that of
+	copying the optional header.
+
+2022-05-19  Jan Beulich  <jbeulich@suse.com>
+
+	COFF: make objcopy / strip honor --keep-file-symbols
+	So far this option had no effect when used together with e.g.
+	--strip-debug. Set BSF_FILE on these symbols to change that.
+
+	While altering this also join two adjacent blocks of case labeled
+	statements with identical code.
+
+2022-05-19  Jan Beulich  <jbeulich@suse.com>
+
+	don't over-align file positions of PE executable sections
+	When a sufficiently small alignment was specified via --file-alignment,
+	individual section alignment shouldn't affect placement within the file.
+	This involves first of all clearing D_PAGED for images when section and
+	file alignment together don't permit paging of the image. The involved
+	comparison against COFF_PAGE_SIZE in turn helped point out (through a
+	compiler warning) that 'page_size' should be of unsigned type (as in
+	particular FileAlignment is). This yet in turn pointed out a dubious
+	error condition (which is being deleted).
+
+	For the D_PAGED case I think the enforced file alignment may still be
+	too high, but I'm wary of changing that logic without knowing of
+	possible corner cases.
+
+	Furthermore file positions in PE should be independent of the alignment
+	recorded in section headers anyway. Otherwise there are e.g. anomalies
+	following commit 6f8f6017a0c4 ("PR27567, Linking PE files adds alignment
+	section flags to executables") in that linking would use information a
+	subsequent processing step (e.g. stripping) wouldn't have available
+	anymore, and hence a binary could change in that 2nd step for no actual
+	reason. (Similarly stripping a binary linked with a linker pre-dating
+	that commit would change the binary again when stripping it a 2nd time.)
+
+2022-05-19  Yvan Roux  <yvan.roux@foss.st.com>
+
+	 _bfd_real_fopen should not use ccs parameter on Windows
+		PR 25713
+		* bfdio.c (_bfd_real_fopen): Delete ccs string.
+
+2022-05-19  Tsukasa OI  <research_trasio@irq.a4lg.com>
+
+	RISC-V: Fix canonical extension order (K and J)
+	This commit fixes canonical extension order to follow the RISC-V ISA
+	Manual draft-20210402-1271737 or later.
+
+	bfd/ChangeLog:
+
+		* elfxx-riscv.c (riscv_recognized_prefixed_ext): Fix "K" extension
+		prefix to be placed before "J".
+
+2022-05-19  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-18  John Baldwin  <jhb@FreeBSD.org>
+
+	Use aarch64_features to describe register features in target descriptions.
+	Replace the sve bool member of aarch64_features with a vq member that
+	holds the vector quotient.  It is zero if SVE is not present.
+
+	Add std::hash<> specialization and operator== so that aarch64_features
+	can be used as a key with std::unordered_map<>.
+
+	Change the various functions that create or lookup aarch64 target
+	descriptions to accept a const aarch64_features object rather than a
+	growing number of arguments.
+
+	Replace the multi-dimension tdesc_aarch64_list arrays used to cache
+	target descriptions with unordered_maps indexed by aarch64_feature.
+
+2022-05-18  Jan Beulich  <jbeulich@suse.com>
+
+	Arm64: follow-on to PR gas/27217 fix
+	PR gas/27217
+
+	Prior to trying to address PR gas/28888 I noticed anomalies in how
+	certain insns would / wouldn't be affected in similar ways.
+
+	Commit eac4eb8ecb26 ("Fix a problem assembling AArch64 sources when a
+	relocation is generated against a symbol that has a defined value") had
+	two copy-and-paste mistakes, passing the wrong type to
+	aarch64_force_reloc().
+
+	It further failed to add placeholder relocation types to that function's
+	block of case labels leading to a return of 1. While not of interest for
+	aarch64_force_relocation() (these placeholders are resolved right in
+	parse_operands()), calls to aarch64_force_reloc() happen before that
+	resolution would take place.
+
+2022-05-18  Nick Clifton  <nickc@redhat.com>
+
+	Fix compile time warning building gold with Clang-14.
+		* int_encoding.cc (get_length_as_unsigned_LEB_128): Remove
+		current_length variable.
+
+2022-05-18  Victor Do Nascimento  <victor.donascimento@arm.com>
+
+	oops - forgot changelog entry for the previous delta.
+
+	arm: Add unwind support for mixed register lists
+		* config/tc-arm.c (parse_reg_list): Add handling of mixed register
+		types.
+		(reg_names): Enumerate pseudoregister according to mapped physical
+		register number.
+		(s_arm_unwind_save_pseudo): Modify function signature.
+		(s_arm_unwind_save_core): Likewise.
+		(s_arm_unwind_save_mixed): New function.
+		(s_arm_unwind_save): Generate register list mask to pass to nested
+		functions.
+		* testsuite/gas/arm/unwind-pacbti-m.s: Expand test for mixed
+	 	register type lists.
+	 	* testsuite/gas/arm/unwind-pacbti-m.d: Likewise.
+		* testsuite/gas/arm/unwind-pacbti-m-readelf.d: Likewise.
+
+2022-05-18  Carl Love  <cel@us.ibm.com>
+
+	PowerPC: bp-permanent.exp, kill-after-signal fix
+	Fix changes that didn't make it into commit:
+	dd9cd55e990bcc9f8448cac38d242d53974b3604.
+
+	Fix missing -wrap on gdb_test_multiple in gdb.base/kill-after-signal.exp
+	that is causing regression test on x86_64-linux with taskset -c 0.
+
+2022-05-18  Yichao Yu  <yyc1992@gmail.com>
+
+	[AArch64] Return the regnum for PC (32) on aarch64
+	This will allow the unwind info to explicitly specify a different value
+	for the return address from the link register.
+	Such usage, although uncommon, is valid and useful for signal frames.
+	It is also supported by aadwarf64 from ARM (Note 9 in [1]).
+
+	Ref https://sourceware.org/pipermail/gdb/2022-May/050091.html
+
+	[1] https://github.com/ARM-software/abi-aa/blob/2022Q1/aadwarf64/aadwarf64.rst#dwarf-register-names
+
+2022-05-18  Jan Beulich  <jbeulich@suse.com>
+
+	x86: shrink op_riprel
+	It is only ever initialized from a boolean, so it as well as related
+	variables' types can simply be bool and there's no masking to 32 bits
+	needed in set_op().
+
+2022-05-18  Nick Clifton  <nickc@redhat.com>
+
+	Add a --no-weak option to nm.
+		PR 29135
+		* nm.c (non_weak): New variable.
+		(filter_symbols): When non-weak is true, ignore weak symbols.
+		(long_options): Add --no-weak.
+		(usage): Mention --no-weak.
+		(main): Handle -W/--no-weak.
+		* doc/binutils.texi: Document new feature.
+		* NEWS: Mention the new feature.
+		* testsuite/binutils-all/nm.exp: Add test of new feature.
+		* testsuite/binutils-all/no-weak.s: New test source file.
+
+2022-05-18  Pedro Alves  <pedro@palves.net>
+
+	Support -prompt and -lbl in gdb_test
+	This teaches gdb_test to forward the -prompt and -lbl options to
+	gdb_test_multiple.
+
+	The option parsing is done with parse_args.
+
+	As a cleanup, instead of using llength and lindex to get at the
+	positional arguments, use lassign, and check whether the corresponding
+	variable is empty.
+
+	Convert gdb.base/ui-redirect.exp and gdb.xml/tdesc-reload.exp to use
+	gdb_test -prompt/-lbl instead of gdb_test_multiple as examples.
+
+	Change-Id: I243e1296d32c05a421ccef30b63d43a89eaeb4a0
+
+2022-05-18  Luis Machado  <luis.machado@arm.com>
+
+	Remove unused DWARF PAUTH registers
+	The AARCH64_DWARF_PAUTH_DMASK and AARCH64_DWARF_PAUTH_CMASK DWARF registers
+	never made their way into the aadwarf64. The following patch removes these
+	constants and their use.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26295
+
+2022-05-18  Luis Machado  <luis.machado@arm.com>
+
+	Rename PAUTH_RA_STATE to RA_SIGN_STATE
+	The aadwarf64 [1] names this register RA_SIGN_STATE, so update the code to use
+	the same name.
+
+	[1] https://github.com/ARM-software/abi-aa/blob/main/aadwarf64/aadwarf64.rst
+
+2022-05-18  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Simplify unknown lang testing in gdb.base/parse_number.exp
+	Move testing of language unknown out of the $supported_archs loop in
+	gdb.base/parse_number.exp.  This reduces total amount of tests from 18466 to
+	17744.
+
+	Tested on x86_64-linux.
+
+2022-05-18  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Use hex_for_lang in gdb.base/parse_number.exp
+	In gdb.base/parse_number.exp, add a new proc hex_for_lang that formats a hex
+	number appropriately for a given language.
+
+	Tested on x86_64-linux.
+
+2022-05-18  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/tdep] Add gdb/syscalls/update-linux-from-src.sh
+	Add a new script gdb/syscalls/update-linux-from-src.sh, that can be used to
+	generate *-linux.xml.in files from linux kernel sources, like so:
+	...
+	$ ./update-linux-from-src.sh ~/upstream/linux-stable.git
+	Skipping aarch64-linux.xml.in, no syscall.tbl
+	Generating amd64-linux.xml.in
+	Skipping arm-linux.xml.in, use arm-linux.py instead
+	Skipping bfin-linux.xml.in, no longer supported
+	Generating i386-linux.xml.in
+	Generating mips-n32-linux.xml.in
+	Generating mips-n64-linux.xml.in
+	Generating mips-o32-linux.xml.in
+	Generating ppc64-linux.xml.in
+	Generating ppc-linux.xml.in
+	Generating s390-linux.xml.in
+	Generating s390x-linux.xml.in
+	Generating sparc64-linux.xml.in
+	Generating sparc-linux.xml.in
+	...
+
+	Update *-linux.xml.in and *-linux.xml using linux kernel tag v5.18-rc6.
+
+2022-05-18  Tamar Christina  <tamar.christina@arm.com>
+
+	AArch64: Enable FP16 by default for Armv9-A.
+	In Armv9-A SVE is mandatory, and for SVE FP16 is mandatory.  This fixes a disconnect
+	between GCC and binutils where GCC has FP16 on by default and gas doesn't.
+
+	include/ChangeLog:
+
+	2022-05-16  Tamar Christina  <tamar.christina@arm.com>
+
+		* opcode/aarch64.h (AARCH64_ARCH_V9_FEATURES): Add AARCH64_FEATURE_F16.
+
+2022-05-18  Jan Beulich  <jbeulich@suse.com>
+
+	gas: avoid octal numbers being accepted when processing .linefile
+	Compilers would put decimal numbers there, so I think we should treat
+	finding octal numbers the same as finding bignums - ignore them as
+	actually being comments of some very specific form.
+
+2022-05-18  Jan Beulich  <jbeulich@suse.com>
+
+	gas: avoid bignum related errors when processing .linefile
+	Any construct which to the scrubber looks like a C preprocessor
+	line/file "directive" is converted to .linefile, but the amount of
+	checking the scrubber does is minimal (albeit it does let through only
+	decimal digits for the line part of the contruct). Since the scrubber
+	conversion is further tied to # being a line comment character, anything
+	which upon closer inspection turns out not to be a line/file "directive"
+	is supposed to be treated as a comment, i.e. ignored. Therefore we
+	cannot use get_absolute_expression(), as this may raise errors. Open-
+	code the function instead, treating everything not resulting in
+	O_constant as a comment as well.
+
+	Furthermore also bounds-check the parsed value. This bounds check tries
+	to avoid implementation defined behavior (which may be the raising of an
+	implementation defined signal), but for now makes the assumption that
+	int has less than 64 bits. The way bfd_signed_vma (which is what offsetT
+	aliases) is defined in bfd.h for the BFD64 case I cannot really see a
+	clean way of avoiding this assumption. Omitting the #ifdef, otoh, would
+	risk "condition is always false" warnings by compilers.
+
+	Convert get_linefile_number() to return bool at this occasion as well.
+
+2022-05-18  Jan Beulich  <jbeulich@suse.com>
+
+	gas: fold do_repeat{,_with_expander}()
+	do_repeat_with_expander() already deals with the "no expander" case
+	quite fine, so there's really little point having two functions. What it
+	lacks compared with do_repeat() is a call to sb_build(), which can
+	simply be moved (and the then redundant sb_new() be avoided). Along with
+	this moving also flip if the main if()'s condition such that the "no
+	expander" case is handled first.
+
+	gas: don't ignore .linefile inside false conditionals
+	When assembling code previously pre-processed by a C compiler, long
+	enough comments may have been collapsed into "# <line> <file>"
+	constructs. If we skip these, line numbers (and possibly even file
+	names) will be off / wrong in both diagnostics and debug info.
+
+	gas: simplify ignore_input()
+	First of all convert to switch(), in preparation of adding another
+	directive here which may not be ignored. While doing so drop dead code:
+	A string the first two characters of which do not match "if" also wont
+	match "ifdef" or "ifndef".
+
+	gas: tweak .irp and alike file/line handling for M68K/MRI
+	In commit 2ee1792bec22 ("gas: further adjust file/line handling for .irp
+	and alike") I neglected the need to omit the leading . in M68K/MRI mode.
+
+2022-05-18  Xi Ruoyao  <xry111@mengyan1223.wang>
+
+	gold: don't invoke IA32 syscall in x86_64 assembly testcase
+	pr17704a_test.s is a x86_64 assembly file, but it invokes IA32 exit
+	syscall with "int 0x80".  This causes a segfault on kernels with
+	CONFIG_IA32_EMULATION disabled.
+
+	gold/
+
+		* testsuite/pr17704a_test.s (_start): Invoke x86_64 exit syscall
+		instead of its IA32 counterpart.
+
+2022-05-18  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-17  Nikolaos Chatzikonstantinou  <nchatz314@gmail.com>
+
+	Fix typo in info page
+
+2022-05-17  Pedro Alves  <pedro@palves.net>
+
+	Fix gdb.python/py-connection.exp with remote targets
+	After the patch to make gdb_test's question non-optional when
+	specified, gdb.python/py-connection.exp started failing like so:
+
+	  $ make check TESTS="gdb.python/py-connection.exp" RUNTESTFLAGS="--target_board=native-gdbserver"
+	  (gdb) PASS: gdb.python/py-connection.exp: info connections while the connection is still around
+	  disconnect^M
+	  Ending remote debugging.^M
+	  (gdb) FAIL: gdb.python/py-connection.exp: kill the inferior
+
+	The problem is that "disconnect" when debugging with the native target
+	asks the user whether to kill the program, while with remote targets,
+	it doesn't.
+
+	Fix it by explicitly killing before disconnecting.
+
+	Tested with --target_board unix, native-gdbserver, and native-extended-gdbserver.
+
+	Change-Id: Icd85015c76deb84b71894715d43853c1087eba0b
+
+2022-05-17  Felix Willgerodt  <felix.willgerodt@intel.com>
+
+	gdb, btrace: Throw an error for empty recordings when replaying starts.
+	This makes record_btrace_start_replaying() more consistent, as it already
+	errors out e.g. on a recording with only gaps.
+
+2022-05-17  Pedro Alves  <pedro@palves.net>
+
+	Make gdb_test's question non-optional if specified
+	gdb_test supports handling scenarios where GDB asks a question before
+	finishing handling some command.  The full prototype of gdb_test is:
+
+	  # gdb_test COMMAND PATTERN MESSAGE QUESTION RESPONSE
+
+	However, QUESTION is a question that GDB _may_ ask, not one that GDB
+	_must_ ask:
+
+	 # QUESTION is a question GDB may ask in response to COMMAND, like
+	 #   "are you sure?"
+	 # RESPONSE is the response to send if QUESTION appears.
+
+	If GDB doesn't raise the question, the test still passes.
+
+	I think that this is a misfeature.  If GDB regresses and stops asking
+	a question, the testsuite won't notice.  So I think that if a QUESTION
+	is specified, gdb_test should ensure it comes out of GDB.
+
+	Running the testsuite exposed a number of tests that pass
+	QUESTION/RESPONSE to GDB, but no question comes out.  The previous
+	commits fixed them all, so this commit changes gdb_test's behavior.
+
+	A related issue is that gdb_test doesn't enforce that if you specify
+	QUESTION, that you also specify RESPONSE.  I.e., you should pass 1, 2,
+	3, or 5 arguments to gdb_test, but never 4, or more than 5.  Making
+	gdb_test detect bogus arguments actually regressed some testcases,
+	also all fixed in previous commits.
+
+	Change-Id: I47c39c9034e6a6841129312037a5ca4c5811f0db
+
+2022-05-17  Pedro Alves  <pedro@palves.net>
+
+	gdb.base/skip.exp: Don't abuse gdb_test's question support
+	gdb.base/skip.exp abuses gdb_test's support for answering a GDB
+	question to do this:
+
+	    # With gcc 9.2.0 we jump once back to main before entering foo here.
+	    # If that happens try to step a second time.
+	    gdb_test "step" "foo \\(\\) at.*" "step 3" \
+		"main \\(\\) at .*\r\n$gdb_prompt " "step"
+
+	After a patch later in this series, gdb_test will FAIL if GDB does NOT
+	issue the question, so this test would start failing on older GCCs.
+
+	Switch to using gdb_test_multiple instead.  There are three spots in
+	the file that have the same pattern, and they're actually in a
+	sequence of commands that is repeated those 3 times.  Factor all that
+	out to a procedure.
+
+	I don't have gcc 9.2 handy, but I do have gcc 6.5, and that one is
+	affected as well, so update the comment.
+
+	Change-Id: If0a7e3cdf5191b4eec95ce0c8845c3a4d801c39e
+
+2022-05-17  Pedro Alves  <pedro@palves.net>
+
+	Avoid having to unload file in gdb.server/connect-with-no-symbol-file.exp
+	gdb.server/connect-with-no-symbol-file.exp's connect_no_symbol_file
+	does:
+
+		gdb_test "file" ".*" "discard symbol table" \
+		    {Discard symbol table from `.*'\? \(y or n\) } "y"
+
+	A following patch will make gdb_test expect the question out of GDB if
+	one is passed down as argument to gdb_test.  With that, this test
+	starts failing.  This is because connect_no_symbol_file is called in a
+	loop, and the first time around, there's a loaded file, so "file" asks
+	the "Discard symbol table ... ?" question, while in the following
+	iterations there's no file, so there's no question.
+
+	Fix this by not loading a file into GDB in the first place.
+
+	Change-Id: I810c036b57842c4c5b47faf340466b0d446d1abc
+
+2022-05-17  Pedro Alves  <pedro@palves.net>
+
+	Fix bogus gdb_test invocations
+	A following patch will make gdb_test error out if bogus arguments are
+	passed, which exposed bugs in a few testcases:
+
+	 - gdb.python/py-parameter.exp, passing a spurious "1" as extra
+	   parameter, resulting in:
+
+	   ERROR: Unexpected arguments: {set test-file-param bar.txt} {The name of the file has been changed to bar.txt} {set new file parameter} 1
+
+	 - gdb.python/py-xmethods.exp, a missing test message, resulting in
+	   the next gdb_test being interpreted as message, question and
+	   response!  With the enforcing patch, this was caught with:
+
+	   ERROR: Unexpected arguments: {p g.mul<char>('a')} {From Python G<>::mul.*} gdb_test {p g_ptr->mul<char>('a')} {From Python G<>::mul.*} {after: g_ptr->mul<char>('a')}
+
+	 - gdb.base/pointers.exp, missing a quote.
+
+	Change-Id: I66f2db4412025a64121db7347dfb0b48240d46d4
+
+2022-05-17  Pedro Alves  <pedro@palves.net>
+
+	gdb.base/scope.exp: Remove bogus gdb_test questions
+	This test is abusing the QUESTION/RESPONSE feature to send an
+	alternative command to GDB if the first command fails.  Like so:
+
+	   gdb_test "print 'scope0.c'::filelocal" \
+		    "\\\$$decimal = 1" "print 'scope0.c'::filelocal at main" \
+		    "No symbol \"scope0.c\" in current context.*" \
+		    "print '$srcdir/$subdir/scope0.c'::filelocal"
+
+	So if 'scope0.c' doesn't work, we try again with
+	'$srcdir/$subdir/scope0.c'.  I strongly suspect this is really an
+	obsolete test.  I think that if '$srcdir/$subdir/scope0.c' works, then
+	'scope0.c' should have worked too, thus I'd think that if we pass due
+	to the question path, then it's a bug.  So just remove the question
+	part passed to gdb_test.
+
+	Change-Id: I2acc99285f1d519284051b49693b5441fbdfe3cd
+
+2022-05-17  Pedro Alves  <pedro@palves.net>
+
+	Remove gdb_test questions that GDB doesn't ask
+	Change-Id: Ib2616dc883e9dc9ee100f6c86d83a921a0113c16
+
+2022-05-17  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: Added half-precision floating-point v1.0 instructions.
+	bfd/
+		* elfxx-riscv.c (riscv_implicit_subsets): Added implicit f
+		and zicsr for zfh.
+		(riscv_supported_std_z_ext): Added default v1.0 version for zfh.
+		(riscv_multi_subset_supports): Handle INSN_CLASS_ZFH,
+		INSN_CLASS_D_AND_ZFH and INSN_CLASS_Q_AND_ZFH.
+	gas/
+		* config/tc-riscv.c (FLT_CHARS): Added "hH".
+		(macro): Expand Pseudo M_FLH and M_FSH.
+		(riscv_pseudo_table): Added .float16 directive.
+		* testsuite/gas/riscv/float16-be.d: New testcase for .float16.
+		* testsuite/gas/riscv/float16-le.d: Likewise.
+		* testsuite/gas/riscv/float16.s: Likewise.
+		* testsuite/gas/riscv/fp-zfh-insns.d: New testcase for zfh.
+		* testsuite/gas/riscv/fp-zfh-insns.s: Likewise.
+	include/
+		* opcode/riscv-opc.h: Added MASK and MATCH encodings for zfh.
+		* opcode/riscv.h: Added INSN_CLASS and pseudo macros for zfh.
+	opcodes/
+		* riscv-opc.c (riscv_opcodes): Added zfh instructions.
+
+2022-05-17  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-16  Ilya Leoshkevich  <iii@linux.ibm.com>
+
+	IBM zSystems: Fix left-shifting negative PCRel32 values (PR gas/29152)
+	s390_insert_operand ()'s val, min and max are encoded PCRel32 values
+	and need to be left-shifted by 1 before being shown to the user.
+	Left-shifting negative values is undefined behavior in C, but the
+	current code does not try to prevent it, causing UBSan to complain.
+
+	Fix by casting the values to their unsigned equivalents before
+	shifting.
+
+2022-05-16  Pedro Alves  <pedro@palves.net>
+
+	Reindent gdbsupport/event-loop.cc:handle_file_event
+	The handle_file_event function has a few unnecessary {} lexical
+	blocks, presumably because they were originally if blocks, and the
+	conditions were removed, or something along those lines.
+
+	Remove the unnecessary blocks, and reindent.
+
+	Change-Id: Iaecbe5c9f4940a80b81dbbc42e51ce506f6aafb2
+
+2022-05-16  Pedro Alves  <pedro@palves.net>
+
+	gdbsupport/event-loop.cc: simplify !HAVE_POLL paths
+	gdbsupport/event-loop.cc throughout handles the case of use_poll being
+	true on a system where HAVE_POLL is not defined, by calling
+	internal_error if that situation ever happens.
+
+	Simplify this by moving the "use_poll" global itself under HAVE_POLL,
+	so that it's way more unlikely to ever end up in such a situation.
+	Then, move the code that checks the value of use_poll under HAVE_POLL
+	too, and remove the internal_error calls.  Like, from:
+
+	    if (use_poll)
+	      {
+	  #ifdef HAVE_POLL
+	        // poll code
+	  #else
+	      internal_error (....);
+	  #endif /* HAVE_POLL */
+	      }
+	    else
+	      {
+		// select code
+	      }
+
+	to
+
+	  #ifdef HAVE_POLL
+	    if (use_poll)
+	      {
+	        // poll code
+	      }
+	    else
+	  #endif /* HAVE_POLL */
+	      {
+		// select code
+	      }
+
+	While at it, make use_poll be a bool.  The current code is using
+	unsigned char most probably to save space, but I don't think it really
+	matters here.
+
+	Co-Authored-By: Youling Tang <tangyouling@loongson.cn>
+	Change-Id: I0dd74fdd4d393ccd057906df4cd75e8e83c1cdb4
+
+2022-05-16  Eli Zaretskii  <eliz@gnu.org>
+
+	gdb: Fix typo in last change in gdb.texinfo
+
+	gdb: Document the 'metadata' styling in GDB displays.
+	The 'metadata' styling was never documented in the GDB manual.
+	This fills that gap.
+
+2022-05-16  Tom Tromey  <tromey@adacore.com>
+
+	Fix Ada exception regression on Windows
+	The breakpoint c++-ification series introduced another bug in Ada --
+	it caused "catch exception" and related commands to fail on Windows.
+	The problem is that the re_set method calls the wrong superclass
+	method, so the breakpoint doesn't get correctly re-set when the
+	runtime offsets change.  This patch fixes the problem.
+
+2022-05-16  Bruno Larsen  <blarsen@redhat.com>
+
+	gdb/testsuite: fix "continue outside of loop" TCL errors
+	Many test cases had a few lines in the beginning that look like:
+
+	if { condition } {
+	  continue
+	}
+
+	Where conditions varied, but were mostly in the form of ![runto_main] or
+	[skip_*_tests], making it quite clear that this code block was supposed
+	to finish the test if it entered the code block. This generates TCL
+	errors, as most of these tests are not inside loops.  All cases on which
+	this was an obvious mistake are changed in this patch.
+
+2022-05-16  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-15  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-14  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-13  Tom Tromey  <tromey@adacore.com>
+
+	Remove unused field cooked_index::m_start
+	cooked_index::m_start is unused and can be removed.  I think this was
+	a leftover from a previous approach in the index finalization code,
+	and then when rewriting it I forgot to remove it.
+
+	Tested by rebuilding.
+
+2022-05-13  Tom Tromey  <tromey@adacore.com>
+
+	Implement pid_to_exec_file for Windows in gdbserver
+	I noticed that gdbserver did not implement pid_to_exec_file for
+	Windows, while gdb did implement it.  This patch moves the code to
+	nat/windows-nat.c, so that it can be shared.  This makes the gdbserver
+	implementation trivial.
+
+	Remove windows_process_info::id
+	I noticed that windows_process_info::id is only used by gdbserver, and
+	not really necessary.  This patch removes it.
+
+	Constify target_pid_to_exec_file
+	This changes target_pid_to_exec_file and target_ops::pid_to_exec_file
+	to return a "const char *".  I couldn't build many of these targets,
+	but did examine the code by hand -- also, as this only affects the
+	return type, it's normally pretty safe.  This brings gdb and gdbserver
+	a bit closer, and allows for the removal of a const_cast as well.
+
+	Put corefile-run.core into test subdirectory
+	I noticed that corefile-run.core ends up in the 'runtest' directory.
+	It's better, when at all possible, for test files to end up in the
+	test's designated subdirectory.  This patch makes this change.
+
+2022-05-13  Tom Tromey  <tromey@adacore.com>
+
+	Do not double-read minimal symbols for PE COFF
+	This changes coffread.c to avoid re-reading minimal symbols when
+	possible.  This only works when there are no COFF symbols to be read,
+	but at least for my mingw builds of gdb, this seems to be the case.
+
+	Tested using the AdaCore internal test suite on Windows.  I also did
+	some local builds to ensure that no warnings crept in.
+
+2022-05-13  Pedro Alves  <pedro@palves.net>
+
+	Fix "gdb --write" with core files
+	If you load a core file into GDB with the --write option, or "set
+	write on" (equivalent), and then poke memory expecting it to patch the
+	core binary, you'll notice something odd -- the write seems to
+	succeed, but in reality, it doesn't.  The value you wrote doesn't
+	persist.  Like so:
+
+	 $ gdb -q --write -c testsuite/outputs/gdb.base/patch/gcore.test
+	 [New LWP 615986]
+	 Core was generated by `/home/pedro/gdb/build/gdb/testsuite/outputs/gdb.base/patch/patch'.
+	 Program terminated with signal SIGTRAP, Trace/breakpoint trap.
+	 #0  0x0000555555555131 in ?? ()
+	 (gdb) p *(unsigned char *)0x0000555555555131 = 1
+	 $1 = 1 '\001'
+	 (gdb) p *(unsigned char *)0x0000555555555131
+	 $2 = 185 '\271'
+	 (gdb)
+
+	Diffing hexdumps of before/after patching, reveals that a "0x1" was
+	actually written somewhere in the file.  The problem is that the "0x1"
+	was written at the wrong offset in the file...
+
+	That happens because _bfd_elf_set_section_contents does this to seek
+	to the section's offset:
+
+	  pos = hdr->sh_offset + offset;
+	  if (bfd_seek (abfd, pos, SEEK_SET) != 0
+	      || bfd_bwrite (location, count, abfd) != count)
+	    return false;
+
+	... and 'hdr->sh_offset' is zero, so we seek to just OFFSET, which is
+	incorrect.  The reason 'hdr->sh_offset' is zero is that
+	kernel-generated core files normally don't even have a section header
+	table (gdb-generated ones do, but that's more an accident than a
+	feature), and indeed elf_core_file_p doesn't even try to read sections
+	at all:
+
+	  /*  Core files are simply standard ELF formatted files that partition
+	      the file using the execution view of the file (program header table)
+	      rather than the linking view.  In fact, there is no section header
+	      table in a core file.
+
+	      The process status information (including the contents of the general
+	      register set) and the floating point register set are stored in a
+	      segment of type PT_NOTE.  We handcraft a couple of extra bfd sections
+	      that allow standard bfd access to the general registers (.reg) and the
+	      floating point registers (.reg2).  */
+
+	  bfd_cleanup
+	  elf_core_file_p (bfd *abfd)
+
+	Changing _bfd_elf_set_section_contents from:
+
+	  pos = hdr->sh_offset + offset;
+
+	to:
+
+	  pos = section->filepos + offset;
+
+	fixes it.  If we do that however, the tail end of
+	_bfd_elf_set_section_contents ends up as a copy of
+	_bfd_generic_set_section_contents, so just call the latter, thus
+	eliminating some duplicate code.
+
+	New GDB testcase included, which exercises both patching an executable
+	and patching a core file.  Patching an executable already works
+	without this fix, because in that case BFD reads in the sections
+	table.  Still, we had no testcase for that yet.  In fact, we have no
+	"set write on" testcases at all, this is the first one.
+
+	Tested on x86-64 GNU/Linux, gdb, ld, binutils, and gas.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18227
+	Change-Id: I0f49f58b48aabab2e269f2959b8fd8a7fe36fdce
+
+2022-05-13  Alan Modra  <amodra@gmail.com>
+
+	Import libiberty from gcc
+
+	sim: remove use of PTR
+	PTR will soon disappear from ansidecl.h.  Remove uses in sim.  Where
+	a PTR cast is used in assignment or function args to a void* I've
+	simply removed the unnecessary (in C) cast rather than replacing with
+	(void *).
+
+2022-05-13  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-13  Alan Modra  <amodra@gmail.com>
+
+	gdb: remove use of PTR
+	PTR will disappear from ansidecl.h and libiberty on the next import
+	from gcc.  Remove current uses in gdb.
+
+2022-05-12  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.cp/break-f-std-string.cc with older gcc
+	When running test-case gdb.cp/break-f-std-string.exp on openSUSE Leap 15.3
+	with system gcc 7.5.0, I run into:
+	...
+	(gdb) whatis /r std::string^M
+	No symbol "string" in namespace "std".^M
+	(gdb) FAIL: gdb.cp/break-f-std-string.exp: _GLIBCXX_USE_CXX11_ABI=1: \
+	  whatis /r std::string
+	...
+	The same for gcc 8.2.1, but it passes with gcc 9.3.1.
+
+	At source level (as we can observe in the .ii file with -save-temps) we have
+	indeed:
+	...
+	namespace std {
+	  namespace __cxx11 {
+	    typedef basic_string<char> string;
+	  }
+	}
+	...
+	while with gcc 9.3.1, we have instead:
+	...
+	namespace std {
+	  namespace __cxx11 {
+	    ...
+	  }
+	  typedef basic_string<char> string;
+	}
+	...
+	due to gcc commit 33b43b0d8cd ("Define std::string and related typedefs
+	outside __cxx11 namespace").
+
+	Fix this by adding the missing typedef for gcc version 5 (the first version to
+	have the dual abi) to 8 (the last version missing aforementioned gcc commit).
+
+	Tested on x86_64-linux, with:
+	- system gcc 7.5.0
+	- gcc 4.8.5, 8.2.1, 9.3.1, 10.3.0, 11.2.1
+	- clang 8.0.1, 12.0.1
+
+2022-05-12  Alan Modra  <amodra@gmail.com>
+
+	Fix an illegal memory access when creating DLLs.
+		PR 29006
+		* pe-dll.c (dll_name): Delete, replacing with..
+		(dll_filename): ..this, moved earlier in file.
+		(generate_edata): Delete parameters.  Don't set up dll_name here..
+		(pe_process_import_defs): ..instead set up dll_filename and
+		dll_symname here before returning.
+		(dll_symname_len): Delete write-only variable.
+		(pe_dll_generate_implib): Don't set up dll_symname here.
+
+2022-05-12  Mark Wielaard  <mark@klomp.org>
+
+	gdb: Workaround stringop-overread warning in debuginfod-support.c on powerpc64
+	Just like on s390x with g++ 11.2.1, ppc64le with g++ 11.3.1 produces a
+	spurious warning for stringop-overread in debuginfod_is_enabled
+	for url_view. Also suppress it on powerpc64.
+
+	 gdb/ChangeLog:
+
+	    * debuginfod-support.c (debuginfod_is_enabled): Use
+	      DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD on powerpc64.
+
+2022-05-12  Luis Machado  <luis.machado@arm.com>
+
+	Make gdb.ada/float-bits.exp more generic
+	There are assumptions in the test about the long double format
+	being used. While the results are OK for i387 128-bit long doubles, it
+	is not correct for IEEE quad 128-bit long doubles.
+
+	Also, depending on the target (64-bit/32-bit), long doubles may not
+	be available at all. And it may be the case that the compiler for a 64-bit
+	target doesn't support 128-bit long doubles, but GDB might still support it
+	internally.
+
+	Lastly, not every long double format has invalid values. Some formats
+	consider all values as valid floating point numbers.
+
+	These divergences cause the following FAIL's on aarch64/arm:
+
+	FAIL: gdb.ada/float-bits.exp: print val_long_double
+	FAIL: gdb.ada/float-bits.exp: print val_long_double after assignment
+
+	With the above in mind, extend the test a little so it behaves well on
+	different architectures and so it works with different long double
+	formats.
+
+	Main changes:
+
+	- Use long double values appropriate for the long double format.
+	- Test long double assignment to compiler-generated long
+	  double variables.
+	- Test long double assignment to GDB internal variables.
+
+	Tested on x86_64 (16 PASS), i686 (16 PASS), aarch64 (12 PASS) and arm (9 PASS).
+
+2022-05-12  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/tdep] Improve gdb/syscalls/update-linux.sh
+	Fix two things in update-linux.sh:
+	- remove use of unnecessary tmp file
+	- inline gen-header.py into update-linux.sh
+
+	Tested on x86_64-linux.
+
+2022-05-12  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.dwarf2/dw2-out-of-range-end-of-seq.exp on aarch64
+	On aarch64-linux, with test-case gdb.dwarf2/dw2-out-of-range-end-of-seq.exp I
+	run into:
+	...
+	(gdb) run ^M
+	Starting program: dw2-out-of-range-end-of-seq ^M
+	^M
+	Program received signal SIGILL, Illegal instruction.^M
+	main () at src/gdb/testsuite/gdb.dwarf2/main.c:1^M
+	1       /* This testcase is part of GDB, the GNU debugger.^M
+	(gdb) FAIL: gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: runto: run to main
+	...
+
+	There are two problems here:
+	- the test-case contains a hardcoded "DW_LNS_advance_pc 1" which causes the
+	  breakpoint pointing in the middle of an insn
+	- the FAIL triggers on aarch64-linux, but not on x86_64-linux, because the
+	  test-case uses 'main_label' as the address of the first and only valid entry
+	  in the line table, and:
+	  - on aarch64-linux, there's no prologue, so main_label and main coincide,
+	    while
+	  - on x86_64-linux, there's a prologue, so main_label is different from main.
+
+	Fix these problems by:
+	- eliminating the use of "DW_LNS_advance_pc 1", and using
+	  "DW_LNE_set_address $main_end" instead, and
+	- eliminating the use of main_label, using "DW_LNE_set_address $main_start"
+	  instead.
+
+	Tested on both x86_64-linux and aarch64-linux.
+
+2022-05-12  Alan Modra  <amodra@gmail.com>
+
+	cgen: increase buffer for hash_insn_list
+	As was done for hash_insn_array in commit d3d1cc7b13b4.
+
+		* cgen-dis.c (hash_insn_list): Increase size of buf.  Assert
+		size is large enough.
+
+2022-05-12  Alan Modra  <amodra@gmail.com>
+
+	PR29142, segv in ar with empty archive and libdeps specified
+		PR 29142
+		* ar.c (main): Properly handle libdeps for zero file_count.
+
+2022-05-12  Alan Modra  <amodra@gmail.com>
+
+	Re: IBM zSystems: Accept (. - 0x100000000) PCRel32 operands
+	The new test failed on s390-linux due to bfd_sprintf_vma trimming
+	output to 32 bits for 32-bit targets.  The test was faulty anyway,
+	expecting zero as the min end of the range is plainly wrong, but
+	that's what you get if you cast min to int.
+
+		* config/tc-s390.c (s390_insert_operand): Print range error using
+		PRId64.
+		* testsuite/gas/s390/zarch-z900-err.l: Correct expected output.
+
+2022-05-12  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-11  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.base/catch-syscall.exp with --with-expat=no
+	When doing a gdb build with --with-expat=no, I run into:
+	...
+	(gdb) PASS: gdb.base/catch-syscall.exp: determine pipe syscall: \
+	  continue to breakpoint: before pipe call
+	catch syscall pipe^M
+	Unknown syscall name 'pipe'.^M
+	(gdb) PASS: gdb.base/catch-syscall.exp: determine pipe syscall: \
+	  catch syscall pipe
+	catch syscall pipe2^M
+	Unknown syscall name 'pipe2'.^M
+	(gdb) PASS: gdb.base/catch-syscall.exp: determine pipe syscall: \
+	  catch syscall pipe2
+	continue^M
+	Continuing.^M
+	[Detaching after vfork from child process 18538]^M
+	[Inferior 1 (process 18537) exited normally]^M
+	(gdb) FAIL: gdb.base/catch-syscall.exp: determine pipe syscall: continue
+	...
+
+	This is a regression since recent commit 5463a15c18b ("[gdb/testsuite] Handle
+	pipe2 syscall in gdb.base/catch-syscall.exp").
+
+	Fix this by using pipe/pipe2 syscall numbers instead.
+
+	Tested on x86_64-linux.
+
+2022-05-11  Nick Clifton  <nickc@redhat.com>
+
+	nm: use -U as an alias for --defines-only, in line with llvm-nm
+
+2022-05-11  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.base/catch-syscall.exp without --enable-targets
+	When doing a gdb build without --enable-targets, I run into:
+	...
+	(gdb) UNSUPPORTED: gdb.base/catch-syscall.exp: multiple targets: \
+	  s390:31-bit vs s390:64-bit: set architecture s390:64-bit
+	delete breakpoints^M
+	(gdb) info breakpoints^M
+	No breakpoints or watchpoints.^M
+	(gdb) break -qualified main^M
+	No symbol table is loaded.  Use the "file" command.^M
+	Make breakpoint pending on future shared library load? (y or [n]) n^M
+	(gdb) FAIL: gdb.base/catch-syscall.exp: gdb_breakpoint: set breakpoint at main
+	...
+
+	The problem is that due to recent commit e21d8399303 ("[gdb/testsuite] Remove
+	target limits in gdb.base/catch-syscall.exp") "clean_restart $binfile" no
+	longer is called at the end of test_catch_syscall_multi_arch.
+
+	Fix this by moving "clean_restart $binfile" back to
+	test_catch_syscall_multi_arch.
+
+	Tested on x86_64-linux.
+
+2022-05-11  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.base/maint.exp on powerpc64le
+	On powerpc64le-linux, I ran into:
+	...
+	FAIL: gdb.base/maint.exp: maint print objfiles: symtabs
+	...
+
+	The problem is that:
+	- the "Cooked index in use" line occurs twice in the gdb output:
+	  - once for exec maint, and
+	  - once for "Object file system-supplied DSO".
+	- the matching of the second "Cooked index in use" also consumes
+	  the "Symtabs:" string, and consequently the corresponding
+	  clause does not trigger and $symtabs remains 0.
+
+	Fix this by limiting the output of the command to the exec.
+
+	Tested on x86_64-linux and powerpcle-linux.
+
+2022-05-11  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/tdep] Update syscalls/{ppc64,ppc}-linux.xml
+	Regenerate syscalls/{ppc64,ppc}-linux.xml on a system with 5.14 kernel.
+
+2022-05-11  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Remove target limits in gdb.base/catch-syscall.exp
+	In test-case gdb.base/catch-syscall.exp, proc test_catch_syscall_multi_arch we
+	test for supported targets using istarget, like so:
+	...
+	    if { [istarget "i*86-*-*"] || [istarget "x86_64-*-*"] } {
+	        ...
+	    } elseif { [istarget "powerpc-*-linux*"] \
+	                  || [istarget "powerpc64*-linux*"] } {
+	        ...
+	...
+	but the tests excercised there can all be executed if gdb is configured with
+	--enable-targets=all.
+
+	Rewrite the proc to iterate over all cases, and check if the test is supported
+	by trying "set arch $arch1" and "set arch $arch2".
+
+	Tested on x86_64-linux, with:
+	- a gdb build with --enable-targets=all, and
+	- a gdb build build with my usual --enable-targets setting (too long to
+	  include here) which means the sparc vs sparc:v9 case is unsupported.
+
+2022-05-11  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/record] Handle statx system call
+	When running test-case gdb.reverse/fstatat-reverse.exp with target board
+	unix/-m32 on openSUSE Tumbleweed, I run into:
+	...
+	(gdb) PASS: gdb.reverse/fstatat-reverse.exp: set breakpoint at marker2
+	continue^M
+	Continuing.^M
+	Process record and replay target doesn't support syscall number 383^M
+	Process record: failed to record execution log.^M
+	^M
+	Program stopped.^M
+	0xf7fc5555 in __kernel_vsyscall ()^M
+	(gdb) FAIL: gdb.reverse/fstatat-reverse.exp: continue to breakpoint: marker2
+	...
+
+	The problems is that while with native we're trying to record these syscalls
+	(showing strace output):
+	...
+	openat(AT_FDCWD, "/", O_RDONLY|O_PATH)  = 3
+	newfstatat(3, ".", {st_mode=S_IFDIR|0755, st_size=146, ...}, 0) = 0
+	...
+	with unix/-m32 we have instead:
+	...
+	openat(AT_FDCWD, "/", O_RDONLY|O_PATH)  = 3
+	statx(3, ".", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_BASIC_STATS, \
+	  {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=STATX_ATTR_MOUNT_ROOT, \
+	  stx_mode=S_IFDIR|0755, stx_size=146, ...}) = 0
+	...
+	and statx is not supported.
+
+	Fix this by adding support for recording syscall statx.
+
+	Tested on x86_64-linux.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28461
+
+2022-05-11  Alan Modra  <amodra@gmail.com>
+
+	opcodes cgen: remove use of PTR
+	Note that opcodes is regenerated with cgen commit d1dd5fcc38e reverted,
+	due to failure of bpf to compile with that patch applied.
+
+	.../opcodes/bpf-opc.c:57:11: error: conversion from ‘long unsigned int’ to ‘unsigned int’ changes value from ‘18446744073709486335’ to ‘4294902015’ [-Werror=overflow]
+	   57 |   64, 64, 0xffffffffffff00ff, { { F (F_IMM32) }, { F (F_OFFSET16) }, { F (F_SRCLE) }, { F (F_OP_CODE) }, { F (F_DSTLE) }, { F (F_OP_SRC) }, { F (F_OP_CLASS) }, { 0 } }
+	plus other similar errors.
+
+	cpu/
+		* mep.opc (print_tpreg, print_spreg): Delete unnecessary
+		forward declarations.  Replace PTR with void *.
+		* mt.opc (print_dollarhex, print_pcrel): Delete forward decls.
+	opcodes/
+		* bpf-desc.c, * bpf-dis.c, * cris-desc.c,
+		* epiphany-desc.c, * epiphany-dis.c,
+		* fr30-desc.c, * fr30-dis.c, * frv-desc.c, * frv-dis.c,
+		* ip2k-desc.c, * ip2k-dis.c, * iq2000-desc.c, * iq2000-dis.c,
+		* lm32-desc.c, * lm32-dis.c, * m32c-desc.c, * m32c-dis.c,
+		* m32r-desc.c, * m32r-dis.c, * mep-desc.c, * mep-dis.c,
+		* mt-desc.c, * mt-dis.c, * or1k-desc.c, * or1k-dis.c,
+		* xc16x-desc.c, * xc16x-dis.c,
+		* xstormy16-desc.c, * xstormy16-dis.c: Regenerate.
+
+2022-05-11  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-10  Youling Tang  <tangyouling@loongson.cn>
+
+	gdb: mips: Fix large-frame.exp test case failure
+	$ objdump -d outputs/gdb.base/large-frame/large-frame-O2
+	0000000120000b20 <func>:
+	   120000b20:   67bdbff0        daddiu  sp,sp,-16400
+	   120000b24:   ffbc4000        sd      gp,16384(sp)
+	   120000b28:   3c1c0002        lui     gp,0x2
+	   120000b2c:   679c8210        daddiu  gp,gp,-32240
+	   120000b30:   0399e02d        daddu   gp,gp,t9
+	   120000b34:   df998058        ld      t9,-32680(gp)
+	   120000b38:   ffbf4008        sd      ra,16392(sp)
+	   120000b3c:   0411ffd8        bal     120000aa0 <blah>
+	...
+
+	The disassembly of the above func function shows that we may use
+	instructions such as daddiu/daddu, so add "daddiu $gp,$gp,n",
+	"daddu $gp,$gp,$t9" and "daddu $gp,$t9,$gp" to the mips32_scan_prologue
+	function to fix the large-frame.exp test case.
+
+	Before applying the patch:
+
+	 backtrace
+	 #0  blah (a=0xfffffee220) at .../gdb/testsuite/gdb.base/large-frame-1.c:24
+	 #1  0x0000000120000b44 in func ()
+	 Backtrace stopped: frame did not save the PC
+	 (gdb) FAIL: gdb.base/large-frame.exp: optimize=-O2: backtrace
+
+	 # of expected passes            5
+	 # of unexpected failures        1
+
+	After applying the patch:
+
+	 # of expected passes            6
+
+2022-05-10  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: LoongArch: Use GDB style to check readbuf and writebuf
+	The GDB style is to write 'if (readbuf != nullptr)', and the same for
+	writebuf.
+
+2022-05-10  Tom Tromey  <tromey@adacore.com>
+
+	Fix --disable-threading build
+	PR build/29110 points out that GDB fails to build on mingw when the
+	"win32" thread model is in use.  It turns out that the Fedora cross
+	tools using the "posix" thread model, which somehow manages to support
+	std::future, whereas the win32 model does not.
+
+	While looking into this, I found that the configuring with
+	--disable-threading will also cause a build failure.
+
+	This patch fixes this build by introducing a compatibility wrapper for
+	std::future.
+
+	I am not able to test the win32 thread model build, but I'm going to
+	ask the reporter to try this patch.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29110
+
+2022-05-10  Pedro Alves  <pedro@palves.net>
+
+	Fix "b f(std::string)" when current language is C
+	If you try to set a breakpoint at a function such as "b
+	f(std::string)", and the current language is C, the breakpoint fails
+	to be set, like so:
+
+	  (gdb) set language c
+	  break f(std::string)
+	  Function "f(std::string)" not defined.
+	  Make breakpoint pending on future shared library load? (y or [n]) n
+	  (gdb)
+
+	The problem is that the code in GDB that expands the std::string
+	typedef hits this in c-typeprint.c:
+
+	      /* If we have "typedef struct foo {. . .} bar;" do we want to
+		 print it as "struct foo" or as "bar"?  Pick the latter for
+		 C++, because C++ folk tend to expect things like "class5
+		 *foo" rather than "struct class5 *foo".  We rather
+		 arbitrarily choose to make language_minimal work in a C-like
+		 way. */
+	      if (language == language_c || language == language_minimal)
+		{
+		  if (type->code () == TYPE_CODE_UNION)
+		    gdb_printf (stream, "union ");
+		  else if (type->code () == TYPE_CODE_STRUCT)
+		    {
+		      if (type->is_declared_class ())
+			gdb_printf (stream, "class ");
+		      else
+			gdb_printf (stream, "struct ");
+		    }
+		  else if (type->code () == TYPE_CODE_ENUM)
+		    gdb_printf (stream, "enum ");
+		}
+
+	I.e., std::string is expanded to "class std::..." instead of just
+	"std::...", and then the "f(class std::..." symbol doesn't exist.
+
+	Fix this by making cp-support.c:inspect_type print the expanded
+	typedef type using the language of the symbol whose type we're
+	expanding the typedefs for -- in the example in question, the
+	"std::string" typedef symbol, which is a C++ symbol.
+
+	Use type_print_raw_options as it seems to me that in this scenario we
+	always want raw types, to match the real symbol names.
+
+	Adjust the gdb.cp/break-f-std-string.exp testcase to try setting a
+	breakpoint at "f(std::string)" in both C and C++.
+
+	Change-Id: Ib54fab4cf0fd307bfd55bf1dd5056830096a653b
+
+2022-05-10  Pedro Alves  <pedro@palves.net>
+
+	Always pass an explicit language down to c_type_print
+	The next patch will want to do language->print_type(type, ...), to
+	print a type in a given language, avoiding a dependency on the current
+	language.  That doesn't work correctly currently, however, because
+	most language implementations of language_defn::print_type call
+	c_print_type without passing down the language.  There are two
+	overloads of c_print_type, one that takes a language, and one that
+	does not.  The one that does not uses the current language, defeating
+	the point of calling language->print_type()...
+
+	This commit removes the c_print_type overload that does not take a
+	language, and adjusts the codebase throughout to always pass down a
+	language.  In most places, there's already an enum language handy.
+	language_defn::print_type implementations naturally pass down
+	this->la_language.  In a couple spots, like in ada-typeprint.c and
+	rust-lang.c there's no enum language handy, but the code is written
+	for a specific language, so we just hardcode the language.
+
+	In gnuv3_print_method_ptr, I wasn't sure whether we could hardcode C++
+	here, and we don't have an enum language handy, so I made it use the
+	current language, just like today.  Can always be improved later.
+
+	Change-Id: Ib54fab4cf0fd307bfd55bf1dd5056830096a653b
+
+2022-05-10  Pedro Alves  <pedro@palves.net>
+
+	Fix "b f(std::string)", always use DMGL_VERBOSE
+	Currently, on any remotely modern GNU/Linux system,
+	gdb.cp/no-dmgl-verbose.exp fails like so:
+
+	  break 'f(std::string)'
+	  Function "f(std::string)" not defined.
+	  (gdb) FAIL: gdb.cp/no-dmgl-verbose.exp: gdb_breakpoint: set breakpoint at 'f(std::string)'
+	  break 'f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)'
+	  Function "f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)" not defined.
+	  (gdb) PASS: gdb.cp/no-dmgl-verbose.exp: DMGL_VERBOSE-demangled f(std::string) is not defined
+
+	This testcase was added back in 2011, here:
+
+	  [patch] Remove DMGL_VERBOSE
+	  https://sourceware.org/pipermail/gdb-patches/2011-June/083081.html
+
+	Back then, the testcase would pass cleanly.  It turns out that the
+	reason it fails today is that the testcase is exercising something in
+	GDB that only makes sense if the program is built for the pre-C++11
+	libstc++ ABI.  Back then the C++11 ABI didn't exist yet, but nowadays,
+	you need to compile with -D_GLIBCXX_USE_CXX11_ABI=0 to use the old
+	ABI.  See "Dual ABI" in the libstdc++ manual, at
+	<https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html>.
+
+	If we tweak the gdb.cp/no-dmgl-verbose.exp testcase to force the old
+	ABI with -D_GLIBCXX_USE_CXX11_ABI=0, then it passes cleanly.
+
+	So why is it that setting a breakpoint at "f(std::string)" fails with
+	modern ABI, but passes with old ABI?
+
+	This is where libiberty demangler's DMGL_VERBOSE option comes in.  The
+	Itanium ABI mangling scheme has a shorthand form for std::string (and
+	some other types).  See
+	<https://itanium-cxx-abi.github.io/cxx-abi/abi.html>:
+
+	  "In addition, the following catalog of abbreviations of the form "Sx" are used:
+
+	     <substitution> ::= St # ::std::
+	     <substitution> ::= Sa # ::std::allocator
+	     <substitution> ::= Sb # ::std::basic_string
+	     <substitution> ::= Ss # ::std::basic_string < char,
+							   ::std::char_traits<char>,
+							   ::std::allocator<char> >
+	     <substitution> ::= Si # ::std::basic_istream<char,  std::char_traits<char> >
+	     <substitution> ::= So # ::std::basic_ostream<char,  std::char_traits<char> >
+	     <substitution> ::= Sd # ::std::basic_iostream<char, std::char_traits<char> >
+	  "
+
+	When the libiberty demangler encounters such a abbreviation, by
+	default, it expands it to the user-friendly typedef "std::string",
+	"std::iostream", etc..  If OTOH DMGL_VERBOSE is specified, the
+	abbreviation is expanded to the underlying, non-typedefed fullname
+	"std::basic_string<char, std::char_traits<char>, std::allocator<char> >"
+	etc. as documented in the Itanium ABI, and pasted above.  You can see
+	the standard abbreviations/substitutions in
+	libiberty/cp-demangle.c:standard_subs.
+
+	Back before Jan's patch in 2011, there were parts of GDB that used
+	DMGL_VERBOSE, and others that did not, leading to mismatches.  The
+	solution back then was to stop using DMGL_VERBOSE throughout.
+
+	GDB has code in place to let users set a breakpoint at a function with
+	typedefs in its parameters, like "b f(uint32_t)".  Demangled function
+	names as they appear in the symbol tables almost (more on this is in a
+	bit) never have typedefs in them, so when processing "b f(uint32_t)"
+	GDB first replaces "uint32_t" for its underlying type, and then sets a
+	breakpoint on the resulting prototype, in this case "f(unsigned int)".
+
+	Now, if DMGL_VERBOSE is _not_ used, then the demangler demangles the
+	mangled name of a function such as "void f(std::string)" that was
+	mangled using the standard abbreviations mentioned above really as:
+
+	  "void f(std::string)".
+
+	For example, the mangled name of "void f(std::string)" if you compile
+	with old pre-C++11 ABI is "_Z1fSs".  That uses the abbreviation "Ss",
+	so if you demangle that without DMGL_VERBOSE, you get:
+
+	  $ echo "_Z1fSs" | c++filt --no-verbose
+	  f(std::string)
+
+	while with DMGL_VERBOSE you'd get:
+
+	  $ echo "_Z1fSs" | c++filt
+	  f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)
+
+	If, when the user sets a breakpoint at "f(std::string)", GDB would
+	replace the std::string typedef for its underlying type using the same
+	mechanism I mentioned for the "f(uint32_t)" example above, then GDB
+	would really try to set a breakpoint at "f(std::basic_string<char,
+	std::char_traits<char>, std::allocator<char> >)", and that would fail,
+	as the function symbol GDB knows about for that function, given no
+	DMGL_VERBOSE, is "f(std::string)".
+
+	For this reason, the code that expands typedefs in function parameter
+	names has an exception for std::string (and other standard
+	abbreviation types), such that "std::string" is never
+	typedef-expanded.
+
+	And here lies the problem when you try to do "b f(std::string)" with a
+	program compiled with the C++11 ABI.  In that case, std::string
+	expands to a different underlying type, like so:
+
+	  f(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)
+
+	and this symbol naturally mangles differently, as:
+
+	  _Z1fNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
+
+	and then because this doesn't use the shorthand mangling abbreviation
+	for "std::string" anymore, it always demangles as:
+
+	  f(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)
+
+	Now, when using the C++11 ABI, and you set a breakpoint at
+	"f(std::string)", GDB's typedefs-in-parameters expansion code hits the
+	exception for "std::string" and doesn't expand it, so the breakpoint
+	fails to be inserted, because the symbol that exists is really the
+
+	  f(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)
+
+	one, not "f(std::string)".
+
+	So to fix things for C++11 ABI, clearly we need to remove the
+	"std::string" exception from the typedef-in-parameters expansion
+	logic.  If we do just that, then "b f(std::string)" starts working
+	with the C++11 ABI.
+
+	However, if we do _just_ that, and nothing else, then we break
+	pre-C++11 ABI...
+
+	The solution is then to in addition switch GDB to always use
+	DMGL_VERBOSE.  If we do this, then pre-C++11 ABI symbols works the
+	same as C++11 ABI symbols overall -- the demangler expands the
+	standard abbreviation for "std::string" as "std::basic_string<char,
+	std::char_traits<char>, std::allocator<char> >" and letting GDB expand
+	the "std::string" typedef (etc.) too is no longer a problem.
+
+	To avoid getting in the situation where some parts of GDB use
+	DMGL_VERBOSE and others not, this patch adds wrappers around the
+	demangler's entry points that GDB uses, and makes those force
+	DMGL_VERBOSE.
+
+	The point of the gdb.cp/no-dmgl-verbose.exp testcase was to try to
+	ensure that DMGL_VERBOSE doesn't creep back in:
+
+	 gdb_test {break 'f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)'} \
+		  {Function ".*" not defined\.} \
+		  "DMGL_VERBOSE-demangled f(std::string) is not defined"
+
+	This obviously no longer makes sense to have, since we now depend on
+	DMGL_VERBOSE.  So the patch replaces gdb.cp/no-dmgl-verbose.exp with a
+	new gdb.cp/break-f-std-string.exp testcase whose purpose is to make
+	sure that setting a breakpoint at "f(std::string)" works.  It
+	exercises both pre-C++11 ABI and C++11 ABI.
+
+	Change-Id: Ib54fab4cf0fd307bfd55bf1dd5056830096a653b
+
+2022-05-10  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	gdb/testsuite: fix testsuite regressions for unix/-m32 board
+	This commit fixes two regressions introduced by
+	891e4190ba705373eec7b374209478215fff5401.
+
+	Reason for the failures was, that on a 32 bit machine the maximum
+	array length as well as the maximum allocatable memory for arrays
+	(in bytes) both seem to be limited by the maximum value of a 4
+	byte (signed) Fortran integer.  This lead to compiler errors/unexpected
+	behavior when compiling/running the test with the -m32 board.  This
+	behavior is compiler dependent and can differ for different compiler
+	implementations, but generally, it seemed like a good idea to simply
+	avoid such situations.
+
+	The affected tests check for GDB's overflow behavior when using KIND
+	parameters with GDB implemented Fortran intrinsic functions.  If these
+	KIND parameters are too small to fit the actual intrinsic function's
+	result, an overflow is expected.  This was done for 1, 2, and 4
+	byte overflows.  The last one caused problems, as it tried to allocate
+	arrays of length/byte-size bigger than the 4 byte signed integers which
+	would then be used with the LBOUND/UBOUND/SIZE intrinsics.
+
+	The tests were adapted to only execute the 4 byte overflow tests when
+	running on targets with 64 bit.  For this, the compiled tests evaluate the
+	byte size of a C_NULL_PTR via C_SIZEOF, both defined in the ISO_C_BINDING
+	module.  The ISO_C_BINDING constant C_NULL_PTR is a Fortran 2003, the
+	C_SIZEOF a Fortran 2008 extension.  Both have been implemented in their
+	respective compilers for while (e.g. C_SIZEOF is available since
+	gfortran 4.6).  If this byte size evaluates to less than 8 we skip the
+	4 byte overflow tests in the compiled tests of size.f90 and
+	lbound-ubound.f90.  Similarly, in the lbound-ubound.exp testsfile we skip
+	the 4 byte overflow tests if the procedure is_64_target evaluates to false.
+
+	In size.f90, additionally, the to-be-allocated amount of bytes did not
+	fit into 4 byte signed integers for some of the arrays, as it was
+	approximately 4 times the maximum size of a 4 byte signed integer.  We
+	adapted the dimensions of the arrays in question as the meaningfulness
+	of the test does not suffer from this.
+
+	With this patch both test run fine with the unix/-m32 board and
+	gcc/gfortran (9.4) as well as the standard board file.
+
+	We also thought about completely removing the affected test from the
+	testsuite.  We decided against this as the 32 bit identification comes
+	with Fortran 2008 and removing tests would have decreased coverage.
+
+	A last change that happened with this patch was due to gfortran's and
+	ifx's type resolution when assigning big constants to Fortran Integer*8
+	variables.  Before the above changes this happened in a parameter
+	statement.  Here, both compilers happily accepted a line like
+
+	  integer*8, parameter :: var = 2147483647 + 5.
+
+	After this change the assignment is not done as a parameter
+	anymore, as this triggered compile time overflow errors.  Instead,
+	the assignment is done dynamically, depending on the kind of machine one
+	is on.  Sadly, just changing this line to
+
+	  integer*8 :: var
+	  var = 2147483647 + 5
+
+	does not work with ifx (or flang for that matter, they behave similarly
+	here).  It will create an integer overflow in the addition as ifx deduces
+	the type the additon is done in as Integer*4.  So var will actually
+	contain the value -2147483644 after this.  The lines
+
+	  integer*8 :: var
+	  var = 2147483652
+
+	on the other hand fail to compile with gfortran (9.4.0) as the compiler
+	identifies an Integer overflow here.  Finally, to make this work with
+	all three compilers an additional parameter has been introduced
+
+	  integer*8, parameter :: helper = 2147483647
+	  integer*8 :: var
+	  var = helper + 5.
+
+	This works on all 3 compilers as expected.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29053
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29054
+
+2022-05-10  Pedro Alves  <pedro@palves.net>
+
+	Move non-dependent gdb::observers::observable::visit_state outside template
+	The other day, while looking at the symbols that end up in a GDB
+	index, I noticed that the gdb::observers::observable::visit_state enum
+	class appears a number of times:
+
+	 $ grep VISIT gdb-index-symbol-names.txt
+	 gdb::observers::observable<bpstat*, int>::visit_state::NOT_VISITED
+	 gdb::observers::observable<bpstat*, int>::visit_state::VISITED
+	 gdb::observers::observable<bpstat*, int>::visit_state::VISITING
+	 gdb::observers::observable<breakpoint*>::visit_state::NOT_VISITED
+	 gdb::observers::observable<breakpoint*>::visit_state::VISITED
+	 gdb::observers::observable<breakpoint*>::visit_state::VISITING
+	 gdb::observers::observable<char const*, char const*>::visit_state::NOT_VISITED
+	 gdb::observers::observable<char const*, char const*>::visit_state::VISITED
+	 gdb::observers::observable<char const*, char const*>::visit_state::VISITING
+	 gdb::observers::observable<char const*>::visit_state::NOT_VISITED
+	 gdb::observers::observable<char const*>::visit_state::VISITED
+	 gdb::observers::observable<char const*>::visit_state::VISITING
+	 gdb::observers::observable<enum_flags<user_selected_what_flag> >::visit_state::NOT_VISITED
+	 gdb::observers::observable<enum_flags<user_selected_what_flag> >::visit_state::VISITED
+	 gdb::observers::observable<enum_flags<user_selected_what_flag> >::visit_state::VISITING
+	 gdb::observers::observable<frame_info*, int>::visit_state::NOT_VISITED
+	 gdb::observers::observable<frame_info*, int>::visit_state::VISITED
+	 gdb::observers::observable<frame_info*, int>::visit_state::VISITING
+	 gdb::observers::observable<gdbarch*>::visit_state::NOT_VISITED
+	 gdb::observers::observable<gdbarch*>::visit_state::VISITED
+	 gdb::observers::observable<gdbarch*>::visit_state::VISITING
+	 gdb::observers::observable<gdb_signal>::visit_state::NOT_VISITED
+	 gdb::observers::observable<gdb_signal>::visit_state::VISITED
+	 gdb::observers::observable<gdb_signal>::visit_state::VISITING
+	 [... snip ...]
+
+	 $ grep VISIT gdb-index-symbol-names.txt | wc -l
+	 72
+
+	enum class visit_state is defined inside the class template
+	observable, but it doesn't have to be, as it does not depend on the
+	template parameters.  This commit moves it out, so that only one such
+	type exists.  This reduces the size of a -O0 -g3 build for me by
+	around 0.6%, like so:
+
+	 $ du -b gdb.before gdb.after
+	 164685280       gdb.before
+	 163707424       gdb.fixed
+
+	and codesize by some 0.5%.
+
+	Change-Id: I405f4ef27b8358fdd22158245b145d849b45658e
+
+2022-05-10  Nick Clifton  <nickc@redhat.com>
+
+	Fix compiling binutils/resbin.c with Clang version 14
+
+2022-05-10  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+	gprofng: include percentages in default metrics list
+	gprofng/ChangeLog
+	2022-05-09  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+		* src/gprofng.rc: Include percentages in default metrics list.
+
+2022-05-10  Alan Modra  <amodra@gmail.com>
+
+	gprof: remove use of PTR
+		* basic_blocks.c: Replace uses of PTR with void * throughout.
+		* cg_arcs.c: Likewise.
+		* cg_print.c: Likewise.
+		* hist.c: Likewise.
+		* source.h: Likewise.
+		* symtab.c: Likewise.
+
+	gas: remove use of PTR
+		* config/obj-evax.c (evax_symbol_new_hook): Don't cast to PTR.
+
+2022-05-10  Alan Modra  <amodra@gmail.com>
+
+	opcodes: remove use of PTR
+	The non-cgen parts of opcodes.
+
+		* cr16-dis.c (print_arg): Replace PTR with void *.
+		* crx-dis.c (print_arg): Likewise.
+		* rl78-dis.c (print_insn_rl78_common): Don't use PTR cast.
+		* rx-dis.c (print_insn_rx): Likewise.
+		* visium-dis.c (print_insn_visium): Likewise.
+		* z8k-dis.c (print_insn_z8k): Likewise.
+
+2022-05-10  Alan Modra  <amodra@gmail.com>
+
+	bfd: remove use of PTR
+		* coffcode.h (coff_write_object_contents): Don't cast to PTR.
+		* elf32-csky.c (csky_elf_link_hash_traverse): Remove use of PTR
+		and PARAMS.
+		(csky_allocate_dynrelocs): Don't use PTR cast.
+		* elf32-nios2.c (adjust_dynrelocs, allocate_dynrelocs): Replace
+		PTR with void *.
+		* elf32-visium.c (visium_elf_howto_parity_reloc): Likewise.
+		* elfxx-ia64.c (ia64_elf_reloc): Likewise.
+		* plugin.c (bfd_plugin_bfd_print_private_bfd_data): Likewise.
+
+	include: remove use of PTR
+		* hashtab.h (HTAB_EMPTY_ENTRY): Replace PTR with void *.
+		(HTAB_DELETED_ENTRY): Likewise.
+
+2022-05-10  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-09  Ilya Leoshkevich  <iii@linux.ibm.com>
+
+	IBM zSystems: Accept (. - 0x100000000) PCRel32 operands
+	as does not accept instructions like brasl %r0,.-0x100000000, because
+	of two problems with the generic overflow check:
+
+	1. PCRel32 operands are signed, but are treated as unsigned.
+
+	2. The allowed range for these operands is [-(1 << 32), (1 << 32) - 1],
+	   and not [-(1 << 31), (1 << 31) - 1].
+
+	Fix both by disabling the generic overflow check - it's not needed,
+	because s390_insert_operand () performs its own.
+
+	gas/
+
+	        * config/tc-s390.c (md_gather_operands): Set fx_no_overflow.
+	        * testsuite/gas/s390/s390.exp: Add zarch-z900-err.
+	        * testsuite/gas/s390/esa-z900.d: New test.
+	        * testsuite/gas/s390/esa-z900.s: New test.
+	        * testsuite/gas/s390/zarch-z900-err.l: New test.
+	        * testsuite/gas/s390/zarch-z900-err.s: New test.
+
+2022-05-09  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: fix occasional failure in gdb.mi/mi-multi-commands.exp
+	In bug PR gdb/29036, another failure was reported for the test
+	gdb.mi/mi-multi-commands.exp.  This test sends two commands to GDB as
+	a single write, and then checks that both commands are executed.
+
+	The problem that was encountered here is that the output of the first
+	command, which looks like this:
+
+	  ^done,value="\"FIRST COMMAND\""
+
+	Is actually produced in parts, first the '^done' is printed, then the
+	',value="\"FIRST COMMAND\"" is printed.
+
+	What was happening is that some characters from the second command
+	were being echoed after the '^done' had been printed, but before the
+	value part had been printed.  To avoid this issue I've relaxed the
+	pattern that checks for the first command a little.  With this fix in
+	place the occasional failure in this test is no longer showing up.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29036
+
+2022-05-09  Tom de Vries  <tdevries@suse.de>
+
+	[gdb] Update syscalls/{amd64,i386}-linux.xml
+	- Add a script syscalls/gen-header.py, based on syscalls/arm-linux.py.
+	- Add a script syscalls/update-linux.sh (alongside update-freebsd.sh and
+	  update-netbsd.sh).
+	- Use syscalls/update-linux.sh to update syscalls/{amd64,i386}-linux.xml.in.
+	- Regenerate syscalls/{amd64,i386}-linux.xml using syscalls/Makefile.
+
+	In gdb/syscalls/i386-linux.xml.in, updating has the following notable effect:
+	...
+	-  <syscall name="madvise1" number="220"/>
+	-  <syscall name="getdents64" number="221"/>
+	-  <syscall name="fcntl64" number="222"/>
+	+  <syscall name="getdents64" number="220"/>
+	+  <syscall name="fcntl64" number="221"/>
+	...
+
+	I've verified in ./arch/x86/entry/syscalls/syscall_32.tbl that the numbers are
+	correct.
+
+	Tested on x86_64-linux.
+
+2022-05-09  Tom de Vries  <tdevries@suse.de>
+
+	[gdb] Add gdb/syscalls/Makefile
+	Add a Makefile in gdb/syscalls that can be used to translate
+	gdb/syscalls/*.xml.in into gdb/syscalls/*.xml.
+
+	Calling make reveals that bfin-linux.xml is missing, so add it.
+
+	Tested on x86_64-linux.
+
+2022-05-09  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: LoongArch: Implement the return_value gdbarch method
+	When execute the following command on LoongArch:
+
+	  make check-gdb TESTS="gdb.base/async.exp"
+
+	there exist the following failed testcases:
+
+	  FAIL: gdb.base/async.exp: finish& (timeout)
+	  FAIL: gdb.base/async.exp: jump& (timeout)
+	  FAIL: gdb.base/async.exp: until& (timeout)
+	  FAIL: gdb.base/async.exp: set exec-done-display off (GDB internal error)
+
+	we can see the following messages in gdb/testsuite/gdb.log:
+
+	  finish&
+	  Run till exit from #0  foo () at /home/loongson/gdb.git/gdb/testsuite/gdb.base/async.c:9
+	  (gdb) /home/loongson/gdb.git/gdb/gdbarch.c:2646: internal-error: gdbarch_return_value: Assertion `gdbarch->return_value != NULL' failed.
+	  A problem internal to GDB has been detected,
+	  further debugging may prove unreliable.
+
+	In order to fix the above failed testcases, implement the return_value
+	gdbarch method on LoongArch.
+
+2022-05-09  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: fix for gdb.base/eof-exit.exp test failures
+	This fix relates to PR gdb/29032, this makes the test more stable by
+	ensuring that the Ctrl-D is only sent once the prompt has been
+	displayed.  This issue was also discussed on the mailing list here:
+
+	  https://sourceware.org/pipermail/gdb-patches/2022-April/187670.html
+
+	The problem identified in the bug report is that sometimes the Ctrl-D
+	(that the test sends to GDB) arrives while GDB is processing a
+	command.  When this happens the Ctrl-D is handled differently than if
+	the Ctrl-D is sent while GDB is waiting for input at a prompt.
+
+	The original intent of the test was that the Ctrl-D be sent while GDB
+	was waiting at a prompt, and that is the case the occurs most often,
+	but, when the Ctrl-D arrives during command processing, then GDB will
+	ignore the Ctrl-D, and the test will fail.
+
+	This commit ensures the Ctrl-D is always sent while GDB is waiting at
+	a prompt, which makes this test stable.
+
+	But, that still leaves an open question, what should happen when the
+	Ctrl-D arrives while GDB is processing a command?  This commit doesn't
+	attempt to answer that question, which is while bug PR gdb/29032 will
+	not be closed once this commit is merged.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29032
+
+2022-05-09  Tom de Vries  <tdevries@suse.de>
+
+	[gdb] Make btrace maintainer entry more clear
+	Do:
+	...
+	-record btrace          <name>       <email>
+	+record
+	+  btrace               <name>       <email>
+	...
+	to clarify that the listed maintainer is only maintainer of the btrace part of
+	record.
+
+2022-05-09  Martin Liska  <mliska@suse.cz>
+
+	ansidecl.h: sync from GCC
+	include/ChangeLog:
+
+		* ansidecl.h: Sync from GCC.
+
+2022-05-09  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/tdep] Support catch syscall pipe2 for i386
+	With test-case gdb.base/catch-syscall.exp and target board unix/-m32, we run
+	into:
+	...
+	(gdb) catch syscall pipe2^M
+	Unknown syscall name 'pipe2'.^M
+	(gdb) FAIL: gdb.base/catch-syscall.exp: determine pipe syscall: catch syscall pipe2
+	...
+
+	Fix this by:
+	- adding a pipe2 entry in gdb/syscalls/i386-linux.xml.in, and
+	- regenerating gdb/syscalls/i386-linux.xml using
+	  "xsltproc --output i386-linux.xml apply-defaults.xsl i386-linux.xml.in".
+
+	Tested on x86_64-linux with native and unix/-m32.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29056
+
+2022-05-09  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Handle pipe2 syscall in gdb.base/catch-syscall.exp
+	When running test-case gdb.reverse/pipe-reverse.exp on openSUSE Tumbleweed,
+	I run into:
+	...
+	(gdb) continue^M
+	Continuing.^M
+	^M
+	Catchpoint 2 (returned from syscall pipe2), in pipe () from /lib64/libc.so.6^M
+	(gdb) FAIL: gdb.base/catch-syscall.exp: without arguments: \
+	  syscall pipe has returned
+	...
+
+	The current glibc on Tumbleweed is 2.35, which contains commit
+	"linux: Implement pipe in terms of __NR_pipe2", and consequently syscall pipe2
+	is used instead of syscall pipe.
+
+	Fix this by detecting whether syscall pipe or pipe2 is used before running the
+	tests.
+
+	Tested on x86_64-linux, specifically on:
+	- openSUSE Tumbleweed (with glibc 2.35), and
+	- openSUSE Leap 15.3 (with glibc 2.31).
+
+	On openSUSE Tumbleweed + target board unix/-m32, this exposes:
+	...
+	(gdb) catch syscall pipe2^M
+	Unknown syscall name 'pipe2'.^M
+	...
+	which will be fixed in a folllow-up patch.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29056
+
+2022-05-09  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/tdep] Handle pipe2 syscall for amd64
+	When running test-case gdb.reverse/pipe-reverse.exp on openSUSE Tumbleweed,
+	I run into:
+	...
+	(gdb) continue^M
+	Continuing.^M
+	Process record and replay target doesn't support syscall number 293^M
+	Process record: failed to record execution log.^M
+	^M
+	Program stopped.^M
+	0x00007ffff7daabdb in pipe () from /lib64/libc.so.6^M
+	(gdb) FAIL: gdb.reverse/pipe-reverse.exp: continue to breakpoint: marker2
+	...
+
+	The current glibc on Tumbleweed is 2.35, which contains commit
+	"linux: Implement pipe in terms of __NR_pipe2", and consequently syscall pipe2
+	is used in stead of syscall pipe.
+
+	There is already support added for syscall pipe2 for aarch64 (which only has
+	syscall pipe2, not syscall pipe), so enable the same for amd64, by:
+	- adding amd64_sys_pipe2 in enum amd64_syscall
+	- translating amd64_sys_pipe2 to gdb_sys_pipe2 in amd64_canonicalize_syscall
+
+	Tested on x86_64-linux, specifically on:
+	- openSUSE Tumbleweed (with glibc 2.35), and
+	- openSUSE Leap 15.3 (with glibc 2.31).
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29056
+
+2022-05-09  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-08  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.tui/scroll.exp with read1
+	When running test-case gdb.tui/scroll.exp, I get:
+	...
+	Box Dump (80 x 8) @ (0, 0):
+	    0 $17 = 16
+	    1 (gdb) p 17
+	    2 $18 = 17
+	    3 (gdb) p 18
+	    4 $19 = 18
+	    5 (gdb) p 19
+	    6 $20 = 19
+	    7 (gdb)
+	PASS: gdb.tui/scroll.exp: check cmd window in flip layout
+	...
+	but with check-read1 I get instead:
+	...
+	Box Dump (80 x 8) @ (0, 0):
+	    0 (gdb) 15
+	    1 (gdb) p 16
+	    2 $17 = 16
+	    3 (gdb) p 17
+	    4 $18 = 17
+	    5 (gdb) p 18
+	    6 $19 = 18
+	    7 (gdb) p 19
+	FAIL: gdb.tui/scroll.exp: check cmd window in flip layout
+	...
+
+	The "p 19" command is handled by Term::command, which sends the command and then
+	does Term::wait_for "^$gdb_prompt [string_to_regexp $cmd]", which:
+	- matches the line with "(gdb) p 19", and
+	- tries to match the following prompt "(gdb) "
+
+	The problem is that scrolling results in reissuing output before the "(gdb) p
+	19", and the second matching triggers on that.  Consequently, wait_for no
+	longer translates gdb output into screen actions, and the screen does not
+	reflect the result of "p 19".
+
+	Fix this by using a new proc wait_for_region_contents, which in contrast to
+	wait_for can handle a multi-line regexp.
+
+	Tested on x86_64-linux with make targets check and check-read1.
+
+2022-05-08  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.cp/casts.exp with -m32
+	When running test-case gdb.cp/casts.exp with target board unix/-m32, I run
+	into:
+	...
+	(gdb) print (unsigned long long) &gd == gd_value^M
+	$31 = false^M
+	(gdb) FAIL: gdb.cp/casts.exp: print (unsigned long long) &gd == gd_value
+	...
+
+	With some additional printing, we can see in more detail why the comparison
+	fails:
+	...
+	(gdb) print /x &gd^M
+	$31 = 0xffffc5c8^M
+	(gdb) PASS: gdb.cp/casts.exp: print /x &gd
+	print /x (unsigned long long)&gd^M
+	$32 = 0xffffc5c8^M
+	(gdb) PASS: gdb.cp/casts.exp: print /x (unsigned long long)&gd
+	print /x gd_value^M
+	$33 = 0xffffffffffffc5c8^M
+	(gdb) PASS: gdb.cp/casts.exp: print /x gd_value
+	print (unsigned long long) &gd == gd_value^M
+	$34 = false^M
+	(gdb) FAIL: gdb.cp/casts.exp: print (unsigned long long) &gd == gd_value
+	...
+
+	The gd_value is set by this assignment:
+	...
+	  unsigned long long gd_value = (unsigned long long) &gd;
+	...
+
+	The problem here is directly casting from a pointer to a non-pointer-sized
+	integer.
+
+	Fix this by adding an intermediate cast to std::uintptr_t.
+
+	Tested on x86_64-linux with native and target board unix/-m32.
+
+2022-05-08  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Handle init errors in gdb.mi/user-selected-context-sync.exp
+	In OBS, on aarch64-linux, with a gdb 11.1 based package, I run into:
+	...
+	(gdb) builtin_spawn -pty^M
+	new-ui mi /dev/pts/5^M
+	New UI allocated^M
+	(gdb) =thread-group-added,id="i1"^M
+	(gdb) ERROR: MI channel failed
+	warning: Error detected on fd 11^M
+	thread 1.1^M
+	Unknown thread 1.1.^M
+	(gdb) UNRESOLVED: gdb.mi/user-selected-context-sync.exp: mode=non-stop: \
+	  test_cli_inferior: reset selection to thread 1.1
+	...
+	with many more UNRESOLVED following.
+
+	The ERROR is a common problem, filed as
+	https://sourceware.org/bugzilla/show_bug.cgi?id=28561 .
+
+	But the many UNRESOLVEDs are due to not checking whether the setup as done in
+	the test_setup function succeeds or not.
+
+	Fix this by:
+	- making test_setup return an error upon failure
+	- handling test_setup error at the call site
+	- adding a "setup done" pass/fail to be turned into an unresolved
+	  in case of error during setup.
+
+	Tested on x86_64-linux, by manually triggering the error in
+	mi_gdb_start_separate_mi_tty.
+
+2022-05-08  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.ada/catch_ex_std.exp with remote-gdbserver-on-localhost
+	When running test-case gdb.ada/catch_ex_std.exp on target board
+	remote-gdbserver-on-localhost, I run into:
+	...
+	(gdb) continue^M
+	Continuing.^M
+	[Inferior 1 (process 15656) exited with code 0177]^M
+	(gdb) FAIL: gdb.ada/catch_ex_std.exp: runto: run to main
+	Remote debugging from host ::1, port 49780^M
+	/home/vries/foo: error while loading shared libraries: libsome_package.so: \
+	  cannot open shared object file: No such file or directory^M
+	...
+
+	Fix this by adding the usual shared-library + remote-target helper
+	"gdb_load_shlib $sofile".
+
+	Tested on x86_64-linux with native and target board
+	remote-gdbserver-on-localhost.
+
+2022-05-08  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.threads/fork-plus-threads.exp with check-readmore
+	When running test-case gdb.threads/fork-plus-threads.exp with check-readmore,
+	I run into:
+	...
+	[Inferior 11 (process 7029) exited normally]^M
+	[Inferior 1 (process 6956) exited normally]^M
+	FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: \
+	  inferior 1 exited (timeout)
+	...
+
+	The problem is that the regexp consuming the "Inferior exited normally"
+	messages:
+	- consumes more than one of those messages at a time, but
+	- counts only one of those messages.
+
+	Fix this by adopting a line-by-line approach, which deals with those messages
+	one at a time.
+
+	Tested on x86_64-linux with native, check-read1 and check-readmore.
+
+2022-05-08  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-07  Tom Tromey  <tom@tromey.com>
+
+	Fix "catch syscall"
+	Simon pointed out that some recent patches of mine broke "catch
+	syscall".  Apparently I forgot to finish the conversion of this code
+	when removing init_catchpoint.  This patch completes the conversion
+	and fixes the bug.
+
+2022-05-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/readline: fix extra 'quit' message problem
+	After these two commits:
+
+	  commit 4fb7bc4b147fd30b781ea2dad533956d0362295a
+	  Date:   Mon Mar 7 13:49:21 2022 +0000
+
+	      readline: back-port changes needed to properly detect EOF
+
+	  commit 91395d97d905c31ac38513e4aaedecb3b25e818f
+	  Date:   Tue Feb 15 17:28:03 2022 +0000
+
+	      gdb: handle bracketed-paste-mode and EOF correctly
+
+	It was observed that, if a previous command is selected at the
+	readline prompt using the up arrow key, then when the command is
+	accepted (by pressing return) an unexpected 'quit' message will be
+	printed by GDB.  Here's an example session:
+
+	  (gdb) p 123
+	  $1 = 123
+	  (gdb) p 123
+	  quit
+	  $2 = 123
+	  (gdb)
+
+	In this session the second 'p 123' was entered not by typing 'p 123',
+	but by pressing the up arrow key to select the previous command.  It
+	is important that the up arrow key is used, typing Ctrl-p will not
+	trigger the bug.
+
+	The problem here appears to be readline's EOF detection when handling
+	multi-character input sequences.  I have raised this issue on the
+	readline mailing list here:
+
+	  https://lists.gnu.org/archive/html/bug-readline/2022-04/msg00012.html
+
+	a solution has been proposed here:
+
+	  https://lists.gnu.org/archive/html/bug-readline/2022-04/msg00016.html
+
+	This patch includes a test for this issue as well as a back-port of
+	(the important bits of) readline commit:
+
+	  commit 2ef9cec8c48ab1ae3a16b1874a49bd1f58eaaca1
+	  Date:   Wed May 4 11:18:04 2022 -0400
+
+	      fix for setting RL_STATE_EOF in callback mode
+
+	That commit also includes some updates to the readline documentation
+	and tests that I have not included in this commit.
+
+	With this commit in place the unexpected 'quit' messages are resolved.
+
+2022-05-07  Alan Modra  <amodra@gmail.com>
+
+	Fix multiple ubsan warnings in i386-dis.c
+	Commit 39fb369834a3 "opcodes: Make i386-dis.c thread-safe" introduced
+	a number of casts to bfd_signed_vma that cause undefined behaviour
+	with a 32-bit libbfd.  Revert those changes.
+
+		* i386-dis.c (OP_E_memory): Do not cast disp to bfd_signed_vma
+		for negation.
+		(get32, get32s): Don't use bfd_signed_vma here.
+
+2022-05-07  Alan Modra  <amodra@gmail.com>
+
+	Re: Fix new linker testsuite failures due to rwx segment test problems
+	Fix it some more.
+
+	bfd/
+		* elfnn-loongarch.c: Remove commented out elf_backend_* defines.
+	ld/
+		* testsuite/ld-elf/elf.exp (target_defaults_to_execstack): Match
+		arm*.  Delete loongarch.
+
+2022-05-07  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-07  Carl Love  <cel@us.ibm.com>
+
+	PowerPC fix for gdb.server/sysroot.exp
+	On PowerPC, the stop in the printf function is of the form:
+
+	Breakpoint 2, 0x00007ffff7c6ab08 in printf@@GLIBC_2.17 () from /lib64/libc.so.6
+
+	On other architectures the output looks like:
+
+	Breakpoint 2, 0x0000007fb7ea29ac in printf () from /lib/aarch64-linux-gnu/libc.so.6
+
+	The following patch modifies the printf test by matchine any character
+	starting immediately after the printf.  The test now works for PowerPC
+	output as well as the output from other architectures.
+
+	The test has been run on a Power 10 system and and Intel x86_64 system.
+
+2022-05-06  Nick Clifton  <nickc@redhat.com>
+
+	Fix new linker testsuite failures due to rwx segment test problems
+
+2022-05-06  Tom Tromey  <tom@tromey.com>
+
+	Introduce catchpoint class
+	This introduces a catchpoint class that is used as the base class for
+	all catchpoints.  init_catchpoint is rewritten to be a constructor
+	instead.
+
+	This changes the hierarchy a little -- some catchpoints now inherit
+	from base_breakpoint whereas previously they did not.  This isn't a
+	problem, as long as re_set is redefined in catchpoint.
+
+2022-05-06  Tom Tromey  <tom@tromey.com>
+
+	Add initializers to tracepoint
+	This adds some initializers to tracepoint.  I think right now these
+	may not be needed, due to obscure rules about zero initialization.
+	However, this will change in the next patch, and anyway it is clearer
+	to be explicit.
+
+	Remove init_raw_breakpoint_without_location
+	This removes init_raw_breakpoint_without_location, replacing it with a
+	constructor on 'breakpoint' itself.  The subclasses and callers are
+	all updated.
+
+	Disable copying for breakpoint
+	It seems to me that breakpoint should use DISABLE_COPY_AND_ASSIGN.
+	This patch does this.
+
+	Add constructor to exception_catchpoint
+	This adds a constructor to exception_catchpoint and simplifies the
+	caller.
+
+	Add constructor to syscall_catchpoint
+	This adds a constructor to syscall_catchpoint and simplifies the
+	caller.
+
+	Add constructor to signal_catchpoint
+	This adds a constructor to signal_catchpoint and simplifies the
+	caller.
+
+	Add constructor to solib_catchpoint
+	This adds a constructor to solib_catchpoint and simplifies the caller.
+
+	Add constructor to fork_catchpoint
+	This adds a constructor to fork_catchpoint and simplifies the caller.
+
+	Remove unnecessary line from catch_exec_command_1
+	catch_exec_command_1 clears the new catchpoint's "exec_pathname"
+	field, but this is already done by virtue of calling "new".
+
+	Constify breakpoint::print_recreate
+	This constifies breakpoint::print_recreate.
+
+	Constify breakpoint::print_mention
+	This constifies breakpoint::print_mention.
+
+	Constify breakpoint::print_one
+	This constifies breakpoint::print_one.
+
+	Constify breakpoint::print_it
+	This constifies breakpoint::print_it.  Doing this pointed out some
+	code in ada-lang.c that can be simplified a little as well.
+
+	Move works_in_software_mode to watchpoint
+	works_in_software_mode is only useful for watchpoints.  This patch
+	moves it from breakpoint to watchpoint, and changes it to return bool.
+
+	Boolify breakpoint::explains_signal
+	This changes breakpoint::explains_signal to return bool.
+
+	Remove breakpoint::ops
+	The breakpoint::ops field is set but never used.  This removes it.
+
+	Change print_recreate_thread to a method
+	This changes print_recreate_thread to be a method on breakpoint.  This
+	function is only used as a helper by print_recreate methods, so I
+	thought this transformation made sense.
+
+2022-05-06  Carl Love  <cel@us.ibm.com>
+
+	PowerPC: bp-permanent.exp, kill-after-signal fix
+	The break point after the stepi on Intel is the entry point of the user
+	signal handler function test_signal_handler.  The code at the break point
+	looks like:
+
+	     0x<hex address> <test_signal_handler>: endbr64
+
+	On PowerPC with a Linux 5.9 kernel or latter, the address where gdb stops
+	after the stepi is in the vdso code inserted by the kernel.  The code at the
+	breakpoint looks like:
+
+	  0x<hex address>  <__kernel_start_sigtramp_rt64>:	bctrl
+
+	This is different from other architectures.  As discussed below, recent
+	kernel changes involving the vdso for PowerPC have been made changes to the
+	signal handler code flow.  PowerPC is now stopping in function
+	__kernel_start_sigtramp_rt64.  PowerPC now requires an additional stepi to
+	reach the user signal handler unlike other architectures.
+
+	The bp-permanent.exp and kill-after-signal tests run fine on PowerPC with an
+	kernel that is older than Linux 5.9.
+
+	The PowerPC 64 signal handler was updated by the Linux kernel 5.9-rc1:
+
+	    commit id: 0138ba5783ae0dcc799ad401a1e8ac8333790df9
+	    powerpc/64/signal: Balance return predictor stack in signal trampoline
+
+	An additional change to the PowerPC 64 signal handler was made in Linux
+	kernel version 5.11-rc7 :
+
+	     commit id: 24321ac668e452a4942598533d267805f291fdc9
+	     powerpc/64/signal: Fix regression in __kernel_sigtramp_rt64() semantics
+
+	The first kernel change, puts code into the user space signal handler (in
+	the vdso) as a performance optimization to prevent the call/return stack
+	from getting out of balance.  The patch ensures that the entire
+	user/kernel/vdso cycle is balanced with the addition of the "brctl"
+	instruction.
+
+	The second patch, fixes the semantics of __kernel_sigtramp_rt64().  A new
+	symbol is introduced to serve as the jump target from the kernel to the
+	trampoline which now consists of two parts.
+
+	The above changes for PowerPC signal handler, causes gdb to stop in the
+	kernel code not the user signal handler as expected.  The kernel dispatches
+	to the vdso code which in turn calls into the signal handler.  PowerPC is
+	special in that the kernel is using a vdso instruction (bctrl) to enter the
+	signal handler.
+
+	I do not have access to a system with the first patch but not the second.  I did
+	test on Power 9 with the Linux 5.15.0-27-generic kernel.  Both tests fail on
+	this Power 9 system.  The two tests also fail on Power 10 with the Linux
+	5.14.0-70.9.1.el9_0.ppc64le kernel.
+
+	The following patch fixes the issue by checking if gdb stopped at "signal
+	handler called".  If gdb stopped there, the tests verifies gdb is in the kernel
+	function __kernel_start_sigtramp_rt64 then does an additional stepi to reach the
+	user signal handler.  With the patch below, the tests run without errors on both
+	the Power 9 and Power 10 systems with out any failures.
+
+2022-05-06  Alan Modra  <amodra@gmail.com>
+
+	bfd targmatch.h makefile rule
+	I hit this just now with a make -j build after touching config.bfd.
+	mv: cannot stat 'targmatch.new': No such file or directory
+	make[2]: *** [Makefile:2336: targmatch.h] Error 1
+	make[2]: *** Waiting for unfinished jobs....
+
+	Fix that by not removing the target of the rule, a practice that seems
+	likely to cause parallel running of the rule recipe.  The bug goes
+	back to 1997, the initial c0734708814c commit.
+
+		* Makefile.am (targmatch.h): rm the temp file, not targmatch.h.
+		* Makefile.in: Regenerate.
+
+2022-05-06  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.dwarf2/locexpr-data-member-location.exp with nopie
+	When running test-case gdb.dwarf2/locexpr-data-member-location.exp with
+	target board unix/-fno-PIE/-no-pie/-m32 I run into:
+	...
+	(gdb) step^M
+	26        return 0;^M
+	(gdb) FAIL: gdb.dwarf2/locexpr-data-member-location.exp: step into foo
+	...
+
+	The problem is that the test-case tries to mimic some gdb_compile_shlib
+	behaviour using:
+	...
+	set flags {additional_flags=-fpic debug}
+	get_func_info foo $flags
+	...
+	but this doesn't work with the target board setting, because we end up doing:
+	...
+	gcc locexpr-data-member-location-lib.c -fpic -g -lm -fno-PIE -no-pie -m32 \
+	  -o func_addr23029.x
+	...
+	while gdb_compile_shlib properly filters out the -fno-PIE -no-pie.
+
+	Consequently, the address for foo determined by get_func_info doesn't match
+	the actual address of foo.
+
+	Fix this by printing the address of foo using the result of gdb_compile_shlib.
+
+2022-05-06  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-05  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: use gdb::function_view for gdbarch_iterate_over_objfiles_in_search_order callback
+	A rather straightforward patch to change an instance of callback +
+	void pointer to gdb::function_view, allowing pasing lambdas that
+	capture, and eliminating the need for the untyped pointer.
+
+	Change-Id: I73ed644e7849945265a2c763f79f5456695b0037
+
+2022-05-05  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+	gprofng: use $host instead $target
+	By mistake, $target was used instead of $host to configure the gprogng build.
+
+	gprofng/ChangeLog
+	2022-04-28  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+		PR gprofng/29113
+		PR gprofng/29116
+		* configure.ac: Use $host instead $target.
+		* libcollector/configure.ac: Likewise.
+		* configure: Rebuild.
+		* libcollector/configure: Rebuild.
+
+2022-05-05  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: make regcache's cooked_write_test selftest work with native-extended-gdbserver board
+	Running
+
+	    $ make check TESTS="gdb.gdb/unittest.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver"
+
+	I get some failures:
+
+	    Running selftest regcache::cooked_write_test::i386.^M
+	    Self test failed: target already pushed^M
+	    Running selftest regcache::cooked_write_test::i386:intel.^M
+	    Self test failed: target already pushed^M
+	    Running selftest regcache::cooked_write_test::i386:x64-32.^M
+	    Self test failed: target already pushed^M
+	    Running selftest regcache::cooked_write_test::i386:x64-32:intel.^M
+	    Self test failed: target already pushed^M
+	    Running selftest regcache::cooked_write_test::i386:x86-64.^M
+	    Self test failed: target already pushed^M
+	    Running selftest regcache::cooked_write_test::i386:x86-64:intel.^M
+	    Self test failed: target already pushed^M
+	    Running selftest regcache::cooked_write_test::i8086.^M
+	    Self test failed: target already pushed^M
+
+	This is because the native-extended-gdbserver automatically connects GDB
+	to a GDBserver on startup, and therefore pushes a remote target on the
+	initial inferior.  cooked_write_test is currently written in a way that
+	errors out if the current inferior has a process_stratum_target pushed.
+
+	Rewrite it to use scoped_mock_context, so it doesn't depend on the
+	current inferior (the current one upon entering the function).
+
+	Change-Id: I0357f989eacbdecc4bf88b043754451b476052ad
+
+2022-05-05  Luis Machado  <luis.machado@arm.com>
+
+	Move TILE-Gx files to TARGET64_LIBOPCODES_CFILES
+	TILE-Gx is a 64-bit core, so we should include those files in the
+	TARGET64_LIBOPCODES_CFILES as opposed to TARGET32_LIBOPCODES_CFILES.
+
+	Don't define ARCH_cris for BFD64
+	I believe it is a mistake to define ARCH_cris when BFD64 is defined. It is
+	a 32-bit architecture, so should be placed outside of the BFD64 block.
+
+2022-05-05  Xi Ruoyao  <xry111@mengyan1223.wang>
+
+	loongarch: Don't check ABI flags if no code section
+	Various packages (glib and gtk4 for example) produces data-only objects
+	using `ld -r -b binary` or `objcopy`, with no elf header flags set.  But
+	these files also have no code sections, so they should be compatible
+	with all ABIs.
+
+	bfd/
+		* elfnn-loongarch.c (elfNN_loongarch_merge_private_bfd_data):
+		Skip ABI checks if the input has no code sections.
+
+	Reported-by: Wu Xiaotian <yetist@gmail.com>
+	Suggested-by: Wang Xuerui <i@xen0n.name>
+
+2022-05-05  Andreas Krebbel  <krebbel@linux.ibm.com>
+
+	IBM zSystems: mgrk, mg first operand requires register pair
+	opcodes/
+
+		* s390-opc.c (INSTR_RRF_R0RER): New instruction type.
+		(MASK_RRF_R0RER): Define mask for new instruction type.
+		* s390-opc.txt: Use RRF_R0RER for mgrk and RXY_RERRD for mg.
+
+2022-05-05  H.J. Lu  <hjl.tools@gmail.com>
+
+	bfd: Check NULL pointer before setting ref_real
+		PR ld/29086
+		* linker.c (bfd_wrapped_link_hash_lookup): Check NULL pointer
+		before setting ref_real.
+
+2022-05-05  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-05  H.J. Lu  <hjl.tools@gmail.com>
+
+	LTO: Handle __real_SYM reference in IR
+	When an IR symbol SYM is referenced in IR via __real_SYM, its resolution
+	should be LDPR_PREVAILING_DEF, not PREVAILING_DEF_IRONLY, since LTO
+	doesn't know that __real_SYM should be resolved by SYM.
+
+	bfd/
+
+		PR ld/29086
+		* linker.c (bfd_wrapped_link_hash_lookup): Mark SYM is referenced
+		via __real_SYM.
+
+	include/
+
+		PR ld/29086
+		* bfdlink.h (bfd_link_hash_entry): Add ref_real.
+
+	ld/
+
+		PR ld/29086
+		* plugin.c (get_symbols): Resolve SYM definition to
+		LDPR_PREVAILING_DEF for __real_SYM reference.
+		* testsuite/ld-plugin/lto.exp: Run PR ld/29086 test.
+		* testsuite/ld-plugin/pr29086.c: New file.
+
+2022-05-04  Alan Modra  <amodra@gmail.com>
+
+	cris bfd config
+	cris support will be built into a 32-bit bfd if using --enable-targets=all
+	on a 32-bit host, so we may as well make targmatch.h include cris.
+
+		* config.bfd (cris): Remove #idef BFD64.
+
+2022-05-04  Alan Modra  <amodra@gmail.com>
+
+	PowerPC64 check_relocs
+	Tidy the dynamic reloc handling code in check_relocs, removing
+	leftover comments and code from when check_relocs was called as each
+	object file was read in.
+
+		* elf64-ppc.c (ppc64_elf_check_relocs): Tidy dynamic reloc
+		handling code.
+		(dec_dynrel_count): Do the same here.
+
+2022-05-04  Tom Tromey  <tromey@adacore.com>
+
+	Fix crash when creating index from index
+	My patches yesterday to unify the DWARF index base classes had a bug
+	-- namely, I did the wholesale dynamic_cast-to-static_cast too hastily
+	and introduced a crash.  This can be seen by trying to add an index to
+	a file that has an index, or by running a test like gdb-index-cxx.exp
+	using the cc-with-debug-names.exp target board.
+
+	This patch fixes the crash by introducing a new virtual method and
+	removing some of the static casts.
+
+2022-05-04  Luis Machado  <luis.machado@arm.com>
+
+	Fix build failure for aarch64 gdbserver
+	We're missing an argument.
+
+2022-05-04  Mark Wielaard  <mark@klomp.org>
+
+	gdb: Workaround stringop-overread warning in debuginfod-support.c on s390x
+	For some reason g++ 11.2.1 on s390x produces a spurious warning for
+	stringop-overread in debuginfod_is_enabled for url_view. Add a new
+	DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD macro to suppress this warning.
+
+	include/ChangeLog:
+
+		* diagnostics.h (DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD): New
+		macro.
+
+	gdb/ChangeLog:
+
+		* debuginfod-support.c (debuginfod_is_enabled): Use
+		DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD on s390x.
+
+2022-05-04  Pedro Alves  <pedro@palves.net>
+
+	Fix GDBserver Aarch64 Linux regression
+	Luis noticed that the recent changes to gdbserver to make it track
+	process and threads independently regressed a few gdb.multi/*.exp
+	tests for aarch64-linux.
+
+	We started seeing the following internal error for
+	gdb.multi/multi-target-continue.exp for example:
+
+	 Starting program: binutils-gdb/gdb/testsuite/outputs/gdb.multi/multi-target-continue/multi-target-continue ^M
+	 Error in re-setting breakpoint 2: Remote connection closed^M
+	 ../../../repos/binutils-gdb/gdb/thread.c:85: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed.^M
+	 A problem internal to GDB has been detected,^M
+	 further debugging may prove unreliable.
+
+	A backtrace looks like:
+
+	 #0  thread_regcache_data (thread=thread@entry=0x0) at ../../../repos/binutils-gdb/gdbserver/inferiors.cc:120
+	 #1  0x0000aaaaaaabf0e8 in get_thread_regcache (thread=0x0, fetch=fetch@entry=0) at ../../../repos/binutils-gdb/gdbserver/regcache.cc:31
+	 #2  0x0000aaaaaaad785c in is_64bit_tdesc () at ../../../repos/binutils-gdb/gdbserver/linux-aarch64-low.cc:194
+	 #3  0x0000aaaaaaad8a48 in aarch64_target::sw_breakpoint_from_kind (this=<optimized out>, kind=4, size=0xffffffffef04) at ../../../repos/binutils-gdb/gdbserver/linux-aarch64-low.cc:3226
+	 #4  0x0000aaaaaaabe220 in bp_size (bp=0xaaaaaab6f3d0) at ../../../repos/binutils-gdb/gdbserver/mem-break.cc:226
+	 #5  check_mem_read (mem_addr=187649984471104, buf=buf@entry=0xaaaaaab625d0 "\006", mem_len=mem_len@entry=56) at ../../../repos/binutils-gdb/gdbserver/mem-break.cc:1862
+	 #6  0x0000aaaaaaacc660 in read_inferior_memory (memaddr=<optimized out>, myaddr=0xaaaaaab625d0 "\006", len=56) at ../../../repos/binutils-gdb/gdbserver/target.cc:93
+	 #7  0x0000aaaaaaac3d9c in gdb_read_memory (len=56, myaddr=0xaaaaaab625d0 "\006", memaddr=187649984471104) at ../../../repos/binutils-gdb/gdbserver/server.cc:1071
+	 #8  gdb_read_memory (memaddr=187649984471104, myaddr=0xaaaaaab625d0 "\006", len=56) at ../../../repos/binutils-gdb/gdbserver/server.cc:1048
+	 #9  0x0000aaaaaaac82a4 in process_serial_event () at ../../../repos/binutils-gdb/gdbserver/server.cc:4307
+	 #10 handle_serial_event (err=<optimized out>, client_data=<optimized out>) at ../../../repos/binutils-gdb/gdbserver/server.cc:4520
+	 #11 0x0000aaaaaaafbcd0 in gdb_wait_for_event (block=block@entry=1) at ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:700
+	 #12 0x0000aaaaaaafc0b0 in gdb_wait_for_event (block=1) at ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:596
+	 #13 gdb_do_one_event () at ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:237
+	 #14 0x0000aaaaaaacacb0 in start_event_loop () at ../../../repos/binutils-gdb/gdbserver/server.cc:3518
+	 #15 captured_main (argc=4, argv=<optimized out>) at ../../../repos/binutils-gdb/gdbserver/server.cc:3998
+	 #16 0x0000aaaaaaab66dc in main (argc=<optimized out>, argv=<optimized out>) at ../../../repos/binutils-gdb/gdbserver/server.cc:4084
+
+	This sequence of functions is invoked due to a series of conditions:
+
+	 1 - The probe-based breakpoint mechanism failed (for some reason) so ...
+
+	 2 - ... gdbserver has to know what type of architecture it is dealing
+	     with so it can pick the right breakpoint kind, so it wants to
+	     check if we have a 64-bit target.
+
+	 3 - To determine the size of a register, we currently fetch the
+	     current thread's register cache, and the current thread pointer
+	     is now nullptr.
+
+	In #3, the current thread is nullptr because gdb_read_memory clears it
+	on purpose, via set_desired_process, exactly to expose code relying on
+	the current thread when it shouldn't.  It was always possible to end
+	up in this situation (when the current thread exits), but it was
+	harder to reproduce before.
+
+	This commit fixes it by tweaking is_64bit_tdesc to look at the current
+	process's tdesc instead of the current thread's tdesc.
+
+	Note that the thread's tdesc is itself filled from the process's
+	tdesc, so this should be equivalent:
+
+	 struct regcache *
+	 get_thread_regcache (struct thread_info *thread, int fetch)
+	 {
+	   struct regcache *regcache;
+
+	   regcache = thread_regcache_data (thread);
+
+	 ...
+	   if (regcache == NULL)
+	     {
+	       struct process_info *proc = get_thread_process (thread);
+
+	       gdb_assert (proc->tdesc != NULL);
+
+	       regcache = new_register_cache (proc->tdesc);
+	       set_thread_regcache_data (thread, regcache);
+	     }
+	 ...
+
+	Change-Id: Ibc809d7345e70a2f058b522bdc5cdbdca97e2cdc
+
+2022-05-04  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb/remote: send qSymbol to all inferiors on startup
+	start_remote_1 calls remote_check_symbols after things are set up to
+	give the remote side a chance to look up symbols.  One call to
+	remote_check_symbols sets the "general thread", if needed, and sends one
+	qSymbol packet.  However, a remote target could have more than one
+	process on initial connection, and this would send a qSymbol for only
+	one of these processes.
+
+	Change it to iterate on all the target's inferiors and send a qSymbol
+	packet for each one.
+
+	I tested this by changing gdbserver to spawn two processes on startup:
+
+	    diff --git a/gdbserver/server.cc b/gdbserver/server.cc
+	    index 33c42714e72..9b682e9f85f 100644
+	    --- a/gdbserver/server.cc
+	    +++ b/gdbserver/server.cc
+	    @@ -3939,6 +3939,7 @@ captured_main (int argc, char *argv[])
+
+	           /* Wait till we are at first instruction in program.  */
+	           target_create_inferior (program_path.get (), program_args);
+	    +      target_create_inferior (program_path.get (), program_args);
+
+	           /* We are now (hopefully) stopped at the first instruction of
+	             the target process.  This assumes that the target process was
+
+	Instead of hacking GDBserver, it should also be possible to test this by
+	starting manually two inferiors on an "extended-remote" connection,
+	disconnecting from GDBserver (with the disconnect command), and
+	re-connecting.
+
+	I was able to see qSymbol being sent for each inferior:
+
+	      [remote] Sending packet: $Hgp828dc.828dc#1f
+	      [remote] Packet received: OK
+	      [remote] Sending packet: $qSymbol::#5b
+	      [remote] Packet received: qSymbol:6764625f6167656e745f6764625f74705f686561705f627566666572
+	      [remote] Sending packet: $qSymbol::6764625f6167656e745f6764625f74705f686561705f627566666572#1e
+	      [remote] Packet received: qSymbol:6e70746c5f76657273696f6e
+	      [remote] Sending packet: $qSymbol::6e70746c5f76657273696f6e#4d
+	      [remote] Packet received: OK
+	      [remote] Sending packet: $Hgp828dd.828dd#21
+	      [remote] Packet received: OK
+	      [remote] Sending packet: $qSymbol::#5b
+	      [remote] Packet received: qSymbol:6764625f6167656e745f6764625f74705f686561705f627566666572
+	      [remote] Sending packet: $qSymbol::6764625f6167656e745f6764625f74705f686561705f627566666572#1e
+	      [remote] Packet received: qSymbol:6e70746c5f76657273696f6e
+	      [remote] Sending packet: $qSymbol::6e70746c5f76657273696f6e#4d
+	      [remote] Packet received: OK
+
+	Note that there would probably be more work to be done to fully support
+	this scenario, more things that need to be done for each discovered
+	inferior instead of just for one.
+
+	Change-Id: I21c4ecf6367391e2e389b560f0b4bd906cf6472f
+
+2022-05-04  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/remote: iterate on pspace inferiors in remote_new_objfile
+	Commit 152a17495663 ("gdb: prune inferiors at end of
+	fetch_inferior_event, fix intermittent failure of
+	gdb.threads/fork-plus-threads.exp") broke some tests with the
+	native-gdbserver board, such as:
+
+	    (gdb) PASS: gdb.base/step-over-syscall.exp: detach-on-fork=off: follow-fork=child: break cond on target : vfork: break marker
+	    continue^M
+	    Continuing.^M
+	    terminate called after throwing an instance of 'gdb_exception_error'^M
+
+	I can manually reproduce the issue by running (just the commands that
+	the test does as a one liner):
+
+	    $ ./gdb -q --data-directory=data-directory \
+	          testsuite/outputs/gdb.base/step-over-syscall/step-over-vfork \
+		  -ex "tar rem | ../gdbserver/gdbserver - testsuite/outputs/gdb.base/step-over-syscall/step-over-vfork" \
+		  -ex "b main" \
+		  -ex c \
+		  -ex "d 1" \
+		  -ex "set displaced-stepping off" \
+		  -ex "b *0x7ffff7d7ac5a if main == 0" \
+		  -ex "set detach-on-fork off" \
+		  -ex "set follow-fork-mode child" \
+		  -ex c \
+		  -ex "inferior 1" \
+		  -ex "b marker" \
+		  -ex c
+
+	... where 0x7ffff7d7ac5a is the exact address of the vfork syscall
+	(which can be found by looking at gdb.log).
+
+	The important part of the above is that a vfork syscall creates inferior
+	2, then inferior 2 executes until exit, then we switch back to inferior
+	1 and try to resume it.
+
+	The uncaught exception happens here:
+
+	    #4  0x00005596969d81a9 in error (fmt=0x559692da9e40 "Cannot execute this command while the target is running.\nUse the \"interrupt\" command to stop the target\nand then try again.")
+	        at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:43
+	    #5  0x0000559695af6f66 in remote_target::putpkt_binary (this=0x617000038080, buf=0x559692da4380 "qSymbol::", cnt=9) at /home/simark/src/binutils-gdb/gdb/remote.c:9560
+	    #6  0x0000559695af6aaf in remote_target::putpkt (this=0x617000038080, buf=0x559692da4380 "qSymbol::") at /home/simark/src/binutils-gdb/gdb/remote.c:9518
+	    #7  0x0000559695ab50dc in remote_target::remote_check_symbols (this=0x617000038080) at /home/simark/src/binutils-gdb/gdb/remote.c:5141
+	    #8  0x0000559695b3cccf in remote_new_objfile (objfile=0x0) at /home/simark/src/binutils-gdb/gdb/remote.c:14600
+	    #9  0x0000559693bc52a9 in std::__invoke_impl<void, void (*&)(objfile*), objfile*> (__f=@0x61b0000167f8: 0x559695b3cb1d <remote_new_objfile(objfile*)>) at /usr/include/c++/11.2.0/bits/invoke.h:61
+	    #10 0x0000559693bb2848 in std::__invoke_r<void, void (*&)(objfile*), objfile*> (__fn=@0x61b0000167f8: 0x559695b3cb1d <remote_new_objfile(objfile*)>) at /usr/include/c++/11.2.0/bits/invoke.h:111
+	    #11 0x0000559693b8dddf in std::_Function_handler<void (objfile*), void (*)(objfile*)>::_M_invoke(std::_Any_data const&, objfile*&&) (__functor=..., __args#0=@0x7ffe0bae0590: 0x0) at /usr/include/c++/11.2.0/bits/std_function.h:291
+	    #12 0x00005596956374b2 in std::function<void (objfile*)>::operator()(objfile*) const (this=0x61b0000167f8, __args#0=0x0) at /usr/include/c++/11.2.0/bits/std_function.h:560
+	    #13 0x0000559695633c64 in gdb::observers::observable<objfile*>::notify (this=0x55969ef5c480 <gdb::observers::new_objfile>, args#0=0x0) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/observable.h:150
+	    #14 0x0000559695df6cc2 in clear_symtab_users (add_flags=...) at /home/simark/src/binutils-gdb/gdb/symfile.c:2873
+	    #15 0x000055969574c263 in program_space::~program_space (this=0x6120000c8a40, __in_chrg=<optimized out>) at /home/simark/src/binutils-gdb/gdb/progspace.c:154
+	    #16 0x0000559694fc086b in delete_inferior (inf=0x61700003bf80) at /home/simark/src/binutils-gdb/gdb/inferior.c:205
+	    #17 0x0000559694fc341f in prune_inferiors () at /home/simark/src/binutils-gdb/gdb/inferior.c:390
+	    #18 0x0000559695017ada in fetch_inferior_event () at /home/simark/src/binutils-gdb/gdb/infrun.c:4293
+	    #19 0x0000559694f629e6 in inferior_event_handler (event_type=INF_REG_EVENT) at /home/simark/src/binutils-gdb/gdb/inf-loop.c:41
+	    #20 0x0000559695b3b0e3 in remote_async_serial_handler (scb=0x6250001ef100, context=0x6170000380a8) at /home/simark/src/binutils-gdb/gdb/remote.c:14466
+	    #21 0x0000559695c59eb7 in run_async_handler_and_reschedule (scb=0x6250001ef100) at /home/simark/src/binutils-gdb/gdb/ser-base.c:138
+	    #22 0x0000559695c5a42a in fd_event (error=0, context=0x6250001ef100) at /home/simark/src/binutils-gdb/gdb/ser-base.c:189
+	    #23 0x00005596969d9ebf in handle_file_event (file_ptr=0x60700005af40, ready_mask=1) at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:574
+	    #24 0x00005596969da7fa in gdb_wait_for_event (block=0) at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:700
+	    #25 0x00005596969d8539 in gdb_do_one_event () at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:212
+
+	If I enable "set debug infrun" just before the last continue, we see:
+
+	    (gdb) continue
+	    Continuing.
+	    [infrun] clear_proceed_status_thread: 965604.965604.0
+	    [infrun] proceed: enter
+	      [infrun] proceed: addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT
+	      [infrun] scoped_disable_commit_resumed: reason=proceeding
+	      [infrun] start_step_over: enter
+	        [infrun] start_step_over: stealing global queue of threads to step, length = 0
+	        [infrun] operator(): step-over queue now empty
+	      [infrun] start_step_over: exit
+	      [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [965604.965604.0] at 0x7ffff7d7ac5c
+	      [infrun] do_target_resume: resume_ptid=965604.0.0, step=0, sig=GDB_SIGNAL_0
+	      [infrun] prepare_to_wait: prepare_to_wait
+	      [infrun] reset: reason=proceeding
+	      [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote
+	      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote
+	    [infrun] proceed: exit
+	    [infrun] fetch_inferior_event: enter
+	      [infrun] scoped_disable_commit_resumed: reason=handling event
+	      [infrun] do_target_wait: Found 2 inferiors, starting at #1
+	      [infrun] random_pending_event_thread: None found.
+	      [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
+	      [infrun] print_target_wait_results:   965604.965604.0 [Thread 965604.965604],
+	      [infrun] print_target_wait_results:   status->kind = VFORK_DONE
+	      [infrun] handle_inferior_event: status->kind = VFORK_DONE
+	      [infrun] context_switch: Switching context from 0.0.0 to 965604.965604.0
+	      [infrun] handle_vfork_done: not waiting for a vfork-done event
+	      [infrun] start_step_over: enter
+	        [infrun] start_step_over: stealing global queue of threads to step, length = 0
+	        [infrun] operator(): step-over queue now empty
+	      [infrun] start_step_over: exit
+	      [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [965604.965604.0] at 0x7ffff7d7ac5c
+	      [infrun] do_target_resume: resume_ptid=965604.0.0, step=0, sig=GDB_SIGNAL_0
+	      [infrun] prepare_to_wait: prepare_to_wait
+	      [infrun] reset: reason=handling event
+	      [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote
+	      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote
+	    terminate called after throwing an instance of 'gdb_exception_error'
+
+	What happens is:
+
+	 - After doing the "continue" on inferior 1, the remote target gives us
+	   a VFORK_DONE event.  The core ignores it and resumes inferior 1.
+	 - Since prune_inferiors is now called after each handled event, in
+	   fetch_inferior_event, it is called after we handled that VFORK_DONE
+	   event and resumed inferior 1.
+	 - Inferior 2 is pruned, which (see backtrace above) causes its program
+	   space to be deleted, which clears the symtabs for that program space,
+	   which calls the new_objfile observable and remote_new_objfile
+	   observer (with a nullptr objfile, to indicate that the previously
+	   loaded symbols have been discarded), which calls
+	   remote_check_symbols.
+
+	remote_check_symbols is the function that sends the qSymbol packet, to
+	let the remote side ask for symbol addresses.  The problem is that the
+	remote target is working in all-stop / sync mode and is currently
+	resumed.  It has sent a vCont packet to resume the target and is waiting
+	for a stop reply.  It can't send any packets in the mean time.  That
+	causes the exception to be thrown.
+
+	This wasn't a problem before, when prune_inferiors was called in
+	normal_stop, because it was always called at a time the target was not
+	resumed.
+
+	An important observation here is that the new_objfile observable is
+	invoked for a change in inferior 2's program space (inferior 2's program
+	space is the current program space).  Inferior 2 isn't bound to any
+	process on the remote side (it has exited, that's why it's being
+	pruned).  It doesn't make sense to try to send a qSymbol packet for a
+	process that doesn't exist on the remote side.  remote_check_symbols
+	actually attempts to avoid that:
+
+	   /* The remote side has no concept of inferiors that aren't running
+	     yet, it only knows about running processes.  If we're connected
+	     but our current inferior is not running, we should not invite the
+	     remote target to request symbol lookups related to its
+	     (unrelated) current process.  */
+	  if (!target_has_execution ())
+	    return;
+
+	The problem here is that while inferior 2's program space is the current
+	program space, inferior 1 is the current inferior.  So the check above
+	passes, since inferior has execution.  We therefore try to send a
+	qSymbol packet for inferior 1 in reaction to a change in inferior 2's
+	program space, that's wrong.
+
+	This exposes a conceptual flaw in remote_new_objfile.  The "new_objfile"
+	event concerns a specific program space, which can concern multiple
+	inferiors, as inferiors can share a program space.  We shouldn't
+	consider the current inferior at all, but instead all inferiors bound to
+	the affected program space.  Especially since the current inferior can
+	be unrelated to the current program space at that point.
+
+	To be clear, we are in this state because ~program_space sets itself as
+	the current program space, but there is no more inferior having that
+	program space to switch to, inferior 2 has already been unlinked.
+
+	To fix this, make remote_new_objfile iterate on all inferiors bound to
+	the affected program space.  Remove the target_has_execution check from
+	remote_check_symbols, replace it with an assert.  All callers must
+	ensure that the current inferior has execution before calling it.
+
+	Change-Id: Ica643145bcc03115248290fd310cadab8ec8371c
+
+2022-05-04  Jan Beulich  <jbeulich@suse.com>
+
+	Dwarf: rename yet another instance of "index"
+	As before, on sufficiently old glibc this conflicts with a global
+	identifier in the library headers. While there also zap the unusual
+	padding by blanks.
+
+2022-05-04  Martin Liska  <mliska@suse.cz>
+
+	LTO plugin: sync header file with GCC
+	include/ChangeLog:
+
+		* plugin-api.h (enum ld_plugin_tag): Sync with GCC.
+
+2022-05-04  Alan Modra  <amodra@gmail.com>
+
+	PowerPC32 treatment of absolute symbols
+	As already done for PowerPC64, fix dynamic relocs for absolute symbols.
+	The patch also tidies the dynamic reloc handling code in check_relocs,
+	removing leftover comments and code from when check_relocs was called
+	as each object file was read in.
+
+	bfd/
+		* elf32-ppc.c (ppc_elf_check_relocs): Set isym and ifunc earlier.
+		Rearrange tests for dynamic relocs, handling absolute symbols.
+		(allocate_dynrelocs): Don't allocate dynamic relocs for locally
+		defined absolute symbols.
+		(ppc_elf_size_dynamic_sections): Similarly.
+		(ppc_elf_relocate_section): Similarly.
+	ld/
+		* testsuite/ld-powerpc/abs32-pie.d,
+		* testsuite/ld-powerpc/abs32-pie.r,
+		* testsuite/ld-powerpc/abs32-reloc.s,
+		* testsuite/ld-powerpc/abs32-shared.d,
+		* testsuite/ld-powerpc/abs32-shared.r,
+		* testsuite/ld-powerpc/abs32-static.d,
+		* testsuite/ld-powerpc/abs32-static.r: New tests.
+		* testsuite/ld-powerpc/powerpc.exp: Run them.
+
+2022-05-04  John Baldwin  <jhb@FreeBSD.org>
+
+	gdbserver: Fix build after adding tls feature to arm tdesc.
+
+2022-05-04  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-04  John Baldwin  <jhb@FreeBSD.org>
+
+	NEWS: Add a note for TLS support on FreeBSD/arm and FreeBSD/Aarch64.
+
+	Read the tpidr register from NT_ARM_TLS on Linux.
+
+	gdbserver: Read the tpidr register from NT_ARM_TLS on Linux.
+
+	Read the tpidr register from NT_ARM_TLS core dump notes on Linux Aarch64.
+
+	Fetch the NT_ARM_TLS register set for native FreeBSD/Aarch64 processes.
+	This permits resolving TLS variables.
+
+	Support TLS variables on FreeBSD/Aarch64.
+	Derive the pointer to the DTV array from the tpidr register.
+
+	Read the tpidr register from NT_ARM_TLS core dump notes on FreeBSD/Aarch64.
+
+	Add an aarch64-tls feature which includes the tpidr register.
+
+	Fetch the NT_ARM_TLS register set for native FreeBSD/arm processes.
+	This permits resolving TLS variables.
+
+	Support TLS variables on FreeBSD/arm.
+	Derive the pointer to the DTV array from the tpidruro register.
+
+	Read the tpidruro register from NT_ARM_TLS core dump notes on FreeBSD/arm.
+
+	Add an arm-tls feature which includes the tpidruro register from CP15.
+
+	fbsd-nat: Add helper routines for register sets using PT_[G]SETREGSET.
+	FreeBSD's kernel has recently added PT_GETREGSET and PT_SETREGSET
+	operations to fetch a register set named by an ELF note type.  These
+	helper routines provide helpers to check for a register set's
+	existence, fetch registers for a register set, and store registers to
+	a register set.
+
+2022-05-03  H.J. Lu  <hjl.tools@gmail.com>
+
+	ld: Regenerate aclocal.m4 with automake 1.15.1
+		* aclocal.m4: Regenerate with automake 1.15.1.
+
+2022-05-03  Pedro Alves  <pedro@palves.net>
+
+	gdbserver: track current process as well as current thread
+	The recent commit 421490af33bf ("gdbserver/linux: Access memory even
+	if threads are running") caused a regression in
+	gdb.threads/access-mem-running-thread-exit.exp with gdbserver, which I
+	somehow missed.  Like so:
+
+	 (gdb) print global_var
+	 Cannot access memory at address 0x555555558010
+	 (gdb) FAIL: gdb.threads/access-mem-running-thread-exit.exp: non-stop: access mem (print global_var after writing, inf=2, iter=1)
+
+	The problem starts with GDB telling GDBserver to select a thread, via
+	the Hg packet, which GDBserver complies with, then that thread exits,
+	and GDB, without knowing the thread is gone, tries to write to memory,
+	through the context of the previously selected Hg thread.
+
+	GDBserver's GDB-facing memory access routines, gdb_read_memory and
+	gdb_write_memory, call set_desired_thread to make GDBserver re-select
+	the thread that GDB has selected with the Hg packet.  Since the thread
+	is gone, set_desired_thread returns false, and the memory access
+	fails.
+
+	Now, to access memory, it doesn't really matter which thread is
+	selected.  All we should need is the target process.  Even if the
+	thread that GDB previously selected is gone, and GDB does not yet know
+	about that exit, it shouldn't matter, GDBserver should still know
+	which process that thread belonged to.
+
+	Fix this by making GDBserver track the current process separately,
+	like GDB also does.  Add a new set_desired_process routine that is
+	similar to set_desired_thread, but just sets the current process,
+	leaving the current thread as NULL.  Use it in the GDB-facing memory
+	read and write routines, to avoid failing if the selected thread is
+	gone, but the process is still around.
+
+	Change-Id: I4ff97cb6f42558efbed224b30d5c71f6112d44cd
+
+2022-05-03  Pedro Alves  <pedro@palves.net>
+
+	Fix gdb.threads/access-mem-running-thread-exit.exp w/ native-extended-gdbserver
+	When testing gdb.threads/access-mem-running-thread-exit.exp with
+	--target_board=native-extended-gdbserver, we get:
+
+	  Running gdb.threads/access-mem-running-thread-exit.exp ...
+	  FAIL: gdb.threads/access-mem-running-thread-exit.exp: non-stop: second inferior: runto: run to main
+	  WARNING: Timed out waiting for EOF in server after monitor exit
+
+			  === gdb Summary ===
+
+	  # of expected passes            3
+	  # of unexpected failures        1
+	  # of unsupported tests          1
+
+	The problem is that the testcase spawns a second inferior with
+	-no-connection, and then runto_main does "run", which fails like so:
+
+	 (gdb) run
+	 Don't know how to run.  Try "help target".
+	 (gdb) FAIL: gdb.threads/access-mem-running-thread-exit.exp: non-stop: second inferior: runto: run to main
+
+	That "run" above failed because native-extended-gdbserver forces "set
+	auto-connect-native-target off", to prevent testcases from mistakenly
+	running programs with the native target, which would exactly be the
+	case here.
+
+	Fix this by letting the second inferior share the first inferior's
+	connection everywhere except on targets that do reload on run (e.g.,
+	--target_board=native-gdbserver).
+
+	Change-Id: Ib57105a238cbc69c57220e71261219fa55d329ed
+
+2022-05-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: add some additional thread status debug output
+	While working on this patch:
+
+	  https://sourceware.org/pipermail/gdb-patches/2022-January/185109.html
+
+	I found it really useful to print the executing/resumed status of all
+	threads (or all threads in a particular inferior) at various
+	places (e.g. when a new inferior is started, when GDB attaches, etc).
+
+	This debug was originally part of the above patch, but I wanted to
+	rewrite this as a separate patch and move the code into a new function
+	in infrun.h, which is what this patch does.
+
+	Unless 'set debug infrun on' is in effect, then there should be no
+	user visible changes after this commit.
+
+2022-05-03  Nick Clifton  <nickc@redhat.com>
+
+	Add a linker warning when creating potentially dangerous executable segments.  Add tests, options to disabke and configure switches to choose defaults.
+
+	Fix potential arithmetic overflow in the linker's plugin handling code.
+		PR 29101
+		* libdep_plugin.c (get_libdeps): Check for overflow when computing
+		amount of memory to allocate.
+
+2022-05-03  Andrew Burgess  <aburgess@redhat.com>
+
+	objdump: fix styled printing of addresses
+	Previous work to add styled disassembler output missed a case in
+	objdump_print_addr, which is fixed in this commit.
+
+2022-05-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: small cleanup in mi-break-qualified.exp
+	It is not necessary to pass an empty string to mi_gdb_start, passing
+	the empty string is equivalent to passing no arguments, which is what
+	we do everywhere else (that we don't need to specify an actual
+	argument).
+
+	The only place we use 'mi_gdb_start ""' is in
+	gdb.mi/mi-break-qualified.exp, so in this commit I just replace that
+	with a call to 'mi_gdb_start' - just for consistency.
+
+	There should be no change in what is tested after this commit.
+
+2022-05-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: change mi_gdb_start to take a list of flags
+	After this previous commit I was thinking about the API of
+	mi_gdb_start.  I felt that the idea of passing flags as separate
+	arguments and using 'args' to gather these into a list, though clever,
+	was not an intuitive API.
+
+	In this commit I modify mi_gdb_start so that it expects a single
+	argument, which should be a list of flags.  Thus, where we previously
+	would have said:
+
+	  mi_gdb_start separate-mi-tty separate-inferior-tty
+
+	We would now say:
+
+	  mi_gdb_start { separate-mi-tty separate-inferior-tty }
+
+	However, it turns out we never actually call mi_gdb_start passing two
+	arguments in this way at all.  We do in some places do this:
+
+	  mi_gdb_start separate-inferior-tty
+
+	But that's fine, a single string like this works equally well as a
+	single item list, so this will not need updating.
+
+	There is also one place where we do this:
+
+	  eval mi_gdb_start $start_ops
+
+	where $start_ops is a list that might contains 0, 1, or 2 items.  The
+	eval here is used to expand the $start_ops list so mi_gdb_start sees
+	the list contents as separate arguments.  In this case we just need to
+	drop the use of eval.
+
+	I think that the new API is more intuitive, but others might
+	disagree, in which case I can drop this change.
+
+	There should be no change in what is tested after this commit.
+
+2022-05-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: fix mi-exec-run.exp with native-extended-gdbserver board
+	When running with the native-extended-gdbserver board, I currently see
+	one failure in gdb.mi/mi-exec-run.exp:
+
+	    FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=0: breakpoint hit reported on console (timeout)
+
+	In this test the MI interface should be started in a separate tty,
+	which means we should have a CLI tty and an MI tty, however, this is
+	not happening.  Instead GDB is just started in MI mode and there is no
+	CLI tty.
+
+	The test script tries to switch between the CLI an MI terminals and
+	look for some expected output on each, however, as there is no CLI
+	terminal the expected output never arrives, and the test times out.
+
+	It turns out that this is not a GDB problem, rather, this is an issue
+	with argument passing within the test script.
+
+	The proc default_mi_gdb_start expects to take a set of flags (strings)
+	as arguments, each of flag is expected to be a separate argument.  The
+	default_mi_gdb_start proc collects all its arguments into a list using
+	the special 'args' parameter name, and then iterates over this list to
+	see which flags were passed.
+
+	In mi_gdb_start, which forwards to default_mi_gdb_start, the arguments
+	are also gathered into the 'args' parameter list, but are then
+	expanded back to be separate arguments using the eval trick, i.e.:
+
+	  proc mi_gdb_start { args } {
+	    return [eval default_mi_gdb_start $args]
+	  }
+
+	This ensures that when we arrive in default_mi_gdb_start each flag is
+	a separate argument, rather than appearing as a single list containing
+	all arguments.
+
+	When using the native-extended-gdbserver board however, the file
+	boards/native-extended-gdbserver.exp is loaded, and this file replaces
+	the default mi_gdb_start with its own version.
+
+	This new mi_gdb_start also gathers the arguments into an 'args' list,
+	but forgets to expand the arguments out using the eval trick.
+
+	As a result, when using the native-extended-gdbserver board, by the
+	time we get to default_mi_gdb_start, we end up with the args list
+	containing a single item, which is a list containing all the arguments
+	the user passed.
+
+	What this means is that if the user passes two arguments, then, in
+	default_mi_gdb_start, instead of seeing two separate arguments, we see
+	a single argument made by concatenating the two arguments together.
+
+	The only place this is a problem is in the test mi-exec-run.exp,
+	which (as far as I can see) is the only test where we might try to
+	pass both arguments at the same time.  Currently we think we passed
+	both arguments to mi_gdb_start, but mi_gdb_start behaves as if no
+	arguments were passed.
+
+	This commit fixes the problem by making use of the eval trick within
+	the native-extended-gdbserver version of mi_gdb_start.  After this,
+	the FAIL listed at the top of this message is resolved.
+
+2022-05-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: fix failures in gdb.mi/mi-exec-run.exp with native-extended-gdbserver
+	When running the gdb.mi/mi-exec-run.exp test using the
+	native-extended-gdbserver I see failures like this:
+
+	  FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=main: force-fail=1: run failure detected
+	  FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=separate: force-fail=1: run failure detected
+	  FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=1: run failure detected
+
+	There's a race condition here, so you might see a slightly different
+	set of failures, but I always see some from the 'run failure detected'
+	test.
+
+	NOTE: I also see an additional test failure:
+
+	 FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=0: breakpoint hit reported on console (timeout)
+
+	but that is a completely different issue, and is not being addressed
+	in this commit.
+
+	The problem for the 'run failure detected' test is that we end up
+	in gdb_expect looking for output from two spawn-ids, one from
+	gdbserver, and one from gdb.  We're looking for one output pattern
+	from each spawn-id, and for the test to pass we need to see both
+	patterns.
+
+	Now, if gdb exits then this is a test failure (this would indicate gdb
+	crashing, which is bad), so we have an eof pattern associated with
+	the gdb spawn-id.
+
+	However, in this particular test we expect gdbserver to fail to
+	execute the binary (the test binary is set non-executable), and so we
+	get an error message from gdbserver (which matches the pattern), and
+	then gdbserver exits, this is expected.
+
+	The problem is that after spotting the pattern from gdbserver, we
+	often see the eof from gdbserver before we see the pattern from gdb.
+	If this happens then we drop out of the gdb_expect without ever seeing
+	the pattern from gdb, and fail the test.
+
+	In this commit, I place the spawn-id of gdbserver into a global
+	variable, and then use this global variable as the -i option within
+	the gdb_expect.
+
+	Now, once we have seen the expected pattern on the gdbserver spawn-id,
+	the global variable is cleared.  After this the gdb_expect no longer
+	checks the gdbserver spawn-id for additional output, and so never sees
+	the eof event.  This leaves the gdb_expect running, which allows the
+	pattern from gdb to be seen, and for the test to pass.
+
+	I now see no failures relating to 'run failure detected'.
+
+2022-05-03  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-02  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.cp/align.exp with gcc 12.1 / 11.3
+	Starting with gcc 12.1 / gcc 11.3, for test-case gdb.cp/align.exp we run into:
+	...
+	align.cc:29:23: error: invalid application of 'alignof' to a void type^M
+	   29 |     unsigned a_void = alignof (void);^M
+	      |                       ^~~~~~~~~~~~~~^M
+	...
+
+	Fix this by using __alignof__ instead.
+
+	Tested on x86_64-linux, with gcc 7.5.0, gcc 12.1 and clang 12.0.1.
+
+2022-05-02  Aaron Merey  <amerey@redhat.com>
+
+	gdb/debuginfod: Whitespace-only URL should disable debuginfod
+	Currently debuginfod is disabled when the string of server URLs
+	is unset or set to be the empty string (via the $DEBUGINFOD_URLS
+	environment variable or the 'set debuginfod urls' gdb command).
+
+	Extend this functionality so that a whitespace-only URL also disables
+	debuginfod.
+
+	Modify a testcase to verify that a whitespace-only URL disables
+	debuginfod.
+
+2022-05-02  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove type_wanted parameter from a few functions
+	The type_wanted value, passed down to the create_sals_from_location
+	callback, is never used.  Remove it.
+
+	Change-Id: Ic363ee13f6af593a3e875ff7fe46de130cdc190c
+
+2022-05-02  Simon Marchi  <simon.marchi@efficios.com>
+
+	gnulib: update to bd11400942d6
+	Update the gnulib import to fixes these issues:
+
+	  - GDB build with clang + glibc < 2.33.
+
+	      https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=d6a07b4dc21b3118727743142c678858df442853
+	      https://lists.gnu.org/archive/html/bug-gnulib/2022-04/msg00072.html
+
+	    With glibc < 2.33, gnulib (since relatively recently) enables a
+	    replacement for free (see gnulib/import/m4/free.m4).  In that path,
+	    clang shows this error:
+
+	        make[2]: Entering directory '/home/smarchi/build/binutils-gdb-clang/gdbsupport'
+	          CXX      agent.o
+	        In file included from /home/smarchi/src/binutils-gdb/gdbsupport/agent.cc:20:
+	        In file included from /home/smarchi/src/binutils-gdb/gdbsupport/common-defs.h:95:
+	        ../gnulib/import/string.h:636:19: error: exception specification in declaration does not match previous declaration
+	        _GL_EXTERN_C void free (void *) throw ();
+	                          ^
+	        ../gnulib/import/stdlib.h:737:17: note: expanded from macro 'free'
+	        #   define free rpl_free
+	                        ^
+	        ../gnulib/import/stdlib.h:739:1: note: previous declaration is here
+	        _GL_FUNCDECL_RPL (free, void, (void *ptr));
+	        ^
+	        ../gnulib/import/sys/select.h:251:23: note: expanded from macro '_GL_FUNCDECL_RPL'
+	          _GL_FUNCDECL_RPL_1 (rpl_##func, rettype, parameters_and_attributes)
+	                              ^
+	        <scratch space>:139:1: note: expanded from here
+	        rpl_free
+	        ^
+
+	    The gnulib commit mentioned fixes the exception specification of `free`.
+
+	 - GDB build on RHEL 7:
+
+	      CC       libgnu_a-openat-proc.o
+	    In file included from /usr/include/string.h:633,
+	                     from ./string.h:41,
+	                     from ../../../binutils-gdb/gnulib/import/openat-proc.c:30:
+	    ./string.h:1105:1: error: expected identifier or '(' before '__extension__'
+	     1105 | _GL_FUNCDECL_SYS (strndup, char *,
+	          | ^~~~~~~~~~~~~~~~
+
+	     https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=84863a1c4dc8cca8fb0f6f670f67779cdd2d543b
+	     https://lists.gnu.org/archive/html/bug-gnulib/2022-04/msg00075.html
+
+	Change-Id: Ibd51302feece6f385d0c53e0d08921b5d95e2776
+
+2022-05-02  Tom Tromey  <tromey@adacore.com>
+
+	Fix Ada catchpoint regression
+	The breakpoint C++-ification series introduced a regression for Ada
+	catchpoints.  Specifically, commit 2b5ab5b8 ("Convert base breakpoints
+	to vtable ops") caused these to start failing.  I didn't notice this
+	because testing Ada using a Linux distro compiler requires installing
+	the GNAT debuginfo, which I hadn't done.
+
+	This patch fixes the problem.  I'm checking it in.
+
+2022-05-02  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-05-01  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.multi/attach-no-multi-process.exp with check-readmore
+	When running test-case gdb.multi/attach-no-multi-process.exp with
+	check-readmore, I get:
+	...
+	(gdb) attach 13411^M
+	Attaching to Remote target^M
+	No unwaited-for children left.^M
+	(gdb) Reading symbols from attach-no-multi-process...^M
+	Reading symbols from /lib64/libm.so.6...^M
+	(No debugging symbols found in /lib64/libm.so.6)^M
+	Reading symbols from /lib64/libc.so.6...^M
+	(No debugging symbols found in /lib64/libc.so.6)^M
+	Reading symbols from /lib64/ld-linux-x86-64.so.2...^M
+	(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)^M
+	0x00007f5df1fffc8a in clock_nanosleep@GLIBC_2.2.5 () from /lib64/libc.so.6^M
+	FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=off: \
+	  attach to the program via remote (timeout)
+	...
+
+	The problem is that the attach output is matched using gdb_test, which uses
+	the '$gdb_prompt $' regexp, and this does not handle the case that '(gdb) ' is
+	not the last available output.
+
+	Fix this by using a gdb_test_multiple instead with a '$gdb_prompt ' regexp, so
+	without the '$' anchor.
+
+	Tested on x86_64-linux with native, check-read1 and check-readmore.
+
+2022-05-01  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-30  Thomas Hebb  <tommyhebb@gmail.com>
+
+	opcodes: don't assume ELF in riscv, csky, rl78, mep disassemblers
+	Currently, the get_disassembler() implementations for riscv, csky, and
+	rl78--and mep_print_insn() for mep--access ELF variants of union fields
+	without first checking that the bfd actually represents an ELF.  This
+	causes undefined behavior and crashes when disassembling non-ELF files
+	(the "binary" BFD, for example).  Fix that.
+
+2022-04-30  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-29  Tom Tromey  <tom@tromey.com>
+
+	Remove create_breakpoints_sal_default
+	create_breakpoints_sal_default is just a simple wrapper, so remove it.
+
+	Remove allocate_bp_location
+	allocate_bp_location is just a small wrapper for a method call, so
+	inline it everywhere.
+
+	Constify breakpoint_ops
+	Now that all breakpoint_ops are statically initialized, they can all
+	be made const.
+
+	Remove breakpoint ops initialization
+	initialize_breakpoint_ops does not do much any more, so remove it in
+	favor of statically-initialize objects.
+
+	Remove vtable_breakpoint_ops
+	There's no need to have vtable_breakpoint_ops any more, so remove it
+	in favor of base_breakpoint_ops.
+
+	Remove most fields from breakpoint_ops
+	At this point, all implementations of breakpoints use the vtable.  So,
+	we can now remove most function pointers from breakpoint_ops and
+	switch to using methods directly in the callers.  Only the two "static
+	virtual" methods remain in breakpoint_ops.
+
+	Remove breakpoint_ops from init_catchpoint
+	init_catchpoint is only ever passed a single breakpoint_ops pointer,
+	so remove the parameter.
+
+	Remove breakpoint_ops from init_ada_exception_breakpoint
+	init_ada_exception_breakpoint is only ever passed a single
+	breakpoint_ops structure, so remove the parameter.
+
+2022-04-29  Tom Tromey  <tom@tromey.com>
+
+	Merge probe and ordinary tracepoints
+	Right now, probe tracepoints are handled by a separate ops object.
+	However, they differ only in a small way from ordinary tracepoints,
+	and furthermore can be distinguished by their event location.
+
+	This patch merges the two cases, just as was done for breakpoints.
+
+2022-04-29  Tom Tromey  <tom@tromey.com>
+
+	Merge probe and ordinary breakpoints
+	Right now, probe breakpoints are handled by a separate ops object.
+	However, they differ only in a small way from ordinary breakpoints,
+	and furthermore can be distinguished by their "probe" object.
+
+	This patch merges the two cases.  This avoids having to introduce a
+	new bp_ constant (which can be quite subtle to do correctly) and a new
+	subclass.
+
+2022-04-29  Tom Tromey  <tom@tromey.com>
+
+	Remove bkpt_base_breakpoint_ops
+	An earlier patch removed the last use of bkpt_base_breakpoint_ops, so
+	remove the object entirely.
+
+	Convert static marker tracepoints to vtable ops
+	This converts static marker tracepoints to use vtable_breakpoint_ops.
+
+	Add bp_static_marker_tracepoint
+	Because the actual construction of a breakpoint is buried deep in
+	create_breakpoint, at present it's necessary to have a new bp_
+	enumerator constant any time a new subclass is needed.  Static marker
+	tracepoints are one such case, so this patch introduces
+	bp_static_marker_tracepoint and updates various spots to recognize it.
+
+	Convert ranged breakpoints to vtable ops
+	This converts ranged breakpoints to use vtable_breakpoint_ops.  This
+	requires introducing a new ranged_breakpoint type, but this is
+	relatively simple because ranged breakpoints can only be created by
+	break_range_command.
+
+	Convert dprintf to vtable ops
+	This converts dprintf to use vtable_breakpoint_ops.
+
+	Convert Ada catchpoints to vtable ops
+	This converts Ada catchpoints to use vtable_breakpoint_ops.
+
+	Convert ordinary breakpoints to vtable ops
+	This converts "ordinary" breakpoint to use vtable_breakpoint_ops.
+	Recall that an ordinary breakpoint is both the kind normally created
+	by users, and also a base class used by other classes.
+
+	Change inheritance of dprintf
+	The dprintf breakpoint ops is mostly a copy of bpkt_breakpoint_ops,
+	except it's written out explicitly -- and, importantly, there's
+	nothing that bpkt_breakpoint_ops overrides that dprintf does not.
+	This changes dprintf to simply inherit directly, and updates struct
+	dprintf_breakpoint to reflect the change as well.
+
+	Convert momentary breakpoints to vtable ops
+	This converts momentary breakpoints to use vtable_breakpoint_ops.
+
+	Convert internal breakpoints to vtable ops
+	This converts internal breakpoints to use vtable_breakpoint_ops.
+
+	Convert break-catch-throw to vtable ops
+	This converts break-catch-throw.c to use vtable_breakpoint_ops.
+
+	Convert base breakpoints to vtable ops
+	This converts base breakpoints to use vtable_breakpoint_ops.
+
+2022-04-29  Tom Tromey  <tom@tromey.com>
+
+	Add some new subclasses of breakpoint
+	This adds a few new subclasses of breakpoint.  The inheritance
+	hierarchy is chosen to reflect what's already present in
+	initialize_breakpoint_ops -- it mirrors the way that the _ops
+	structures are filled in.
+
+	This patch also changes new_breakpoint_from_type to create the correct
+	sublcass based on bptype.  This is important due to the somewhat
+	inverted way in which create_breakpoint works; and in particular later
+	patches will change some of these entries.
+
+2022-04-29  Tom Tromey  <tom@tromey.com>
+
+	Convert tracepoints to vtable ops
+	This converts tracepoints to use vtable_breakpoint_ops.
+
+	Convert watchpoints to vtable ops
+	This converts watchpoints and masked watchpoints. to use
+	vtable_breakpoint_ops.  For masked watchpoints, a new subclass must be
+	introduced, and watch_command_1 is changed to create one.
+
+	Convert break-catch-load to vtable ops
+	This converts break-catch-load.c to use vtable_breakpoint_ops.
+
+	Convert break-catch-fork to vtable ops
+	This converts break-catch-fork.c to use vtable_breakpoint_ops.
+
+	Convert break-catch-exec to vtable ops
+	This converts break-catch-exec.c to use vtable_breakpoint_ops.
+
+	Convert break-catch-syscall to vtable ops
+	This converts break-catch-syscall.c to use vtable_breakpoint_ops.
+
+	Convert break-catch-sig to use vtable ops
+	This converts break-catch-sig.c to use vtable_breakpoint_ops.
+
+2022-04-29  Tom Tromey  <tom@tromey.com>
+
+	Add a vtable-based breakpoint ops
+	This adds methods to struct breakpoint.  Each method has a similar
+	signature to a corresponding function in breakpoint_ops, with the
+	exceptions of create_sals_from_location and create_breakpoints_sal,
+	which can't be virtual methods on breakpoint -- they are only used
+	during the construction of breakpoints.
+
+	Then, this adds a new vtable_breakpoint_ops structure and populates it
+	with functions that simply forward a call from breakpoint_ops to the
+	corresponding virtual method.  These are all done with lambdas,
+	because they are just a stepping stone -- by the end of the series,
+	this structure will be deleted.
+
+2022-04-29  Tom Tromey  <tom@tromey.com>
+
+	Return bool from breakpoint_ops::print_one
+	This changes breakpoint_ops::print_one to return bool, and updates all
+	the implementations and the caller.  The caller is changed so that a
+	NULL check is no longer needed -- something that will be impossible
+	with a real method.
+
+	Delete some unnecessary wrapper functions
+	This patch deletes a few unnecessary wrapper functions from
+	breakpoint.c.
+
+	Add an assertion to clone_momentary_breakpoint
+	This adds an assertion to clone_momentary_breakpoint.  This will
+	eventually be removed, but in the meantime is is useful for helping
+	convince oneself that momentary breakpoints will always use
+	momentary_breakpoint_ops.  This understanding will help when cleaning
+	up the code later.
+
+	Boolify print_solib_event
+	Change print_solib_event to accept a bool parameter and update the
+	callers.
+
+	Move "catch load" to a new file
+	The "catch load" code is reasonably self-contained, and so this patch
+	moves it out of breakpoint.c and into a new file, break-catch-load.c.
+	One function from breakpoint.c, print_solib_event, now has to be
+	exposed, but this seems pretty reasonable.
+
+2022-04-29  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+	gprofng: assertion in gprofng/src/Expression.cc:139
+	gprofng/ChangeLog
+	2022-04-28  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+		PR gprofng/29102
+		* src/Expression.h: Remove fixupValues.
+		* src/Expression.cc (Expression::copy): Fix a bug.
+
+2022-04-29  Tom Tromey  <tromey@adacore.com>
+
+	De-duplicate .gdb_index
+	This de-duplicates variables and types in .gdb_index, making the new
+	index closer to what gdb generated before the new DWARF scanner
+	series.  Spot-checking the resulting index for gdb itself, it seems
+	that the new scanner picks up some extra symbols not detected by the
+	old one.  I tested both the new and old versions of gdb on both new
+	and old versions of the index, and startup time in all cases is
+	roughly the same (it's worth noting that, for gdb itself, the index no
+	longer provides any benefit over the DWARF scanner).  So, I think this
+	fixes the size issue with the new index writer.
+
+	Regression tested on x86-64 Fedora 34.
+
+2022-04-29  Tom Tromey  <tromey@adacore.com>
+
+	Fix .debug_names regression with new indexer
+	At AdaCore, we run the internal gdb test suite in several modes,
+	including one using the .debug_names index.  This caught a regression
+	caused by the new DWARF indexer.
+
+	First, the psymtabs-based .debug_names generator was completely wrong.
+	However, to avoid making the rewrite series even bigger (fixing the
+	writer will also require rewriting the .debug_names reader), it
+	attempted to preserve the weirdness.
+
+	However, this was not done properly.  For example the old writer did
+	this:
+
+	-      case STRUCT_DOMAIN:
+	-	return DW_TAG_structure_type;
+
+	The new code, instead, simply preserves the actual DWARF tag -- but
+	this makes future lookups fail, because the .debug_names reader only
+	looks for DW_TAG_structure_type.
+
+	This patch attempts to revert to the old behavior in the writer.
+
+2022-04-29  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/infrun: make fetch_inferior_event restore thread if exited or signalled
+	Commit 152a1749566 ("gdb: prune inferiors at end of
+	fetch_inferior_event, fix intermittent failure of
+	gdb.threads/fork-plus-threads.exp") introduced some follow-fork-related
+	test failures, such as:
+
+	    info inferiors^M
+	      Num  Description       Connection           Executable        ^M
+	    * 1    process 634972    1 (native)           /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork ^M
+	      2    process 634975    1 (native)           /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork ^M
+	    (gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: info inferiors
+	    inferior 2^M
+	    [Switching to inferior 2 [process 634975] (/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork)]^M
+	    [Switching to thread 2.1 (Thread 0x7ffff7c9a740 (LWP 634975))]^M
+	    #0  0x00007ffff7d7abf7 in _Fork () from /usr/lib/libc.so.6^M
+	    (gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: inferior 2
+	    continue^M
+	    Continuing.^M
+	    [Inferior 2 (process 634975) exited normally]^M
+	    [Switching to Thread 0x7ffff7c9a740 (LWP 634972)]^M
+	    (gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: continue until exit at continue unfollowed inferior to end
+	    break callee^M
+	    Breakpoint 2 at 0x555555555160: file /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c, line 9.^M
+	    (gdb) FAIL: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: break callee
+
+	What happens here is:
+
+	 - inferior 2 is selected
+	 - we continue, leading to inferior 2's exit
+	 - we set breakpoint, expect 2 locations, but only one location is
+	   resolved
+
+	Reading between the lines, we understand that inferior 2 got pruned,
+	when it shouldn't have been.
+
+	The issue can be reproduced by hand with:
+
+	    $ ./gdb -q --data-directory=data-directory testsuite/outputs/gdb.base/foll-fork/foll-fork -ex "set detach-on-fork off" -ex start -ex "next 2" -ex "inferior 2" -ex "set debug infrun"
+	    ...
+	    Temporary breakpoint 1, main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:14
+	    14        int  v = 5;
+	    [New inferior 2 (process 637627)]
+	    [Thread debugging using libthread_db enabled]
+	    Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
+	    17        if (pid == 0) /* set breakpoint here */
+	    [Switching to inferior 2 [process 637627] (/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork)]
+	    [Switching to thread 2.1 (Thread 0x7ffff7c9a740 (LWP 637627))]
+	    #0  0x00007ffff7d7abf7 in _Fork () from /usr/lib/libc.so.6
+	    (gdb) continue
+	    Continuing.
+	    [infrun] clear_proceed_status_thread: 637627.637627.0
+	    [infrun] proceed: enter
+	      [infrun] proceed: addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT
+	      [infrun] scoped_disable_commit_resumed: reason=proceeding
+	      [infrun] start_step_over: enter
+	        [infrun] start_step_over: stealing global queue of threads to step, length = 0
+	        [infrun] operator(): step-over queue now empty
+	      [infrun] start_step_over: exit
+	      [infrun] proceed: start: resuming threads, all-stop-on-top-of-non-stop
+	        [infrun] proceed: resuming 637627.637627.0
+	        [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [637627.637627.0] at 0x7ffff7d7abf7
+	        [infrun] do_target_resume: resume_ptid=637627.637627.0, step=0, sig=GDB_SIGNAL_0
+	        [infrun] infrun_async: enable=1
+	        [infrun] prepare_to_wait: prepare_to_wait
+	      [infrun] proceed: end: resuming threads, all-stop-on-top-of-non-stop
+	      [infrun] reset: reason=proceeding
+	      [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target native
+	      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target native
+	      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target native
+	    [infrun] proceed: exit
+	    [infrun] fetch_inferior_event: enter
+	      [infrun] scoped_disable_commit_resumed: reason=handling event
+	      [infrun] do_target_wait: Found 2 inferiors, starting at #1
+	      [infrun] random_pending_event_thread: None found.
+	      [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
+	      [infrun] print_target_wait_results:   637627.637627.0 [process 637627],
+	      [infrun] print_target_wait_results:   status->kind = EXITED, exit_status = 0
+	      [infrun] handle_inferior_event: status->kind = EXITED, exit_status = 0
+	    [Inferior 2 (process 637627) exited normally]
+	      [infrun] stop_waiting: stop_waiting
+	      [infrun] stop_all_threads: start: reason=presenting stop to user in all-stop, inf=-1
+	        [infrun] stop_all_threads: pass=0, iterations=0
+	        [infrun] stop_all_threads:   637624.637624.0 not executing
+	        [infrun] stop_all_threads: pass=1, iterations=1
+	        [infrun] stop_all_threads:   637624.637624.0 not executing
+	        [infrun] stop_all_threads: done
+	      [infrun] stop_all_threads: end: reason=presenting stop to user in all-stop, inf=-1
+	    [Switching to Thread 0x7ffff7c9a740 (LWP 637624)]
+	      [infrun] infrun_async: enable=0
+	      [infrun] reset: reason=handling event
+	      [infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target native, no resumed threads
+	    (gdb) [infrun] fetch_inferior_event: exit
+	    (gdb) info inferiors
+	      Num  Description       Connection           Executable
+	    * 1    process 637624    1 (native)           /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork
+	    (gdb) i th
+	      Id   Target Id                                      Frame
+	    * 1    Thread 0x7ffff7c9a740 (LWP 637624) "foll-fork" main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:17
+
+	After handling the EXITED event for inferior 2, inferior 2 should have
+	stayed the current inferior, which should have prevented it from getting
+	pruned.  When debugging, we find that when getting at the
+	prune_inferiors call, the current inferior is inferior 1.  Further
+	debugging shows that prior to the call to
+	clean_up_just_stopped_threads_fsms, the current inferior is inferior 2,
+	and after, it's inferior 1.  Then, back in fetch_inferior_event, the
+	restore_thread object is disabled, due to:
+
+		    /* If we got a TARGET_WAITKIND_NO_RESUMED event, then the
+		       previously selected thread is gone.  We have two
+		       choices - switch to no thread selected, or restore the
+		       previously selected thread (now exited).  We chose the
+		       later, just because that's what GDB used to do.  After
+		       this, "info threads" says "The current thread <Thread
+		       ID 2> has terminated." instead of "No thread
+		       selected.".  */
+		    if (!non_stop
+			&& cmd_done
+			&& ecs->ws.kind () != TARGET_WAITKIND_NO_RESUMED)
+		      restore_thread.dont_restore ();
+
+	So in the end, inferior 1 stays current, and inferior 2 gets wrongfully
+	pruned.
+
+	I'd say clean_up_just_stopped_threads_fsms is the culprit here.  It
+	actually attempts to restore the event_thread to be current at the end,
+	after the loop (I presume the current thread on entry is always supposed
+	to be the event thread).  But in this case, the event is of kind EXITED,
+	and ecs->event_thread is not set, so the current inferior isn't
+	restored.
+
+	Fix that by using scoped_restore_current_thread.  If there is no current
+	thread, scoped_restore_current_thread will still restore the current
+	inferior, and that's what we want.
+
+	Random note: the thread_info object for inferior 2's thread is never
+	freed.  It is held (by refcount) by the restore_thread object in
+	fetch_inferior_event, while the inferior's thread list gets cleared, in
+	the exit event processing.  When the refcount reaches 0 (when the
+	restore_thread object is destroyed), there's nothing that actually
+	deletes the thread_info object.  And I think that nothing in GDB points
+	to it anymore, so it leaks.  I don't want to fix that in this patch, but
+	thought it would be good to mention it, in case somebody has an idea for
+	how to fix that.
+
+	Change-Id: Ibc7df543e2c46aad5f3b9250b28c3fb5912be4e8
+
+2022-04-29  Pedro Alves  <pedro@palves.net>
+
+	Slightly tweak and clarify target_resume's interface
+	The current target_resume interface is a bit odd & non-intuitive.
+	I've found myself explaining it a couple times the recent past, while
+	reviewing patches that assumed STEP/SIGNAL always applied to the
+	passed in PTID.  It goes like this today:
+
+	  - if the passed in PTID is a thread, then the step/signal request is
+	    for that thread.
+
+	  - otherwise, if PTID is a wildcard (all threads or all threads of
+	    process), the step/signal request is for inferior_ptid, and PTID
+	    indicates which set of threads run free.
+
+	Because GDB always switches the current thread to "leader" thread
+	being resumed/stepped/signalled, we can simplify this a bit to:
+
+	  - step/signal are always for inferior_ptid.
+
+	  - PTID indicates the set of threads that run free.
+
+	Still not ideal, but it's a minimal change and at least there are no
+	special cases this way.
+
+	That's what this patch does.  It renames the PTID parameter to
+	SCOPE_PTID, adds some assertions to target_resume, and tweaks
+	target_resume's description.  In addition, it also renames PTID to
+	SCOPE_PTID in the remote and linux-nat targets, and simplifies their
+	implementation a little bit.  Other targets could do the same, but
+	they don't have to.
+
+	Change-Id: I02a2ec2ab3a3e9b191de1e9a84f55c17cab7daaf
+
+2022-04-29  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-28  Tom Tromey  <tromey@adacore.com>
+
+	Fix libinproctrace.so build on PPC
+	The recent gnulib import caused a build failure of libinproctrace.so
+	on PPC:
+
+	    alloc.c:(.text+0x20): undefined reference to `rpl_malloc'
+	    alloc.c:(.text+0x70): undefined reference to `rpl_realloc'
+
+	This patch fixes the problem using the same workaround that was
+	previously used for free.
+
+2022-04-28  H.J. Lu  <hjl.tools@gmail.com>
+
+	x86: Properly handle function pointer reference
+	Update
+
+	commit ebb191adac4ab45498dec0bfaac62f0a33537ba4
+	Author: H.J. Lu <hjl.tools@gmail.com>
+	Date:   Wed Feb 9 15:51:22 2022 -0800
+
+	    x86: Disallow invalid relocation against protected symbol
+
+	to allow function pointer reference and make sure that PLT entry isn't
+	used for function reference due to function pointer reference.
+
+	bfd/
+
+		PR ld/29087
+		* elf32-i386.c (elf_i386_scan_relocs): Don't set
+		pointer_equality_needed nor check non-canonical reference for
+		function pointer reference.
+		* elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise.
+
+	ld/
+
+		PR ld/29087
+		* testsuite/ld-x86-64/x86-64.exp: Run PR ld/29087 tests.
+		* testsuite/ld-x86-64/protected-func-3.c: New file.
+
+2022-04-28  Tom Tromey  <tom@tromey.com>
+
+	Check OBJF_NOT_FILENAME in DWARF index code
+	The DWARF index code currently uses 'stat' to see if an objfile
+	represents a real file.  However, I think it's more correct to check
+	OBJF_NOT_FILENAME instead.
+
+	Regression tested on x86-64 Fedora 34.
+
+2022-04-28  Tom Tromey  <tromey@adacore.com>
+
+	Remove "typedef enum ..."
+	I noticed a few spots in GDB that use "typedef enum".  However, in C++
+	this isn't as useful, as the tag is automatically entered as a
+	typedef.  This patch removes most uses of "typedef enum" -- the
+	exceptions being in some nat-* code I can't compile, and
+	glibc_thread_db.h, which I think is more or less a copy of some C code
+	from elsewhere.
+
+	Tested by rebuilding.
+
+2022-04-28  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: fix nullptr dereference in block::ranges()
+	This commit:
+
+	  commit f5cb8afdd297dd68273d98a10fbfd350dff918d8
+	  Date:   Sun Feb 6 22:27:53 2022 -0500
+
+	      gdb: remove BLOCK_RANGES macro
+
+	introduces a potential nullptr dereference in block::ranges, this is
+	breaking most tests, e.g. gdb.base/break.exp is failing for me.
+
+	In the above patch BLOCK_CONTIGUOUS_P is changed from this:
+
+	  #define BLOCK_CONTIGUOUS_P(bl)  (BLOCK_RANGES (bl) == nullptr \
+	                                   || BLOCK_NRANGES (bl) <= 1)
+
+	to this:
+
+	  #define BLOCK_CONTIGUOUS_P(bl)  ((bl)->ranges ().size () == 0 \
+	                                   || (bl)->ranges ().size () == 1)
+
+	So, before the commit we checked for the block ranges being nullptr,
+	but afterwards we just call block::ranges() in all cases.
+
+	The problem is that block::ranges() looks like this:
+
+	  /* Return a view on this block's ranges.  */
+	  gdb::array_view<blockrange> ranges ()
+	  { return gdb::make_array_view (m_ranges->range, m_ranges->nranges); }
+
+	where m_ranges is:
+
+	  struct blockranges *m_ranges;
+
+	And so, we see that the nullptr check has been lost, and we might end
+	up dereferencing a nullptr.
+
+	My proposed fix is to move the nullptr check into block::ranges, and
+	return an explicit empty array_view if m_ranges is nullptr.
+
+	After this, everything seems fine again.
+
+2022-04-28  Stefan Liebler  <stli@linux.ibm.com>
+
+	s390: Add DT_JMPREL pointing to .rela.[i]plt with static-pie
+	In static-pie case, there are IRELATIVE-relocs in
+	.rela.iplt (htab->irelplt), which will later be grouped
+	to .rela.plt.  On s390, the IRELATIVE relocations are
+	always located in .rela.iplt - even for non-static case.
+	Ensure that DT_JMPREL, DT_PLTRELA, DT_PLTRELASZ is added
+	to the dynamic section even if htab->srelplt->size == 0.
+	See _bfd_elf_add_dynamic_tags in bfd/elflink.c.
+
+	bfd/
+		elf64-s390.c (elf_s390_size_dynamic_sections):
+		Enforce DT_JMPREL via htab->elf.dt_jmprel_required.
+
+2022-04-28  Stefan Liebler  <stli@linux.ibm.com>
+
+	s390: Avoid dynamic TLS relocs in PIE
+	No dynamic relocs are needed for TLS defined in an executable, the
+	TP relative offset is known at link time.
+
+	Fixes
+	FAIL: Build pr22263-1
+
+	bfd/
+		PR ld/22263
+		* elf64-s390.c (elf_s390_tls_transition): Use bfd_link_dll
+		instead of bfd_link_pic for TLS.
+		(elf_s390_check_relocs): Likewise.
+		(allocate_dynrelocs): Likewise.
+		(elf_s390_relocate_section): Likewise.
+
+2022-04-28  Nick Alcock  <nick.alcock@oracle.com>
+
+	libctf: impose an ordering on conflicting types
+	When two types conflict and they are not types which can have forwards
+	(say, two arrays of different sizes with the same name in two different
+	TUs) the CTF deduplicator uses a popularity contest to decide what to
+	do: the type cited by the most other types ends up put into the shared
+	dict, while the others are relegated to per-CU child dicts.
+
+	This works well as long as one type *is* most popular -- but what if
+	there is a tie?  If several types have the same popularity count,
+	we end up picking the first we run across and promoting it, and
+	unfortunately since we are working over a dynhash in essentially
+	arbitrary order, this means we promote a random one.  So multiple
+	runs of ld with the same inputs can produce different outputs!
+	All the outputs are valid, but this is still undesirable.
+
+	Adjust things to use the same strategy used to sort types on the output:
+	when there is a tie, always put the type that appears in a CU that
+	appeared earlier on the link line (and if there is somehow still a tie,
+	which should be impossible, pick the type with the lowest type ID).
+
+	Add a testcase -- and since this emerged when trying out extern arrays,
+	check that those work as well (this requires a newer GCC, but since all
+	GCCs that can emit CTF at all are unreleased this is probably OK as
+	well).
+
+	Fix up one testcase that has slight type ordering changes as a result
+	of this change.
+
+	libctf/ChangeLog:
+
+		* ctf-dedup.c (ctf_dedup_detect_name_ambiguity): Use
+		cd_output_first_gid to break ties.
+
+	ld/ChangeLog:
+
+		* testsuite/ld-ctf/array-conflicted-ordering.d: New test, using...
+		* testsuite/ld-ctf/array-char-conflicting-1.c: ... this...
+		* testsuite/ld-ctf/array-char-conflicting-2.c: ... and this.
+		* testsuite/ld-ctf/array-extern.d: New test, using...
+		* testsuite/ld-ctf/array-extern.c: ... this.
+		* testsuite/ld-ctf/conflicting-typedefs.d: Adjust for ordering
+		changes.
+
+2022-04-28  Nick Alcock  <nick.alcock@oracle.com>
+
+	libctf: add a comment explaining how to use ctf_*open
+	Specifically, tell users what to pass to those functions that accept raw
+	section content, since it's fairly involved and easy to get wrong.
+	(.dynsym / .dynstr when CTF_F_DYNSTR is set, otherwise .symtab / .strtab).
+
+	include/ChangeLog:
+
+		* ctf-api.h (ctf_*open): Improve comment.
+
+2022-04-28  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+	gprofng: test suite problems
+	gprofng/ChangeLog
+	2022-04-27  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+		PR gprofng/29065
+		* testsuite/lib/Makefile.skel: Search parent dir for libs too.
+
+2022-04-28  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove BLOCKVECTOR_MAP macro
+	Replace with equivalent methods.
+
+	Change-Id: I4e56c76dfc363c1447686fb29c4212ea18b4dba0
+
+2022-04-28  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: constify addrmap_find
+	addrmap_find shouldn't need to modify the addrmap, so constify the
+	addrmap parameter.  This helps for the following patch, where getting
+	the map of a const blockvector will return a const addrmap.
+
+	Change-Id: If670e425ed013724a3a77aab7961db50366dccb2
+
+2022-04-28  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove BLOCKVECTOR_BLOCK and BLOCKVECTOR_NBLOCKS macros
+	Replace with calls to blockvector::blocks, and the appropriate method
+	call on the returned array_view.
+
+	Change-Id: I04d1f39603e4d4c21c96822421431d9a029d8ddd
+
+2022-04-28  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove BLOCK_ENTRY_PC macro
+	Replace with equivalent method.
+
+	Change-Id: I0e033095e7358799930775e61028b48246971a7d
+
+2022-04-28  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove BLOCK_CONTIGUOUS_P macro
+	Replace with an equivalent method.
+
+	Change-Id: I60fd3be7b4c2601c2a74328f635fa48ed80eb7f5
+
+2022-04-28  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove BLOCK_RANGE macro
+	Replace with access through the block::ranges method.
+
+	Change-Id: I50f3ed433b997c9f354e49bc6583f540ae4b6121
+
+2022-04-28  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove BLOCK_NRANGES macro
+	Replace with range for loops.
+
+	Change-Id: Icbe04f9b6f9e6ddae2e15b2409c61f7a336bc3e3
+
+2022-04-28  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove BLOCK_RANGES macro
+	Replace with an equivalent method on struct block.
+
+	Change-Id: I6dcf13e9464ba8a08ade85c89e7329c300fd6c2a
+
+2022-04-28  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove BLOCK_RANGE_{START,END} macros
+	Replace with equivalent methods on blockrange.
+
+	Change-Id: I20fd8f624e0129782c36768291891e7582d77c74
+
+2022-04-28  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove BLOCK_NAMESPACE macro
+	Replace with equivalent methods.
+
+	Change-Id: If86b8cbdfb0f52e22c929614cd53e73358bab76a
+
+2022-04-28  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove BLOCK_MULTIDICT macro
+	Replace with equivalent methods.
+
+	Change-Id: If9a239c511a664f2a59fecb6d1cd579881b23dc2
+
+2022-04-28  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove BLOCK_SUPERBLOCK macro
+	Replace with equivalent methods.
+
+	Change-Id: I334a319909a50b5cc5570a45c38c70e10dc00630
+
+2022-04-28  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove BLOCK_FUNCTION macro
+	Replace with equivalent methods.
+
+	Change-Id: I31ec00f5bf85335c8b23d306ca0fe0b84d489101
+
+2022-04-28  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove BLOCK_{START,END} macros
+	Replace with equivalent methods.
+
+	Change-Id: I10a6c8a2a86462d9d4a6a6409a3f07a6bea66310
+
+2022-04-28  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-27  H.J. Lu  <hjl.tools@gmail.com>
+
+	x86: Disable 2 tests with large memory requirement
+	gas/
+
+		* testsuite/gas/i386/i386.exp: Disable rept.
+
+	ld/
+
+		* testsuite/ld-x86-64/x86-64.exp: Disable pr17618.
+
+2022-04-27  Pedro Alves  <pedro@palves.net>
+
+	Make gdb.base/parse_number.exp test all architectures
+	There are some subtle differences between architectures, like the size
+	of a "long" type, and this isn't currently accounted for in
+	gdb.base/parse_number.exp.
+
+	For example, on aarch64 a long type is 8 bytes, whereas a long type is
+	4 bytes for x86_64.  This causes the following FAIL's:
+
+	 FAIL: gdb.base/parse_number.exp: lang=asm: ptype 0xffffffffffffffff
+	 FAIL: gdb.base/parse_number.exp: lang=auto: ptype 0xffffffffffffffff
+	 FAIL: gdb.base/parse_number.exp: lang=c: ptype 0xffffffffffffffff
+	 FAIL: gdb.base/parse_number.exp: lang=c++: ptype 0xffffffffffffffff
+	 FAIL: gdb.base/parse_number.exp: lang=fortran: p/x 0xffffffffffffffff
+	 FAIL: gdb.base/parse_number.exp: lang=fortran: ptype 0xffffffffffffffff
+	 FAIL: gdb.base/parse_number.exp: lang=go: ptype 0xffffffffffffffff
+	 FAIL: gdb.base/parse_number.exp: lang=local: ptype 0xffffffffffffffff
+	 FAIL: gdb.base/parse_number.exp: lang=minimal: ptype 0xffffffffffffffff
+	 FAIL: gdb.base/parse_number.exp: lang=objective-c: ptype 0xffffffffffffffff
+	 FAIL: gdb.base/parse_number.exp: lang=opencl: ptype 0xffffffffffffffff
+	 FAIL: gdb.base/parse_number.exp: lang=pascal: ptype 0xffffffffffffffff
+
+	There are some fortran-specific divergences as well, where 32-bit
+	architectures show "unsigned int" for both 32-bit and 64-bit integers
+	and 64-bit architectures show "unsigned int" and "unsigned long" for
+	32-bit and 64-bit integers.
+
+	There might be a bug that 32-bit fortran truncates 64-bit values to
+	32-bit, given "p/x 0xffffffffffffffff" returns "0xffffffff".
+
+	Here's what we get for aarch64:
+
+	 (gdb) ptype 0xffffffff
+	 type = unsigned int
+	 (gdb) ptype 0xffffffffffffffff
+	 type = unsigned long
+	 (gdb) p sizeof (0xffffffff)
+	 $1 = 4
+	 (gdb) p sizeof (0xffffffffffffffff)
+	 quit
+	 $2 = 8
+	 (gdb) ptype 0xffffffff
+	 type = unsigned int
+	 (gdb) ptype 0xffffffffffffffff
+	 type = unsigned long
+
+	And for arm:
+
+	 (gdb) ptype 0xffffffff
+	 type = unsigned int
+	 (gdb) ptype 0xffffffffffffffff
+	 quit
+	 type = unsigned long long
+	 (gdb) p sizeof (0xffffffff)
+	 quit
+	 $1 = 4
+	 (gdb) p sizeof (0xffffffffffffffff)
+	 quit
+	 $2 = 8
+	 (gdb) ptype 0xffffffff
+	 type = unsigned int
+	 (gdb) ptype 0xffffffffffffffff
+	 type = unsigned long
+
+	This patch...
+
+	* Makes the testcase iterate over all architectures, thus covering all
+	  the different combinations of types/sizes every time.
+
+	* Adjusts the expected values and types based on the sizes of long
+	  long, long and int.
+
+	A particularly curious architecture is s12z, which has 32-bit long
+	long, and thus no way to represent 64-bit integers in C-like
+	languages.
+
+	Co-Authored-By: Luis Machado <luis.machado@arm.com>
+	Change-Id: Ifc0ccd33e7fd3c7585112ff6bebe7d266136768b
+
+2022-04-27  Tom Tromey  <tromey@adacore.com>
+
+	Fix gdbserver build for x86-64 Windows
+	I broke the gdbserver build on x86-64 Windows a little while back.
+	Previously, I could not build this configuration, but today I found
+	out that if I configure with:
+
+	    --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
+
+	using the Fedora 34 tools, it will in fact build.  I'm not certain,
+	but maybe the gnulib update helped with this.
+
+	This patch fixes the build.  I'm checking it in.
+
+2022-04-27  John Baldwin  <jhb@FreeBSD.org>
+
+	Create pseudo sections for NT_ARM_TLS notes on FreeBSD.
+	bfd/ChangeLog:
+
+		* elf.c (elfcore_grok_freebsd_note): Handle NT_ARM_TLS notes.
+
+2022-04-27  Christophe Lyon  <christophe.lyon@arm.com>
+
+	gdb/arm: Extend arm_m_addr_is_magic to support FNC_RETURN, add unwind-secure-frames command
+	This patch makes use of the support for several stack pointers
+	introduced by the previous patch to switch between them as needed
+	during unwinding.
+
+	It introduces a new 'unwind-secure-frames' arm command to enable/disable
+	mode switching during unwinding. It is enabled by default.
+
+	It has been tested using an STM32L5 board (with cortex-m33) and the
+	sample applications shipped with the STM32Cube development
+	environment: GTZC_TZSC_MPCBB_TrustZone in
+	STM32CubeL5/Projects/NUCLEO-L552ZE-Q/Examples/GTZC.
+
+	The test consisted in setting breakpoints in various places and check
+	that the backtrace is correct: SecureFault_Callback (Non-secure mode),
+	__gnu_cmse_nonsecure_call (before and after the vpush instruction),
+	SecureFault_Handler (Secure mode).
+
+	This implies that we tested only some parts of this patch (only MSP*
+	were used), but remaining parts seem reasonable.
+
+2022-04-27  Christophe Lyon  <christophe.lyon@arm.com>
+
+	gdb/arm: Add support for multiple stack pointers on Cortex-M
+	Armv8-M architecture with Security extension features four stack pointers
+	to handle Secure and Non-secure modes.
+
+	This patch adds support to switch between them as needed during
+	unwinding, and replaces all updates of cache->prev_sp with calls to
+	arm_cache_set_prev_sp.
+
+2022-04-27  Christophe Lyon  <christophe.lyon@arm.com>
+
+	gdb/arm: Introduce arm_cache_init
+	This patch is a preparation for the rest of the series and adds two
+	arm_cache_init helper functions. It updates every place that updates
+	cache->saved_regs to call the helper instead.
+
+	gdb/arm: Define MSP and PSP registers for M-Profile
+	This patch removes the hardcoded access to PSP in
+	arm_m_exception_cache() and relies on the definition with the XML
+	descriptions.
+
+2022-04-27  Christophe Lyon  <christophe.lyon@arm.com>
+
+	gdb/arm: Fix prologue analysis to support vpush
+	While working on adding support for Non-secure/Secure modes unwinding,
+	I noticed that the prologue analysis lacked support for vpush, which
+	is used for instance in the CMSE stub routine.
+
+	This patch updates thumb_analyze_prologue accordingly, adding support
+	for vpush of D-registers.
+
+2022-04-27  Enze Li  <lienze2010@hotmail.com>
+
+	gdb/testsuite: fix FAIL in gdb.base/clear_non_user_bp.exp
+	Tom and Simon feedback that there is a test failing in this commit:
+
+	  commit a5c69b1e49bae4d0dcb20f324cebb310c63495c6
+	  Date:   Sun Apr 17 15:09:46 2022 +0800
+
+	    gdb: fix using clear command to delete non-user breakpoints(PR cli/7161)
+
+	Then, I reproduced the same fail with Ubuntu 20.04 as Simon said, and I
+	fixed the nit in this patch.  The root of the problem is not correctly
+	matching the presentation of internal breakpoints.
+
+	In addition, as Pedro pointed out, the original testcase is not portable
+	in some methods, so this patch fixes this issue and some other
+	improvements.
+
+	Tested on x86_64 ubuntu 20.04.4 and openSUSE Tumbleweed(VERSION_ID="20220425").
+
+2022-04-27  Jan Beulich  <jbeulich@suse.com>
+
+	x86: VFPCLASSSH is Evex.LLIG
+	This also was mistakenly flagged as Evex.128.
+
+2022-04-27  Nick Clifton  <nickc@redhat.com>
+
+	Fix potential buffer overruns when creating DLLs.
+		PR 29006
+		* pe-dll.c (make_head): Use asprintf to allocate and populate a
+		buffer containing the temporary name.
+		(make_tail, make_one, make_singleton_name_thunk): Likewise.
+		(make_import_fixup_mark, make_import_fixup_entry): Likewise.
+		(make_runtime_pseudo_reloc): Likewise.
+		(pe_create_runtime_relocator_reference): Likewise.
+
+2022-04-27  Alan Modra  <amodra@gmail.com>
+
+	Revert pr29072 lto test changes
+	Revert commit 65daf5bed6 testsuite changes in ld-plugin/.  -z isn't
+	supported for non-ELF targets, and isn't needed since we now prune the
+	exec stack warning (commit 333cd559ba).
+
+		PR 29072
+
+2022-04-27  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/testsuite: use with_cwd where possible
+	I learned about with_cwd today.  I spotted a few spots that could use
+	it, to make the code more robust.
+
+	Change-Id: Ia23664cb827f25e79d31948e0c006a8dc61c33e1
+
+2022-04-27  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-26  Carl Love  <cel@us.ibm.com>
+
+	GDB PowerPC record test cases for ISA 2.06 and ISA 3.1
+	This patch adds PowerPC specific tests to verify recording of various
+	instructions.  The first test case checks the ISA 2.06 lxvd2x instruction.
+	The second test case tests several of the ISA 3.01 instructions.  Specifically,
+	it checks the word and prefixed instructions and some of the Matrix
+	Multiply Assist (MMA) instructions.
+
+	The patch has been run on both Power 10 and Power 9 to verify the ISA
+	2.06 test case runs on both platforms without errors.  The ISA 3.1 test
+	runs without errors on Power 10 and is skipped as expected on Power 9.
+
+2022-04-26  Carl Love  <cel@us.ibm.com>
+
+	Add recording support for the ISA 3.1 PowerPC instructions.
+	This patch adds support for the PowerPC ISA 3.1 instructions to the PowerPC
+	gdb instruction recording routines.  Case statement entries are added to a
+	number of the existing routines for recording the 32-bit word instructions.
+	A few new functions were added to handle the new word instructions.  The 64-bit
+	prefix instructions are all handled by a set of new routines.  The function
+	ppc_process_prefix_instruction() is the primary function to handle the
+	prefixed instructions. It calls additional functions to handle specific
+	sets of prefixed instructions.  These new functions are:
+	  ppc_process_record_prefix_vsx_d_form(),
+	  ppc_process_record_prefix_store_vsx_ds_form(),
+	  ppc_process_record_prefix_op34(),
+	  ppc_process_record_prefix_op33(),
+	  ppc_process_record_prefix_op32(),
+	  ppc_process_record_prefix_store(),
+	  ppc_process_record_prefix_op59_XX3(),
+	  ppc_process_record_prefix_op42().
+
+2022-04-26  Tom Tromey  <tromey@adacore.com>
+
+	Handle encoding failures in Windows thread names
+	Internally at AdaCore, we noticed that the new Windows thread name
+	code could fail.  First, it might return a zero-length string, but in
+	gdb conventions it should return nullptr instead.  Second, an encoding
+	failure could wind up showing replacement characters to the user; this
+	is confusing and not useful; it's better to recognize such errors and
+	simply discard the name.  This patch makes both of these changes.
+
+2022-04-26  H.J. Lu  <hjl.tools@gmail.com>
+
+	i386: Pass -z noexecstack to linker tests
+		PR ld/29072
+		* testsuite/ld-i386/i386.exp: Pass -z noexecstack to gotpc1
+		and property-6.
+
+2022-04-26  John Baldwin  <jhb@FreeBSD.org>
+
+	bsd-kvm: Fix build after recent changes to path handling functions.
+	Convert bsd_kvm_corefile and the local filename in bsd_kvm_open to
+	std::string rather than simple char * pointers freed by xfree.
+
+2022-04-26  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: make some random Python files Python 3-compatible
+	I noticed that these files failed to format with Black, because they use
+	print without parenthesis (which isn't Python 3 compatible).
+
+	I don't know if these files are still relevant, but the change is
+	trivial, so here it is.
+
+	Change-Id: I116445c2b463486016f824d32effffc915b60766
+
+2022-04-26  Carl Love  <cel@us.ibm.com>
+
+	PowerPC: Update expected floating point output for gdb.arch/altivec-regs.exp and gdb.arch/vsx-regs.exp
+	The format for printing the floating point values was changed by commit:
+
+	   commit 56262a931b7ca8ee3ec9104bc7e9e0b40cf3d64e
+	   Author: Tom Tromey <tromey@adacore.com>
+	   Date:   Thu Feb 17 13:43:59 2022 -0700
+
+	       Change how "print/x" displays floating-point value
+
+	       Currently, "print/x" will display a floating-point value by first
+	       casting it to an integer type.  This yields weird results like:
+
+	           (gdb) print/x 1.5
+	           $1 = 0x1
+	        ...
+	        Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16242
+
+	The above change results in 417 regression test failures since the expected
+	Power vector register output no longer match.
+
+	This patch updates the expected Altivec floating point register prints to
+	the hexadecimal format for both big endian and little endian systems.  The
+	patch also fixes a formatting isue with the decimal_vector expected value
+	assign statements.
+
+	The expected VSX vector_register1, vector_register1_vr, vector_register2,
+	vector_register2_vr variables are updated to include the new float128 entry.
+	Additionally, the comment in the vsx expect file about the initialization
+	of the vs registers is updated.
+
+	The patch has been tested on Power 10, Power 8 LE and Power 8 BE.
+
+2022-04-26  John Baldwin  <jhb@FreeBSD.org>
+
+	gdbsupport/pathstuff.h: #include <array> explicitly for std::array<>
+	This fixes build breakage using clang with libc++ on FreeBSD where
+	std::array<> is not yet declared when used by the path_join variadic
+	function template.
+
+2022-04-26  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-25  Tom Tromey  <tromey@adacore.com>
+
+	Do not put linkage names into .gdb_index
+	This changes the .gdb_index writer to skip linkage names.  This was
+	always done historically (though somewhat implicitly).
+
+2022-04-25  Nick Clifton  <nickc@redhat.com>
+
+	Emit a note warning the user that creating an executable stack because of a missing .note.GNU-stack section is deprecated.
+		PR 29072
+	bfd	* elflink.c (bfd_elf_size_dynamic_sections): Display a note to the
+		user that the current ehaviour of creating an executable stack
+		because of a missing .note.GNU-stack section is deprecated and
+		will be changed in a future release.
+
+	binutils* testsuite/lib/binutils-common.exp (prune_warnings_extra): Filter
+		out notes about the executable stacjk behaviour beign deprecated.
+
+	ld	* testsuite/ld-elf/pr29072.b.warn: Update to include the note
+		about the linker's behaviour being depreccated.
+
+2022-04-25  rupothar  <rupesh.potharla@amd.com>
+
+	gdb/fortran: Support for assumed rank zero
+	If a variable is passed to function in FORTRAN as an argument the
+	variable is treated as an array with rank zero.  GDB currently does
+	not support the case for assumed rank 0.  This patch provides support
+	for assumed rank 0 and updates the testcase as well.
+
+	Without patch:
+	Breakpoint 1, arank::sub1 (a=<error reading variable:
+	  failed to resolve dynamic array rank>) at assumedrank.f90:11
+	11       PRINT *, RANK(a)
+	(gdb) p a
+	failed to resolve dynamic array rank
+	(gdb) p rank(a)
+	failed to resolve dynamic array rank
+
+	With patch:
+	Breakpoint 1, arank::sub1 (a=0) at assumedrank.f90:11
+	11       PRINT *, RANK(a)
+	(gdb) p a
+	$1 = 0
+	(gdb) p rank(a)
+	$2 = 0
+
+2022-04-25  Lancelot SIX  <lancelot.six@amd.com>
+
+	gdb/infrun: assert !step_over_info_valid_p in restart_threads
+	While working in gdb/infrun.c:restart_threads, I was wondering what are
+	the preconditions to call the function.  It seems to me that
+	!step_over_info_valid_p should be a precondition (i.e. if we are doing
+	an inline step over breakpoint, we do not want to resume non stepping
+	threads as one of them might miss the breakpoint which is temporally
+	disabled).
+
+	To convince myself that this is true, I have added an assertion to
+	enforce this, and got one regression in the testsuite:
+
+	    FAIL: gdb.base/step-over-syscall.exp: vfork: displaced=off: single step over vfork (GDB internal error)
+
+	This call to restart_threads originates from handle_vfork_done which
+	does not check if a step over is active when restarting other threads:
+
+	    if (target_is_non_stop_p ())
+	      {
+	        scoped_restore_current_thread restore_thread;
+
+	        insert_breakpoints ();
+	        restart_threads (event_thread, event_thread->inf);
+	        start_step_over ();
+	      }
+
+	In this patch, I propose to:
+	- Call start_step_over before restart_threads.  If a step over is already
+	  in progress (as it is the case in the failing testcase),
+	  start_step_over return immediately, and there is no point in restarting
+	  all threads just to stop them right away for a step over breakpoint.
+	- Only call restart_threads if no step over is in progress at this
+	  point.
+
+	In this patch, I also propose to keep the assertion in restart_threads
+	to help enforce this precondition, and state it explicitly.
+
+	I have also checked all other places which call restart_threads, and
+	they all seem to check that there is no step over currently active
+	before doing the call.
+
+	As for infrun-related things, I am never completely sure I did not miss
+	something.  So as usual, all feedback and thoughts are very welcome.
+
+	Tested on x86_64-linux-gnu.
+
+	Change-Id: If5f5f98ec4cf9aaeaabb5e3aa88ae6ffd70d4f37
+
+2022-04-25  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-24  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: move setbuf calls out of gdb_readline_no_editing_callback
+	After this commit:
+
+	  commit d08cbc5d3203118da5583296e49273cf82378042
+	  Date:   Wed Dec 22 12:57:44 2021 +0000
+
+	      gdb: unbuffer all input streams when not using readline
+
+	Issues were reported with some MS-Windows hosts, see the thread
+	starting here:
+
+	  https://sourceware.org/pipermail/gdb-patches/2022-March/187004.html
+
+	Filed in bugzilla as: PR mi/29002
+
+	The problem seems to be that calling setbuf on terminal file handles
+	is not always acceptable, see this mail for more details:
+
+	  https://sourceware.org/pipermail/gdb-patches/2022-April/187310.html
+
+	This commit does two things, first moving the setbuf calls out of
+	gdb_readline_no_editing_callback so that we don't end up calling
+	setbuf so often.
+
+	Then, for MS-Windows hosts, we don't call setbuf for terminals, this
+	appears to resolve the issues that have been reported.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29002
+
+2022-04-24  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-23  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-22  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: handle_no_resumed: only update thread list of event target
+	When running:
+
+	    $ make check TESTS="gdb.multi/multi-re-run.exp" RUNTESTFLAGS="--target_board=native-gdbserver"
+
+	I get:
+
+	    target remote localhost:2347^M
+	    Remote debugging using localhost:2347^M
+	    Reading symbols from /lib64/ld-linux-x86-64.so.2...^M
+	    Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/ld-2.31.so...^M
+	    0x00007ffff7fd0100 in _start () from /lib64/ld-linux-x86-64.so.2^M
+	    (gdb) continue^M
+	    Continuing.^M
+	    Cannot execute this command while the target is running.^M
+	    Use the "interrupt" command to stop the target^M
+	    and then try again.^M
+	    (gdb) FAIL: gdb.multi/multi-re-run.exp: re_run_inf=1: iter=1: runto: run to all_started
+
+	The test does:
+
+	 - Connect to a remote target with inferior 2, continue and stop on the
+	   all_started function
+	 - Connect to a separate remote target / GDBserver instance with inferior 1,
+	   continue and (expect to) stop on the all_started function
+
+	The failure seen above happens when trying to continue inferior 1.
+
+	What happens is:
+
+	 - GDB tells inferior 1's remote target to continue
+	 - We go into fetch_inferior_event, try to get an event at random from
+	   the targets
+	 - do_target_wait happens to pick inferior 2's target
+	 - That target return TARGET_WAITKIND_NO_RESUMED, which makes sense:
+	   inferior 2 is stopped, that target has no resumed thread
+	 - handle_no_resumed tries to update the thread list of all targets:
+
+	   for (auto *target : all_non_exited_process_targets ())
+	     {
+	       switch_to_target_no_thread (target);
+	       update_thread_list ();
+	     }
+
+	 - When trying to update the thread list of inferior 1's target, it hits
+	   the "Cannot execute this command while the target is running" error.
+	   This target is working in "remote all-stop" mode, and it is currently
+	   waiting for a stop reply, so it can't send packets to update the
+	   thread list at this time.
+
+	To handle the problem described in the comment in handle_no_resumed, I
+	don't think it is necessary to update the thread list of all targets,
+	but only the event target.  That comment describes a kind of race
+	condition where some target reports a breakpoint hit for a thread and
+	then its last remaining resumed thread exits, so sends a "no resumed"
+	event.  If we ended up resuming the thread that hit a breakpoint, we
+	want to ignore the "no resumed" and carry on.
+
+	But I don't really see why we need to update the thread list on the
+	other targets.  I can't really articulate this, it's more a gut feeling,
+	maybe I just fail to imagine the situation where this is needed.  But
+	here is the patch anyway, so we can discuss it.  The patch changes
+	handle_no_resumed to only update the thread list of the event target.
+	This fixes the test run shown above.
+
+	The way I originally tried to fix this was to make
+	remote_target::update_thread_list return early if the target is
+	currently awaiting a stop reply, since there's no way it can update the
+	thread list at that time.  But that felt more like papering over the
+	problem.  I then thought that we probably shouldn't be asking the target
+	to update the thread list unnecessarily.
+
+	Change-Id: Ide3df22b4f556478e155ad1c67ad4b4fe7c26a58
+
+2022-04-22  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdbserver/linux: free process_info_private and arch_process_info when failing to attach
+	Running
+
+	  $ ../gdbserver/gdbserver --once --attach :1234 539436
+
+	with ASan while /proc/sys/kernel/yama/ptrace_scope is set to 1 (prevents
+	attaching) shows that we fail to free some platform-specific objects
+	tied to the process_info (process_info_private and arch_process_info):
+
+	    Direct leak of 32 byte(s) in 1 object(s) allocated from:
+	        #0 0x7f6b558b3fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
+	        #1 0x562eaf15d04a in xcalloc /home/simark/src/binutils-gdb/gdbserver/../gdb/alloc.c:100
+	        #2 0x562eaf251548 in xcnew<process_info_private> /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/poison.h:122
+	        #3 0x562eaf22810c in linux_process_target::add_linux_process_no_mem_file(int, int) /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:426
+	        #4 0x562eaf22d33f in linux_process_target::attach(unsigned long) /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:1132
+	        #5 0x562eaf1a7222 in attach_inferior /home/simark/src/binutils-gdb/gdbserver/server.cc:308
+	        #6 0x562eaf1c1016 in captured_main /home/simark/src/binutils-gdb/gdbserver/server.cc:3949
+	        #7 0x562eaf1c1d60 in main /home/simark/src/binutils-gdb/gdbserver/server.cc:4084
+	        #8 0x7f6b552f630f in __libc_start_call_main (/usr/lib/libc.so.6+0x2d30f)
+
+	    Indirect leak of 56 byte(s) in 1 object(s) allocated from:
+	        #0 0x7f6b558b3fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
+	        #1 0x562eaf15d04a in xcalloc /home/simark/src/binutils-gdb/gdbserver/../gdb/alloc.c:100
+	        #2 0x562eaf2a0d79 in xcnew<arch_process_info> /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/poison.h:122
+	        #3 0x562eaf295e2c in x86_target::low_new_process() /home/simark/src/binutils-gdb/gdbserver/linux-x86-low.cc:723
+	        #4 0x562eaf22819b in linux_process_target::add_linux_process_no_mem_file(int, int) /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:428
+	        #5 0x562eaf22d33f in linux_process_target::attach(unsigned long) /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:1132
+	        #6 0x562eaf1a7222 in attach_inferior /home/simark/src/binutils-gdb/gdbserver/server.cc:308
+	        #7 0x562eaf1c1016 in captured_main /home/simark/src/binutils-gdb/gdbserver/server.cc:3949
+	        #8 0x562eaf1c1d60 in main /home/simark/src/binutils-gdb/gdbserver/server.cc:4084
+	        #9 0x7f6b552f630f in __libc_start_call_main (/usr/lib/libc.so.6+0x2d30f)
+
+	Those objects are deleted by linux_process_target::mourn, but that is
+	not called if we fail to attach, we only call remove_process.  I
+	initially fixed this by making linux_process_target::attach call
+	linux_process_target::mourn on failure (before calling error).  But this
+	isn't done anywhere else (including in GDB) so it would just be
+	confusing to do things differently here.
+
+	Instead, add a linux_process_target::remove_linux_process helper method
+	(which calls remove_process), and call that instead of remove_process in
+	the Linux target.  Move the free-ing of the extra data from the mourn
+	method to that new method.
+
+	Change-Id: I277059a69d5f08087a7f3ef0b8f1792a1fcf7a85
+
+2022-04-22  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: handle bracketed-paste-mode and EOF correctly
+	This commit replaces an earlier commit that worked around the issues
+	reported in bug PR gdb/28833.
+
+	The previous commit just implemented a work around in order to avoid
+	the worst results of the bug, but was not a complete solution.  The
+	full solution was considered too risky to merge close to branching GDB
+	12.  This improved fix has been applied after GDB 12 branched.  See
+	this thread for more details:
+
+	  https://sourceware.org/pipermail/gdb-patches/2022-March/186391.html
+
+	This commit replaces this earlier commit:
+
+	  commit 74a159a420d4b466cc81061c16d444568e36740c
+	  Date:   Fri Mar 11 14:44:03 2022 +0000
+
+	      gdb: work around prompt corruption caused by bracketed-paste-mode
+
+	Please read that commit for a full description of the bug, and why is
+	occurs.
+
+	In this commit I extend GDB to use readline's rl_deprep_term_function
+	hook to call a new function gdb_rl_deprep_term_function.  From this
+	new function we can now print the 'quit' message, this replaces the
+	old printing of 'quit' in command_line_handler.  Of course, we only
+	print 'quit' in gdb_rl_deprep_term_function when we are handling EOF,
+	but thanks to the previous commit (to readline) we now know when this
+	is.
+
+	There are two aspects of this commit that are worth further
+	discussion, the first is in the new gdb_rl_deprep_term_function
+	function.  In here I have used a scoped_restore_tmpl to disable the
+	readline global variable rl_eof_found.
+
+	The reason for this is that, in rl_deprep_terminal, readline will
+	print an extra '\n' character before printing the escape sequence to
+	leave bracketed paste mode.  You might then think that in the
+	gdb_rl_deprep_term_function function, we could simply print "quit" and
+	rely on rl_deprep_terminal to print the trailing '\n'.  However,
+	rl_deprep_terminal only prints the '\n' when bracketed paste mode is
+	on.  If the user has turned this feature off, no '\n' is printed.
+	This means that in gdb_rl_deprep_term_function we need to print
+	"quit" when bracketed paste mode is on, and "quit\n" when bracketed
+	paste mode is off.
+
+	We could absolutely do that, no problem, but given we know how
+	rl_deprep_terminal is implemented, it's easier (I think) to just
+	temporarily clear rl_eof_found, this prevents the '\n' being printed
+	from rl_deprep_terminal, and so in gdb_rl_deprep_term_function, we can
+	now always print "quit\n" and this works for all cases.
+
+	The second issue that should be discussed is backwards compatibility
+	with older versions of readline.  GDB can be built against the system
+	readline, which might be older than the version contained within GDB's
+	tree.  If this is the case then the system readline might not contain
+	the fixes needed to support correctly printing the 'quit' string.
+
+	To handle this situation I have retained the existing code in
+	command_line_handler for printing 'quit', however, this code is only
+	used now if the version of readline we are using doesn't not include
+	the required fixes.  And so, if a user is using an older version of
+	readline, and they have bracketed paste mode on, then they will see
+	the 'quit' sting printed on the line below the prompt, like this:
+
+	  (gdb)
+	  quit
+
+	I think this is the best we can do when someone builds GDB against an
+	older version of readline.
+
+	Using a newer version of readline, or the patched version of readline
+	that is in-tree, will now give a result like this in all cases:
+
+	  (gdb) quit
+
+	Which is what we want.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28833
+
+2022-04-22  Andrew Burgess  <aburgess@redhat.com>
+
+	readline: back-port changes needed to properly detect EOF
+	This commit is a partial back-port of this upstream readline commit:
+
+	  commit 002d31aa5f5929eb32d0e0e2e8b8d35d99e59961
+	  Author: Chet Ramey <chet.ramey@case.edu>
+	  Date:   Thu Mar 3 11:11:47 2022 -0500
+
+	      add rl_eof_found to public API; fix pointer aliasing problems  \
+	            with history-search-backward; fix a display problem with \
+	            runs of invisible characters at the end of a physical    \
+	            screen line
+
+	I have only pulled in the parts of this commit that relate to the new
+	rl_eof_found global, and the RL_STATE_EOF state flag.  These changes
+	are needed in order to fix PR cli/28833, and are discussed in this
+	thread to the bug-readline mailing list:
+
+	  https://lists.gnu.org/archive/html/bug-readline/2022-02/msg00021.html
+
+	The above commit is not yet in any official readline release, but my
+	hope is that now it has been merged into the readline tree it should
+	be safe enough to back port this fix to GDB's tree.
+
+	At some point in the future we will inevitably want to roll forward
+	the version of readline that we maintain in the binutils-gdb
+	repository.  When that day comes the changes in this commit can be
+	replaced with the latest upstream readline code, as I have not changed
+	the meaning of this code at all from what is in upstream readline.
+
+	This commit alone does not fix the PR cli/28833 issue, for that see
+	the next commit, which changes GDB itself.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28833
+
+2022-04-22  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: improved EOF handling when using readline 7
+	In this commit:
+
+	  commit a6b413d24ccc5d76179bab866834e11fd6fec294
+	  Date:   Fri Mar 11 14:44:03 2022 +0000
+
+	      gdb: work around prompt corruption caused by bracketed-paste-mode
+
+	a change was made to GDB to work around bug PR gdb/28833.  The
+	consequence of this work around is that, when bracketed paste mode is
+	enabled in readline, and GDB is quit by sending EOF, then the output
+	will look like this:
+
+	  (gdb)
+	  quit
+
+	The ideal output, which is what we get when bracketed paste mode is
+	off, is this:
+
+	  (gdb) quit
+
+	The reason we need to make this change is explained in the original
+	commit referenced above.  What isn't mentioned in the above commit, is
+	that the change that motivated this work around was only added in
+	readline 8, older versions of readline don't require the change.
+
+	In later commits in this series I will add a fix to GDB's in-tree copy
+	of readline (this fix is back-ported from upstream readline), and then
+	I will change GDB so that, when using the (patched) in-tree readline,
+	we can have the ideal output in all cases.
+
+	However, GDB can be built against the system readline.  When this is
+	done, and the system readline is version 8, then we will still have to
+	use the work around (two line) style output.
+
+	But, if GDB is built against the system readline, and the system
+	readline is an older version 7 readline, then there's no reason why we
+	can't have the ideal output, after all, readline 7 doesn't include the
+	change that we need to work around.
+
+	This commit changes GDB so that, when using readline 7 we get the
+	ideal output in all cases.  This change is trivial (a simple check
+	against the readline version number) so I think this should be fine to
+	include.
+
+	For testing this commit, you need to configure GDB including the
+	'--with-system-readline' flag, and build GDB on a system that uses
+	readline 7, for example 'Ubuntu 18.04'.  Then run the test
+	'gdb.base/eof-exit.exp', you should expect everything to PASS.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28833
+
+2022-04-22  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: prune inferiors at end of fetch_inferior_event, fix intermittent failure of gdb.threads/fork-plus-threads.exp
+	This test sometimes fail like this:
+
+	    info threads^M
+	      Id   Target Id         Frame ^M
+	      11.12 process 2270719   Couldn't get registers: No such process.^M
+	    (gdb) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: no threads left
+	    [Inferior 11 (process 2270719) exited normally]^M
+	    info inferiors^M
+	      Num  Description       Connection           Executable        ^M
+	    * 1    <null>                                 /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/fork-plus-threads/fork-plus-threads ^M
+	      11   <null>                                 /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/fork-plus-threads/fork-plus-threads ^M
+	    (gdb) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: only inferior 1 left (the program exited)
+
+	I can get it to fail quite reliably by pinning it to a core:
+
+	  $ taskset -c 5 make check TESTS="gdb.threads/fork-plus-threads.exp"
+
+	The previous attempt at fixing this was:
+
+	  https://sourceware.org/pipermail/gdb-patches/2021-October/182846.html
+
+	What we see is part due to a possible unfortunate ordering of events
+	given by the kernel, and what could be considered a bug in GDB.
+
+	The test program makes a number of forks, waits them all, then exits.
+	Most of the time, GDB will get and process the exit event for inferior 1
+	after the exit events of all the children.  But this is not guaranteed.
+	After the last child exits and is waited by the parent, the parent can
+	exit quickly, such that GDB collects from the kernel the exit events for
+	the parent and that child at the same time.  It then chooses one event
+	at random, which can be the event for the parent.  This will result in
+	the parent appearing to exit before its child.  There's not much we can
+	do about it, so I think we have to adjust the test to cope.
+
+	After expect has seen the "exited normally" notification for inferior 1,
+	it immediately does an "info thread" that it expects to come back empty.
+	But at this point, GDB might not have processed inferior 11's (the last
+	child) exit event, so it will look like there is still a thread.  Of
+	course that thread is dead, we just don't know it yet.  But that makes
+	the "no thread" test fail.  If the test waited just a bit more for the
+	"exited normally" notification for inferior 11, then the list of threads
+	would be empty.
+
+	So, first change, make the test collect all the "exited normally"
+	notifications for all inferiors before proceeding, that should ensure we
+	see an empty thread list.  That would fix the first FAIL above.
+
+	However, we would still have the second FAIL, as we expect inferior 11
+	to not be there, it should have been deleted automatically.  Inferior 11
+	is normally deleted when prune_inferiors is called.  That is called by
+	normal_stop, which is only called by fetch_inferior_event only if the
+	event thread completed an execution command FSM (thread_fsm).  But the
+	FSM for the continue command completed when inferior 1 exited.  At that
+	point inferior 11 was not prunable, as it still had a thread.  When
+	inferior 11 exits, prune_inferiors is not called.
+
+	I think that can be considered a GDB bug.  From the user point of view,
+	there's no reason why in one case inferior 11 would be deleted and not
+	in the other case.
+
+	This patch makes the somewhat naive change to call prune_inferiors in
+	fetch_inferior_event, so that it is called in this case.  It is placed
+	at this particular point in the function so that it is called after the
+	user inferior / thread selection is restored.  If it was called before
+	that, inferior 11 wouldn't be pruned, because it would still be the
+	current inferior.
+
+	Change-Id: I48a15d118f30b1c72c528a9f805ed4974170484a
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26272
+
+2022-04-22  Tom Tromey  <tromey@adacore.com>
+
+	Un-break the coff-pe-read.c build
+	This fixes a build breakage in my recent coff-pe-read.c change.
+
+	I'm sorry about this.  I don't understand how it happened, because I
+	definitely built and tested the series on Windows, and I didn't change
+	it before pushing.  Something must have gone wrong on the Windows
+	build, but I don't know what.  I'll investigate and and re-test to be
+	sure.
+
+2022-04-22  Tom Tromey  <tromey@adacore.com>
+
+	More const use and alloca avoidance in coff-pe-read.c
+	This changes another function in coff-pe-read.c to use 'const' more,
+	and to avoid the use of alloca by instead using std::string.
+
+	Use std::string in coff-pe-read.c
+	coff-pe-read.c uses xsnprintf and alloca, but using std::string is
+	better, and just as easy.  In general I think alloca is something to
+	be avoided, and unbounded uses especially so.
+
+	Remove a const-removing cast from coff-pe-read.c
+	coff-pe-read.c casts away const at one spot, but this is easily
+	replaced by calling bfd_get_filename directly in a couple of debugging
+	prints.
+
+	Simplify BFD section iteration in coff-pe-read.c
+	coff-pe-read.c iterates over BFD sections using bfd_map_over_sections,
+	but it's much simpler to use a for-each loop.  This allows for the
+	removal of helper functions and types.
+
+2022-04-22  Tom Tromey  <tromey@adacore.com>
+
+	Fix method naming bug in new DWARF indexer
+	Pedro pointed out that gdb-add-index is much slower with the new DWARF
+	indexer.  He also noticed that, in some cases, the generated
+	.gdb_index would have the wrong fully-qualified name for a method.
+
+	I tracked this down to a bug in the indexer.  If a type could have
+	methods but was marked as a declaration, the indexer was ignoring it.
+	However, this meant that the internal map to find the qualified name
+	was not updated for this container.
+
+2022-04-22  Christoph Muellner  <cmuellner@gcc.gnu.org>
+
+	RISC-V: Add missing DECLARE_INSNs for Zicbo{m,p,z}
+	The recently added support for the Zicbo{m,p,z} extensions did not
+	include DECLARE_INSN() declarations for the instructions.
+	These declarations are needed by GDB's instruction detection code.
+	This patch adds them.
+
+2022-04-22  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-21  Carl Love  <cel@us.ibm.com>
+
+	Fix for gdb.base/solib-search.exp test.
+	The variable right_lib_flags is not being set correctly to define RIGHT.
+	The value RIGHT is needed to force the address of the library functions
+	lib1_func3 and lib2_func4 to occur at different address in the wrong and
+	right libraries.
+
+	With RIGHT defined correctly, functions lib1_func3 and lib2_func4 occur
+	at different addresses the test runs correctly on Powerpc.
+
+	The test needs the lib2 addresses to be different in the right and
+	wrong cases.  That is the point of introducing function lib2_spacer
+	with the ifdef RIGHT compiler directive.
+
+	On Intel, the ARRAY_SIZE of 1 versus 8192 is sufficient to get the
+	dynamic linker to move the addresses of the library.  You can also get
+	the same effect on PowerPC but you must use a value much larger than
+	8192.
+
+	The key thing is that the test was not properly setting RIGHT to
+	defined to get the lib2_spacer function on Intel and Powerpc.
+
+	Without the patch, we have the Intel backtrace for the bad libraries:
+
+	backtrace
+	#0  break_here () at /home/ ... /gdb/testsuite/gdb.base/solib-search.c:30
+	#1  0x00007ffff7fae156 in ?? ()
+	#2  0x00007fffffffc150 in ?? ()
+	#3  0x00007ffff7fbb156 in ?? ()
+	#4  0x00007fffffffc160 in ?? ()
+	#5  0x00007ffff7fae146 in ?? ()
+	#6  0x00007fffffffc170 in ?? ()
+	#7  0x00007ffff7fbb146 in ?? ()
+	#8  0x00007fffffffc180 in ?? ()
+	#9  0x0000555555555156 in main () at /home/ ... /binutils-gdb/gdb/testsuite/gdb.base/solib-search.c:23
+	Backtrace stopped: previous frame inner to this frame (corrupt stack?)
+	(gdb) PASS: gdb.base/solib-search.exp: backtrace (with wrong libs) (data collection)
+
+	The backtrace on Intel with the good libraries is:
+
+	backtrace
+	#0  break_here () at /.../binutils-gdb/gdb/testsuite/gdb.base/solib-search.c:30
+	#1  0x00007ffff7fae156 in lib2_func4 () at /.../binutils-gdb/gdb/testsuite/gdb.base/solib-search-lib2.c:49
+	#2  0x00007ffff7fbb156 in lib1_func3 () at /.../gdb.base/solib-search-lib1.c:49
+	#3  0x00007ffff7fae146 in lib2_func2 () at /.../testsuite/gdb.base/solib-search-lib2.c:30
+	#4  0x00007ffff7fbb146 in lib1_func1 () at /.../gdb.base/solib-search-lib1.c:30
+	#5  0x0000555555555156 in main () at /...solib-search.c:23
+	(gdb) PASS: gdb.base/solib-search.exp: backtrace (with right libs) (data collection)
+	PASS: gdb.base/solib-search.exp: backtrace (with right libs)
+
+	In one case the backtrace is correct and the other it
+	is wrong on Intel.  This is due to the fact that the ARRAY_SIZE caused
+	the dynamic linker to move the library function addresses around.  I
+	believe it has to do with the default size of the data and code
+	sections used by the dynamic linker.
+
+	So without the patch the backtrace on PowerPC looks like:
+
+	 backtrace
+	#0  break_here () at /.../solib-search.c:30
+	#1  0x00007ffff7f007f4 in lib2_func4 () at /.../solib-search-lib2.c:49
+	#2  0x00007ffff7f307f4 in lib1_func3 () at /.../solib-search-lib1.c:49
+	#3  0x00007ffff7f007ac in lib2_func2 () at /.../solib-search-lib2.c:30
+	#4  0x00007ffff7f307ac in lib1_func1 () at /.../solib-search-lib1.c:30
+	#5  0x000000001000074c in main () at /.../solib-search.c:23
+
+	for both the good and bad libraries.
+
+	The patch fixes defining RIGHT in solib-search-lib1.c and solib-search-
+	lib2.c.  Note, without the patch the lib1_spacer and lib2_spacer
+	functions do not show up in the object dump of the Intel or Powerpc
+	libraries as it should.  The patch fixes that by making sure RIGHT gets
+	defined.
+
+	Now with the patch the backtrace for the bad library on PowerPC looks
+	like:
+
+	backtrace
+	#0  break_here () at /.../solib-search.c:30
+	#1  0x00007ffff7f0083c in __glink_PLTresolve () from /.../solib-search-lib2.so
+	Backtrace stopped: frame did not save the PC
+
+	And the backtrace for the good libraries on PowerPC looks like:
+
+	backtrace
+	#0  break_here () at /.../solib-search.c:30
+	#1  0x00007ffff7f0083c in lib2_func4 () at /.../solib-search-lib2.c:49
+	#2  0x00007ffff7f3083c in lib1_func3 () at /.../solib-search-lib1.c:49
+	#3  0x00007ffff7f007cc in lib2_func2 () at /.../solib-search-lib2.c:30
+	#4  0x00007ffff7f307cc in lib1_func1 () at /.../solib-search-lib1.c:30
+	#5  0x000000001000074c in main () at /.../solib-search.c:23
+	(gdb) PASS: gdb.base/solib-search.exp: backtrace (with right libs) (data collection)
+	PASS: gdb.base/solib-search.exp: backtrace (with right libs)
+
+	The issue then is on Power where the ARRAY_SIZE of 1 versus 8192 is not
+	sufficient to cause the dymanic linker to allocate the libraries at
+	different addresses.  I don't claim to understand the specifics of how
+	the dynamic linker works and what the default size is for the data and
+	code sections are.  My guess is by default PowerPC allocates a larger
+	data size by default, which is large enough to hold array[8192].  The
+	default size of the data section allocated by the dynamic linker on
+	Intel is not large enough to hold array[8192] thus causing the code
+	section on Intel to have to move when the large array is defined.
+
+	Note on PowerPC, if you make ARRAY_SIZE big enough, then you will cause
+	the library addresses to occur at different addresses as the larger
+	data section forces the code section to a different address.  That was
+	actually my original fix for the program until I spoke with Doug Evans
+	who originally wrote the test.  Doug noticed that RIGHT was not getting
+	defined as he originally intended in the test.
+
+	With the patch to fix the definition of RIGHT, PowerPC has a bad and a
+	good backtrace because the address of lib1_func3 and lib2_func4 both
+	move because lib1_spacer and lib2_spacer are now defined
+	before lib1_func3 and lib2_func4.
+
+	Without the patch, the lib1_spacer and lib2_spacer function doesn't show
+	up in the binary for the correct or incorrect library on Intel or PowerPC.
+	With the patch, RIGHT gets defined as originally intended for the test on
+	both architectures and lib1_spacer and lib2_spacer function show up in the
+	binaries on both architectures changing the other function addresses as
+	intended thus causing the test work as intended on PowerPC.
+
+2022-04-21  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb/dwarf: remove line_header::header_length field
+	This can be a local in dwarf_decode_line_header.
+
+	Change-Id: I2ecf4616d1a3197bd1e81ded9f999a2da9a685af
+
+2022-04-21  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb/dwarf: remove line_header::total_length field
+	This doesn' have to be a field, it can simply be a local variable in
+	dwarf_decode_line_header.  Name the local variable "unit_length", since
+	that's what the field in called in DWARF 4 and 5.  It's always easier to
+	follow the code with the standard on the side when we use the same
+	terminology.
+
+	Change-Id: I3ad1022afd9410b193ea11b9b5437686c1e4e633
+
+2022-04-21  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb/testsuite: fix "set temporary breakpoint" DUPLICATEs
+	Commit c67f4e538 ("gdb/testsuite: make gdb.ada/mi_prot.exp stop at
+	expected location") introduced some DUPLICATEs in MI tests using
+	mi_continue_to_line, for example:
+
+	    DUPLICATE: gdb.ada/mi_ref_changeable.exp: mi_continue_to_line: set temporary breakpoint
+
+	These test names were previously differentiated by the location passed
+	to mi_continue_to_line.  Since the location can contain a path, that
+	commit removed the location from the test name, in favor of a hardcoded
+	string "set temporary breakpoint", hence removing the differentiator.
+
+	mi_continue_to_line receives a "test" parameter, containing a test
+	name.  Add a "with_test_prefix" with that name, so that all tests
+	recorded during mi_continue_to_line have this in their name.
+
+	mi_continue_to_line passes that "test" string to mi_get_stop_line, that
+	is a bit superfluous.  mi_get_stop_line only uses that string in case of
+	failures (it doesn't record a pass if everything goes fine).  Since it's
+	not crucial, just remove it, and adjust all callers.
+
+	Adjust three gdb.mi/mi-var-*.exp tests to use prefixes to differentiate
+	the multiple calls to mi_run_inline_test (which calls
+	mi_continue_to_line).
+
+	Change-Id: I511c6caa70499f8657b1cde37d71068d74d56a74
+
+2022-04-21  Tom Tromey  <tromey@adacore.com>
+
+	Always use dwarf2_initialize_objfile
+	Internally we noticed that some tests would fail like so on Windows:
+
+	warning: Section .debug_aranges in [...] has duplicate debug_info_offset 0x0, ignoring .debug_aranges.
+
+	Debugging showed that, in fact, a second CU was being created at this
+	offset.  We tracked this down to the fact that, while the ELF reader
+	is careful to re-use the per-BFD data, other readers are not, and
+	could re-read the DWARF data multiple times.
+
+	However, since the change to allow an objfile to have multiple "quick
+	symbol" implementations, there's no reason for this approach -- it's
+	safe and easy for all symbol readers to reuse the per-BFD data when
+	reading DWARF.
+
+	This patch implements this idea, simplifying dwarf2_build_psymtabs and
+	making it private, and then switching to dwarf2_initialize_objfile as
+	the sole way to start the DWARF reader.
+
+	Note that, while I think the call to dwarf2_build_frame_info in
+	machoread.c is also obsolete, I haven't attempted to remove it here.
+
+2022-04-21  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: fix 'remote show FOO-packet' aliases
+	The following behaviour was observed in GDB:
+
+	  (gdb) show remote X-packet
+	  Support for the `p' packet is auto-detected, currently unknown.
+
+	Note the message mentions the 'p' packet.  This is a regression since
+	this commit:
+
+	  commit 8579fd136a614985bd27f20539c7bb7c5a51287d
+	  Date:   Mon Nov 8 14:58:46 2021 +0000
+
+	      gdb/gdbsupport: make xstrprintf and xstrvprintf return a unique_ptr
+
+	Before this commit the behaviour was:
+
+	  (gdb) show remote X-packet
+	  Support for the `X' packet is auto-detected, currently unknown.
+
+	The problem was caused by a failed attempt to ensure that some
+	allocated strings were deleted when GDB exits.  The code in the above
+	commit attempted to make use of 'static' to solve this problem,
+	however, the solution was just wrong.
+
+	In this new commit I instead allocate a static vector into which all
+	the allocated strings are stored, this ensures the strings are
+	released when GDB exits (which makes output from tools like valgrind
+	cleaner), but each string within the vector can be unique, which fixes
+	the regression.
+
+2022-04-21  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdbsupport: add path_join function
+	In this review [1], Eli pointed out that we should be careful when
+	concatenating file names to avoid duplicated slashes.  On Windows, a
+	double slash at the beginning of a file path has a special meaning.  So
+	naively concatenating "/"  and "foo/bar" would give "//foo/bar", which
+	would not give the desired results.  We already have a few spots doing:
+
+	  if (first_path ends with a slash)
+	    path = first_path + second_path
+	  else
+	    path = first_path + slash + second_path
+
+	In general, I think it's nice to avoid superfluous slashes in file
+	paths, since they might end up visible to the user and look a bit
+	unprofessional.
+
+	Introduce the path_join function that can be used to join multiple path
+	components together (along with unit tests).
+
+	I initially wanted to make it possible to join two absolute paths, to
+	support the use case of prepending a sysroot path to a target file path,
+	or the prepending the debug-file-directory to a target file path.  But
+	the code in solib_find_1 shows that it is more complex than this anyway
+	(for example, when the right hand side is a Windows path with a drive
+	letter).  So I don't think we need to support that case in path_join.
+	That also keeps the implementation simpler.
+
+	Change a few spots to use path_join to show how it can be used.  I
+	believe that all the spots I changed are guarded by some checks that
+	ensure the right hand side operand is not an absolute path.
+
+	Regression-tested on Ubuntu 18.04.  Built-tested on Windows, and I also
+	ran the new unit-test there.
+
+	[1] https://sourceware.org/pipermail/gdb-patches/2022-April/187559.html
+
+	Change-Id: I0df889f7e3f644e045f42ff429277b732eb6c752
+
+2022-04-21  Lancelot SIX  <lancelot.six@amd.com>
+
+	gdb_spawn_attach_cmdline: use unsupported instead of untested
+	In a previous commit (b750766ac96: gdb/testsuite: Introduce and use
+	gdb_spawn_attach_cmdline), if gdb_spawn_attach_cmdline cannot have GDB
+	attach to the process because of ptrace restrictions (operation not
+	permitted), the proc issues UNTESTED.  This should really be
+	UNSUPPORTED, as it is done in gdb_attach.
+
+	This patch fixes this oversight.
+
+	Change-Id: Ib87e33b9230f3fa7a85e06220ef4c63814b71f7d
+
+2022-04-21  Enze Li  <lienze2010@hotmail.com>
+
+	gdb/testsuite: add binary testcases to py-format-string.exp
+	We currently only test decimal and hexadecimal for the
+	gdb.Value.format_string() interface, this patch adds testcases for
+	binary format.
+
+	Tested on x86_64 openSUSE Tumbleweed(VERSION_ID="20220413").
+
+2022-04-21  Pedro Alves  <pedro@palves.net>
+
+	gdb.debuginfod/fetch_src_and_symbols.exp: Fix "notice empty URL" test
+	The gdb_test_multiple pattern for the "notice empty URL" test in
+	gdb.debuginfod/fetch_src_and_symbols.exp misses expecting the prompt.
+	Fix it by using -re -wrap.
+
+	Also, by using "confirm off", the message GDB prints if Debuginfod
+	downloading is available doesn't contain "Enable debuginfod" any
+	longer.  E.g.:
+
+	~~~
+	  (gdb) file testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols
+	  Reading symbols from testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols...
+
+	  This GDB supports auto-downloading debuginfo from the following URLs:
+	    <http://localhost:123>
+	  Enable debuginfod for this session? (y or [n])
+	~~~
+
+	~~~
+	  (gdb) with confirm off -- file testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols
+	  Reading symbols from testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols...
+
+	  This GDB supports auto-downloading debuginfo from the following URLs:
+	    <http://127.0.0.1:8000>
+	    <127.0.0.1:8000>
+	  Debuginfod has been disabled.
+	  To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
+	  (No debugging symbols found in testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols)
+	  (gdb)
+	~~~
+
+	I handled that correctly in the other tests that use test_urls, but
+	had forgotten to update the "notice empty URL" one.
+
+	Change-Id: I00040c83466e1494b3875574eb009c571a1504bf
+
+2022-04-21  Alan Modra  <amodra@gmail.com>
+
+	prune .note.GNU-stack warning from testsuite
+	binutils/
+		* testsuite/lib/binutils-common.exp (prune_warnings_extra): Remove
+		.note.GNU-stack warning.
+		(run_dump_test): Call prune_warnings for ld and objcopy output.
+	ld/
+		* testsuite/ld-elf/elf.exp: Disable prune_warnings_extra temporarily
+		around test for absent .note.GNU-stack
+		* testsuite/ld-cris/globsymw2.s,
+		* testsuite/ld-cris/warn3.d: Modify "is not implemented" message
+		to avoid dejagnu prune_warnings.
+
+	ld testsuite xcoff XPASS
+		* testsuite/ld-scripts/defined5.d: Don't xfail xcoff targets.
+
+	Delete unused COFF gas macro
+		* config/obj-coff.h (sy_obj): Don't define.
+		(OBJ_SYMFIELD_TYPE): Revise comments.
+
+2022-04-21  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-20  Aaron Merey  <amerey@redhat.com>
+
+	gdb/debuginfod: Prevent out_of_range exception
+	Trailing whitespace in the string of debuginfod URLs causes an
+	out_of_range exception during the printing of URLs for the first
+	use notice.
+
+	To fix this, stop printing URLs when the substring to be printed
+	consists only of whitespace.
+
+	Also add first use notice testcases.
+
+	Co-Authored-By: Pedro Alves <pedro@palves.net>
+
+2022-04-20  Lancelot SIX  <lancelot.six@amd.com>
+
+	gdb/testsuite: Introduce and use gdb_spawn_attach_cmdline
+	Following a7e6a19e87f3d719ea23c65b580a6d9bca4ccab3 "gdb: testsuite: add
+	new gdb_attach to check "attach" command", this commit proposes to
+	introduce the gdb_spawn_attach_cmdline helper and use it in
+	gdb.base/attach.exp.
+
+	This helper starts GDB and adds the "--pid=$PID" argument.
+
+	Also note that both the original and new implementation use
+	gdb_spawn_with_cmdline_opts, which in the end uses default_gdb_spawn.
+	This makes sure that we use $INTERNAL_GDBFLAGS, which by default already
+	contain "-iex \"set height 0\" -iex \"set width 0\"".  To avoid
+	repetition of those arguments, gdb_spawn_attach_cmdline does not repeat
+	those arguments.
+
+	To maintain a behavior similat to what gdb.base/attach.exp used to do,
+	gdb_spawn_attach_cmdline keeps the -quiet flag.
+
+	Tested on x86_64-gnu-linux
+
+	Change-Id: I1fdcdb71c86d9c5d34bb28fc86fac68bcec37358
+
+2022-04-20  Tom Tromey  <tom@tromey.com>
+
+	Replace symbol_symtab with symbol::symtab
+	This turns symbol_symtab into a method on symbol.  It also replaces
+	symbol_set_symtab with a method.
+
+	Replace symbol_arch with symbol::arch
+	This turns symbol_arch into a method on symbol.
+
+	Replace symbol_objfile with symbol::objfile
+	This turns symbol_objfile into a method on symbol.
+
+	Remove symbol::aclass_index
+	Symbols have an aclass_index method, but this isn't needed, because
+	the aclass index isn't useful outside of the symbol implementation.
+
+	Use array_view for symbol_impls
+	It seemed to me that using array_view for symbol_impls would give a
+	bit more error checking, at least when gdb is built in libstdc++ debug
+	mode.
+
+	Add accessors for symbol's artificial field
+	For a series I'm experimenting with, it was handy to hide a symbol's
+	"artificial" field behind accessors.  This patch is the result.
+
+	Unify the DWARF index holders
+	The dwarf2_per_bfd object has a separate field for each possible kind
+	of index.  Until an earlier patch in this series, two of these were
+	even derived from a common base class, but still had separate slots.
+	This patch unifies all the index fields using the common base class
+	that was introduced earlier in this series.  This makes it more
+	obvious that only a single index can be active at a time, and also
+	removes some code from dwarf2_initialize_objfile.
+
+	Add an ad hoc version check to dwarf_scanner_base
+	Some generic code in the DWARF reader has a special case for older
+	versions of .gdb_index.  This patch adds an ad hoc version check
+	method so that these spots can work without specific knowledge of
+	which index is in use.
+
+	Simplify version check in dw2_symtab_iter_next
+	This simplifies the index versio check in dw2_symtab_iter_next, by
+	passing a reference to the index object to this function.  This avoids
+	an indirection via the per_bfd object.
+
+	Introduce and use dwarf_scanner_base
+	This introduces dwarf_scanner_base, a base class for all the index
+	readers in the DWARF code.  Then, it changes both mapped_index_base
+	and cooked_index_vector to derive from this new base class.
+
+	Introduce readnow_functions
+	This introduces readnow_functions, a new subclass of
+	dwarf2_base_index_functions, and changes the DWARF reader to use it.
+	This lets us drop the "index is NULL" hack from the gdb index code.
+
+	Remove some "OBJF_READNOW" code from dwarf2_debug_names_index
+	The dwarf2_debug_names_index code treats a NULL debug_names_table as
+	if it were from OBJF_READNOW.  However, this trick is only done for
+	gdb_index, never for debug_names -- see dwarf2_initialize_objfile.
+
+	Let mapped index classes create the quick_symbol_functions object
+	This changes the mapped index classes to create the
+	quick_symbol_functions objects.  This is a step toward having a more
+	abstract interface to mapped indices.
+
+	Give mapped_index_base a virtual destructor
+	This changes mapped_index_base to have a virtual destructor, so it can
+	be destroyed via its base class.
+
+	Move mapped_index_base to new header file
+	This moves mapped_index_base and the helper struct name_component to a
+	new header file in gdb/dwarf2/.
+
+2022-04-20  Jan Beulich  <jbeulich@suse.com>
+
+	x86: reject all invalid SAE variants
+	So far an SAE-only specifier was accepted for static-rounding insns,
+	while SAE-only insns didn't accept static rounding specifiers. If
+	anything it would make sense the other way around, allowing SAE-only
+	insns to have the (ignored) rounding mode specified individually rather
+	than globally via -mevexrcig=. But for now make things match the SDM.
+
+2022-04-20  Alan Modra  <amodra@gmail.com>
+
+	Re: xcoff: implement linker relaxation
+		* xcofflink.c (xcoff_stub_csect_name): Increase buffer size.
+		(xcoff_stub_get_csect_in_range, xcoff_build_one_stub): Whitespace.
+		(bfd_xcoff_size_stubs): Cast PRIx64 arg to required type.
+		Don't use freed stub_name.
+
+	Revert "as: Reject unknown -gXXX option" testsuite
+	This reverts the test committed as part of 6ea673e2d6.
+
+2022-04-20  Cl?ment Chigot  <clement.chigot@atos.net>
+
+	xcoff: implement linker relaxation
+	bfd/ChangeLog:
+
+		* coff-rs6000.c (xcoff_reloc_type_noop): Add info argument.
+		(xcoff_reloc_type_fail): Likewise.
+		(xcoff_reloc_type_pos): Likewise.
+		(xcoff_reloc_type_neg): Likewise.
+		(xcoff_reloc_type_rel): Likewise.
+		(xcoff_reloc_type_toc): Likewise.
+		(xcoff_reloc_type_ba): Likewise.
+		(xcoff_reloc_type_crel): Likewise.
+		(xcoff_reloc_type_tls): Likewise.
+		(xcoff_reloc_type_br): Add stub handler.
+		(xcoff_ppc_relocate_section): Add info to
+		xcoff_calculate_relocation.
+		(xcoff_stub_indirect_call_code): New constant.
+		(xcoff_stub_shared_call_code): Likewise.
+		(bfd_xcoff_backend_data): Add stub code fields.
+		(bfd_pmac_xcoff_backend_data): Likewise.
+		* coff64-rs6000.c (xcoff64_reloc_type_br): Add stub handler.
+		(xcoff64_ppc_relocate_section): Add info to
+		xcoff64_calculate_relocation.
+		(xcoff64_stub_indirect_call_code): New constant.
+		(xcoff64_stub_shared_call_code): Likewise.
+		(bfd_xcoff_backend_data): Add stub code fields.
+		(bfd_xcoff_aix5_backend_data): Likewise.
+		* libxcoff.h (struct xcoff_backend_data_rec): Add stub fields.
+		(bfd_xcoff_stub_indirect_call_code): New define.
+		(bfd_xcoff_stub_indirect_call_size): New define.
+		(bfd_xcoff_stub_shared_call_code): New define.
+		(bfd_xcoff_stub_shared_call_size): New define.
+		(xcoff_reloc_function): Add info argument.
+		(enum xcoff_stub_type): New enum.
+		(struct xcoff_stub_hash_entry): New structure.
+		* xcofflink.c (struct xcoff_link_hash_table): Add stub hash
+		table and params fields.
+		(xcoff_stub_hash_entry): New define.
+		(xcoff_stub_hash_lookup): New define.
+		(stub_hash_newfunc): New function.
+		(_bfd_xcoff_bfd_link_hash_table_free): Free the new stub hash
+		table.
+		(_bfd_xcoff_bfd_link_hash_table_create): Create the new stub
+		hash table.
+		(xcoff_link_add_symbols): Save rawsize for XTY_SD.
+		(bfd_xcoff_link_init): New function.
+		(xcoff_stub_csect_name): New function.
+		(xcoff_stub_get_csect_in_range): New function.
+		(xcoff_stub_name): New function.
+		(bfd_xcoff_get_stub_entry): New function.
+		(bfd_xcoff_type_of_stub): New function.
+		(xcoff_add_stub): New function.
+		(xcoff_build_one_stub): New function.
+		(bfd_xcoff_size_stubs): New function.
+		(bfd_xcoff_build_stubs): New function.
+		(xcoff_stub_create_relocations): New function.
+		(xcoff_link_input_bfd): Adapt relocations to stub.
+		(xcoff_write_global_symbol): Adapt to new TOC entries generated
+		for stubs.
+		(_bfd_xcoff_bfd_final_link): Handle stub file.
+		* xcofflink.h (struct bfd_xcoff_link_params): New structure.
+
+	ld/ChangeLog:
+
+		* emultempl/aix.em (params): New variable.
+		(stub_file): New variable.
+		(xcoff_add_stub_section): New function.
+		(xcoff_layout_sections_again): New function
+		(hook_in_stub): New function.
+		(_after_allocation): Add stub creation.
+		(_create_output_section_statements): Allocate stub file and
+		pass params to backend.
+
+2022-04-20  Cl?ment Chigot  <clement.chigot@atos.net>
+
+	Stubs (added in a later patch) will generate new .loader symbols, once the allocations have been done. Thus, the .loader section cannot be layout before that.
+	bfd/ChangeLog:
+
+		* coff-rs6000.c (_bfd_xcoff_put_ldsymbol_name): Write len in
+		  ldinfo->strings instead of directly in the output_bfd.
+		* coff64-rs6000.c (_bfd_xcoff64_put_ldsymbol_name): Likewise.
+		* xcofflink.c (struct xcoff_link_hash_table): Remove ldrel_count
+		  field. Add ldinfo field.
+		(xcoff_mark_symbol): Adjust to new ldinfo field.
+		(xcoff_mark): Likewise.
+		(bfd_xcoff_link_count_reloc): Likewise.
+		(xcoff_build_loader_section): Split into two functions: one that
+		build the loader section (this function) and one that only size
+		it...
+		(xcoff_size_loader_section): ... (this function).
+		(bfd_xcoff_size_dynamic_sections): Adapt to new ldinfo field.
+		Move the part where the dynamic sections are build to ...
+		(bfd_xcoff_build_dynamic_sections): ... this function.
+		* xcofflink.h: Add bfd_xcoff_build_dynamic_sections prototype.
+
+	include/ChangeLog:
+
+		* coff/xcoff.h (struct xcoff_loader_info): Add ldrel_count and
+		libpath fields.
+
+	ld/ChangeLog:
+
+		* emultempl/aix.em (_after_allocation): New function.
+
+2022-04-20  Tom Tromey  <tom@tromey.com>
+
+	Use symbol_symtab accessor in compile-object-load.c
+	I noticed that compile-object-load.c directly references owner.symtab
+	of a symbol.  However, I think it's better for all users to call
+	symbol_symtab.  This patch makes this change.
+
+2022-04-20  Nick Clifton  <nickc@redhat.com>
+
+	Add linker warning for when it creates an executable stack.
+	   PR 29072
+
+2022-04-20  Tom Tromey  <tom@tromey.com>
+
+	Micro-optimize cooked_index_entry::full_name
+	I noticed that cooked_index_entry::full_name can return the canonical
+	string when there is no parent entry.
+
+	Regression tested on x86-64 Fedora 34.
+
+2022-04-20  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: LoongArch: Implement loongarch_scan_prologue()
+	If can't determine prologue from the symbol table, need to examine
+	instructions. Implement loongarch_scan_prologue() to analyze the
+	function prologue from START_PC to LIMIT_PC, return the address of
+	the first instruction past the prologue.
+
+2022-04-20  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-19  H.J. Lu  <hjl.tools@gmail.com>
+
+	as: Reject unknown -gXXX option
+		* as.c (parse_args): Reject unknown -gXXX option.
+		* testsuite/gas/all/empty.s: New file.
+		* testsuite/gas/all/pr29067.d: Likewise.
+		* testsuite/gas/all/pr29067.err: Likewise.
+		* testsuite/gas/all/gas.exp: Run pr29067.
+
+2022-04-19  Lancelot SIX  <lancelot.six@amd.com>
+
+	gdb/selftest-arch: Make register_test_foreach_arch generate arch tests lazily
+	The register_test_foreach_arch is used to instantiate a given selftest
+	for all architectures supported by GDB.  It is used in many _initialize_*
+	functions (under initialize_all_files, called by gdb_init).
+
+	Because the call is done during GDB's initialization, and because there
+	is no guaranty about the order in which all the _initialize_* functions
+	are executed, when register_test_foreach_arch is called, GDB is not
+	fully initialized.  Specifically, when a particular initialize function
+	is executed, only the architectures registered at that point are listed
+	by gdbarch_printable_names.
+
+	As a consequence, the list of selftest effectively executed depends on
+	the order the _initialize_* functions are called.  This can be observed
+	with the following:
+
+	    $ ./gdb/gdb \
+	        -data-directory ./gdb/data-directory \
+	        -quiet -batch -ex "maint selftest" 2>&1 \
+	        | grep -E "Ran [0-9]+ unit tests"
+	    Ran 145 unit tests, 0 failed
+	    $ GDB_REVERSE_INIT_FUNCTIONS=1 ./gdb/gdb \
+	        -data-directory ./gdb/data-directory \
+	        -quiet -batch -ex "maint selftest" 2>&1 \
+	        | grep -E "Ran [0-9]+ unit tests"
+	    Ran 82 unit tests, 0 failed
+
+	To fix this, make register_test_foreach_arch register a lazy selftest
+	generator.  This way when the test generator is eventually executed, all
+	architectures are registered and we do not have a dependency on the
+	order the initialize functions are executed in.
+
+	Tested on x86_64-linux
+
+	Change-Id: I88eefebf7d372ad672f42d3a103e89354bc8a925
+
+2022-04-19  Lancelot SIX  <lancelot.six@amd.com>
+
+	gdbsupport/selftest: Allow lazy registration
+	This patch adds a way to delay the registration of tests until the
+	latest possible moment.  This is intended for situations where GDB needs
+	to be fully initialized in order to decide if a particular selftest can
+	be executed or not.
+
+	This mechanism will be used in the next patch.
+
+	Change-Id: I7f6b061f4c0a6832226c7080ab4e3a2523e1b0b0
+
+2022-04-19  Lancelot SIX  <lancelot.six@amd.com>
+
+	gdbsupport/selftest: Replace for_each_selftest with an iterator_range
+	Remove the callback-based selftests::for_each_selftest function and use
+	an iterator_range instead.
+
+	Also use this iterator range in run_tests so all iterations over the
+	selftests are done in a consistent way.  This will become useful in a
+	later commit.
+
+	Change-Id: I0b3a5349a7987fbcb0071f11c394e353df986583
+
+2022-04-19  Jan Beulich  <jbeulich@suse.com>
+
+	x86: don't mistake ordinary immediates for SAE / rounding control
+	The way SAE templates are constructed was always puzzling me (including
+	the need for separate templates in the first place), and expressing the
+	extzra attribute via Imm8 actually has a bad effect: Ordinary immediates
+	would also be accepted, leading to an extra byte being added after the
+	instruction (i.e. generating bad code). Before re-working this (in
+	particular to accept proper Intel syntax there), fix the immediate issue
+	by adding the so far missing check.
+
+	x86: VCMPSH is Evex.LLIG
+	These were mistakenly flagged as Evex.128. Getting the LLIG status right
+	for insns allowing for SAE is a prereq for planned further work.
+
+	x86: drop stray CheckRegSize from VFPCLASSPH
+	Like VFPCLASSP{S,D} it has only a single operand allowing multiple
+	sizes, hence there are no pairs of operands to check for consistent
+	size.
+
+	x86/Intel: test non-legacy VCVT{,U}SI2SH insn forms
+	For an unclear reason corresponding AVX512F tests were apparently not
+	cloned or used as reference here, and instead the bogus legacy forms of
+	the insns (with the embedded rounding specifier not last) were used.
+
+2022-04-19  Jan Beulich  <jbeulich@suse.com>
+
+	x86: correct and simplify NOP disassembly
+	It's not just REX.W which is ignored with opcode 0x90. The same goes for
+	REX.R and REX.X as well as empty REX. None of these are forms of
+	"xchg %eax,%eax" (which would mean zero-extending %eax to %rax), so they
+	also shouldn't be disassembled this way.
+
+	While there simplify things: A single hook function suffices, thus
+	making it unnecessary to keep two expressions in sync. And checking
+	ins->address_mode for mode_64bit also is unnecessary, as "rex" can be
+	non-zero only in that case anyway.
+
+2022-04-19  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-18  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb/testsuite/dwarf: don't automatically add directory and file entry for DWARF 5
+	To support DWARF 5 in the DWARF assembler line tables, we currently copy
+	the first user-provided directory and the first user-provided files and
+	make them elements at indices 0 in the directory and file name tables.
+	That was a sufficient behavior at the time (see commit 44fda089397a
+	("[gdb/testsuite] Support .debug_line v5 in dwarf assembler")), but in
+	the following patches, I would need to have finer grained control on
+	what is generated exactly.  For example, I'd like to generate a DWARF 5 line
+	table with just a single file and a single directory.
+
+	Get rid of this behavior, and implement what is suggested in
+	44fda089397a: make include_dir return the directory index that can be
+	used to refer to that directory entry (based on the DWARF version), and
+	use it afterwards.
+
+	Adjust dw2-lines.exp and dw2-prologue-end.exp accordingly.  Their produced
+	DWARF5 binaries will change a bit, in that they will now have a single
+	directory and file, where they had two before.  But it doesn't change
+	the expected GDB behavior.
+
+	Change-Id: I5459b16ac9b7f28c34c9693c35c9afd2ebb3aa3b
+
+2022-04-18  Simon Marchi  <simon.marchi@efficios.com>
+
+	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
+
+2022-04-18  Simon Marchi  <simon.marchi@efficios.com>
+
+	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
+
+2022-04-18  Simon Marchi  <simon.marchi@efficios.com>
+
+	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
+
+2022-04-18  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	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
+
+2022-04-18  Tom Tromey  <tromey@adacore.com>
+
+	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.
+
+2022-04-18  Tom Tromey  <tom@tromey.com>
+
+	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
+
+2022-04-18  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	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
+
+2022-04-18  Vignesh Balasubramanian  <Vignesh.Balasubrmanian@amd.com>
+
+	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
+
+2022-04-18  Enze Li  <lienze2010@hotmail.com>
+
+	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
+
+2022-04-18  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-17  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-16  Tom Tromey  <tom@tromey.com>
+
+	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.
+
+2022-04-16  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-15  Tom Tromey  <tom@tromey.com>
+
+	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.
+
+2022-04-15  Tom Tromey  <tom@tromey.com>
+
+	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
+
+2022-04-15  Tom Tromey  <tom@tromey.com>
+
+	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
+
+2022-04-15  Tom Tromey  <tom@tromey.com>
+
+	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
+
+2022-04-15  Tom Tromey  <tom@tromey.com>
+
+	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
+
+2022-04-15  Tom Tromey  <tom@tromey.com>
+
+	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.
+
+2022-04-15  Tom Tromey  <tom@tromey.com>
+
+	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.
+
+2022-04-15  Tom de Vries  <tdevries@suse.de>
+
+	[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
+
+2022-04-15  Tom Tromey  <tom@tromey.com>
+
+	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.
+
+2022-04-15  Tom de Vries  <tdevries@suse.de>
+
+	[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
+
+2022-04-15  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-14  Pedro Alves  <pedro@palves.net>
+
+	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
+
+2022-04-14  Pedro Alves  <pedro@palves.net>
+
+	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
+
+2022-04-14  Pedro Alves  <pedro@palves.net>
+
+	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
+
+2022-04-14  Pedro Alves  <pedro@palves.net>
+
+	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
+
+2022-04-14  Tom Tromey  <tromey@adacore.com>
+
+	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.
+
+2022-04-14  Tom Tromey  <tromey@adacore.com>
+
+	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
+
+2022-04-14  Tom Tromey  <tromey@adacore.com>
+
+	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
+
+2022-04-14  Tom Tromey  <tromey@adacore.com>
+
+	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.
+
+2022-04-14  Lancelot SIX  <lancelot.six@amd.com>
+	    Pedro Alves  <pedro@palves.net>
+
+	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"
+
+	Change-Id: I42858b13db2cbd623c5c1739de65ad423e0c0938
+
+2022-04-14  Tom Tromey  <tromey@adacore.com>
+
+	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.
+
+2022-04-14  Tom Tromey  <tromey@adacore.com>
+
+	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.
+
+2022-04-14  Tom Tromey  <tromey@adacore.com>
+
+	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.
+
+2022-04-14  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	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
+
+2022-04-14  Tom Tromey  <tromey@adacore.com>
+
+	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.
+
+2022-04-14  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	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;
+	                                       ^~~~
+
+2022-04-14  Tom de Vries  <tdevries@suse.de>
+
+	[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.
+
+2022-04-14  Sergei Trofimovich  <siarheit@google.com>
+
+	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.
+
+2022-04-14  caiyinyu  <caiyinyu@loongson.cn>
+
+	ld:LoongArch: Fix glibc fail: tst-audit25a/b.
+	  bfd/
+
+	  * elfnn-loongarch.c: Add new func elf_loongarch64_hash_symbol.
+
+2022-04-14  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-13  Simon Marchi  <simon.marchi@efficios.com>
+
+	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
+
+2022-04-13  Simon Marchi  <simon.marchi@efficios.com>
+
+	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
+
+2022-04-13  Alexander von Gluck IV  <kallisti5@unixzen.com>
+
+	binutils: enable PE on 32bit haiku build
+		* config.bfd (x86-haiku): Add i386_pei_vec as a selectable format.
+
+2022-04-13  Pedro Alves  <pedro@palves.net>
+
+	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
+
+2022-04-13  Pedro Alves  <pedro@palves.net>
+
+	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
+
+2022-04-13  Alan Modra  <amodra@gmail.com>
+
+	ubsan: member access within null pointer of union
+	Add some nonsense to cover "undefined behaviour".
+
+		* ldlang.c (section_for_dot): Avoid UB.
+
+2022-04-13  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-12  Tom Tromey  <tromey@adacore.com>
+
+	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.
+
+2022-04-12  Simon Marchi  <simon.marchi@efficios.com>
+
+	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
+
+2022-04-12  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	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
+
+2022-04-12  Simon Marchi  <simon.marchi@efficios.com>
+
+	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
+
+2022-04-12  Simon Marchi  <simon.marchi@efficios.com>
+
+	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
+
+2022-04-12  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	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
+
+2022-04-12  Simon Marchi  <simon.marchi@efficios.com>
+
+	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
+
+2022-04-12  Simon Marchi  <simon.marchi@efficios.com>
+
+	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
+
+2022-04-12  Tom Tromey  <tom@tromey.com>
+
+	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.
+
+2022-04-12  Tom Tromey  <tom@tromey.com>
+
+	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.
+
+2022-04-12  Tom Tromey  <tom@tromey.com>
+
+	Adapt .debug_names writer to new DWARF scanner
+	This updates the .debug_names writer to work with the new DWARF
+	scanner.
+
+2022-04-12  Tom Tromey  <tom@tromey.com>
+
+	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.
+
+2022-04-12  Tom Tromey  <tom@tromey.com>
+
+	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.
+
+2022-04-12  Tom Tromey  <tom@tromey.com>
+
+	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.
+
+2022-04-12  Tom Tromey  <tom@tromey.com>
+
+	"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.
+
+2022-04-12  Tom Tromey  <tom@tromey.com>
+
+	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.)
+
+2022-04-12  Tom Tromey  <tom@tromey.com>
+
+	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.
+
+2022-04-12  Tom Tromey  <tom@tromey.com>
+
+	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'.
+
+2022-04-12  Tom Tromey  <tom@tromey.com>
+
+	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.
+
+2022-04-12  Tom Tromey  <tom@tromey.com>
+
+	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.
+
+2022-04-12  Tom Tromey  <tom@tromey.com>
+
+	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.
+
+2022-04-12  Tom Tromey  <tom@tromey.com>
+
+	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.
+
+2022-04-12  Tom Tromey  <tom@tromey.com>
+
+	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.
+
+2022-04-12  Tom Tromey  <tom@tromey.com>
+
+	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.
+
+2022-04-12  Tom Tromey  <tom@tromey.com>
+
+	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.
+
+2022-04-12  Tom Tromey  <tom@tromey.com>
+
+	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.
+
+2022-04-12  Tom Tromey  <tom@tromey.com>
+
+	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.
+
+2022-04-12  Tom Tromey  <tom@tromey.com>
+
+	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.
+
+2022-04-12  Tom Tromey  <tom@tromey.com>
+
+	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.
+
+2022-04-12  Nick Clifton  <nickc@redhat.com>
+
+	Rebase the zlib sources to the 1.2.12 release
+
+2022-04-12  Tom de Vries  <tdevries@suse.de>
+
+	[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.
+
+2022-04-12  Tom Tromey  <tom@tromey.com>
+
+	Add C++ "save gdb-index" test
+	I found a bug in the new DWARF reader series, related to the handling
+	of enumerator names.  This bug caused a crash, so this patch adds a
+	regression test for this particular case.  I'm checking this in.
+
+2022-04-12  Tom Tromey  <tromey@adacore.com>
+
+	Remove "Ada Settings" node from the manual
+	A while back, I sent a patch to unify the Ada varsize-limit setting
+	with the more generic max-value-size:
+
+	https://sourceware.org/pipermail/gdb-patches/2021-September/182004.html
+
+	However, it turns out I somehow neglected to send part of the patch.
+	Internally, I also removed the "Ada Settings" node from the manual, as
+	it only documents the obsolete setting.
+
+	This patch removes this text.
+
+2022-04-12  Tom Tromey  <tromey@adacore.com>
+
+	Require GNAT debug info for some Ada tests
+	A few Ada tests require some debug info in the GNAT runtime.  When run
+	without this info, these tests can't pass.  This patch changes these
+	tests to detect this situation and stop with "untested".
+
+2022-04-12  Nick Clifton  <nickc@redhat.com>
+
+	Stop strip from removing debuglink sections.
+		PR 28992
+		* objcopy.c (is_strip_section_1): Do not delete debuglink sections
+		when stripping debug information.
+
+2022-04-12  Jan Beulich  <jbeulich@suse.com>
+
+	gas: new_logical_line{,_flags}() can return "void"
+	With the sole user of the return value gone, convert the return type to
+	void. This in turn allows simplifying another construct, by moving it
+	slightly later in the function.
+
+	gas: drop .appfile and .appline
+	These were used originally to represent "# <line> <file>" constructs
+	inserted by (typically) compilers when pre-processing. Quite some time
+	ago they were replaced by .linefile though. Since the original
+	directives were never documented, we ought to be able to remove support
+	for them. As a result in a number of case function parameter aren't used
+	anymore and can hence be dropped.
+
+2022-04-12  Jan Beulich  <jbeulich@suse.com>
+
+	gas: further adjust file/line handling for .macro
+	Commit 7992631e8c0b ("gas/Dwarf: improve debug info generation from .irp
+	and alike blocks"), while dealing okay with actual assembly source files
+	not using .file/.line and alike outside but not inside of .macro, has
+	undue effects when the logical file/line pair was already overridden:
+	Line numbers would continuously increment while processing the expanded
+	macro, while the goal of the PR gas/16908 workaround is to keep the
+	expansion associated with the line invoking the macro. However, as soon
+	as enough state was overridden _inside_ the macro to cause as_where() to
+	no longer fall back top as_where_physical(), honor this by resuming the
+	bumping of the logical line number.
+
+	Note that from_sb_is_expansion's initializer was 1 for an unknown
+	reason. While renaming the variable and changing its type, also change
+	the initializer to "expanding_none", which would have been "0" in the
+	original code. Originally the initializer value itself wasn't ever used
+	anyway (requiring sb_index != -1), as it necessarily had changed in
+	input_scrub_include_sb() alongside setting sb_index to other than -1.
+
+	Strictly speaking input_scrub_insert_line() perhaps shouldn't use
+	expanding_none, yet none of the other enumerators fit there either. And
+	then strictly speaking that function probably shouldn't exist in the
+	first place. It's used only by tic54x.
+
+2022-04-12  Jan Beulich  <jbeulich@suse.com>
+
+	gas: further adjust file/line handling for .irp and alike
+	Commit 7992631e8c0b ("gas/Dwarf: improve debug info generation from .irp
+	and alike blocks"), while dealing okay with actual assembly source files
+	not using .file/.line and alike outside but not inside of .irp et al,
+	has undue effects when the logical file/line pair was already
+	overridden: Line numbers would continuously increment upon every
+	iteration, thus potentially getting far off. Furthermore it left it to
+	the user to actually insert .file/.line inside such constructs. Note
+	though that before aforementioned change things weren't pretty either:
+	Diagnostics (and debug info) would be associated with the directive
+	terminating the iteration construct, rather than with the actual lines.
+
+	Handle this automatically by simply latching the present line and then
+	re-instating coordinates first thing on every iteration; note that the
+	file can't change from what was previously pushed on the scrubber's
+	state stack, and hence can be taken from there by using a new flavor of
+	.linefile (which is far better memory-footprint-wise than recording the
+	full path in the inserted directive). (This then leaves undisturbed any
+	file/line control occurring in the body of the construct, as these will
+	only be seen and processed afterwards.)
+
+2022-04-12  Jan Beulich  <jbeulich@suse.com>
+
+	x86: make {disp16} work similarly to {disp32}
+	In a few places {disp32} was handled specially when really {disp16}
+	wants handling just the same.
+
+2022-04-12  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+	gprofng doesn't build with gcc 5.5
+	gprofng/ChangeLog
+	2022-04-07  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+		PR gprofng/29026
+		* configure.ac: Check version of bison.
+		* src/Makefile.am (QLParser.yy): Run bison
+		* src/QLParser.yy: Adapted for bison 3.04 or later.
+		* src/DbeSession.cc: make some params const.
+		* src/DbeSession.h: Likewise.
+		* configure: Regenerate.
+		* Makefile.in: Regenerate.
+		* src/Makefile.in: Regenerate.
+		* src/QLParser.tab.cc: Deleted.
+		* src/QLParser.tab.hh: Deleted.
+		* doc/Makefile.in: Regenerate.
+		* gp-display-html/Makefile.in: Regenerate.
+		* libcollector/configure: Regenerate.
+
+2022-04-12  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-11  John Baldwin  <jhb@FreeBSD.org>
+
+	i386-fbsd-nat: Remove two unused variables.
+	Earlier versions of the change in
+	1285ce8629b37f800bf21731ee7c7a8b1b8d0233 used this variable, but not
+	the final version that landed.
+
+2022-04-11  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove MSYMBOL_TARGET_FLAG_{1,2} macros
+	Replace with equivalent getter/setter macros.
+
+	Change-Id: I1042564dd47347337374762bd64ec31b5c573ee2
+
+2022-04-11  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove minimal symbol size macros
+	Remove MSYMBOL_HAS_SIZE, MSYMBOL_SIZE and SET_MSYMBOL_SIZE, replace them
+	with equivalent methods.
+
+	Change-Id: I6ee1cf82df37e58dff52ea6568ceb4649c7d7538
+
+2022-04-11  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove MSYMBOL_TYPE macro
+	Add a getter and a setter for a minimal symbol's type.  Remove the
+	corresponding macro and adjust all callers.
+
+	Change-Id: I89900df5ffa5687133fe1a16b2e0d4684e67a77d
+
+2022-04-11  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove symbol value macros
+	Remove all macros related to getting and setting some symbol value:
+
+	    #define SYMBOL_VALUE(symbol)           (symbol)->value.ivalue
+	    #define SYMBOL_VALUE_ADDRESS(symbol)                         \
+	    #define SET_SYMBOL_VALUE_ADDRESS(symbol, new_value)    \
+	    #define SYMBOL_VALUE_BYTES(symbol)     (symbol)->value.bytes
+	    #define SYMBOL_VALUE_COMMON_BLOCK(symbol) (symbol)->value.common_block
+	    #define SYMBOL_BLOCK_VALUE(symbol)     (symbol)->value.block
+	    #define SYMBOL_VALUE_CHAIN(symbol)     (symbol)->value.chain
+	    #define MSYMBOL_VALUE(symbol)          (symbol)->value.ivalue
+	    #define MSYMBOL_VALUE_RAW_ADDRESS(symbol) ((symbol)->value.address + 0)
+	    #define MSYMBOL_VALUE_ADDRESS(objfile, symbol)                         \
+	    #define BMSYMBOL_VALUE_ADDRESS(symbol) \
+	    #define SET_MSYMBOL_VALUE_ADDRESS(symbol, new_value)   \
+	    #define MSYMBOL_VALUE_BYTES(symbol)    (symbol)->value.bytes
+	    #define MSYMBOL_BLOCK_VALUE(symbol)    (symbol)->value.block
+
+	Replace them with equivalent methods on the appropriate objects.
+
+	Change-Id: Iafdab3b8eefc6dc2fd895aa955bf64fafc59ed50
+
+2022-04-11  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	gdb/doc: add section about Fortran intrinsic functions and types
+	The earlier version of this document had no sections about the
+	available Fortran intrinsic functions or the Fortran builtin types.
+
+	I added two sections 'Fortran intrinsics' and 'Fortran types' to
+	document the available Fortran language features.  The subsection
+	'Fortran Defaults' has been integrated into the Fortran subsection.
+
+2022-04-11  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	gdb/fortran/testsuite: add complex from integers test
+	When working on the files I noted that there was no actual test for a
+	COMPLEX built from two INTEGERS.  I added that now for completion.
+
+2022-04-11  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	gdb/fortran: rewrite intrinsic handling and add some missing overloads
+	The operators FLOOR, CEILING, CMPLX, LBOUND, UBOUND, and SIZE accept
+	(some only with Fortran 2003) the optional parameter KIND.  This
+	parameter determines the kind of the associated return value.  So far,
+	implementation of this kind parameter has been missing in GDB.
+	Additionally, the one argument overload for the CMPLX intrinsic function
+	was not yet available.
+
+	This patch adds overloads for all above mentioned functions to the
+	Fortran intrinsics handling in GDB.
+
+	It re-writes the intrinsic function handling section to use the helper
+	methods wrap_unop_intrinsic/wrap_binop_intrinsic/wrap_triop_intrinsic.
+	These methods define the action taken when a Fortran intrinsic function
+	is called with a certain amount of arguments (1/2/3). The helper methods
+	fortran_wrap2_kind and fortran_wrap3_kind have been added as equivalents
+	to the existing wrap and wrap2 methods.
+
+	After adding more overloads to the intrinsics handling, some of the
+	operation names were no longer accurate.  E.g. UNOP_FORTRAN_CEILING
+	has been renamed to FORTRAN_CEILING as it is no longer a purely unary
+	intrinsic function.  This patch also introduces intrinsic functions with
+	one, two, or three arguments to the Fortran parser and the
+	UNOP_OR_BINOP_OR_TERNOP_INTRINSIC token has been added.
+
+2022-04-11  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	gdb/fortran: rename f77_keywords to f_keywords
+	Rename f77_keywords to f_keywords since some of the introduced keywords
+	in the array are f90 only.
+
+2022-04-11  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	gdb/fortran: Change GDB print for fortran default types
+	Currently, when asking GDB to print the type of a Fortran default type
+	such as INTEGER or REAL, GDB will return the default name of that type,
+	e.g. "integer"/"real":
+
+	   (gdb) ptype integer
+	   type = integer
+	   (gdb) ptype real
+	   type = real
+
+	For LOGICAL and COMPLEX it would return the actual underlying types
+
+	   (gdb) ptype logical
+	   type = logical*4
+	   (gdb) ptype complex
+	   type = complex*4
+
+	Similarly, GDB would print the default integer type for the underlying
+	default type:
+
+	   (gdb) ptype integer*4
+	   type = integer
+	   (gdb) ptype real*4
+	   type = real
+	   (gdb) ptype logical
+	   type = logical*4
+	   (gdb) ptype complex*4
+	   type = complex*4
+
+	This is inconsistent and a bit confusing.  Both options somehow indicate
+	what the internal underlying type for the default type is - but I think
+	the logical/complex version is a bit clearer.
+
+	Consider again:
+
+	   (gdb) ptype integer
+	   type = integer
+
+	This indicates to a user that the type of "integer" is Fortran's default
+	integer type.  Without examining "ptype integer*4" I would expect, that
+	any variable declared integer in the actual code would also fit into a
+	GDB integer.  But, since we cannot adapt out internal types to the
+	compiler flags used at compile time of a debugged binary, this might be
+	wrong.  Consider debugging Fortran code compiled with GNU and e.g. the
+	"-fdefault-integer-8" flag.  In this case the gfortran default integer
+	would be integer*8 while GDB internally still would use a builtin_integer,
+	so an integer of the size of an integer*4 type.  On the other hand having
+	GDB print
+
+	   (gdb) ptype integer
+	   type = integer*4
+
+	makes this clearer.  I would still be tempted to fit a variable declared
+	integer in the code into a GDB integer - but at least ptype would
+	directly tell me what is going on.  Note, that when debugging a binary
+	compiled with "-fdefault-integer-8" a user will always see the actual
+	underlying type of any variable declared "integer" in the Fortran code.
+	So having the code
+
+	   program test
+	     integer :: a = 5
+	     print *, a ! breakpt
+	   end program test
+
+	will, when breaking at breakpt print
+
+	   (gdb) ptype var
+	   type = integer(kind=4)
+
+	or
+
+	   (gdb) ptype var
+	   type = integer(kind=8)
+
+	depending on the compiler flag.
+
+	This patch changes the outputs for the REAL and INTEGER default types to
+	actually print the internally used type over the default type name.
+
+	The new behavior for the above examples is:
+
+	   (gdb) ptype integer
+	   type = integer*4
+	   (gdb) ptype integer*4
+	   type = integer*4
+
+	Existing testcases have been adapted to reflect the new behavior.
+
+2022-04-11  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	gdb/fortran: clean-up Fortran intrinsic types
+	The currently implemented intrinsic type handling for Fortran missed some
+	tokens and their parsing.  While still not all Fortran type kinds are
+	implemented this patch at least makes the currently handled types
+	consistent.  As an example for what this patch does, consider the
+	intrinsic type INTEGER.  GDB implemented the handling of the
+	keywords "integer" and "integer_2" but missed "integer_4" and "integer_8"
+	even though their corresponding internal types were already available as
+	the Fortran builtin types builtin_integer and builtin_integer_s8.
+	Similar problems applied to LOGICAL, REAL, and COMPLEX.  This patch adds
+	all missing tokens and their parsing.  Whenever a section containing the
+	type handling was touched, it also was reordered to be in a more easy to
+	grasp order.  All INTEGER/REAL/LOGICAL/COMPLEX types were grouped
+	together and ordered ascending in their size making a missing one more
+	easy to spot.
+
+	Before this change GDB would print the following when tyring to use the
+	INTEGER keywords:
+
+	   (gdb) set language fortran
+	   (gdb) ptype integer*1
+	   unsupported kind 1 for type integer
+	   (gdb) ptype integer_1
+	   No symbol table is loaded.  Use the "file" command.
+	   (gdb) ptype integer*2
+	   type = integer*2
+	   (gdb) ptype integer_2
+	   type = integer*2
+	   (gdb) ptype integer*4
+	   type = integer
+	   (gdb) ptype integer_4
+	   No symbol table is loaded.  Use the "file" command.
+	   (gdb) ptype integer*8
+	   type = integer*8
+	   (gdb) ptype integer_8
+	   No symbol table is loaded.  Use the "file" command.
+	   (gdb) ptype integer
+	   type = integer
+
+	With this patch all keywords are available and the GDB prints:
+
+	   (gdb) set language fortran
+	   (gdb) ptype integer*1
+	   type = integer*1
+	   (gdb) ptype integer_1
+	   type = integer*1
+	   (gdb) ptype integer*2
+	   type = integer*2
+	   (gdb) ptype integer_2
+	   type = integer*2
+	   (gdb) ptype integer*4
+	   type = integer*4
+	   (gdb) ptype integer_4
+	   type = integer*4
+	   (gdb) ptype integer*8
+	   type = integer*8
+	   (gdb) ptype integer_8
+	   type = integer*8
+	   (gdb) ptype integer
+	   type = integer
+
+	The described changes have been applied to INTEGER, REAL, COMPLEX,
+	and LOGICAL. Existing testcases have been adapted to reflect the
+	new behavior.  Tests for formerly missing types have been added.
+
+2022-04-11  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	gdb/fortran: change default logical type to builtin_logical
+	According to the Fortran standard, logical is of the size of a
+	'single numeric storage unit' (just like real and integer). For
+	gfortran, flang and ifx/ifort this storage unit (or the default
+	logical type) is of size kind 4, actually occupying 4 bytes of
+	storage, and so the default type for logical expressions in
+	Fortran should probably also be Logical*4 and not Logical*2.  I
+	adapted GDB's behavior to be in line with
+	gfortran/ifort/ifx/flang.
+
+	gdb/fortran: reformat build_fortran_types in f-lang.c
+	Add a few newlines after the type definitions and remove some
+	unnecessary linebreaks.
+
+2022-04-11  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	gdb/fortran: fix complex type in Fortran builtin types
+	Before this patch things like
+
+	  (gdb) ptype complex*8
+	  complex*16
+	  (gdb) ptype complex*4
+	  complex*8
+
+	were possible in GDB, which seems confusing for a user.  The reason
+	is a mixup in the implementation of the Fortran COMPLEX type.  In
+	Fortran the "*X" after a type would normally (I don't think this
+	is language required) specify the type's size in memory.  For the
+	COMPLEX type the kind parameters usually (at least for GNU, Intel, Flang)
+	specify not the size of the whole type but the size of the individual
+	two REALs used to form the COMPLEX.  Thus, a COMPLEX*4 will usually
+	consist of two REAL*4s.  Internally this type was represented by a
+	builtin_complex_s8 - but here I think the s8 actually meant the raw
+	size of the type.  This is confusing and I renamed the types (e.g.
+	builting_complex_s8 became builtin_complex_s4 according to its most
+	common useage) and their printed names to their language equivalent.
+	Additionally, I added the default COMPLEX type "COMPLEX" being the same
+	as a COMPLEX*4 (as is normally the case) and removed the latter.  I added
+	a few tests for this new behavior as well.
+
+	The new behavior is
+
+	  (gdb) ptype complex*8
+	  complex*8
+	  (gdb) ptype complex*4
+	  complex*4
+
+2022-04-11  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	gdb/f-lang: remove hidden ^L characters
+
+	gdb/f-lang: add Integer*1 to Fortran builtin types
+	Add builtin_integer_s1 of size TARGET_CHAR_BIT to Fortran builtin types.
+
+2022-04-11  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.base/annota1.exp with pie
+	Since commit 359efc2d894 ("[gdb/testsuite] Make gdb.base/annota1.exp more
+	robust") we see this fail with target board unix/-fPIE/-pie:
+	...
+	FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout)
+	...
+
+	The problem is that the commit makes the number and order of matched
+	annotations fixed, while between target boards unix and unix/-fPIE/-pie there
+	is a difference:
+	...
+	 \032\032post-prompt
+	 Starting program: outputs/gdb.base/annota1/annota1
+
+	+\032\032breakpoints-invalid
+	+
+	 \032\032starting
+
+	 \032\032frames-invalid
+	...
+
+	Fix this by optionally matching the additional annotation.
+
+	Tested on x86_64-linux.
+
+2022-04-11  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.dwarf2/dw2-lines.exp for m32 pie
+	As reported in PR29043, when running test-case gdb.dwarf2/dw2-lines.exp with
+	target board unix/-m32/-fPIE/-pie, we run into:
+	...
+	Breakpoint 2, 0x56555540 in bar ()^M
+	(gdb) PASS: gdb.dwarf2/dw2-lines.exp: cv=2: cdw=32: lv=2: ldw=32: \
+	  continue to breakpoint: foo \(1\)
+	next^M
+	Single stepping until exit from function bar,^M
+	which has no line number information.^M
+	0x56555587 in main ()^M
+	(gdb) FAIL: gdb.dwarf2/dw2-lines.exp: cv=2: cdw=32: lv=2: ldw=32: \
+	  next to foo (2)
+	...
+
+	The problem is that the bar breakpoint ends up at an unexpected location
+	because:
+	- the synthetic debug info is incomplete and doesn't provide line info
+	  for the prologue part of the function, so consequently gdb uses the i386
+	  port prologue skipper to get past the prologue
+	- the i386 port prologue skipper doesn't get past a get_pc_thunk call.
+
+	Work around this in the test-case by breaking on bar_label instead.
+
+	Tested on x86_64-linux with target boards unix, unix/-m32, unix/-fPIE/-pie and
+	unix/-m32/-fPIE/-pie.
+
+2022-04-11  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-10  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-09  Tom Tromey  <tom@tromey.com>
+
+	Remove MSYMBOL_VALUE_CHAIN
+	I noticed that MSYMBOL_VALUE_CHAIN is unused, so this patch removes it.
+
+2022-04-09  Alan Modra  <amodra@gmail.com>
+
+	Rearrange struct bfd_section a little
+	For better packing on 64-bit hosts.
+
+		* section.c (struct bfd_section): Move next and prev field earlier.
+		Move alignment_power later.
+		(BFD_FAKE_SECTION): Adjust to suit.
+		* bfd-in2.h: Regenerate.
+
+2022-04-09  Alan Modra  <amodra@gmail.com>
+
+	Don't run pr27228 test for hppa
+	As the comment says, hppa doesn't support use of BFD_RELOC_* in
+	.reloc directives.  Using xfail can result in a spurious XPASS result
+	as BFD_RELOC values change.
+
+		* testsuite/gas/elf/pr27228.d: Change xfail to notarget for hppa.
+
+2022-04-09  Alan Modra  <amodra@gmail.com>
+
+	Correct nds32 readelf reloc numbers
+		* readelf.c (is_32bit_abs_reloc, is_16bit_abs_reloc): Comment fixes.
+		(is_none_reloc): Correct nds32 reloc numbers.
+
+2022-04-09  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-08  Fangrui Song  <i@maskray.me>
+
+	gas: Port "copy st_size only if unset" to aarch64 and riscv
+	And disable the new test gas/elf/size.s for alpha which uses its own
+	.set, for hppa*-*-hpux* which does not allow .size before declaration.
+
+2022-04-08  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+	gprofng: fprintf_styled_func not inizialized for disassembler
+	gprofng/ChangeLog
+	2022-04-07  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+		* libcollector/unwind.c: inizialize fprintf_styled_func.
+		* src/Disasm.cc: Likewise.
+
+2022-04-08  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+	gprofng: zlib handling
+	gprofng/ChangeLog
+	2022-04-06  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+		* configure.ac: Add AM_ZLIB.
+		* src/Makefile.am: Add $(ZLIBINC) and $(ZLIB).
+		* gprofng/src/DbeSession.h: Likewise.
+		* configure: Regenerate.
+		* Makefile.in: Regenerate.
+		* doc/Makefile.in: Regenerate.
+		* gp-display-html/Makefile.in: Regenerate.
+		* src/Makefile.in: Regenerate.
+
+2022-04-08  Pedro Alves  <pedro@palves.net>
+
+	gdb: Avoid undefined shifts, fix Go shifts
+	I noticed that a build of GDB with GCC + --enable-ubsan, testing
+	against GDBserver showed this GDB crash:
+
+	  (gdb) PASS: gdb.trace/trace-condition.exp: trace: 0x00abababcdcdcdcd << 46 == 0x7373400000000000: advance to trace begin
+	  tstart
+	  ../../src/gdb/valarith.c:1365:15: runtime error: left shift of 48320975398096333 by 46 places cannot be represented in type 'long int'
+	  ERROR: GDB process no longer exists
+	  GDB process exited with wait status 269549 exp9 0 1
+	  UNRESOLVED: gdb.trace/trace-condition.exp: trace: 0x00abababcdcdcdcd << 46 == 0x7373400000000000: start trace experiment
+
+	The problem is that, "0x00abababcdcdcdcd << 46" is an undefined signed
+	left shift, because the result is not representable in the type of the
+	lhs, which is signed.  This actually became defined in C++20, and if
+	you compile with "g++ -std=c++20 -Wall", you'll see that GCC no longer
+	warns about it, while it warns if you specify prior language versions.
+
+	While at it, there are a couple other situations that are undefined
+	(and are still undefined in C++20) and result in GDB dying: shifting
+	by a negative ammount, or by >= than the bit size of the promoted lhs.
+	For the latter, GDB shifts using (U)LONGEST internally, so you have to
+	shift by >= 64 bits to see it:
+
+	 $ gdb --batch -q -ex "p 1 << -1"
+	 ../../src/gdb/valarith.c:1365:15: runtime error: shift exponent -1 is negative
+	 $ # gdb exited
+
+	 $ gdb --batch -q -ex "p 1 << 64"
+	 ../../src/gdb/valarith.c:1365:15: runtime error: shift exponent 64 is too large for 64-bit type 'long int'
+	 $ # gdb exited
+
+	Also, right shifting a negative value is implementation-defined
+	(before C++20, after which it is defined).  For this, I chose to
+	change nothing in GDB other than adding tests, as I don't really know
+	whether we need to do anything.  AFAIK, most implementations do an
+	arithmetic right shift, and it may be we don't support any host or
+	target that behaves differently.  Plus, this becomes defined in C++20
+	exactly as arithmetic right shift.
+
+	Compilers don't error out on such shifts, at best they warn, so I
+	think GDB should just continue doing the shifts anyhow too.
+
+	Thus:
+
+	- Adjust scalar_binop to avoid the undefined paths, either by adding
+	  explicit result paths, or by casting the lhs of the left shift to
+	  unsigned, as appropriate.
+
+	  For the shifts by a too-large count, I made the result be what you'd
+	  get if you split the large count in a series of smaller shifts.
+	  Thus:
+
+	     Left shift, positive or negative lhs:
+
+	       V << 64
+		 =>  V << 16 << 16 << 16 << 16
+		   => 0
+
+	     Right shift, positive lhs:
+
+	       Vpos >> 64
+		 =>  Vpos >> 16 >> 16 >> 16 >> 16
+		   => 0
+
+	     Right shift, negative lhs:
+
+	       Vneg >> 64
+		 =>  Vneg >> 16 >> 16 >> 16 >> 16
+		   => -1
+
+	  This is actually Go's semantics (the compiler really emits
+	  instructions to make it so that you get 0 or -1 if you have a
+	  too-large shift).  So for that language GDB does the shift and
+	  nothing else.  For other C-like languages where such a shift is
+	  undefined, GDB warns in addition to performing the shift.
+
+	  For shift by a negative count, for Go, this is a hard error.  For
+	  other languages, since their compilers only warn, I made GDB warn
+	  too.  The semantics I chose (we're free to pick them since this is
+	  undefined behavior) is as-if you had shifted by the count cast to
+	  unsigned, thus as if you had shifted by a too-large count, thus the
+	  same as the previous scenario illustrated above.
+
+	  Examples:
+
+	    (gdb) set language go
+	    (gdb) p 1 << 100
+	    $1 = 0
+	    (gdb) p -1 << 100
+	    $2 = 0
+	    (gdb) p 1 >> 100
+	    $3 = 0
+	    (gdb) p -1 >> 100
+	    $4 = -1
+	    (gdb) p -2 >> 100
+	    $5 = -1
+	    (gdb) p 1 << -1
+	    left shift count is negative
+
+	    (gdb) set language c
+	    (gdb) p -2 >> 100
+	    warning: right shift count >= width of type
+	    $6 = -1
+	    (gdb) p -2 << 100
+	    warning: left shift count >= width of type
+	    $7 = 0
+	    (gdb) p 1 << -1
+	    warning: left shift count is negative
+	    $8 = 0
+	    (gdb) p -1 >> -1
+	    warning: right shift count is negative
+	    $9 = -1
+
+	- The warnings' texts are the same as what GCC prints.
+
+	- Add comprehensive tests in a new gdb.base/bitshift.exp testcase, so
+	  that we exercise all these scenarios.
+
+	Change-Id: I8bcd5fa02de3114b7ababc03e65702d86ec8d45d
+
+2022-04-08  Pedro Alves  <pedro@palves.net>
+
+	Fix undefined behavior in the Fortran, Go and Pascal number parsers
+	This commit ports these two fixes to the C parser:
+
+	  commit ebf13736b42af47c9907b5157c8e80c78dbe00e1
+	  CommitDate: Thu Sep 4 21:46:28 2014 +0100
+
+	      parse_number("0") reads uninitialized memory
+
+	  commit 20562150d8a894bc91657c843ee88c508188e32e
+	  CommitDate: Wed Oct 3 15:19:06 2018 -0600
+
+	      Avoid undefined behavior in parse_number
+
+	... to the Fortran, Go, and Fortran number parsers, fixing the same
+	problems there.
+
+	Also add a new testcase that exercises printing 0xffffffffffffffff
+	(max 64-bit) in all languages, which crashes a GDB built with UBsan
+	without the fix.
+
+	I moved get_set_option_choices out of all-architectures.exp.tcl to
+	common code to be able to extract all the supported languages.  I did
+	a tweak to it to generalize it a bit -- you now have to pass down the
+	"set" part of the command as well.  This is so that the proc can be
+	used with "maintenance set" commands as well in future.
+
+	Change-Id: I8e8f2fdc1e8407f63d923c26fd55d98148b9e16a
+
+2022-04-08  Nick Clifton  <nickc@redhat.com>
+
+	Debug info for function in Windows PE binary on wrong instruction
+		PR 29038
+		* coffgen.c (coff_find_nearest_line_with_names): Fix typo
+		retrieving saved bias.
+
+2022-04-08  Simon Marchi  <simon.marchi@efficios.com>
+
+	Pass PKG_CONFIG_PATH down from top-level Makefile
+	[Sending to binutils, gdb-patches and gcc-patches, since it touches the
+	top-level Makefile/configure]
+
+	I have my debuginfod library installed in a non-standard location
+	(/opt/debuginfod), which requires me to set
+	PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config.  If I just set it during
+	configure:
+
+	    $ PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config ./configure --with-debuginfod
+	    $ make
+
+	or
+
+	    $ ./configure --with-debuginfod PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config
+	    $ make
+
+	Then PKG_CONFIG_PATH is only present (and ignored) during the top-level
+	configure.  When running make (which runs gdb's and binutils'
+	configure), PKG_CONFIG_PATH is not set, which results in their configure
+	script not finding the library:
+
+	    checking for libdebuginfod >= 0.179... no
+	    configure: error: "--with-debuginfod was given, but libdebuginfod is missing or unusable."
+
+	Change the top-level configure/Makefile system to capture the value
+	passed when configuring the top-level and pass it down to
+	subdirectories (similar to CFLAGS, LDFLAGS, etc).
+
+	I don't know much about the top-level build system, so I really don't
+	know if I did this correctly.  The changes are:
+
+	 - Use AC_SUBST(PKG_CONFIG_PATH) in configure.ac, so that
+	   @PKG_CONFIG_PATH@ gets replaced with the actual PKG_CONFIG_PATH value
+	   in config files (i.e. Makefile)
+	 - Add a PKG_CONFIG_PATH Makefile variable in Makefile.tpl, initialized
+	   to @PKG_CONFIG_PATH@
+	 - Add PKG_CONFIG_PATH to HOST_EXPORTS in Makefile.tpl, which are the
+	   variables set when running the sub-configures
+
+	I initially added PKG_CONFIG_PATH to flags_to_pass, in Makefile.def, but
+	I don't think it's needed.  AFAIU, this defines the flags to pass down
+	when calling "make" in subdirectories.  We only need PKG_CONFIG_PATH to
+	be passed down during configure.  After that, it's captured in
+	gdb/config.status, so even if a "make" causes a re-configure later
+	(because gdb/configure has changed, for example), the PKG_CONFIG_PATH
+	value will be remembered.
+
+	ChangeLog:
+
+		* configure.ac: Add AC_SUBST(PKG_CONFIG_PATH).
+		* configure: Re-generate.
+		* Makefile.tpl (HOST_EXPORTS): Pass PKG_CONFIG_PATH.
+		(PKG_CONFIG_PATH): New.
+		* Makefile.in: Re-generate.
+
+	Change-Id: I91138dfca41c43b05e53e445f62e4b27882536bf
+
+2022-04-08  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb/testsuite: use nopie in gdb.dwarf2/dw2-inline-param.exp
+	I see this failure:
+
+	    (gdb) run ^M
+	    Starting program: /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-inline-param/dw2-inline-param ^M
+	    Warning:^M
+	    Cannot insert breakpoint 1.^M
+	    Cannot access memory at address 0x113b^M
+	    ^M
+	    (gdb) FAIL: gdb.dwarf2/dw2-inline-param.exp: runto: run to *0x113b
+
+	The test loads the binary in GDB, grabs the address of a symbol, strips
+	the binary, reloads it in GDB, runs the program, and then tries to place
+	a breakpoint at that address.  The problem is that the binary is built
+	as position independent, so the address GDB grabs in the first place
+	isn't where the code ends up after running.
+
+	Fix this by linking the binary as non-position-independent.  The
+	alternative would be to compute the relocated address where to place the
+	breakpoint, but that's not very straightforward, unfortunately.
+
+	I was confused for a while, I was trying to load the binary in GDB
+	manually to get the symbol address, but GDB was telling me the symbol
+	could not be found.  Meanwhile, it clearly worked in gdb.log.  The thing
+	is that GDB strips the binary in-place, so we don't have access to the
+	intermediary binary with symbols.  Change the test to output the
+	stripped binary to a separate file instead.
+
+	Change-Id: I66c56293df71b1ff49cf748d6784bd0e935211ba
+
+2022-04-08  Alan Modra  <amodra@gmail.com>
+
+	gdb maintainer commit rights
+	Formalise what ought to be obvious.  The top level of the binutils-gdb
+	repository isn't owned by binutils.
+
+		* MAINTAINERS: Spelling fix.  GDB global maintainer rights.
+
+2022-04-08  Bernhard Heckel  <bernhard.heckel@intel.com>
+	    Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	gdb/fortran: print fortran extended types with ptype
+	Add the print of the base-class of an extended type to the output of
+	ptype.  This requires the Fortran compiler to emit DW_AT_inheritance
+	for the extended type.
+
+2022-04-08  Bernhard Heckel  <bernhard.heckel@intel.com>
+	    Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	gdb/fortran: add support for accessing fields of extended types
+	Fortran 2003 supports type extension.  This patch allows access
+	to inherited members by using their fully qualified name as described
+	in the Fortran standard.
+
+	In doing so the patch also fixes a bug in GDB when trying to access the
+	members of a base class in a derived class via the derived class' base
+	class member.
+
+	This patch fixes PR22497 and PR26373 on GDB side.
+
+	Using the example Fortran program from PR22497
+
+	program mvce
+	  implicit none
+
+	  type :: my_type
+	     integer :: my_int
+	  end type my_type
+
+	  type, extends(my_type) :: extended_type
+	  end type extended_type
+
+	  type(my_type) :: foo
+	  type(extended_type) :: bar
+
+	  foo%my_int = 0
+	  bar%my_int = 1
+
+	  print*, foo, bar
+
+	end program mvce
+
+	and running this with GDB and setting a BP at 17:
+
+	Before:
+	(gdb) p bar%my_type
+	A syntax error in expression, near `my_type'.
+	(gdb) p bar%my_int
+	There is no member named my_int.
+	(gdb) p bar%my_type%my_int
+	A syntax error in expression, near `my_type%my_int'.
+	(gdb) p bar
+	$1 = ( my_type = ( my_int = 1 ) )
+
+	After:
+	(gdb) p bar%my_type
+	$1 = ( my_int = 1 )
+	(gdb) p bar%my_int
+	$2 = 1                 # this line requires DW_TAG_inheritance to work
+	(gdb) p bar%my_type%my_int
+	$3 = 1
+	(gdb) p bar
+	$4 = ( my_type = ( my_int = 1 ) )
+
+	In the above example "p bar%my_int" requires the compiler to emit
+	information about the inheritance relationship between extended_type
+	and my_type which gfortran and flang currently do not de.  The
+	respective issue gcc/49475 has been put as kfail.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26373
+	     https://sourceware.org/bugzilla/show_bug.cgi?id=22497
+
+2022-04-08  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	gdb: add Nils-Christian Kempke to gdb/MAINTAINERS
+
+2022-04-08  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: change file_file_name to return an std::string
+	Straightforward change, return an std::string instead of a
+	gdb::unique_xmalloc_ptr<char>.  No behavior change expected.
+
+	Change-Id: Ia5e94c94221c35f978bb1b7bdffbff7209e0520e
+
+2022-04-08  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/fortran: fix fetching assumed rank array content
+	Commit:
+
+	  commit df7a7bdd9766adebc6b117c31bc617d81c1efd43
+	  Date:   Thu Mar 17 18:56:23 2022 +0000
+
+	      gdb: add support for Fortran's ASSUMED RANK arrays
+
+	Added support for Fortran assumed rank arrays.  Unfortunately, this
+	commit contained a bug that means though GDB can correctly calculate
+	the rank of an assumed rank array, GDB can't fetch the contents of an
+	assumed rank array.
+
+	The history of this patch can be seen on the mailing list here:
+
+	  https://sourceware.org/pipermail/gdb-patches/2022-January/185306.html
+
+	The patches that were finally committed can be found here:
+
+	  https://sourceware.org/pipermail/gdb-patches/2022-March/186906.html
+
+	The original patches did support fetching the array contents, it was
+	only the later series that introduced the regression.
+
+	The problem is that when calculating the array rank the result is a
+	count of the number of ranks, i.e. this is a 1 based result, 1, 2, 3,
+	etc.
+
+	In contrast, when computing the details of any particular rank the
+	value passed to the DWARF expression evaluator should be a 0 based
+	rank offset, i.e. a 0 based number, 0, 1, 2, etc.
+
+	In the patches that were originally merged, this was not the case, and
+	we were passing the 1 based rank number to the expression evaluator,
+	e.g. passing 1 when we should pass 0, 2 when we should pass 1, etc.
+	As a result the DWARF expression evaluator was reading the
+	wrong (undefined) memory, and returning garbage results.
+
+	In this commit I have extended the test case to cover checking the
+	array contents, I've then ensured we make use of the correct rank
+	value, and extended some comments, and added or adjusted some asserts
+	as appropriate.
+
+2022-04-07  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb/testsuite: add "macros" option to gdb_compile
+	Make gdb_compile handle a new "macros" option, which makes it pass the
+	appropriate flag to make the compiler include macro information in the
+	debug info.  This will help simplify tests using macros, reduce
+	redundant code, and make it easier to add support for a new compiler.
+
+	Right now it only handles clang specially (using -fdebug-macro) and
+	falls back to -g3 otherwise (which works for gcc).  Other compilers can
+	be added as needed.
+
+	There are some tests that are currently skipped if the compiler is nor
+	gcc nor clang.  After this patch, the tests will attempt to run (the -g3
+	fall back will be used).  That gives a chance to people using other
+	compilers to notice something is wrong and maybe add support for their
+	compiler.  If it is needed to support a compiler that doesn't have a way
+	to include macro information, then we can always introduce a
+	"skip_macro_tests" that can be used to skip over them.
+
+	Change-Id: I50cd6ab1bfbb478c1005486408e214b551364c9b
+
+2022-04-07  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove subfile::buildsym_compunit field
+	It is only set, never used.
+
+	Change-Id: Ia46ed2f9da243b0ccfc4588c1b57be2a0f3939de
+
+2022-04-07  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Make gdb.base/annota1.exp more robust
+	On openSUSE Tumbleweed I run into:
+	...
+	FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout)
+	...
+
+	The problem is that the libthread_db message occurs at a location where it's
+	not expected:
+	...
+	Starting program: outputs/gdb.base/annota1/annota1 ^M
+	^M
+	^Z^Zstarting^M
+	^M
+	^Z^Zframes-invalid^M
+	[Thread debugging using libthread_db enabled]^M
+	Using host libthread_db library "/lib64/libthread_db.so.1".^M
+	^M
+	^Z^Zbreakpoints-invalid^M
+	^M
+	...
+
+	Fix this by making the matching more robust:
+	- rewrite the regexp such that each annotation is on a single line,
+	  starting with \r\n\032\032 and ending with \r\n
+	- add a regexp variable optional_re, that matches all possible optional
+	  output, and use it as a separator in the first part of the regexp
+
+	Tested on x86_64-linux.
+
+2022-04-07  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/testsuite/dwarf: simplify line number program syntax
+	By calling `uplevel $body` in the program proc (a pattern we use at many
+	places), we can get rid of curly braces around each line number program
+	directive.  That seems like a nice small improvement to me.
+
+	Change-Id: Ib327edcbffbd4c23a08614adee56c12ea25ebc0b
+
+2022-04-07  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/testsuite/dwarf: remove two unused variables
+	These variables seem to be unused, remove them.
+
+	Change-Id: I7d613d9d35735930ee78b2c348943c73a702afbb
+
+2022-04-07  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove symtab::pspace
+	Same idea as previous patch, but for symtab::pspace.
+
+	Change-Id: I1023abe622bea75ef648c6a97a01b53775d4104d
+
+2022-04-07  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove symtab::objfile
+	Same idea as previous patch, but for symtab::objfile.  I find
+	it clearer without this wrapper, as it shows that the objfile is
+	common to all symtabs of a given compunit.  Otherwise, you could think
+	that each symtab (of a given compunit) can have a specific objfile.
+
+	Change-Id: Ifc0dbc7ec31a06eefa2787c921196949d5a6fcc6
+
+2022-04-07  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove symtab::blockvector
+	symtab::blockvector is a wrapper around compunit_symtab::blockvector.
+	It is a bit misleadnig, as it gives the impression that a symtab has a
+	blockvector.  Remove it, change all users to fetch the blockvector
+	through the compunit instead.
+
+	Change-Id: Ibd062cd7926112a60d52899dff9224591cbdeebf
+
+2022-04-07  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove symtab::dirname
+	I think the symtab::dirname method is bogus, or at least very
+	misleading.  It makes you think that it returns the directory that was
+	used to find that symtab's file during compilation (i.e. the directory
+	the file refers to in the DWARF line header file table), or the
+	directory part of the symtab's filename maybe.  In fact, it returns the
+	compilation unit's directory, which is the CWD of the compiler, at
+	compilation time.  At least for DWARF, if the symtab's filename is
+	relative, it will be relative to that directory.  But if the symtab's
+	filename is absolute, then the directory returned by symtab::dirname has
+	nothing to do with the symtab's filename.
+
+	Remove symtab::dirname to avoid this confusion, change all users to
+	fetch the same information through the compunit.  At least, it will be
+	clear that this is a compunit property, not a symtab property.
+
+	Change-Id: I2894c3bf3789d7359a676db3c58be2c10763f5f0
+
+2022-04-07  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/testsuite: make gdb_breakpoint and runto take a linespec
+	Change gdb_breakpoint to accept a linespec, not just a function.  In
+	fact, no behavior changes are necessary, this only changes the parameter
+	name and documentation.  Change runto as well, since the two are so
+	close (runto forwards all its arguments to gdb_breakpoint).
+
+	I wrote this for a downstrean GDB port,  but thought it could be
+	useful upstream, eventually, even though not callers take advantage of
+	it yet.
+
+	Change-Id: I08175fd444d5a60df90fd9985e1b5dfd87c027cc
+
+2022-04-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: update comments throughout reggroups.{c,h} files
+	This commit updates the comments in the gdb/reggroups.{c,h} files.
+	Fill in some missing comments, correct a few comments that were not
+	clear, and where we had comments duplicated between .c and .h files,
+	update the .c to reference the .h.
+
+	No user visible changes after this commit.
+
+2022-04-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: move struct reggroup into reggroups.h header
+	Move 'struct reggroup' into the reggroups.h header.  Remove the
+	reggroup_name and reggroup_type accessor functions, and just use the
+	name/type member functions within 'struct reggroup', update all uses
+	of these removed functions.
+
+	There should be no user visible changes after this commit.
+
+2022-04-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: convert reggroup to a C++ class with constructor, etc
+	Convert the 'struct reggroup' into a real class, with a constructor
+	and getter methods.
+
+	There should be no user visible changes after this commit.
+
+2022-04-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: make the pre-defined register groups const
+	Convert the 7 global, pre-defined, register groups const, and fix the
+	fall out (a minor tweak required in riscv-tdep.c).
+
+	There should be no user visible changes after this commit.
+
+2022-04-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: more 'const' in gdb/reggroups.{c,h}
+	Convert the reggroup_new and reggroup_gdbarch_new functions to return
+	a 'const regggroup *', and fix up all the fallout.
+
+	There should be no user visible changes after this commit.
+
+2022-04-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: remove reggroup_next and reggroup_prev
+	Add a new function gdbarch_reggroups that returns a reference to a
+	vector containing all the reggroups for an architecture.
+
+	Make use of this function throughout GDB instead of the existing
+	reggroup_next and reggroup_prev functions.
+
+	Finally, delete the reggroup_next and reggroup_prev functions.
+
+	Most of these changes are pretty straight forward, using range based
+	for loops instead of the old style look using reggroup_next.  There
+	are two places where the changes are less straight forward.
+
+	In gdb/python/py-registers.c, the register group iterator needed to
+	change slightly.  As the iterator is tightly coupled to the gdbarch, I
+	just fetch the register group vector from the gdbarch when needed, and
+	use an index counter to find the next item from the vector when
+	needed.
+
+	In gdb/tui/tui-regs.c the tui_reg_next and tui_reg_prev functions are
+	just wrappers around reggroup_next and reggroup_prev respectively.
+	I've just inlined the logic of the old functions into the tui
+	functions.  As the tui function had its own special twist (wrap around
+	behaviour) I think this is OK.
+
+	There should be no user visible changes after this commit.
+
+2022-04-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: convert reggroups to use a std::vector
+	Replace manual linked list with a std::vector.  This commit doesn't
+	change the reggroup_next and reggroup_prev API, but that will change
+	in a later commit.
+
+	This commit is focused on the minimal changes needed to manage the
+	reggroups using a std::vector, without changing the API exposed by the
+	reggroup.c file.
+
+	There should be no user visible changes after this commit.
+
+2022-04-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: always add the default register groups
+	There's a set of 7 default register groups.  If we don't add any
+	gdbarch specific register groups during gdbarch initialisation, then
+	when we iterate over the register groups using reggroup_next and
+	reggroup_prev we will make use of these 7 default groups.  See the use
+	of default_groups in gdb/reggroups.c for details on this.
+
+	However, if the gdbarch adds its own groups during gdbarch
+	initialisation, then these groups will be used in preference to the
+	default groups.
+
+	A problem arises though if the particular architecture makes use of
+	the target description mechanism.  If the default target
+	description(s) (i.e. those internal to GDB that are used when the user
+	doesn't provide their own) don't mention any additional register
+	groups then the default register groups will be used.
+
+	But if the target description does mention additional groups then the
+	default groups are not used, and instead, the groups from the target
+	description are used.
+
+	The problem with this is that what usually happens is that the target
+	description will mention additional groups, e.g. groups for special
+	registers.  Most architectures that use target descriptions work
+	around this by adding all (or most) of the default register groups in
+	all cases.  See i386_add_reggroups, aarch64_add_reggroups,
+	riscv_add_reggroups, xtensa_add_reggroups, and others.
+
+	In this patch, my suggestion is that we should just add the default
+	register groups for every architecture, always.  This change is in
+	gdb/reggroups.c.
+
+	All the remaining changes are me updating the various architectures to
+	not add the default groups themselves.
+
+	So, where will this change be visible to the user?  I think the
+	following commands will possibly change:
+
+	* info registers / info all-registers:
+
+	  The user can provide a register group to these commands.  For example,
+	  on csky, we previously never added the 'vector' group.  Now, as a
+	  default group, this will be available, but (presumably) will not
+	  contain any registers.  I don't think this is necessarily a bad
+	  thing, there's something to be said for having some consistent
+	  defaults available.  There are other architectures that didn't add
+	  all 7 of the defaults, which will now have gained additional groups.
+
+	* maint print reggroups
+
+	  This prints the set of all available groups.  As a maintenance
+	  command I'm less concerned with the output changing here.
+	  Obviously, for the architectures that didn't previously add all the
+	  defaults, this list just got bigger.
+
+	* maint print register-groups
+
+	  This prints all the registers, and the groups they are in.  If the
+	  defaults were not previously being added then a register (obviously)
+	  can't appear in one of the default groups.  Now the groups are
+	  available then registers might be in more groups than previously.
+	  However, this is again a maintenance command, so I'm less concerned
+	  about this changing.
+
+2022-04-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/tui: fix 'tui reg next/prev' command when data window is hidden
+	Start GDB like:
+
+	  $ gdb -q executable
+	  (gdb) start
+	  (gdb) layout src
+	  ... tui windows are now displayed ...
+	  (gdb) tui reg next
+
+	At this point the data (register) window should be displayed, but will
+	contain the message 'Register Values Unavailable', and at the console
+	you'll see the message "unknown register group 'next'".
+
+	The same happens with 'tui reg prev' (but the error message is
+	slightly different).
+
+	At this point you can continue to use 'tui reg next' and/or 'tui reg
+	prev' and you'll keep getting the error message.
+
+	The problem is that when the data (register) window is first
+	displayed, it's current register group is nullptr.  As a consequence
+	tui_reg_next and tui_reg_prev (tui/tui-regs.c) will always just return
+	nullptr, which triggers an error in tui_reg_command.
+
+	In this commit I change tui_reg_next and tui_reg_prev so that they
+	instead return the first and last register group respectively if the
+	current register group is nullptr.
+
+	So, after this, using 'tui reg next' will (in the above case) show the
+	first register group, while 'tui reg prev' will display the last
+	register group.
+
+2022-04-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/tui: avoid theoretical bug with 'tui reg' command
+	While looking at the 'tui reg' command as part of another patch, I
+	spotted a theoretical bug.
+
+	The 'tui reg' command takes the name of a register group, but also
+	handles partial register group matches, though the partial match has to
+	be unique.  The current command logic goes:
+
+	With the code as currently written, if a target description named a
+	register group either 'prev' or 'next' then GDB would see this as an
+	ambiguous register name, and refuse to switch groups.
+
+	Naming a register group 'prev' or 'next' seems pretty unlikely, but,
+	by adding a single else block we can prevent this problem.
+
+	Now, if there's a 'prev' or 'next' register group, the user will not
+	be able to select the group directly, the 'prev' and 'next' names will
+	always iterate through the available groups instead.  But at least the
+	user could select their groups by iteration, rather than direct
+	selection.
+
+2022-04-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: have reggroup_find return a const
+	Update reggroup_find to return a const reggroup *.
+
+	There are other function in gdb/reggroup.{c,h} files that could
+	benefit from returning const, these will be updated in later commits.
+
+	There should be no user visible changes after this commit.
+
+2022-04-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: use 'const reggroup *' in python/py-registers.c file
+	Convert uses of 'struct reggroup *' in python/py-registers.c to be
+	'const'.
+
+	There should be no user visible changes after this commit.
+
+2022-04-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: switch to using 'const reggroup *' in tui-regs.{c,h}
+	Make uses of 'reggroup *' const throughout tui-regs.{c,h}.
+
+	There should be no user visible changes after this commit.
+
+2022-04-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: make gdbarch_register_reggroup_p take a const reggroup *
+	Change gdbarch_register_reggroup_p to take a 'const struct reggroup *'
+	argument.  This requires a change to the gdb/gdbarch-components.py
+	script, regeneration of gdbarch.{c,h}, and then updates to all the
+	architectures that implement this method.
+
+	There should be no user visible changes after this commit.
+
+2022-04-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: add some const in gdb/reggroups.c
+	This commit makes the 'struct reggroup *' argument const for the
+	following functions:
+
+	  reggroup_next
+	  reggroup_prev
+	  reggroup_name
+	  reggroup_type
+
+	There are other places that could benefit from const in the
+	reggroup.{c,h} files, but these will be changing in further commits.
+
+	There should be no user visible changes after this commit.
+
+2022-04-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: don't try to use readline before it's initialized
+	While working on a different patch, I triggered an assertion from the
+	initialize_current_architecture code, specifically from one of
+	the *_gdbarch_init functions in a *-tdep.c file.  This exposes a
+	couple of issues with GDB.
+
+	This is easy enough to reproduce by adding 'gdb_assert (false)' into a
+	suitable function.  For example, I added a line into i386_gdbarch_init
+	and can see the following issue.
+
+	I start GDB and immediately hit the assert, the output is as you'd
+	expect, except for the very last line:
+
+	  $ ./gdb/gdb --data-directory ./gdb/data-directory/
+	  ../../src.dev-1/gdb/i386-tdep.c:8455: internal-error: i386_gdbarch_init: Assertion `false' failed.
+	  A problem internal to GDB has been detected,
+	  further debugging may prove unreliable.
+	  ----- Backtrace -----
+	  ... snip ...
+	  ---------------------
+	  ../../src.dev-1/gdb/i386-tdep.c:8455: internal-error: i386_gdbarch_init: Assertion `false' failed.
+	  A problem internal to GDB has been detected,
+	  further debugging may prove unreliable.
+	  Quit this debugging session? (y or n) ../../src.dev-1/gdb/ser-event.c:212:16: runtime error: member access within null pointer of type 'struct serial'
+
+	Something goes wrong when we try to query the user.  Note, I
+	configured GDB with --enable-ubsan, I suspect that without this the
+	above "error" would actually just be a crash.
+
+	The backtrace from ser-event.c:212 looks like this:
+
+	  (gdb) bt 10
+	  #0  serial_event_clear (event=0x675c020) at ../../src/gdb/ser-event.c:212
+	  #1  0x0000000000769456 in invoke_async_signal_handlers () at ../../src/gdb/async-event.c:211
+	  #2  0x000000000295049b in gdb_do_one_event () at ../../src/gdbsupport/event-loop.cc:194
+	  #3  0x0000000001f015f8 in gdb_readline_wrapper (
+	      prompt=0x67135c0 "../../src/gdb/i386-tdep.c:8455: internal-error: i386_gdbarch_init: Assertion `false' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nQuit this debugg"...)
+	      at ../../src/gdb/top.c:1141
+	  #4  0x0000000002118b64 in defaulted_query(const char *, char, typedef __va_list_tag __va_list_tag *) (
+	      ctlstr=0x2e4eb68 "%s\nQuit this debugging session? ", defchar=0 '\000', args=0x7fffffffa6e0)
+	      at ../../src/gdb/utils.c:934
+	  #5  0x0000000002118f72 in query (ctlstr=0x2e4eb68 "%s\nQuit this debugging session? ")
+	      at ../../src/gdb/utils.c:1026
+	  #6  0x00000000021170f6 in internal_vproblem(internal_problem *, const char *, int, const char *, typedef __va_list_tag __va_list_tag *) (problem=0x6107bc0 <internal_error_problem>, file=0x2b976c8 "../../src/gdb/i386-tdep.c",
+	      line=8455, fmt=0x2b96d7f "%s: Assertion `%s' failed.", ap=0x7fffffffa8e8) at ../../src/gdb/utils.c:417
+	  #7  0x00000000021175a0 in internal_verror (file=0x2b976c8 "../../src/gdb/i386-tdep.c", line=8455,
+	      fmt=0x2b96d7f "%s: Assertion `%s' failed.", ap=0x7fffffffa8e8) at ../../src/gdb/utils.c:485
+	  #8  0x00000000029503b3 in internal_error (file=0x2b976c8 "../../src/gdb/i386-tdep.c", line=8455,
+	      fmt=0x2b96d7f "%s: Assertion `%s' failed.") at ../../src/gdbsupport/errors.cc:55
+	  #9  0x000000000122d5b6 in i386_gdbarch_init (info=..., arches=0x0) at ../../src/gdb/i386-tdep.c:8455
+	  (More stack frames follow...)
+
+	It turns out that the problem is that the async event handler
+	mechanism has been invoked, but this has not yet been initialized.
+
+	If we look at gdb_init (in gdb/top.c) we can indeed see the call to
+	gdb_init_signals is after the call to initialize_current_architecture.
+
+	If I reorder the calls, moving gdb_init_signals earlier, then the
+	initial error is resolved, however, things are still broken.  I now
+	see the same "Quit this debugging session? (y or n)" prompt, but when
+	I provide an answer and press return GDB immediately crashes.
+
+	So what's going on now?  The next problem is that the call_readline
+	field within the current_ui structure is not initialized, and this
+	callback is invoked to process the reply I entered.
+
+	The problem is that call_readline is setup as a result of calling
+	set_top_level_interpreter, which is called from captured_main_1.
+	Unfortunately, set_top_level_interpreter is called after gdb_init is
+	called.
+
+	I wondered how to solve this problem for a while, however, I don't
+	know if there's an easy "just reorder some lines" solution here.
+	Looking through captured_main_1 there seems to be a bunch of
+	dependencies between printing various things, parsing config files,
+	and setting up the interpreter.  I'm sure there is a solution hiding
+	in there somewhere.... I'm just not sure I want to spend any longer
+	looking for it.
+
+	So.
+
+	I propose a simpler solution, more of a hack/work-around.  In utils.c
+	we already have a function filtered_printing_initialized, this is
+	checked in a few places within internal_vproblem.  In some of these
+	cases the call gates whether or not GDB will query the user.
+
+	My proposal is to add a new readline_initialized function, which
+	checks if the current_ui has had readline initialized yet.  If this is
+	not the case then we should not attempt to query the user.
+
+	After this change GDB prints the error message, the backtrace, and
+	then aborts (including dumping core).  This actually seems pretty sane
+	as, if GDB has not yet made it through the initialization then it
+	doesn't make much sense to allow the user to say "no, I don't want to
+	quit the debug session" (I think).
+
+2022-04-07  Luis Machado  <luis.machado@arm.com>
+
+	Recognize the NT_ARM_SYSTEM_CALL register set
+	Update binutils to recognize the NT_ARM_SYSTEM_CALL set that is dumped by
+	Linux to core files.
+
+2022-04-07  Mark Harmstone  <mark@harmstone.com>
+
+	Add support for COFF secidx relocations
+	bfd	* coff-i386.c (in_reloc_p): Add R_SECTION.
+		(howto_table): Add R_SECTION.
+		(coff_pe_i386_relocation_section): Add support for R_SECTION.
+		(coff_i386_reloc_type_lookup): Add support for
+		BFD_RELOC_16_SECCIDX.
+		* coff-x86_64.c (in_reloc_p): Add R_SECTION.
+		(howto_table): Add R_SECTION.
+		(coff_pe_amd64_relocation_section): Add support for R_SECTION.
+		(coff_amd64_reloc_type_lookup): Add support for
+		BFD_RELOC_16_SECCIDX.
+		* reloc.c: Add BFD_RELOC_16_SECIDX.
+		* bfd-in2.h: Regenerate.
+		* libbfd.h: Regenerate.
+
+	gas	* config/tc-i386.c (pe_directive_secidx): New function.
+		(md_pseudo_table): Add support for secidx.
+		(x86_cons_fix_new): Likewise.
+		(tc_gen_reloc): Likewise.
+		* expr.c (op_rank): Add O_secidx.
+		* expr.h (operatorT): Likewise.
+		* symbols.c (resolve_symbol_value): Add support for O_secidx.
+		* testsuite/gas/i386/secidx.s: New test source file.
+		* testsuite/gas/i386/secidx.d: New test driver file.
+		* testsuite/gas/i386/i386.exp: Run new test.
+
+	include	* coff/i386.h: Define R_SECTION.
+		* coff/x86_64.h: Likewise.
+
+	ld	* testsuite/ld-pe/secidx1.s: New test source file.
+		* testsuite/ld-pe/secidx2.s: New test source file.
+		* testsuite/ld-pe/secidx.d: New test driver file.
+		* testsuite/ld-pe/secidx_64.d: New test driver file.
+		* testsuite/ld-pe/pe.exp: Add new tests.
+
+2022-04-07  Jan Beulich  <jbeulich@suse.com>
+
+	gas/Dwarf: record functions
+	To help tools like addr2line looking up function names, in particular
+	when dealing with e.g. PE/COFF binaries (linked from ELF objects), where
+	there's no ELF symbol table to fall back to, emit minimalistic
+	information for functions marked as such and having their size
+	specified.
+
+	Notes regarding the restriction to (pure) ELF:
+	- I realize this is a layering violation; I don't see how to deal with
+	  that in a better way.
+	- S_GET_SIZE(), when OBJ_MAYBE_ELF is defined, looks wrong: Unlike
+	  S_SET_SIZE() it does not check whether the hook is NULL.
+	- symbol_get_obj(), when OBJ_MAYBE_ELF is defined, looks unusable, as
+	  its return type can only ever be one object format's type (and this
+	  may then not be ELF's).
+
+	The new testcases are limited to x86 because I wanted to include the
+	case where function size can't be determined yet at the time Dwarf2 info
+	is generated. As .nops gains support by further targets, they could also
+	be added here then (with, as necessary, expecations suitably relaxed to
+	cover for insn size differences).
+
+2022-04-07  Jan Beulich  <jbeulich@suse.com>
+
+	Arm64: arrange for line number emission for .inst
+	Just like insns encoded the more conventional way these should have line
+	number info associated with them.
+
+	Arm32: arrange for line number emission for .inst
+	Just like insns encoded the more conventional way these should have line
+	number info associated with them.
+
+	RISC-V: add testcase to check line number emission for .insn
+	Since no such test looks to exist, derive one from insn.s.
+
+2022-04-07  Andreas Krebbel  <krebbel@linux.ibm.com>
+
+	IBM zSystems: Add support for z16 as CPU name.
+	So far z16 was identified as arch14. After the machine has been
+	announced we can now add the real name.
+
+	gas/ChangeLog:
+
+		* config/tc-s390.c (s390_parse_cpu): Add z16 as alternate CPU
+		name.
+		* doc/as.texi: Add z16 and arch14 to CPU string list.
+		* doc/c-s390.texi: Add z16 to CPU string list.
+
+	opcodes/ChangeLog:
+
+		* s390-mkopc.c (main): Enable z16 as CPU string in the opcode
+		table.
+
+2022-04-07  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-06  Youling Tang  <tangyouling@loongson.cn>
+
+	gdb: mips: Fix the handling of complex type of function return value
+	$ objdump -d outputs/gdb.base/varargs/varargs
+	00000001200012e8 <find_max_float_real>:
+	...
+	   1200013b8:   c7c10000        lwc1    $f1,0(s8)
+	   1200013bc:   c7c00004        lwc1    $f0,4(s8)
+	   1200013c0:   46000886        mov.s   $f2,$f1
+	   1200013c4:   46000046        mov.s   $f1,$f0
+	   1200013c8:   46001006        mov.s   $f0,$f2
+	   1200013cc:   46000886        mov.s   $f2,$f1
+	   1200013d0:   03c0e825        move    sp,s8
+	   1200013d4:   dfbe0038        ld      s8,56(sp)
+	   1200013d8:   67bd0080        daddiu  sp,sp,128
+	   1200013dc:   03e00008        jr      ra
+	   1200013e0:   00000000        nop
+
+	From the above disassembly, we can see that when the return value of the
+	function is a complex type and len <= 2 * MIPS64_REGSIZE, the return value
+	will be passed through $f0 and $f2, so fix the corresponding processing
+	in mips_n32n64_return_value().
+
+	$ make check RUNTESTFLAGS='GDB=../gdb gdb.base/varargs.exp --outdir=test'
+
+	Before applying the patch:
+	 FAIL: gdb.base/varargs.exp: print find_max_float_real(4, fc1, fc2, fc3, fc4)
+	 FAIL: gdb.base/varargs.exp: print find_max_double_real(4, dc1, dc2, dc3, dc4)
+
+	 # of expected passes            9
+	 # of unexpected failures        2
+
+	After applying the patch:
+	 # of expected passes            11
+
+	This also fixes:
+	 FAIL: gdb.base/callfuncs.exp: call inferior func with struct - returns float _Complex
+
+	Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk>
+
+2022-04-06  Tom Tromey  <tom@tromey.com>
+
+	Use new and delete in jit.c
+	This changes jit.c to use new and delete, rather than XCNEW.  This
+	simplifies the code a little.  This was useful for another patch I'm
+	working on, and I thought it would make sense to send it separately.
+
+	Regression tested on x86-64 Fedora 34.
+
+2022-04-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: don't copy entirely optimized out values in value_copy
+	Bug 28980 shows that trying to value_copy an entirely optimized out
+	value causes an internal error.  The original bug report involves MI and
+	some Python pretty printer, and is quite difficult to reproduce, but
+	another easy way to reproduce (that is believed to be equivalent) was
+	proposed:
+
+	    $ ./gdb -q -nx --data-directory=data-directory -ex "py print(gdb.Value(gdb.Value(5).type.optimized_out()))"
+	    /home/smarchi/src/binutils-gdb/gdb/value.c:1731: internal-error: value_copy: Assertion `arg->contents != nullptr' failed.
+
+	This is caused by 5f8ab46bc691 ("gdb: constify parameter of
+	value_copy").  It added an assertion that the contents buffer is
+	allocated if the value is not lazy:
+
+	  if (!value_lazy (val))
+	    {
+	      gdb_assert (arg->contents != nullptr);
+
+	This was based on the comment on value::contents, which suggest that
+	this is the case:
+
+	  /* Actual contents of the value.  Target byte-order.  NULL or not
+	     valid if lazy is nonzero.  */
+	  gdb::unique_xmalloc_ptr<gdb_byte> contents;
+
+	However, it turns out that it can also be nullptr also if the value is
+	entirely optimized out, for example on exit of
+	allocate_optimized_out_value.  That function creates a lazy value, marks
+	the entire value as optimized out, and then clears the lazy flag.  But
+	contents remains nullptr.
+
+	This wasn't a problem for value_copy before, because it was calling
+	value_contents_all_raw on the input value, which caused contents to be
+	allocated before doing the copy.  This means that the input value to
+	value_copy did not have its contents allocated on entry, but had it
+	allocated on exit.  The result value had it allocated on exit.  And that
+	we copied bytes for an entirely optimized out value (i.e. meaningless
+	bytes).
+
+	From here I see two choices:
+
+	 1. respect the documented invariant that contents is nullptr only and
+	    only if the value is lazy, which means making
+	    allocate_optimized_out_value allocate contents
+	 2. extend the cases where contents can be nullptr to also include
+	    values that are entirely optimized out (note that you could still
+	    have some entirely optimized out values that do have contents
+	    allocated, it depends on how they were created) and adjust
+	    value_copy accordingly
+
+	Choice #1 is safe, but less efficient: it's not very useful to allocate
+	a buffer for an entirely optimized out value.  It's even a bit less
+	efficient than what we had initially, because values coming out of
+	allocate_optimized_out_value would now always get their contents
+	allocated.
+
+	Choice #2 would be more efficient than what we had before: giving an
+	optimized out value without allocated contents to value_copy would
+	result in an optimized out value without allocated contents (and the
+	input value would still be without allocated contents on exit).  But
+	it's more risky, since it's difficult to ensure that all users of the
+	contents (through the various_contents* accessors) are all fine with
+	that new invariant.
+
+	In this patch, I opt for choice #2, since I think it is a better
+	direction than choice #1.  #1 would be a pessimization, and if we go
+	this way, I doubt that it will ever be revisited, it will just stay that
+	way forever.
+
+	Add a selftest to test this.  I initially started to write it as a
+	Python test (since the reproducer is in Python), but a selftest is more
+	straightforward.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28980
+	Change-Id: I6e2f5c0ea804fafa041fcc4345d47064b5900ed7
+
+2022-04-06  Jeff Law  <jeffreyalaw@gmail.com>
+
+	Fix for v850e divq instruction
+	This is the last of the correctness fixes I've been carrying around for the
+	v850.
+
+	Like the other recent fixes, this is another case where we haven't been as
+	careful as we should WRT host vs target types.   For the divq instruction
+	both operands are 32 bit types.  Yet in the simulator code we convert them
+	from unsigned int to signed long by assignment.  So 0xfffffffb (aka -5)
+	turns into 4294967291 and naturally that changes the result of our division.
+
+	The fix is simple, insert a cast to int32_t to force interpretation as a
+	signed value.
+
+	Testcase for the simulator is included.  It has a trivial dependency on the
+	bins patch.
+
+2022-04-06  Jeff Law  <jeffreyalaw@gmail.com>
+
+	Fix "bins" simulation for v850e3v5
+	I've been carrying this for a few years.   One test in the GCC testsuite is
+	failing due to a bug in the handling of the v850e3v5 instruction "bins".
+
+	When the "bins" instruction specifies a 32bit bitfield size, the simulator
+	exhibits undefined behavior by trying to shift a 32 bit quantity by 32 bits.
+	In the case of a 32 bit shift, we know what the resultant mask should be.  So
+	we can just set it.
+
+	That seemed better than using 1UL for the constant (on a 32bit host unsigned
+	long might still just be 32 bits) or needlessly forcing everything to
+	long long types.
+
+	Thankfully the case where this shows up is only bins <src>, 0, 32, <dest>
+	which would normally be encoded as a simple move.
+
+		* testsuite/v850/allinsns.exp: Add v850e3v5.
+		* testsuite/v850/bins.cgs: New test.
+		* v850/simops.c (v850_bins): Avoid undefined behavior on left shift.
+
+2022-04-06  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: LoongArch: prepend tramp frame unwinder for signal
+	Implement the "init" method of struct tramp_frame to prepend tramp
+	frame unwinder for signal on LoongArch.
+
+	With this patch, the following failed testcases can be fixed:
+
+	  FAIL: gdb.base/annota1.exp: backtrace @ signal handler (timeout)
+	  FAIL: gdb.base/annota3.exp: backtrace @ signal handler (pattern 2)
+
+2022-04-06  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: make interp_add static
+	Since this commit:
+
+	  commit 8322445e0584be846f5873b9aab257dc9fbda05d
+	  Date:   Tue Jun 21 01:11:45 2016 +0100
+
+	      Introduce interpreter factories
+
+	Interpreters should be registered with GDB, not by calling interp_add,
+	but with a call to interp_factory_register.  I've checked the insight
+	source, and it too has moved over to using interp_factory_register.
+
+	In this commit I make interp_add static within interps.c.
+
+	There should be no user visible change after this commit.
+
+2022-04-06  Nick Clifton  <nickc@redhat.com>
+
+	Add code to display the contents of .debug_loclists sections which contain offset entry tables.
+		PR 28981
+		* dwarf.c (fetch_indexed_value): Rename to fecth_indexed_addr and
+		return the address, rather than a string.
+		(fetch_indexed_value): New function - returns a value indexed by a
+		DW_FORM_loclistx or DW_FORM_rnglistx form.
+		(read_and_display_attr_value): Add support for DW_FORM_loclistx
+		and DW_FORM_rnglistx.
+		(process_debug_info): Load the loclists and rnglists sections.
+		(display_loclists_list): Add support for DW_LLE_base_addressx,
+		DW_LLE_startx_endx, DW_LLE_startx_length and
+		DW_LLE_default_location.
+		(display_offset_entry_loclists): New function.  Displays a
+		.debug_loclists section that contains offset entry tables.
+		(display_debug_loc): Call the new function.
+		(display_debug_rnglists_list): Add support for
+		DW_RLE_base_addressx, DW_RLE_startx_endx and DW_RLE_startx_length.
+		(display_debug_ranges): Display the contents of the section's
+		header.
+		* dwarf.h (struct debug_info): Add loclists_base field.
+		* testsuite/binutils-all/dw5.W: Update expected output.
+		* testsuite/binutils-all/x86-64/pr26808.dump: Likewise.
+
+2022-04-06  Luis Machado  <luis.machado@linaro.org>
+
+	Enable ARMv8.1-m PACBTI support
+	This set of changes enable support for the ARMv8.1-m PACBTI extensions [1].
+
+	The goal of the PACBTI extensions is similar in scope to that of a-profile
+	PAC/BTI (aarch64 only), but the underlying implementation is different.
+
+	One important difference is that the pointer authentication code is stored
+	in a separate register, thus we don't need to mask/unmask the return address
+	from a function in order to produce a correct backtrace.
+
+	The patch introduces the following modifications:
+
+	- Extend the prologue analyser for 32-bit ARM to handle some instructions
+	from ARMv8.1-m PACBTI: pac, aut, pacg, autg and bti. Also keep track of
+	return address signing/authentication instructions.
+
+	- Adds code to identify object file attributes that indicate the presence of
+	ARMv8.1-m PACBTI (Tag_PAC_extension, Tag_BTI_extension, Tag_PACRET_use and
+	Tag_BTI_use).
+
+	- Adds support for DWARF pseudo-register RA_AUTH_CODE, as described in the
+	aadwarf32 [2].
+
+	- Extends the dwarf unwinder to track the value of RA_AUTH_CODE.
+
+	- Decorates backtraces with the "[PAC]" identifier when a frame has signed
+	the return address.
+
+	- Makes GDB aware of a new XML feature "org.gnu.gdb.arm.m-profile-pacbti". This
+	feature is not included as an XML file on GDB's side because it is only
+	supported for bare metal targets.
+
+	- Additional documentation.
+
+	[1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/armv8-1-m-pointer-authentication-and-branch-target-identification-extension
+	[2] https://github.com/ARM-software/abi-aa/blob/main/aadwarf32/aadwarf32.rst
+
+2022-04-06  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: move gdb_disassembly_flag into a new disasm-flags.h file
+	While working on the disassembler I was getting frustrated.  Every
+	time I touched disasm.h it seemed like every file in GDB would need to
+	be rebuilt.  Surely the disassembler can't be required by that many
+	parts of GDB, right?
+
+	Turns out that disasm.h is included in target.h, so pretty much every
+	file was being rebuilt!
+
+	The only thing from disasm.h that target.h needed is the
+	gdb_disassembly_flag enum, as this is part of the target_ops api.
+
+	In this commit I move gdb_disassembly_flag into its own file.  This is
+	then included in target.h and disasm.h, after which, the number of
+	files that depend on disasm.h is much reduced.
+
+	I also audited all the other includes of disasm.h and found that the
+	includes in mep-tdep.c and python/py-registers.c are no longer needed,
+	so I've removed these.
+
+	Now, after changing disasm.h, GDB rebuilds much quicker.
+
+	There should be no user visible changes after this commit.
+
+2022-04-06  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-05  Tom Tromey  <tom@tromey.com>
+
+	Introduce wrapped_file
+	Simon pointed out that timestamped_file probably needed to implement a
+	few more methods.  This patch introduces a new file-wrapping file that
+	forwards most of its calls, making it simpler to implement new such
+	files.  It also converts timestamped_file and pager_file to use it.
+
+	Regression tested on x86-64 Fedora 34.
+
+2022-04-05  Tom Tromey  <tromey@adacore.com>
+
+	Don't call init_thread_list in windows-nat.c
+	I don't think there's any need to call init_thread_list in
+	windows-nat.c.  This patch removes it.  I tested this using the
+	internal AdaCore test suite on Windows, which FWIW does include some
+	multi-threaded inferiors.
+
+2022-04-05  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb/testsuite: fix intermittent failure in gdb.base/vfork-follow-parent.exp
+	Tom de Vries reported some failures in this test:
+
+	    continue
+	    Continuing.
+	    [New inferior 2 (process 14967)]
+
+	    Thread 1.1 "vfork-follow-pa" hit Breakpoint 2, break_parent () at /home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.base/vfork-follow-parent.c:23
+	    23	}
+	    (gdb) FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: continue to end of inferior 2
+	    inferior 1
+	    [Switching to inferior 1 [process 14961] (/home/vries/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/vfork-follow-parent/vfork-follow-parent)]
+	    [Switching to thread 1.1 (process 14961)]
+	    #0  break_parent () at /home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.base/vfork-follow-parent.c:23
+	    23	}
+	    (gdb) PASS: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: inferior 1
+	    continue
+	    Continuing.
+	    [Inferior 2 (process 14967) exited normally]
+	    (gdb) FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: continue to break_parent (the program exited)
+
+	Here, we continue both the vfork parent and child, since
+	schedule-multiple is on.  The child exits, which un-freezes the parent
+	and makes an exit event available to GDB.  We expect GDB to consume this
+	exit event and present it to the user.  Here, we see that GDB shows the
+	parent hitting a breakpoint before showing the child exit.
+
+	Because of the vfork, we know that chronologically, the child exiting
+	must have happend before the parent hitting a breakpoint.  However,
+	scheduling being what it is, it is possible for the parent to un-freeze
+	and exit quickly, such that when GDB pulls events out of the kernel,
+	exit events for both processes are available.  And then, GDB may chose
+	at random to return the one for the parent first.  This is what I
+	imagine what causes the failure shown above.
+
+	We could change the test to expect both possible outcomes, but I wanted
+	to avoid complicating the .exp file that way.  Instead, add a variable
+	that the parent loops on that we set only after we confirmed the exit of
+	the child.  That should ensure that the order is always the same.
+
+	Note that I wasn't able to reproduce the failure, so I can't tell if
+	this fix really fixes the problem.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29021
+	Change-Id: Ibc8e527e0e00dac54b22021fe4d9d8ab0f3b28ad
+
+2022-04-05  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb/testsuite: fix intermittent failures in gdb.mi/mi-cmd-user-context.exp
+	I got failures like this once on a CI:
+
+	    frame^M
+	    &"frame\n"^M
+	    ~"#0  child_sub_function () at /home/jenkins/workspace/binutils-gdb_master_build/arch/amd64/target_board/unix/src/binutils-gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:33\n"^M
+	    ~"33\t    dummy = !dummy; /* thread loop line */\n"^M
+	    ^done^M
+	    (gdb) ^M
+	    FAIL: gdb.mi/mi-cmd-user-context.exp: frame 1 (unexpected output)
+
+	The problem is that the test expects the following regexp:
+
+	  ".*#0  0x.*"
+
+	And that typically works, when the output of the frame command looks
+	like:
+
+	  #0  0x00005555555551bb in child_sub_function () at ...
+
+	Note the lack of hexadecimal address in the failing case.  Whether or
+	not the hexadecimal address is printed (roughly) depends on whether the
+	current PC is at the beginning of a line.  So depending on where thread
+	2 was when GDB stopped it (after thread 1 hit its breakpoint), we can
+	get either output.  Adjust the regexps to not expect an hexadecimal
+	prefix (0x) but a function name instead (either child_sub_function or
+	child_function).  That one is always printed, and is also a good check
+	that we are in the frame we expect.
+
+	Note that for test "frame 5", we are showing a pthread frame (on my
+	system), so the function name is internal to pthread, not something we
+	can rely on.  In that case, it's almost certain that we are not at the
+	beginning of a line, or that we don't have debug info, so I think it's
+	fine to expect the hex prefix.
+
+	And for test "frame 6", it's ok to _not_ expect a hex prefix (what the
+	test currently does), since we are showing thread 1, which has hit a
+	breakpoint placed at the beginning of a line.
+
+	When testing this, Tom de Vries pointed out that the current test code
+	doesn't ensure that the child threads are in child_sub_function when
+	they are stopped.  If the scheduler chooses so, it is possible for the
+	child threads to be still in the pthread_barrier_wait or child_function
+	functions when they get stopped.  So that would be another racy failure
+	waiting to happen.
+
+	The only way I can think of to ensure the child threads are in the
+	child_sub_function function when they get stopped is to synchronize the
+	threads using some variables instead of pthread_barrier_wait.  So,
+	replace the barrier with an array of flags (one per child thread).  Each
+	child thread flips its flag in child_sub_function to allow the main
+	thread to make progress and eventually hit the breakpoint.
+
+	I copied user-selected-context-sync.c to a new mi-cmd-user-context.c and
+	made modifications to that, to avoid interfering with
+	user-selected-context-sync.exp.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29025
+	Change-Id: I919673bbf9927158beb0e8b7e9e980b8d65eca90
+
+2022-04-05  Luis Machado  <luis.machado@arm.com>
+
+	Fix qRcmd error code parsing
+	Someone at IRC spotted a bug in qRcmd handling. This looks like an oversight
+	or it is that way for historical reasons.
+
+	The code in gdb/remote.c:remote_target::rcmd uses isdigit instead of
+	isxdigit. One could argue that we are expecting decimal numbers, but further
+	below we use fromhex ().
+
+	Update the function to use isxdigit instead and also update the documentation.
+
+	I see there are lots of other cases of undocumented number format for error
+	messages, mostly described as NN instead of nn. For now I'll just update
+	this particular function.
+
+2022-04-05  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: resume ongoing step after handling fork or vfork
+	The test introduced by this patch would fail in this configuration, with
+	the native-gdbserver or native-extended-gdbserver boards:
+
+	    FAIL: gdb.threads/next-fork-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=auto: i=2: next to for loop
+
+	The problem is that the step operation is forgotten when handling the
+	fork/vfork.  With "debug infrun" and "debug remote", it looks like this
+	(some lines omitted for brevity).  We do the next:
+
+	    [infrun] proceed: enter
+	      [infrun] proceed: addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT
+	      [infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=0, current thread [4154304.4154304.0] at 0x5555555553bf
+	      [infrun] do_target_resume: resume_ptid=4154304.0.0, step=1, sig=GDB_SIGNAL_0
+	      [remote] Sending packet: $vCont;r5555555553bf,5555555553c4:p3f63c0.3f63c0;c:p3f63c0.-1#cd
+	    [infrun] proceed: exit
+
+	We then handle a fork event:
+
+	    [infrun] fetch_inferior_event: enter
+	      [remote] wait: enter
+	        [remote] Packet received: T05fork:p3f63ee.3f63ee;06:0100000000000000;07:b08e59f6ff7f0000;10:bf60e8f7ff7f0000;thread:p3f63c0.3f63c6;core:17;
+	      [remote] wait: exit
+	      [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
+	      [infrun] print_target_wait_results:   4154304.4154310.0 [Thread 4154304.4154310],
+	      [infrun] print_target_wait_results:   status->kind = FORKED, child_ptid = 4154350.4154350.0
+	      [infrun] handle_inferior_event: status->kind = FORKED, child_ptid = 4154350.4154350.0
+	      [remote] Sending packet: $D;3f63ee#4b
+	      [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [4154304.4154310.0] at 0x7ffff7e860bf
+	      [infrun] do_target_resume: resume_ptid=4154304.0.0, step=0, sig=GDB_SIGNAL_0
+	      [remote] Sending packet: $vCont;c:p3f63c0.-1#73
+	    [infrun] fetch_inferior_event: exit
+
+	In the first snippet, we resume the stepping thread with the range-stepping (r)
+	vCont command.  But after handling the fork (detaching the fork child), we
+	resumed the whole process freely.  The stepping thread, which was paused by
+	GDBserver while reporting the fork event, was therefore resumed freely, instead
+	of confined to the addresses of the stepped line.  Note that since this
+	is a "next", it could be that we have entered a function, installed a
+	step-resume breakpoint, and it's ok to continue freely the stepping
+	thread, but that's not the case here.  The two snippets shown above were
+	next to each other in the logs.
+
+	For the fork case, we can resume stepping right after handling the
+	event.
+
+	However, for the vfork case, where we are waiting for the
+	external child process to exec or exit, we only resume the thread that
+	called vfork, and keep the others stopped (see patch "gdb: fix handling of
+	vfork by multi-threaded program" prior in this series).  So we can't
+	resume the stepping thread right now.  Instead, do it after handling the
+	vfork-done event.
+
+	Change-Id: I92539c970397ce880110e039fe92b87480f816bd
+
+2022-04-05  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/remote: remove_new_fork_children don't access target_waitstatus::child_ptid if kind == TARGET_WAITKIND_THREAD_EXITED
+	Following the previous patch, running
+	gdb.threads/forking-threads-plus-breakpoints.exp continuously eventually
+	gives me an internal error.
+
+	    gdb/target/waitstatus.h:372: internal-error: child_ptid: Assertion `m_kind == TARGET_WAITKIND_FORKED || m_kind == TARGET_WAITKIND_VFORKED' failed.^M
+	    FAIL: gdb.threads/forking-threads-plus-breakpoint.exp: cond_bp_target=0: detach_on_fork=on: displaced=off: inferior 1 exited (GDB internal error)
+
+	The backtrace is:
+
+	    0x55925b679c85 internal_error(char const*, int, char const*, ...)
+	    	/home/simark/src/binutils-gdb/gdbsupport/errors.cc:55
+	    0x559258deadd2 target_waitstatus::child_ptid() const
+	    	/home/simark/src/binutils-gdb/gdb/target/waitstatus.h:372
+	    0x55925a7cbac9 remote_target::remove_new_fork_children(threads_listing_context*)
+	    	/home/simark/src/binutils-gdb/gdb/remote.c:7311
+	    0x55925a79dfdb remote_target::update_thread_list()
+	    	/home/simark/src/binutils-gdb/gdb/remote.c:3981
+	    0x55925ad79b83 target_update_thread_list()
+	    	/home/simark/src/binutils-gdb/gdb/target.c:3793
+	    0x55925addbb15 update_thread_list()
+	    	/home/simark/src/binutils-gdb/gdb/thread.c:2031
+	    0x559259d64838 stop_all_threads(char const*, inferior*)
+	    	/home/simark/src/binutils-gdb/gdb/infrun.c:5104
+	    0x559259d88b45 keep_going_pass_signal
+	    	/home/simark/src/binutils-gdb/gdb/infrun.c:8215
+	    0x559259d8951b keep_going
+	    	/home/simark/src/binutils-gdb/gdb/infrun.c:8251
+	    0x559259d78835 process_event_stop_test
+	    	/home/simark/src/binutils-gdb/gdb/infrun.c:6858
+	    0x559259d750e9 handle_signal_stop
+	    	/home/simark/src/binutils-gdb/gdb/infrun.c:6580
+	    0x559259d6c07b handle_inferior_event
+	    	/home/simark/src/binutils-gdb/gdb/infrun.c:5832
+	    0x559259d57db8 fetch_inferior_event()
+	    	/home/simark/src/binutils-gdb/gdb/infrun.c:4222
+
+	Indeed, the code accesses target_waitstatus::child_ptid when the kind
+	is TARGET_WAITKIND_THREAD_EXITED, which is not right.  A
+	TARGET_WAITKIND_THREAD_EXITED event does not have a child_ptid value
+	associated, it has an exit status, which we are not interested in.  The
+	intent is to remove from the thread list the thread that has exited.
+	Its ptid is found in the stop reply event, get it from there.
+
+	Change-Id: Icb298cbb80b8779fdf0c660dde9a5314d5591535
+
+2022-04-05  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdbserver: report correct status in thread stop race condition
+	The test introduced by the following patch would sometimes fail in this
+	configuration:
+
+	    FAIL: gdb.threads/next-fork-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=auto: i=14: next to for loop
+
+	The test has multiple threads constantly forking or vforking while the
+	main thread keep doing "next"s.
+
+	(After writing the commit message, I realized this also fixes a similar
+	failure in gdb.threads/forking-threads-plus-breakpoint.exp with the
+	native-gdbserver and native-extended-gdbserver boards.)
+
+	As stop_all_threads is called, because the main thread finished its
+	"next", it inevitably happens at some point that we ask the remote
+	target to stop a thread and wait() reports that this thread stopped with
+	a fork or vfork event, instead of the SIGSTOP we sent to try to stop it.
+
+	While running this test, I attached to GDBserver and stopped at
+	linux-low.cc:3626.  We can see that the status pulled from the kernel
+	for 2742805 is indeed a vfork event:
+
+	    (gdb) p/x w
+	    $3 = 0x2057f
+	    (gdb) p WIFSTOPPED(w)
+	    $4 = true
+	    (gdb) p WSTOPSIG(w)
+	    $5 = 5
+	    (gdb) p/x (w >> 8) & (PTRACE_EVENT_VFORK << 8)
+	    $6 = 0x200
+
+	However, the statement at line 3626 overrides that:
+
+	    ourstatus->set_stopped (gdb_signal_from_host (WSTOPSIG (w)));
+
+	OURSTATUS becomes "stopped by a SIGTRAP".  The information about the
+	fork or vfork is lost.
+
+	It's then all downhill from there, stop_all_threads eventually asks for
+	a thread list update.  That thread list includes the child of that
+	forgotten fork or vfork, the remote target goes "oh cool, a new process,
+	let's attach to it!", when in fact that vfork child's destiny was to be
+	detached.
+
+	My reverse-engineered understanding of the code around there is that the
+	if/else between lines 3562 and 3583 (in the original code) makes sure
+	OURSTATUS is always initialized (not "ignore").  Either the details are
+	already in event_child->waitstatus (in the case of fork/vfork, for
+	example), in which case we just copy event_child->waitstatus to
+	ourstatus.  Or, if the event is a plain "stopped by a signal" or a
+	syscall event, OURSTATUS is set to "stopped", but without a signal
+	number.  Lines 3601 to 3629 (in the original code) serve to fill in that
+	last bit of information.
+
+	The problem is that when `w` holds the vfork status, the code wrongfully
+	takes this branch, because WSTOPSIG(w) returns SIGTRAP:
+
+	  else if (current_thread->last_resume_kind == resume_stop
+	       && WSTOPSIG (w) != SIGSTOP)
+
+	The intent of this branch is, for example, when we sent SIGSTOP to try
+	to stop a thread, but wait() reports that it stopped with another signal
+	(that it must have received from somewhere else simultaneously), say
+	SIGWINCH.  In that case, we want to report the SIGWINCH.  But in our
+	fork/vfork case, we don't want to take this branch, as the thread didn't
+	really stop because it received a signal.  For the non "stopped by a
+	signal" and non "syscall signal" cases, we would ideally skip over all
+	that snippet that fills in the signal or syscall number.
+
+	The fix I propose is to move this snipppet of the else branch of the
+	if/else above.  In addition to moving the code, the last two "else if"
+	branches:
+
+	  else if (current_thread->last_resume_kind == resume_stop
+		   && WSTOPSIG (w) != SIGSTOP)
+	    {
+	      /* A thread that has been requested to stop by GDB with vCont;t,
+		 but, it stopped for other reasons.  */
+	      ourstatus->set_stopped (gdb_signal_from_host (WSTOPSIG (w)));
+	    }
+	  else if (ourstatus->kind () == TARGET_WAITKIND_STOPPED)
+	    ourstatus->set_stopped (gdb_signal_from_host (WSTOPSIG (w)));
+
+	are changed into a single else:
+
+	  else
+	    ourstatus->set_stopped (gdb_signal_from_host (WSTOPSIG (w)));
+
+	This is the default path we take if:
+
+	 - W is not a syscall status
+	 - W does not represent a SIGSTOP that have sent to stop the thread and
+	   therefore want to suppress it
+
+	Change-Id: If2dc1f0537a549c293f7fa3c53efd00e3e194e79
+
+2022-04-05  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: fix handling of vfork by multi-threaded program (follow-fork-mode=parent, detach-on-fork=on)
+	There is a problem with how GDB handles a vfork happening in a
+	multi-threaded program.  This problem was reported to me by somebody not
+	using vfork directly, but using system(3) in a multi-threaded program,
+	which may be implemented using vfork.
+
+	This patch only deals about the follow-fork-mode=parent,
+	detach-on-fork=on case, because it would be too much to chew at once to
+	fix the bugs in the other cases as well (I tried).
+
+	The problem
+	-----------
+
+	When a program vforks, the parent thread is suspended by the kernel
+	until the child process exits or execs.  Specifically, in a
+	multi-threaded program, only the thread that called vfork is suspended,
+	other threads keep running freely. This is documented in the vfork(2)
+	man page ("Caveats" section).
+
+	Let's suppose GDB is handling a vfork and the user's desire is to detach
+	from the child. Before detaching the child, GDB must remove the software
+	breakpoints inserted in the shared parent/child address space, in case
+	there's a breakpoint in the path the child is going to take before
+	exec'ing or exit'ing (unlikely, but possible). Otherwise the child could
+	hit a breakpoint instruction while running outside the control of GDB,
+	which would make it crash.  GDB must also avoid re-inserting breakpoints
+	in the parent as long as it didn't receive the "vfork done" event (that
+	is, when the child has exited or execed): since the address space is
+	shared with the child, that would re-insert breakpoints in the child
+	process also. So what GDB does is:
+
+	  1. Receive "vfork" event for the parent
+	  2. Remove breakpoints from the (shared) address space and set
+	     program_space::breakpoints_not_allowed to avoid re-inserting them
+	  3. Detach from the child thread
+	  4. Resume the parent
+	  5. Wait for and receive "vfork done" event for the parent
+	  6. Clean program_space::breakpoints_not_allowed and re-insert
+	     breakpoints
+	  7. Resume the parent
+
+	Resuming the parent at step 4 is necessary in order for the kernel to
+	report the "vfork done" event.  The kernel won't report a ptrace event
+	for a thread that is ptrace-stopped.  But the theory behind this is that
+	between steps 4 and 5, the parent won't actually do any progress even
+	though it is ptrace-resumed, because the kernel keeps it suspended,
+	waiting for the child to exec or exit.  So it doesn't matter for that
+	thread if breakpoints are not inserted.
+
+	The problem is when the program is multi-threaded.  In step 4, GDB
+	resumes all threads of the parent. The thread that did the vfork stays
+	suspended by the kernel, so that's fine. But other threads are running
+	freely while breakpoints are removed, which is a problem because they
+	could miss a breakpoint that they should have hit.
+
+	The problem is present with all-stop and non-stop targets.  The only
+	difference is that with an all-stop targets, the other threads are
+	stopped by the target when it reports the vfork event and are resumed by
+	the target when GDB resumes the parent.  With a non-stop target, the
+	other threads are simply never stopped.
+
+	The fix
+	-------
+
+	There many combinations of settings to consider (all-stop/non-stop,
+	target-non-stop on/off, follow-fork-mode parent/child, detach-on-fork
+	on/off, schedule-multiple on/off), but for this patch I restrict the
+	scope to follow-fork-mode=parent, detach-on-fork=on.  That's the
+	"default" case, where we detach the child and keep debugging the
+	parent.  I tried to fix them all, but it's just too much to do at once.
+	The code paths and behaviors for when we don't detach the child are
+	completely different.
+
+	The guiding principle for this patch is that all threads of the vforking
+	inferior should be stopped as long as breakpoints are removed.  This is
+	similar to handling in-line step-overs, in a way.
+
+	For non-stop targets (the default on Linux native), this is what
+	happens:
+
+	 - In follow_fork, we call stop_all_threads to stop all threads of the
+	   inferior
+	 - In follow_fork_inferior, we record the vfork parent thread in
+	   inferior::thread_waiting_for_vfork_done
+	 - Back in handle_inferior_event, we call keep_going, which resumes only
+	   the event thread (this is already the case, with a non-stop target).
+	   This is the thread that will be waiting for vfork-done.
+	 - When we get the vfork-done event, we go in the (new) handle_vfork_done
+	   function to restart the previously stopped threads.
+
+	In the same scenario, but with an all-stop target:
+
+	 - In follow_fork, no need to stop all threads of the inferior, the
+	   target has stopped all threads of all its inferiors before returning
+	   the event.
+	 - In follow_fork_inferior, we record the vfork parent thread in
+	   inferior::thread_waiting_for_vfork_done.
+	 - Back in handle_inferior_event, we also call keep_going.  However, we
+	   only want to resume the event thread here, not all inferior threads.
+	   In internal_resume_ptid (called by resume_1), we therefore now check
+	   whether one of the inferiors we are about to resume has
+	   thread_waiting_for_vfork_done set.  If so, we only resume that
+	   thread.
+
+	   Note that when resuming multiple inferiors, one vforking and one not
+	   non-vforking, we could resume the vforking thread from the vforking
+	   inferior plus all threads from the non-vforking inferior.  However,
+	   this is not implemented, it would require more work.
+	 - When we get the vfork-done event, the existing call to keep_going
+	   naturally resumes all threads.
+
+	Testing-wise, add a test that tries to make the main thread hit a
+	breakpoint while a secondary thread calls vfork.  Without the fix, the
+	main thread keeps going while breakpoints are removed, resulting in a
+	missed breakpoint and the program exiting.
+
+	Change-Id: I20eb78e17ca91f93c19c2b89a7e12c382ee814a1
+
+2022-04-05  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/infrun: add logging statement to do_target_resume
+	This helped me, it shows which ptid we actually call target_resume with.
+
+	Change-Id: I2dfd771e83df8c25f39371a13e3e91dc7882b73d
+
+2022-04-05  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/infrun: add inferior parameters to stop_all_threads and restart_threads
+	A following patch will want to stop all threads of a given inferior (as
+	opposed to all threads of all inferiors) while handling a vfork, and
+	restart them after.  To help with this, add inferior parameters to
+	stop_all_threads and restart_threads.  This is done as a separate patch
+	to make sure this doesn't cause regressions on its own, and to keep the
+	following patches more concise.
+
+	No visible changes are expected here, since all calls sites pass
+	nullptr, which should keep the existing behavior.
+
+	Change-Id: I4d9ba886ce842042075b4e346cfa64bbe2580dbf
+
+2022-04-05  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: replace inferior::waiting_for_vfork_done with inferior::thread_waiting_for_vfork_done
+	The inferior::waiting_for_vfork_done flag indicates that some thread in
+	that inferior is waiting for a vfork-done event.  Subsequent patches
+	will need to know which thread precisely is waiting for that event.
+
+	Replace the boolean flag (waiting_for_vfork_done) with a thread_info
+	pointer (thread_waiting_for_vfork_done).
+
+	I think there is a latent buglet in that waiting_for_vfork_done is
+	currently not reset on inferior exec or exit.  I could imagine that if a
+	thread in the parent process calls exec or exit while another thread of
+	the parent process is waiting for its vfork child to exec or exit, we
+	could end up with inferior::waiting_for_vfork_done without a thread
+	actually waiting for a vfork-done event anymore.  And since that flag is
+	checked in resume_1, things could misbehave there.
+
+	Since the new field points to a thread_info object, and those are
+	destroyed on exec or exit, it could be worse now since we could try to
+	access freed memory, if thread_waiting_for_vfork_done were to point to a
+	stale thread_info.  To avoid this, clear the field in
+	infrun_inferior_exit and infrun_inferior_execd.
+
+	Change-Id: I31b847278613a49ba03fc4915f74d9ceb228fdce
+
+2022-04-05  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: make timestamped_file implement write_async_safe
+	Trying to use "set debug linux-nat 1", I get an internal error:
+
+	    /home/smarchi/src/binutils-gdb/gdb/ui-file.h:70: internal-error: write_async_safe: write_async_safe
+
+	The problem is that timestamped_file doesn't implement write_async_safe,
+	which linux-nat's sigchld_handler uses.  Implement it.
+
+	Change-Id: I830981010c6119f13ae673605ed015cced0f5ee8
+
+2022-04-05  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-04  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: fix timeout in server-pipe.exp test
+	I noticed that the gdb.server/server-pipe.exp test would sometimes
+	timeout when my machine was more heavily loaded.  Turns out the test
+	is reading all the shared libraries over GDB's remote protocol, which
+	can be slow.
+
+	We avoid this in other tests by setting the sysroot in GDBFLAGS,
+	something which is missing from the gdb.server/server-pipe.exp test.
+
+	Fix the timeouts by setting sysroot in GDBFLAGS, after this the shared
+	libraries are no longer copied over the remote protocol, and I no
+	longer see the test timeout.
+
+2022-04-04  John Baldwin  <jhb@FreeBSD.org>
+
+	Handle TLS variable lookups when using separate debug files.
+	Commit df22c1e5d53c38f38bce6072bb46de240f9e0e2b handled the case that
+	a separate debug file was passed as the objfile for a shared library
+	to svr4_fetch_objfile_link_map.  However, a separate debug file can
+	also be passed for TLS variables in the main executable.  In addition,
+	frv_fetch_objfile_link_map also expects to be passed the original
+	objfile rather than a separate debug file, so pull the code to resolve
+	a separate debug file to the main objfile up into
+	target_translate_tls_address.
+
+2022-04-04  Lancelot SIX  <lancelot.six@amd.com>
+
+	gdb: Add maint set ignore-prologue-end-flag
+	The previous patch added support for the DWARF prologue-end flag in line
+	table. This flag can be used by DWARF producers to indicate where to
+	place breakpoints past a function prologue.  However, this takes
+	precedence over prologue analyzers. So if we have to debug a program
+	with erroneous debug information, the overall debugging experience will
+	be degraded.
+
+	This commit proposes to add a maintenance command to instruct GDB to
+	ignore the prologue_end flag.
+
+	Tested on x86_64-gnu-linux.
+
+	Change-Id: Idda6d1b96ba887f4af555b43d9923261b9cc6f82
+
+2022-04-04  Lancelot SIX  <lancelot.six@amd.com>
+
+	gdb: Add support for DW_LNS_set_prologue_end in line-table
+	Add support for DW_LNS_set_prologue_end when building line-tables.  This
+	attribute can be set by the compiler to indicate that an instruction is
+	an adequate place to set a breakpoint just after the prologue of a
+	function.
+
+	The compiler might set multiple prologue_end, but considering how
+	current skip_prologue_using_sal works, this commit modifies it to accept
+	the first instruction with this marker (if any) to be the place where a
+	breakpoint should be placed to be at the end of the prologue.
+
+	The need for this support came from a problematic usecase generated by
+	hipcc (i.e. clang).  The problem is as follows:  There's a function
+	(lets call it foo) which covers PC from 0xa800 to 0xa950.  The body of
+	foo begins with a call to an inlined function, covering from 0xa800 to
+	0xa94c.   The issue is that when placing a breakpoint at 'foo', GDB
+	inserts the breakpoint at 0xa818.  The 0x18 offset is what GDB thinks is
+	foo's first address past the prologue.
+
+	Later, when hitting the breakpoint, GDB reports the stop within the
+	inlined function because the PC falls in its range while the user
+	expects to stop in FOO.
+
+	Looking at the line-table for this location, we have:
+
+	    INDEX  LINE   ADDRESS            IS-STMT
+	    [...]
+	    14     293    0x000000000000a66c Y
+	    15     END    0x000000000000a6e0 Y
+	    16     287    0x000000000000a800 Y
+	    17     END    0x000000000000a818 Y
+	    18     287    0x000000000000a824 Y
+	    [...]
+
+	For comparison, let's look at llvm-dwarfdump's output for this CU:
+
+	    Address            Line   Column File   ISA Discriminator Flags
+	    ------------------ ------ ------ ------ --- ------------- -------------
+	    [...]
+	    0x000000000000a66c    293     12      2   0             0  is_stmt
+	    0x000000000000a6e0     96     43     82   0             0  is_stmt
+	    0x000000000000a6f8    102     18     82   0             0  is_stmt
+	    0x000000000000a70c    102     24     82   0             0
+	    0x000000000000a710    102     18     82   0             0
+	    0x000000000000a72c    101     16     82   0             0  is_stmt
+	    0x000000000000a73c   2915     50     83   0             0  is_stmt
+	    0x000000000000a74c    110      1      1   0             0  is_stmt
+	    0x000000000000a750    110      1      1   0             0  is_stmt end_sequence
+	    0x000000000000a800    107      0      1   0             0  is_stmt
+	    0x000000000000a800    287     12      2   0             0  is_stmt prologue_end
+	    0x000000000000a818    114     59     81   0             0  is_stmt
+	    0x000000000000a824    287     12      2   0             0  is_stmt
+	    0x000000000000a828    100     58     82   0             0  is_stmt
+	    [...]
+
+	The main difference we are interested in here is that llvm-dwarfdump's
+	output tells us that 0xa800 is an adequate place to place a breakpoint
+	past a function prologue.  Since we know that foo covers from 0xa800 to
+	0xa94c, 0xa800 is the address at which the breakpoint should be placed
+	if the user wants to break in foo.
+
+	This commit proposes to add support for the prologue_end flag in the
+	line-program processing.
+
+	The processing of this prologue_end flag is made in skip_prologue_sal,
+	before it calls gdbarch_skip_prologue_noexcept.  The intent is that if
+	the compiler gave information on where the prologue ends, we should use
+	this information and not try to rely on architecture dependent logic to
+	guess it.
+
+	The testsuite have been executed using this patch on GNU/Linux x86_64.
+	Testcases have been compiled with both gcc/g++ (verison 9.4.0) and
+	clang/clang++ (version 10.0.0) since at the time of writing GCC does not
+	set the prologue_end marker.  Tests done with GCC 11.2.0 (not over the
+	entire testsuite) show that it does not emit this flag either.
+
+	No regression have been observed with GCC or Clang.  Note that when
+	using Clang, this patch fixes a failure in
+	gdb.opt/inline-small-func.exp.
+
+	Change-Id: I720449a8a9b2e1fb45b54c6095d3b1e9da9152f8
+
+2022-04-04  Lancelot SIX  <lancelot.six@amd.com>
+
+	gdb/buildsym: Line record use a record flag
+	Currently when recording a line entry (with
+	buildsym_compunit::record_line), a boolean argument argument is used to
+	indicate that the is_stmt flag should be set for this particular record.
+	As a later commit will add support for new flags, instead of adding a
+	parameter to record_line for each possible flag, transform the current
+	is_stmt parameter into a enum flag.  This flags parameter will allow
+	greater flexibility in future commits.
+
+	This enum flags type is not propagated into the linetable_entry type as
+	this would require a lot of changes across the codebase for no practical
+	gain (it currently uses a bitfield where each interesting flag only
+	occupy 1 bit in the structure).
+
+	Tested on x86_64-linux, no regression observed.
+
+	Change-Id: I5d061fa67bdb34918742505ff983d37453839d6a
+
+2022-04-04  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: make timestamped_file implement can_emit_style_escape
+	In our AMDGPU downstream port, we use styling in some logging output.
+	We noticed it stopped working after the gdb_printf changes.  Making
+	timestamped_file implement can_emit_style_escape (returning the value of
+	the stream it wraps) fixes it.  To show that it works, modify some
+	logging statements in auto-load.c to output style filenames.  You can
+	see it in action by setting "set debug auto-load 1" and running a
+	program.  We can incrementally add styling to other debug statements
+	throughout GDB, as needed.
+
+	Change-Id: I78a2fd1e078f80f2263251cf6bc53b3a9de9c17a
+
+2022-04-04  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove assertion in psymbol_functions::expand_symtabs_matching
+	psymtab_to_symtab is documented as possibly returning nullptr, if the
+	primary symtab of the partial symtab has no symbols.  However,
+	psymbol_functions::expand_symtabs_matching asserts that the result of
+	psymtab_to_symtab as non-nullptr.
+
+	I caught this assert by trying the CTF symbol reader on a library I
+	built with -gctf:
+
+	    $ ./gdb --data-directory=data-directory /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0
+	    ...
+	    Reading symbols from /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0...
+	    (gdb) maintenance expand-symtabs
+	    /home/simark/src/binutils-gdb/gdb/psymtab.c:1142: internal-error: expand_symtabs_matching: Assertion `symtab != nullptr' failed.
+
+	The "symtab" in question is:
+
+	    $  readelf --ctf=.ctf /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0
+	    ...
+	    CTF archive member: /home/simark/src/babeltrace/src/lib/graph/component-descriptor-set.c:
+
+	      Header:
+	        Magic number: 0xdff2
+	        Version: 4 (CTF_VERSION_3)
+	        Flags: 0xe (CTF_F_NEWFUNCINFO, CTF_F_IDXSORTED, CTF_F_DYNSTR)
+	        Parent name: .ctf
+	        Compilation unit name: /home/simark/src/babeltrace/src/lib/graph/component-descriptor-set.c
+	        Type section:       0x0 -- 0x13 (0x14 bytes)
+	        String section:     0x14 -- 0x5f (0x4c bytes)
+
+	      Labels:
+
+	      Data objects:
+
+	      Function objects:
+
+	      Variables:
+
+	      Types:
+	        0x80000001: (kind 5) bt_bool (*) (const bt_value *) (aligned at 0x8)
+
+	      Strings:
+	        0x0:
+	        0x1: .ctf
+	        0x6: /home/simark/src/babeltrace/src/lib/graph/component-descriptor-set.c
+
+	It contains a single type, and it is skipped by ctf_add_type_cb, because
+	an identical type was already seen earlier in this objfile.  As a
+	result, no compunit_symtab is created.
+
+	Change psymbol_functions::expand_symtabs_matching to expect that
+	psymtab_to_symtab can return nullptr.
+
+	Another possibility would be to make the CTF symbol reader always create
+	a compunit_symtab, even if there are no symbols in it (like the DWARF
+	parser does), but so far I don't see any advantage in doing so.
+
+	Change-Id: Ic43c38202c838a5eb87630ed1fd61d33528164f4
+
+2022-04-04  Andrew Burgess  <aburgess@redhat.com>
+
+	sim: fixes for libopcodes styled disassembler
+	In commit:
+
+	  commit 60a3da00bd5407f07d64dff82a4dae98230dfaac
+	  Date:   Sat Jan 22 11:38:18 2022 +0000
+
+	      objdump/opcodes: add syntax highlighting to disassembler output
+
+	I broke several sim/ targets by forgetting to update their uses of the
+	libopcodes disassembler to take account of the new styled printing.
+
+	These should all be fixed by this commit.
+
+	I've not tried to add actual styled output to the simulator traces,
+	instead, the styled print routines just ignore the style and print the
+	output unstyled.
+
+2022-04-04  Tom Tromey  <tromey@adacore.com>
+
+	Remove some globals from nat/windows-nat.c
+	nat/windows-nat.c has a number of globals that it uses to communicate
+	with its clients (gdb and gdbserver).  However, if we ever want the
+	Windows ports to be multi-inferior, globals won't work.
+
+	This patch takes a step toward that by moving most nat/windows-nat.c
+	globals into a new struct windows_process_info.  Many functions are
+	converted to be methods on this object.
+
+	A couple of globals remain, as they are needed to truly be global due
+	to the way that the Windows debugging APIs work.
+
+	The clients still have a global for the current process.  That is,
+	this patch is a step toward the end goal, but doesn't implement the
+	goal itself.
+
+2022-04-04  Tom Tromey  <tromey@adacore.com>
+
+	Remove windows_thread_info destructor
+	windows_thread_info declares and defines a destructor, but this
+	doesn't need to be explicit.
+
+	Use unique_ptr in the Windows thread list
+	windows-nat.c uses some manual memory management when manipulating the
+	thread_list global.  Changing this to use unique_ptr simplifies the
+	code, in particular windows_init_thread_list.  (Note that, while I
+	think the the call to init_thread_list in there is wrong, I haven't
+	removed it in this patch.)
+
+	Use auto_obstack in windows-nat.c
+	One spot in windows-nat.c can use auto_obstack, removing some manual
+	memory management.
+
+2022-04-04  Tom Tromey  <tromey@adacore.com>
+
+	Simplify windows-nat.c solib handling
+	Currently windows-nat.c uses struct so_list to record its local idea
+	of which shared libraries have been loaded.  However, many fields in
+	this are not needed, and furthermore I found this quite confusing at
+	first -- Windows actually uses solib-target and so the use of so_list
+	here is weird.
+
+	This patch simplifies this code by changing it to use a std::vector
+	and a new type that holds exactly what's needed for the Windows code.
+
+2022-04-04  Pedro Alves  <pedro@palves.net>
+
+	Avoid undefined behavior in gdbscm_make_breakpoint
+	Running gdb.guile/scm-breakpoint.exp against an --enable-ubsan build,
+	we see:
+
+	 UNRESOLVED: gdb.guile/scm-breakpoint.exp: test_watchpoints: create a breakpoint with an invalid type number
+	 ...
+	 guile (define wp2 (make-breakpoint "result" #:wp-class WP_WRITE #:type 999))
+	 ../../src/gdb/guile/scm-breakpoint.c:377:11: runtime error: load of value 999, which is not a valid value for type 'bptype'
+	 ERROR: GDB process no longer exists
+
+	Fix this by parsing the user/guile input as plain int, and cast to
+	internal type only after we know we have a number that would be valid.
+
+	Change-Id: I03578d07db00be01b610a8f5ce72e5521aea6a4b
+
+2022-04-04  Tom Tromey  <tromey@adacore.com>
+
+	Add context-sensitive field name completion to Ada parser
+	This updates the Ada expression parser to implement context-sensitive
+	field name completion.  This is PR ada/28727.
+
+	This is somewhat complicated due to some choices in the Ada lexer --
+	it chooses to represent a sequence of "."-separated identifiers as a
+	single token, so the parser must partially recreate the completer's
+	logic to find the completion word boundaries.
+
+	Despite the minor warts in this patch, though, it is a decent
+	improvement.  It's possible that the DWARF reader rewrite will help
+	fix the package completion problem pointed out in this patch as well.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28727
+
+2022-04-04  Tom Tromey  <tromey@adacore.com>
+
+	Consolidate single-char tokens in ada-lex.l
+	There are two rules in ada-lex.l that match single-character tokens.
+	This merges them.
+
+	Also, this removes '.' from the list of such tokens.  '.' is not used
+	in any production in ada-exp.y, and removing it here helps the
+	subsequent completion patches.
+
+2022-04-04  Tom Tromey  <tromey@adacore.com>
+
+	Remove the Ada DOT_ALL token
+	The Ada parser has a DOT_ALL token to represent ".all", and another
+	token to represent other ".<identifier>" forms.  However, for
+	completion it is a bit more convenient to unify these cases, so this
+	patch removes DOT_ALL.
+
+	Refactor ada-lex.l:processId
+	processId in ada-lex.l is a bit funny -- it uses an "if" and a
+	"switch", and a nested loop.  This patch cleans it up a bit, changing
+	it to use a boolean flag and a simpler "if".
+
+	Implement completion for Ada attributes
+	This adds a completer for Ada attributes.  Some work in the lexer is
+	required in order to match end-of-input correctly, as flex does not
+	have a general-purpose way of doing this.  (The approach taken here is
+	recommended in the flex manual.)
+
+2022-04-04  Tom Tromey  <tromey@adacore.com>
+
+	Refactor expression completion
+	This refactors the gdb expression completion code to make it easier to
+	add more types of completers.
+
+	In the old approach, just two kinds of completers were supported:
+	field names for some sub-expression, or tag names (like "enum
+	something").  The data for each kind was combined in single structure,
+	"expr_completion_state", and handled explicitly by
+	complete_expression.
+
+	In the new approach, the parser state just holds an object that is
+	responsible for implementing completion.  This way, new completion
+	types can be added by subclassing this base object.
+
+	The structop completer is moved into structop_base_operation, and new
+	objects are defined for use by the completion code.  This moves much
+	of the logic of expression completion out of completer.c as well.
+
+2022-04-04  Tom Tromey  <tromey@adacore.com>
+
+	Enable "set debug parser" for Ada
+	I noticed that "set debug parser 1" did not affect Ada parsing.  This
+	patch fixes the problem.
+
+	Because this is rarely useful, and pretty much only for maintainers, I
+	didn't write a test case.
+
+2022-04-04  Tom Tromey  <tromey@adacore.com>
+
+	Fix bug in Ada attributes lexing
+	The Ada lexer allows whitespace between the apostrophe and the
+	attribute text, but processAttribute does not handle this.  This patch
+	fixes the problem and introduces a regression test.
+
+	Remove null sentinel from 'attributes'
+	In a subsequent patch, it's handy if the 'attributes' array in
+	ada-lex.l does not have a NULL sentinel at the end.  In C++, this is
+	easy to avoid.
+
+	Handle ghost entities in symbol lookup
+	Normally, SPARK ghost entities are removed from the executable.
+	However, with -gnata, they will be preserved.  In this situation, it's
+	handy to be able to inspect them.  This patch allows this by removing
+	the "___ghost_" prefix in the appropriate places.
+
+2022-04-04  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: rename start_symtab/end_symtab to start_compunit_symtab/end_compunit_symtab
+	It's a bit confusing because we have both "compunit_symtab" and "symtab"
+	types, and many methods and functions containing "start_symtab" or
+	"end_symtab", which actually deal with compunit_symtabs.  I believe this
+	comes from the time before compunit_symtab was introduced, where
+	symtab did the job of both.
+
+	Rename everything I found containing start_symtab or end_symtab to use
+	start_compunit_symtab or end_compunit_symtab.
+
+	Change-Id: If3849b156f6433640173085ad479b6a0b085ade2
+
+2022-04-04  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove some unused buildsym-legacy functions
+	Pretty much self-explanatory.
+
+	Change-Id: I5b658d017cd891ecdd1df61075eacb0f44316935
+
+2022-04-04  Fangrui Song  <i@maskray.me>
+
+	gas: copy st_size only if unset
+	For
+	```
+	.size foo1, 1
+	foo1:
+
+	.set bar1, foo1
+	.size bar1, 2
+	.size bar2, 2
+	.set bar2, foo1
+
+	.set bar3, foo2
+	.size bar3, 2
+	.size bar4, 2
+	.set bar4, foo2
+
+	.size foo2, 1
+	foo2:
+	```
+
+	bar1's size is 2 while bar2, bar3, bar4's is 1. The behavior of bar1 makes sense
+	(generally directives on the new symbol should win) and is relied upon by glibc
+	stdio-common/errlist.c:
+
+	```
+	        .hidden _sys_errlist_internal
+	        .globl  _sys_errlist_internal
+	        .type   _sys_errlist_internal, @object
+	        .size   _sys_errlist_internal, 1072
+	_sys_errlist_internal:
+
+	        .globl __GLIBC_2_1_sys_errlist
+	        .set __GLIBC_2_1_sys_errlist, _sys_errlist_internal
+	        .type __GLIBC_2_1_sys_errlist, %object
+	        .size __GLIBC_2_1_sys_errlist, 125 * (64 / 8)
+
+	// glibc expects that .size __GLIBC_2_1_sys_errlist, 125 * (64 / 8) wins.
+	```
+
+	The behavior of bar2/bar3/bar4 seems brittle. To avoid the reordering of the two
+	code blocks which will result in the bar3 situation, glibc compiles errlist.c
+	with gcc -fno-toplevel-reorder (previously -fno-unit-at-a-time).
+
+	To fix the inconsistency and improve robustness, make bar2/bar3/bar4 match bar1,
+	removing the directive order sensitivity.
+
+	There is a pity that `.size dest, 0` is indistinguishable from the case where
+	dest is unset, but the compromise seems fine.
+
+	    PR gas/29012
+	    * config/obj-elf.c (elf_copy_symbol_attributes): don't copy if src's size
+	      has been set.
+	    * testsuite/gas/elf/elf.exp: New test.
+	    * testsuite/gas/elf/size.d: New file.
+	    * testsuite/gas/elf/size.s: Likewise.
+
+2022-04-04  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: remove use of vfprintf_filtered
+	Commit:
+
+	  commit 60a3da00bd5407f07d64dff82a4dae98230dfaac
+	  Date:   Sat Jan 22 11:38:18 2022 +0000
+
+	      objdump/opcodes: add syntax highlighting to disassembler output
+
+	Introduced a new use of vfprintf_filtered, which has been deprecated.
+	This commit replaces this with gdb_vprintf instead.
+
+2022-04-04  Andrew Burgess  <aburgess@redhat.com>
+
+	opcodes/i386: partially implement disassembler style support
+	This commit adds partial support for disassembler styling in the i386
+	disassembler.
+
+	The i386 disassembler collects the instruction arguments into an array
+	of strings, and then loops over the array printing the arguments out
+	later on.  The problem is that by the time we print the arguments out
+	it's not obvious what the type of each argument is.
+
+	Obviously this can be fixed, but I'd like to not do that as part of
+	this commit, rather, I'd prefer to keep this commit as small as
+	possible to get the basic infrastructure in place, then we can improve
+	on this, to add additional styling, in later commits.
+
+	For now then, I think this commit should correctly style mnemonics,
+	some immediates, and comments.  Everything else will be printed as
+	plain text, which will include most instruction arguments, unless the
+	argument is printed as a symbol, by calling the print_address_func
+	callback.
+
+	Ignoring colours, there should be no other user visible changes in the
+	output of the disassembler in either objdump or gdb.
+
+	opcodes/ChangeLog:
+
+		* disassembler.c (disassemble_init_for_target): Set
+		created_styled_output for i386 based targets.
+		* i386-dis.c: Changed throughout to use fprintf_styled_func
+		instead of fprintf_func.
+
+2022-04-04  Andrew Burgess  <aburgess@redhat.com>
+
+	opcodes/riscv: implement style support in the disassembler
+	Update the RISC-V disassembler to supply style information.  This
+	allows objdump to apply syntax highlighting to the disassembler
+	output (when the appropriate command line flag is used).
+
+	Ignoring colours, there should be no other user visible changes in the
+	output of the disassembler in either objdump or gdb.
+
+	opcodes/ChangeLog:
+
+		* disassembler.c (disassemble_init_for_target): Set
+		created_styled_output for riscv.
+		* riscv-dis.c: Changed throughout to use fprintf_styled_func
+		instead of fprintf_func.
+
+2022-04-04  Andrew Burgess  <aburgess@redhat.com>
+
+	objdump/opcodes: add syntax highlighting to disassembler output
+	This commit adds the _option_ of having disassembler output syntax
+	highlighted in objdump.  This option is _off_ by default.  The new
+	command line options are:
+
+	  --disassembler-color=off		# The default.
+	  --disassembler-color=color
+	  --disassembler-color=extended-color
+
+	I have implemented two colour modes, using the same option names as we
+	use of --visualize-jumps, a basic 8-color mode ("color"), and an
+	extended 8bit color mode ("extended-color").
+
+	The syntax highlighting requires that each targets disassembler be
+	updated; each time the disassembler produces some output we now pass
+	through an additional parameter indicating what style should be
+	applied to the text.
+
+	As updating all target disassemblers is a large task, the old API is
+	maintained.  And so, a user of the disassembler (i.e. objdump, gdb)
+	must provide two functions, the current non-styled print function, and
+	a new, styled print function.
+
+	I don't currently have a plan for converting every single target
+	disassembler, my hope is that interested folk will update the
+	disassemblers they are interested in.  But it is possible some might
+	never get updated.
+
+	In this initial series I intend to convert the RISC-V disassembler
+	completely, and also do a partial conversion of the x86 disassembler.
+	Hopefully having the x86 disassembler at least partial converted will
+	allow more people to try this out easily and provide feedback.
+
+	In this commit I have focused on objdump.  The changes to GDB at this
+	point are the bare minimum required to get things compiling, GDB makes
+	no use of the styling information to provide any colors, that will
+	come later, if this commit is accepted.
+
+	This first commit in the series doesn't convert any target
+	disassemblers at all (the next two commits will update some targets),
+	so after this commit, the only color you will see in the disassembler
+	output, is that produced from objdump itself, e.g. from
+	objdump_print_addr_with_sym, where we print an address and a symbol
+	name, these are now printed with styling information, and so will have
+	colors applied (if the option is on).
+
+	Finally, my ability to pick "good" colors is ... well, terrible.  I'm
+	in no way committed to the colors I've picked here, so I encourage
+	people to suggest new colors, or wait for this commit to land, and
+	then patch the choice of colors.
+
+	I do have an idea about using possibly an environment variable to
+	allow the objdump colors to be customised, but I haven't done anything
+	like that in this commit, the color choices are just fixed in the code
+	for now.
+
+	binutils/ChangeLog:
+
+		* NEWS: Mention new feature.
+		* doc/binutils.texi (objdump): Describe --disassembler-color
+		option.
+		* objdump.c (disassembler_color): New global.
+		(disassembler_extended_color): Likewise.
+		(disassembler_in_comment): Likewise.
+		(usage): Mention --disassembler-color option.
+		(long_options): Add --disassembler-color option.
+		(objdump_print_value): Use fprintf_styled_func instead of
+		fprintf_func.
+		(objdump_print_symname): Likewise.
+		(objdump_print_addr_with_sym): Likewise.
+		(objdump_color_for_disassembler_style): New function.
+		(objdump_styled_sprintf): New function.
+		(fprintf_styled): New function.
+		(disassemble_jumps): Use disassemble_set_printf, and reset
+		disassembler_in_comment.
+		(null_styled_print): New function.
+		(disassemble_bytes): Use disassemble_set_printf, and reset
+		disassembler_in_comment.
+		(disassemble_data): Update init_disassemble_info call.
+		(main): Handle --disassembler-color option.
+
+	include/ChangeLog:
+
+		* dis-asm.h (enum disassembler_style): New enum.
+		(struct disassemble_info): Add fprintf_styled_func field, and
+		created_styled_output field.
+		(disassemble_set_printf): Declare.
+		(init_disassemble_info): Add additional parameter.
+		(INIT_DISASSEMBLE_INFO): Add additional parameter.
+
+	opcodes/ChangeLog:
+
+		* dis-init.c (init_disassemble_info): Take extra parameter,
+		initialize the new fprintf_styled_func and created_styled_output
+		fields.
+		* disassembler.c (disassemble_set_printf): New function definition.
+
+2022-04-04  Tom Tromey  <tom@tromey.com>
+
+	Remove more Python 2 code
+	I found another more place that still had a workaround for Python 2.
+	This patch removes it.
+
+2022-04-04  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix KPASS in gdb.ada/arrayptr.exp
+	On openSUSE Leap 15.3 I run into:
+	...
+	KPASS: gdb.ada/arrayptr.exp: scenario=minimal: print pa_ptr.all \
+	  (PRMS minimal encodings)
+	KPASS: gdb.ada/arrayptr.exp: scenario=minimal: print pa_ptr(3) \
+	  (PRMS minimal encodings)
+	KPASS: gdb.ada/arrayptr.exp: scenario=minimal: print pa_ptr.all(3) \
+	  (PRMS minimal encodings)
+	...
+
+	The test-case KFAILs some tests.  However, the analysis in the corresponding
+	PR talks of a compiler problem, so it should use XFAILs instead.
+
+	The KFAILs are setup for pre-gcc-12, but apparantly the fix has been
+	backported to system compiler 7.5.0, hence the KPASS.
+
+	Fix this by:
+	- using an XFAIL instead of a KFAIL
+	- matching the specific gdb output that corresponds to the XFAILs
+	  (reproduced on Fedora 34).
+
+	Tested on x86_64-linux, specifically openSUSE Leap 15.3 and Fedora 34.
+
+2022-04-04  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-03  rupothar  <rupesh.potharla@amd.com>
+
+	gdb: add support for Fortran's ASSUMED RANK arrays
+	This patch adds a new dynamic property DYN_PROP_RANK, this property is
+	read from the DW_AT_rank attribute and stored within the type just
+	like other dynamic properties.
+
+	As arrays with dynamic ranks make use of a single
+	DW_TAG_generic_subrange to represent all ranks of the array, support
+	for this tag has been added to dwarf2/read.c.
+
+	The final piece of this puzzle is to add support in gdbtypes.c so that
+	we can resolve an array type with dynamic rank.  To do this the
+	existing resolve_dynamic_array_or_string function is split into two,
+	there's a new resolve_dynamic_array_or_string_1 core that is
+	responsible for resolving each rank of the array, while the now outer
+	resolve_dynamic_array_or_string is responsible for figuring out the
+	array rank (which might require resolving a dynamic property) and then
+	calling the inner core.
+
+	The resolve_dynamic_range function now takes a rank, which is passed
+	on to the dwarf expression evaluator.  This rank will only be used in
+	the case where the array itself has dynamic rank, but we now pass the
+	rank in all cases, this should be harmless if the rank is not needed.
+
+	The only small nit is that resolve_dynamic_type_internal actually
+	handles resolving dynamic ranges itself, which now obviously requires
+	us to pass a rank value.  But what rank value to use?  In the end I
+	just passed '1' through here as a sane default, my thinking is that if
+	we are in resolve_dynamic_type_internal to resolve a range, then the
+	range isn't part of an array with dynamic rank, and so the range
+	should actually be using the rank value at all.
+
+	An alternative approach would be to make the rank value a
+	gdb::optional, however, this ends up adding a bunch of complexity to
+	the code (e.g. having to conditionally build the array to pass to
+	dwarf2_evaluate_property, and handling the 'rank - 1' in
+	resolve_dynamic_array_or_string_1) so I haven't done that, but could,
+	if people think that would be a better approach.
+
+	Finally, support for assumed rank arrays was only fixed very recently
+	in gcc, so you'll need the latest gcc in order to run the tests for
+	this.
+
+	Here's an example test program:
+
+	  PROGRAM arank
+	    REAL :: a1(10)
+	    CALL sub1(a1)
+
+	  CONTAINS
+
+	    SUBROUTINE sub1(a)
+	      REAL :: a(..)
+	      PRINT *, RANK(a)
+	    END SUBROUTINE sub1
+	  END PROGRAM arank
+
+	Compiler Version:
+	gcc (GCC) 12.0.0 20211122 (experimental)
+
+	Compilation command:
+	gfortran assumedrank.f90 -gdwarf-5 -o assumedrank
+
+	Without Patch:
+
+	  gdb -q assumedrank
+	  Reading symbols from assumedrank...
+	  (gdb) break sub1
+	  Breakpoint 1 at 0x4006ff: file assumedrank.f90, line 10.
+	  (gdb) run
+	  Starting program: /home/rupesh/STAGING-BUILD-2787/bin/assumedrank
+
+	  Breakpoint 1, arank::sub1 (a=<unknown type in /home/rupesh/STAGING-BUILD-2787
+	  /bin/assumedrank, CU 0x0, DIE 0xd5>) at assumedrank.f90:10
+	  10       PRINT *, RANK(a)
+	  (gdb) print RANK(a)
+	  'a' has unknown type; cast it to its declared type
+
+	With patch:
+
+	  gdb -q assumedrank
+	  Reading symbols from assumedrank...
+	  (gdb) break sub1
+	  Breakpoint 1 at 0x4006ff: file assumedrank.f90, line 10.
+	  (gdb) run
+	  Starting program: /home/rupesh/STAGING-BUILD-2787/bin/assumedrank
+
+	  Breakpoint 1, arank::sub1 (a=...) at assumedrank.f90:10
+	  10       PRINT *, RANK(a)
+	  (gdb) print RANK(a)
+	  $1 = 1
+	  (gdb) ptype a
+	  type = real(kind=4) (10)
+	  (gdb)
+
+	Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
+
+2022-04-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/dwarf: pass an array of values to the dwarf evaluator
+	When we need to evaluate a DWARF expression in order to resolve some
+	dynamic property of a type we call the dwarf2_evaluate_property
+	function, which is declared in gdb/dwarf/loc.h and defined in
+	gdb/dwarf/loc.c.
+
+	Currently, this function takes (amongst other things) an argument of
+	type property_addr_info called addr_stack and a boolean called
+	push_initial_value.  When push_initial_value then the top value of
+	addr_stack is pushed onto the dwarf expression evaluation stack before
+	the expression is evaluated.
+
+	So far this has worked fine, as the only two cases we needed to handle
+	are the case the DWARF expression doesn't require the object
+	address (what the top of addr_stack represents), and the case where
+	the DWARF expression does require the address.
+
+	In the next commit this is going to change.  As we add support for
+	Fortran assumed rank arrays, we need to start resolving the dynamic
+	properties of arrays.  To do this, we need to push the array rank onto
+	the dwarf expression evaluation stack before the expression is
+	evaluated.
+
+	This commit is a refactoring commit aimed at making it easier to
+	support Fortran assumed rank arrays.  Instead of passing a boolean,
+	and using this to decide if we should push the object address or not,
+	we instead pass an array (view) of values that should be pushed to the
+	dwarf expression evaluation stack.
+
+	In the couple of places where we previously passed push_initial_value
+	as true (mostly this was defaulting to false), we now have to pass the
+	address from the addr_stack as an item in the array view.
+
+	In the next commit, when we want to handle passing the array rank,
+	this will easily be supported too.
+
+	There should be no user visible changes after this commit.
+
+2022-04-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: small simplification in dwarf2_locexpr_baton_eval
+	While examining the dwarf expression evaluator, I noticed that in
+	dwarf2_locexpr_baton_eval, whenever push_initial_value is true, the
+	addr_stack will never be nullptr.
+
+	This allows for a small cleanup, replacing an if/then/else with an
+	assertion.
+
+	There should be no user visible changes after this commit.
+
+2022-04-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: resolve some duplicate test names in gdb.base
+	This commit resolves all the duplicate test names that I see in the
+	script:
+
+	  gdb.base/attach-pie-misread.exp
+
+	The duplicate names all come from a second call to
+	build_executable_own_libs, so in this commit I've places the second
+	call inside a with_test_prefix block.
+
+	While I was making this change I've also modified the value being
+	passed as the testname for the second build_executable_own_libs call.
+	Previously we used ${test}, however, I think this was likely a
+	mistake, the 'test' variable is setup for the previous test.  I
+	suspect that ${testfile} is a better choice - especially now we have a
+	testname prefix.
+
+	As the testname is only used (after various calls) from within
+	build_executable_from_specs should the build fail, I don't think this
+	change really makes much difference though.
+
+	There should be no change in what is tested after this commit.
+
+2022-04-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: resolve a duplicate test name in a gdb.mi test
+	Solve two duplicate test names in the test script:
+
+	  gdb.mi/mi-catch-cpp-exceptions.exp
+
+	by moving the call to restart_for_test inside the with_test_prefix
+	block.  There should be no difference in what is tested after this
+	commit.
+
+2022-04-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/Makefile.in: move ALLDEPFILES earlier in Makefile.in
+	If I do 'make tags' in the gdb build directory, the tags target does
+	complete, but I see these warnings:
+
+	  ../../src/gdb/arm.c: No such file or directory
+	  ../../src/gdb/arm-get-next-pcs.c: No such file or directory
+	  ../../src/gdb/arm-linux.c: No such file or directory
+
+	The reason for this is the ordering of build rules and make variables
+	in gdb/Makefile.in, specifically, the placement of the tags related
+	rules, and the ALLDEPFILES variable.  The ordering is like this:
+
+	  TAGFILES_NO_SRCDIR = .... $(ALLDEPFILES) ....
+
+	  TAGS: $(TAGFILES_NO_SRCDIR) ....
+	          # Recipe uses $(TAGFILES_NO_SRCDIR)
+
+	  tags: TAGS
+
+	  ALLDEPFILES = .....
+
+	When the TAGS rule is parsed TAGFILES_NO_SRCDIR is expanded, which
+	then expands ALLDEPFILES, which, at that point in the Makefile is
+	undefined, and so expands to the empty string.  As a result TAGS does
+	not depend on any file listed in ALLDEPFILES.
+
+	However, when the TAGS recipe is invoked ALLDEPFILES is now defined.
+	As a result, all the files in ALLDEPFILES are passed to the etags
+	program.
+
+	The ALLDEPFILES references three files, arm.c, arm-get-next-pcs.c, and
+	arm-linux.c, which are actually in the gdb/arch/ directory, but, in
+	ALLDEPFILES these files don't include the arch/ prefix.  As a result,
+	the etags program ends up looking for these files in the wrong
+	location.
+
+	As ALLDEPFILES is only used by the TAGS rule, this mistake was not
+	previously noticed (the TAGS rule itself was broken until a recent
+	commit).
+
+	In this commit I make two changes, first, I move ALLDEPFILES to be
+	defined before TAGFILES_NO_SRCDIR, this means that the TAGS rule will
+	depend on all the files in ALLDEPFILES.  With this change the TAGS
+	rule now breaks complaining that there's no rule to build the 3 files
+	mentioned above.
+
+	Next, I have added all *.c files in gdb/arch/ to ALLDEPFILES,
+	including their arch/ prefix, and removed the incorrect (missing arch/
+	prefix) references.
+
+	With these two changes the TAGS (or tags if you prefer) target now
+	builds without any errors or warnings.
+
+2022-04-03  Reuben Thomas  <rrt@sc3d.org>
+
+	gdb/Makefile.in: fix 'make tags' build target
+	The gdb_select.h file was moved to the gdbsupport directory long ago,
+	but a reference was accident left in gdb/Makefile.in (in the
+	HFILES_NO_SRCDIR variable), this commit removes that reference.
+
+	Before this commit, if I use 'make tags' here's what I see:
+
+	  $ make tags
+	  make: *** No rule to make target 'gdb_select.h', needed by 'TAGS'.  Stop.
+
+	After this commit 'make tags' completes, but I still see these
+	warnings:
+
+	  ../../src/gdb/arm.c: No such file or directory
+	  ../../src/gdb/arm-get-next-pcs.c: No such file or directory
+	  ../../src/gdb/arm-linux.c: No such file or directory
+
+	These are caused by a separate issue, and will be addressed in the
+	next commit.
+
+2022-04-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/Makefile.in: remove SOURCES variable
+	The SOURCES variable was added to gdb/Makefile.in as part of commit:
+
+	  commit fb40c20903110ed8af9701ce7c2635abd3770d52
+	  Date:   Wed Feb 23 00:25:43 2000 +0000
+
+	      Add mi/ and testsuite/gdb.mi/ subdirectories.
+
+	But as far as I can tell was not used at the time it was added, and is
+	not used today.
+
+	Lets remove it.
+
+2022-04-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/tui: fair split of delta after a resize
+	Currently, in master gdb, when a tui window is changed in size, the
+	screen delta is mostly just added to the next available window.  We
+	do take care to respect the min/max size, but in most cases, these
+	limits are just "the terminal size", and so, we end up placing the
+	whole delta on the next window.
+
+	Consider these steps in an 80 column, 24 line terminal:
+
+	  (gdb) tui enable
+	  (gdb) layout src
+	  (gdb) layout split
+	  (gdb) info win
+	  Name       Lines Columns Focus
+	  src            8      80 (has focus)
+	  asm            8      80
+	  status         1      80
+	  cmd            8      80
+	  (gdb) winheight cmd +2
+	  (gdb) info win
+	  Name       Lines Columns Focus
+	  src            6      80 (has focus)
+	  asm            8      80
+	  status         1      80
+	  cmd           10      80
+
+	Notice that initially, the windows were balanced, 8 lines each for the
+	major windows.  Then, when the cmd window was adjusted, the extra two
+	lines were given to the asm window.
+
+	I think it would be nicer if the delta was spread more evenly over the
+	available windows.  In the example above, after the adjustment the
+	layout now looks like:
+
+	  (gdb) info win
+	  Name       Lines Columns Focus
+	  src            7      80 (has focus)
+	  asm            7      80
+	  status         1      80
+	  cmd           10      80
+
+	This is achieved within tui_layout_split::set_size, by just handing
+	out the delta in increments of 1 to each window (except for the window
+	the user adjusted), until there's no more delta left.  Of course, we
+	continue to respect the min/max window sizes.
+
+2022-04-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/tui: relax restrictions on window max height and width
+	This commit removes some arbitrary adjustments made in
+	tui_cmd_window::max_height, tui_win_info::max_height, and
+	tui_win_info::max_width.
+
+	These member functions all subtract some constant from the theoretical
+	maximum height or width.  I've looked back through the history a
+	little and can see no real reason why these adjustments should be
+	needed, with these adjustments removed all the existing tui tests
+	still pass.
+
+	However, retaining these restrictions causes some bugs, consider:
+
+	  (gdb) tui new-layout hsrc {-horizontal src 1 cmd 1} 1
+
+	When this layout is selected with current master, gdb will leave a 4
+	line gap at the bottom of the terminal.
+
+	The problem is that the maximum height is restricted, for the cmd
+	window, to 4 less than the terminal height.
+
+	By removing this restriction gdb is able to size the windows to the
+	complete terminal height, and the layout is done correctly.
+
+	This 4 line restriction is also what prevents this layout from working
+	correctly:
+
+	  (gdb) tui new-layout conly cmd 1
+
+	Previously, this layout would present a cmd window only, but there
+	would be a 4 line gap at the bottom of the terminal.  This issue was
+	mentioned in an earlier commit in this series (when a different bug
+	was fixed), but with this commit, the above layout now correctly fills
+	the terminal.  The associated test is updated.
+
+	After removing the adjustment in tui_cmd_window::max_height, the
+	implementation is now the same as the implementation in the parent
+	class tui_win_info, so I've completely removed the max_height call
+	from tui_cmd_window.
+
+2022-04-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: some additional tests in gdb.tui/scroll.exp
+	This commit just adds an extra check of the src window size prior to
+	sending all the commands to gdb.  We also set the cmd window height to
+	its existing height, this (obviously) shouldn't change the window
+	layout, which we check.
+
+	My main motivation was adding the initial window layout check, the
+	winheight and recheck are just extras.  All of these test pass both
+	before and after this commit.
+
+2022-04-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/tui: support placing the cmd window into a horizontal layout
+	This commit allows the user to place the cmd window within horizontal
+	tui layouts.  Consider this set of steps, carried out in an 80 columns
+	by 24 lines terminal, using current master gdb:
+
+	  (gdb) tui new-layout hsrc { -horizontal src 1 cmd 1 } 1 status 1
+	  (gdb) tui layout hsrc
+
+	What you end up with is a full width cmd window with the status bar
+	beneath.  Where's the src window gone?  We then try:
+
+	  (gdb) info win
+	  Name       Lines Columns Focus
+	  src           23       3 (has focus)
+	  cmd           23      80
+	  status         1      80
+	  (gdb)
+
+	Something weird has gone on, gdb has overlapped the cmd window with
+	the src window.  If we trigger the src window to redraw is content,
+	for example, 'list main', then we see corruption in the cmd window as
+	the src window overwrites it.
+
+	So, what's going on?
+
+	The problem is some code in tui_layout_split::apply, in tui-layout.c.
+	Within 'Step 1', there is a loop that calculates the min/max window
+	sizes for all windows within a tui_layout_split.  However, there's a
+	special case for the cmd window.
+
+	This special case is trying to have the cmd window retain its current
+	size when a layout is re-applied, or a new layout is applied.  This
+	makes sense, consider moving from the 'src' layout to the 'asm'
+	layout, this looks something like this (status window removed):
+
+	    .-------.         .-------.
+	    |  src  |         |  asm  |
+	    |-------|  ====>  |-------|
+	    |  cmd  |         |  cmd  |
+	    '-------'         '-------'
+
+	If the user has gone to the effort of adjusting the cmd window size,
+	then, the thinking goes, we shouldn't reset the cmd window size when
+	switching layouts like this.
+
+	The problem though, is that when we do a switch more like this:
+
+	    .-----------.         .-----------.
+	    |    src    |         |     |     |
+	    |-----------|  ====>  | asm | cmd |
+	    |    cmd    |         |     |     |
+	    '-----------'         '-----------'
+
+	Now retaining the cmd window width makes no sense; the new layout has
+	a completely different placement for the cmd window, instead of sizing
+	by height, we're now sizing by width.  The existing code doesn't
+	understand this though, and tried to retain the full width for the cmd
+	window.
+
+	To solve this problem, I propose we introduce the idea of a layout
+	"fingerprint".  The fingerprint tries to capture, in an abstract way,
+	where the cmd window lives within the layout.
+
+	Only when two layouts have the same fingerprint will we attempt to
+	retain the cmd window size.
+
+	The fingerprint for a layout is represented as a string, the string is
+	a series of 'V' or 'H' characters, ending with a single 'C'
+	character.  The series of 'V' and 'H' characters represent the
+	vertical or horizontal layouts that must be passed through to find the
+	cmd window.
+
+	Here are a few examples:
+
+	  # This layout is equivalent to the builtin 'src' layout.
+	  # Fingerprint: VC
+	  tui new-layout example1 src 2 status 0 cmd 1
+
+	  # This layout is equivalent to the builtin 'split' layout.
+	  # Fingerprint: VC
+	  tui new-layout example2 src 1 asm 1 status 0 cmd 1
+
+	  # This is the same layout that was given at the top.
+	  # Fingerprint: VHC
+	  tui new-layout hsrc { -horizontal src 1 cmd 1 } 1 status 1
+
+	And so, when switching between example1 and example2, gdb knows that
+	the cmd window is, basically, in the same sort of position within the
+	layout, and will retain the cmd window size.
+
+	In contrast, when switching to the hsrc layout, gdb understands that
+	the position of the cmd window is different, and does not try to
+	retain the cmd window size.
+
+2022-04-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/tui: allow cmd window to change size in tui_layout_split::apply
+	When we switch layouts we call the tui_layout_split::apply member
+	function to reapply the layout, and recalculate all the window sizes.
+
+	One special case is the cmd window, which we try to keep at its
+	existing size.
+
+	However, in some cases it is not appropriate to keep the cmd window at
+	its existing size.  I will describe two such cases here, in one, we
+	want the cmd window to reduce in size, and in the other, we want the
+	cmd window to grow in size.
+
+	Try these steps in a 80 columns, by 24 lines terminal:
+
+	  (gdb) tui enable
+	  (gdb) layout src
+	  (gdb) winheight cmd 20
+	  (gdb) layout split
+
+	You should see that the status window is missing from the new layout,
+	and that the cmd window has been placed over the border of the asm
+	window.  The 'info win' output is:
+
+	  (gdb) info win
+	  Name       Lines Columns Focus
+	  src            3      80 (has focus)
+	  asm            3      80
+	  status         1      80
+	  cmd           20      80
+
+	Notice that gdb has assigned 27 lines of screen space, even with the
+	border overlap between the src and asm windows, this is still 2 lines
+	too many.
+
+	The problem here is that after switching layouts, gdb has forced the
+	cmd window to retain its 20 line height.  Really, we want the cmd
+	window to reduce in height so that the src and asm windows can occupy
+	their minimum required space.
+
+	This commit allows this (details on how are below).  After this
+	commit, in the above situation, we now see the status window displayed
+	correctly, and the 'info win' output is:
+
+	  (gdb) info win
+	  Name       Lines Columns Focus
+	  src            3      80 (has focus)
+	  asm            3      80
+	  status         1      80
+	  cmd           18      80
+
+	The cmd window has been reduced in size by 2 lines so that everything
+	can fit on the screen.
+
+	The second example is one which was discussed in a recent commit,
+	consider this case (still in the 80 column, 24 line terminal):
+
+	  (gdb) tui enable
+	  (gdb) tui new-layout conly cmd 1
+	  (gdb) layout conly
+	  (gdb) info win
+	  Name       Lines Columns Focus
+	  cmd            8      80 (has focus)
+	  (gdb)
+
+	This layout only contains a cmd window, which we would expect to
+	occupy the entire terminal.  But instead, the cmd window only occupies
+	the first 8 lines, and the rest of the terminal is unused!
+
+	The reason is, again, that the cmd window is keeping its previous
+	size (8 lines).
+
+	After this commit things are slightly different, the 'info win' output
+	is now:
+
+	  (gdb) info win
+	  Name       Lines Columns Focus
+	  cmd           20      80 (has focus)
+
+	Which is a little better, but why only 20 lines?  Turns out there's
+	yet another bug hitting this case.  That bug will be addressed in a
+	later commit, so, for now, we're accepting the 20 lines.
+
+	What this commit does is modify the phase of tui_layout_split::apply
+	that handles any left over space.  Usually, in "Step 2", each
+	sub-layout has a size calculated.  As the size is an integer, then,
+	when all sizes are calculated we may have some space left over.
+
+	This extra space is then distributed between all the windows fairly
+	until all the space is used up.
+
+	When we consider windows minimum size, or fixed size windows, then it
+	is possible that we might try to use more space than is available,
+	this was our first example above.  The same code that added extra
+	space to the windows, can also be used to reclaim space (in the over
+	allocation case) to allow all windows to fit.
+
+	The problem then is the cmd window, which we often force to a fixed
+	size.  Inside the loop that handles the allocation of excess space, if
+	we find that we have tried every window, and still have space either
+	left to give, or we need to claim back more space, then, if the cmd
+	window was changed to a fixed size, we can change the cmd window back
+	to a non-fixed-size window, and proceed to either give, or take space
+	from the cmd window as needed.
+
+2022-04-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/tui: fairer distribution of excess space during apply
+	When applying layouts gdb computes the size of each window (or rather,
+	each sub-layout within a layout) using integer arithmetic.  As this
+	rounds down the results, then, when all sub-layouts are sized, there
+	is the possibility that we have some space left over.
+
+	Currently, this space is just assigned to an arbitrary sub-layout.
+
+	This can result in some unbalanced results.  Consider this set of
+	steps with current master:
+
+	  (gdb) tui enable
+	  (gdb) layout regs
+	  (gdb) info win
+	  Name       Lines Columns Focus
+	  regs           7      80
+	  src            9      80 (has focus)
+	  status         1      80
+	  cmd            8      80
+
+	Notice the weird split between the src and regs windows, the original
+	layout specification has these windows given equal weight.  The
+	problem is that, with rounding, both the regs and src windows are
+	initially sized to 7, the extra 2 lines are then arbitrarily added to
+	the src window.
+
+	In this commit, rather than add all the extra space to one single
+	window, I instead hand out the extra space 1 line at a time, looping
+	over all the sub-layouts.  We take care to respect the min/max sizes,
+	and so, we now get this result:
+
+	  (gdb) tui enable
+	  (gdb) layout regs
+	  (gdb) info win
+	  Name       Lines Columns Focus
+	  regs           8      80
+	  src            8      80 (has focus)
+	  status         1      80
+	  cmd            8      80
+
+	This looks more natural to me.
+
+	This is obviously a change in behaviour, and so, lots of the existing
+	tests need to be updated to take this into account.  None of the
+	changes are huge, it's just a line or two (or column for width) moved
+	between windows.
+
+2022-04-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/tui: avoid fp exception when applying layouts
+	Consider:
+
+	  (gdb) tui enable
+	  (gdb) layout src
+	  (gdb) tui new-layout conly cmd 1
+	  (gdb) layout conly
+
+	After this, with current master, gdb crashes with a floating-point
+	exception.
+
+	The problem is that in tui_layout_split::apply, when we switch from
+	'src' to 'conly', we will try to retain the cmd window height.  As
+	such, the cmd window will become a fixed size window, which decreases
+	the available_size, but doesn't count towards the total_weight.
+
+	As the cmd window is the only window, the total_weight stays at zero,
+	and, when we move into step 2, where we attempt to size the windows,
+	we perform a divide by zero, and crash.
+
+	After this commit we avoid the divide by zero, and just directly set
+	the window size based on the fixed size.
+
+	There is still a problem after this commit, when the conly layout is
+	selected the cmd window retains its original height, which will only
+	be part of the terminal.  The rest of the terminal is left unused.
+	This issue will be addressed in a later commit, this commit is just
+	about the floating-point exception.
+
+2022-04-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/tui/testsuite: refactor new-layout.exp test
+	This commit changes the gdb.tui/new-layout.exp test to make use of a
+	list of test descriptions, and a loop to check each description in
+	turn.  There's no change to what is actually tested after this commit.
+
+	In future commits I plan to add additional tests to this file, and
+	this will be easier now that all I have to do is add a new test
+	description to the list.
+
+2022-04-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/tui: add left_boxed_p and right_boxed_p member functions
+	When I initially saw this code in tui_layout_split::apply, I assumed
+	that this must be a bug:
+
+	    /* Two adjacent boxed windows will share a border, making a bit
+	       more size available.  */
+	    if (i > 0
+	        && m_splits[i - 1].layout->bottom_boxed_p ()
+	        && m_splits[i].layout->top_boxed_p ())
+	      ...
+
+	After all, the apply might be laying out a horizontal layout, right?
+	So checking bottom_boxed_p and top_boxed_p is clearly wrong.
+
+	Well, it turns on, that due to the implementations of these things,
+	bottom_boxed_p is equivalent to an imagined right_boxed_p, and
+	top_boxed_p is equivalent to an imagined left_boxed_p.
+
+	In this commit I've renamed both top_boxed_p and bottom_boxed_p to
+	first_edge_has_border_p and last_edge_has_border_p respectively, and
+	extended the comments in tui_layout_base to mention that these methods
+	handle both horizontal and vertical layouts.
+
+	Now, hopefully, the code shouldn't look like it only applies for
+	vertical layouts.
+
+	There should be no user visible changes after this commit.
+
+2022-04-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/tui: add a tui debugging flag
+	This commit adds 'set debug tui on|off' and 'show debug tui'.  This
+	commit adds the control variable, and the printing macros in
+	tui/tui.h.  I've then added some uses of these in tui.c and
+	tui-layout.c.
+
+	To help produce more useful debug output in tui-layout.c, I've added
+	some helper member functions in the class tui_layout_split, and also
+	moved the size_info struct out of tui_layout_split::apply into the
+	tui_layout_split class.
+
+	If tui debug is not turned on, then there should be no user visible
+	changes after this commit.
+
+	One thing to note is that, due to the way that the tui terminal is
+	often cleared, the only way I've found this useful is when I do:
+
+	  (gdb) tui enable
+	  (gdb) set logging file /path/to/file
+	  (gdb) set logging debugredirect on
+	  (gdb) set logging enable on
+
+	Additionally, gdb has some quirks when it comes to setting up logging
+	redirect and switching interpreters.  Thus, the above only really
+	works if the logging is enabled after the tui is enabled, and disabled
+	again before the tui is disabled.
+
+	Enabling logging and switching interpreters can cause undefined
+	results, including crashes.  This is an existing bug in gdb[1], and
+	has nothing directly to do with tui debug, but it is worth mentioning
+	here I think.
+
+	[1] https://sourceware.org/bugzilla/show_bug.cgi?id=28948
+
+2022-04-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/tui: add new 'tui window width' command and 'winwidth' alias
+	This commit adds a new command 'tui window width', and an alias
+	'winwidth'.  This command is equivalent to the old 'winheight'
+	command (which was recently renamed 'tui window height').
+
+	Even though I recently moved the old tui commands under the tui
+	namespace, and I would strongly encourage all new tui commands to be
+	added as 'tui ....' only (users can create their own top-level aliases
+	if they want), I'm breaking that suggestion here, and adding a
+	'winwidth' alias.
+
+	Given that we already have 'winheight' and have done for years, it
+	just didn't seem right to no have the matching 'winwidth'.
+
+	You might notice in the test that the window resizing doesn't quite
+	work right.  I setup a horizontal layout, then grow and shrink the
+	windows.  At the end of the test the windows should be back to their
+	original size...
+
+	... they are not.  This isn't my fault, honest!  GDB's window resizing
+	is a little ... temperamental, and is prone to getting things slightly
+	wrong during resizes, off by 1 type things.  This is true for height
+	resizing, as well as the new width resizing.
+
+	Later patches in this series will rework the resizing algorithm, which
+	should improve things in this area.  For now, I'm happy that the width
+	resizing is as good as the height resizing, given the existing quirks.
+
+	For the docs side I include a paragraph that explains how multiple
+	windows are required before the width can be adjusted.  For
+	completeness, I've added the same paragraph to the winheight
+	description.  With the predefined layouts this extra paragraph is not
+	really needed for winheight, as there are always multiple windows on
+	the screen.  However, with custom layouts, this might not be true, so
+	adding the paragraph seems like a good idea.
+
+	As for the changes in gdb itself, I've mostly just taken the existing
+	height adjustment code, changed the name to make it generic 'size'
+	adjustment, and added a boolean flag to indicate if we are adjusting
+	the width or the height.
+
+2022-04-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/tui: rename tui_layout_split:set_weights_from_heights
+	In a following commit I'm going to add the ability to change the width
+	of a tui window (when in a horizontal layout).  As a result, some of
+	the places where we currently hard-code references to height need to
+	be changed to handle either height, or width, based on whether we are
+	in a vertical, or horizontal layout.
+
+	This commit renames set_weights_from_heights to
+	set_weights_from_sizes, and makes the function use either the height,
+	or width as appropriate.
+
+	Currently, the only place that we call this function is from the
+	tui_layout_split::set_height function, in a part of the code we will
+	only reach for vertical layouts, so the new code is not actually being
+	used, but, this small change will help make later patches smaller, so
+	I'm proposing this as a stand alone change.
+
+	There should be no user visible changes after this commit.
+
+2022-04-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/tui: rename tui_layout_base::adjust_size to ::set_height
+	Rename tui_layout_base::adjust_size to tui_layout_base::set_height,
+	the new name more accurately reflects what this member function does,
+	and makes it easier for a later commit to add a new
+	tui_layout_base::set_width member function.
+
+	There should be no user visible changes after this commit.
+
+2022-04-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: move some commands into the tui namespace
+	There are a lot of tui related commands that live in the top-level
+	command name space, e.g. layout, focus, refresh, winheight.
+
+	Having them at the top level means less typing for the user, which is
+	good, but, I think, makes command discovery harder.
+
+	In this commit, I propose moving all of the above mentioned commands
+	into the tui namespace, so 'layout' becomes 'tui layout', etc.  But I
+	will then add aliases so that the old commands will still work,
+	e.g. I'll make 'layout' an alias for 'tui layout'.
+
+	The benefit I see in this work is that tui related commands can be
+	more easily discovered by typing 'tui ' and then tab-completing.  Also
+	the "official" command is now a tui-sub-command, this is visible in,
+	for example, the help output, e.g.:
+
+	  (gdb) help layout
+	  tui layout, layout
+	  Change the layout of windows.
+	  Usage: tui layout prev | next | LAYOUT-NAME
+
+	  List of tui layout subcommands:
+
+	  tui layout asm -- Apply the "asm" layout.
+	  tui layout next -- Apply the next TUI layout.
+	  tui layout prev -- Apply the previous TUI layout.
+	  tui layout regs -- Apply the TUI register layout.
+	  tui layout split -- Apply the "split" layout.
+	  tui layout src -- Apply the "src" layout.
+
+	Which I think is a good thing, it makes it clearer that this is a tui
+	command.
+
+	I've added a NEWS entry and updated the docs to mention the new and
+	old command names, with the new name being mentioned first.
+
+2022-04-03  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: fix gdb_print -> gdb_printf typo
+	This caused a build failure with !CXX_STD_THREAD.
+
+	Change-Id: I30f0c89c43a76f85c0db34809192644fa64a9d18
+
+2022-04-03  Alan Modra  <amodra@gmail.com>
+
+	Move microblaze relax info to target specific data
+	Target specific data shouldn't be put in struct bfd_section.
+
+		* section.c (struct bfd_section): Delete relax and relax_count.
+		(BFD_FAKE_SECTION): Adjust to suit.
+		(struct relax_table): Move to..
+		* elf32-microblaze.c (struct relax_table): ..here.
+		(struct _microblaze_elf_section_data): New.
+		(microblaze_elf_section_data): Define.
+		(microblaze_elf_new_section_hook): New function.
+		(bfd_elf32_new_section_hook): Define.
+		(calc_fixup): Return a size_t.  Adjust to suit new location of
+		relax and relax_count.
+		(microblaze_elf_relax_section): Adjust to suit new location of
+		relax and relax_count.  Make some variables size_t.
+		* bfd-in2.h: Regenerate.
+
+2022-04-03  Alan Modra  <amodra@gmail.com>
+
+	Revert commit 240d6706c6a2
+		PR 28592
+		PR 15994
+		PR 15935
+		* dwarf2.c (lookup_address_in_line_info_table): Return bool rather
+		than a range.
+		(comp_unit_find_nearest_line): Likewise.  Return true if function
+		info found without line info.
+		(_bfd_dwarf2_find_nearest_line): Revert range handling code.
+
+	Regen bfd po/SRC-POTFILES.in
+
+2022-04-03  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-02  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: rename floatformats_ia64_quad to floatformats_ieee_quad
+	It is better to rename floatformats_ia64_quad to floatformats_ieee_quad
+	to reflect the reality, and then we can clean up the related code.
+
+	As Tom Tromey said [1]:
+
+	  These files are maintained in gcc and then imported into the
+	  binutils-gdb repository, so any changes to them will have to
+	  be proposed there first.
+
+	the related changes have been merged into gcc master now [2], it is time
+	to do it for gdb.
+
+	[1] https://sourceware.org/pipermail/gdb-patches/2022-March/186569.html
+	[2] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b2dff6b2d9d6
+
+2022-04-02  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-04-01  John Baldwin  <jhb@FreeBSD.org>
+
+	Remove unused variable.
+
+2022-04-01  Aaron Merey  <amerey@redhat.com>
+
+	gdb/debuginfod-support.c: Always display debuginfod errors
+	Errors encountered when downloading files from debuginfod servers
+	are not displayed if debuginfod verbosity is set to 0 (via
+	'set debuginfod verbose 0').
+
+	Tom recommended that these errors always be displayed, regardless
+	of the verbosity setting [1]. Fix this.
+
+	[1] https://sourceware.org/pipermail/gdb-patches/2022-March/186350.html
+
+2022-04-01  John Baldwin  <jhb@FreeBSD.org>
+
+	Use I386_GSBASE_REGNUM in i386fbsd_get_thread_local_address.
+	32-bit x86 arches always the I386_*BASE_REGNUM values.  Only code that
+	needs to support both 64-bit and 32-bit arches needs to use
+	tdep->fsbase_regnum to compute a segment base register number.
+
+	FreeBSD/x86: Read segment base registers from NT_X86_SEGBASES.
+	FreeBSD kernels recently grew a new register core dump note containing
+	the base addresses of the %fs and %gs segments (corresponding to the
+	%fsbase and %gsbase registers).  Parse this note to permit inspecting
+	TLS variables in core dumps.  Native processes already supported TLS
+	via older ptrace() operations.
+
+2022-04-01  John Baldwin  <jhb@FreeBSD.org>
+
+	Use pseudosections for NT_FREEBSD_X86_SEGBASES core dump notes.
+	This includes adding pseudosections when reading a core dump as well
+	as support for writing out a core dump note from a pseudosection.
+
+	bfd/ChangeLog:
+
+		* elf-bfd.h (elfcore_write_x86_segbases): New.
+		* elf.c (elfcore_grok_freebsd_note): Add pseudosections for
+		NT_FREEBSD_X86_SEGBASES register notes.
+		(elfcore_write_x86_segbases): New.
+		(elfcore_write_register_note): Write NT_FREEBSD_X86_SEGBASES
+		register notes.
+
+2022-04-01  John Baldwin  <jhb@FreeBSD.org>
+
+	Recognize FreeBSD core dump note for x86 segment base registers.
+	This core dump note contains the value of the base address of the %fs
+	and %gs segments for both i386 and amd64 core dumps.  It is primarily
+	useful in resolving the address of TLS variables in core dumps.
+
+	binutils/ChangeLog:
+
+		* readelf.c (get_freebsd_elfcore_note_type): Handle
+		NT_FREEBSD_X86_SEGBASES.
+
+	include/ChangeLog:
+
+		* elf/common.h (NT_FREEBSD_X86_SEGBASES): Define.
+
+2022-04-01  John Baldwin  <jhb@FreeBSD.org>
+
+	elfcore_grok_freebsd_note: Remove checks of note->namesz.
+	This function is only called if the note name is "FreeBSD", so
+	checking the name size is unnecessary.
+
+	bfd/ChangeLog:
+
+		* elf.c (elfcore_grok_freebsd_note): Remove checks for namesz.
+
+2022-04-01  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testing/tui: add new _csi_{L,S,T}
+	This patch was original part of this series:
+
+	  https://sourceware.org/pipermail/gdb-patches/2022-March/186429.html
+	  https://sourceware.org/pipermail/gdb-patches/2022-March/186433.html
+
+	I've pulled this out as it might be useful ahead of the bigger series
+	being merged.
+
+	This commit adds:
+
+	  _csi_L - insert line
+	  _csi_S - pan down
+	  _csi_T - pan up
+
+2022-04-01  H.J. Lu  <hjl.tools@gmail.com>
+
+	x86: Remove bfd_arch_l1om and bfd_arch_k1om
+	Remove bfd_arch_l1om and bfd_arch_k1om since L1OM/K1OM support has been
+	removed from gas, ld and opcodes.
+
+	bfd/
+
+		* Makefile.am (ALL_MACHINES): Remove cpu-l1om.lo and cpu-k1om.lo.
+		(ALL_MACHINES_CFILES): Remove cpu-l1om.c and cpu-k1om.c.
+		* archures.c (bfd_mach_l1om): Removed.
+		(bfd_mach_l1om_intel_syntax): Likewise.
+		(bfd_mach_k1om): Likewise.
+		(bfd_mach_k1om_intel_syntax): Likewise.
+		(bfd_k1om_arch): Likewise.
+		(bfd_l1om_arch): Likewise.
+		(bfd_archures_list): Remove bfd_k1om_arch and bfd_l1om_arch
+		references.
+		* config.bfd (targ_selvecs): Remove l1om_elf64_vec.
+		l1om_elf64_fbsd_vec, k1om_elf64_vec and k1om_elf64_fbsd_vec.
+		(targ_archs): Remove bfd_l1om_arch and bfd_k1om_arch.
+		* configure.ac (k1om_elf64_vec): Removed.
+		(k1om_elf64_fbsd_vec): Likewise.
+		(l1om_elf64_vec): Likewise.
+		(l1om_elf64_fbsd_vec): Likewise.
+		* cpu-k1om.c: Removed.
+		* cpu-l1om.c: Likewise.
+		* elf64-x86-64.c (elf64_l1om_elf_object_p): Removed.
+		(elf64_k1om_elf_object_p): Likewise.
+		(l1om_elf64_vec): Removed.
+		(l1om_elf64_fbsd_vec): Likewise.
+		(k1om_elf64_vec): Likewise.
+		(k1om_elf64_fbsd_vec): Likewise.
+		(ELF_TARGET_OS): Undefine.
+		* targets.c (_bfd_target_vector): Remove k1om_elf64_vec,
+		k1om_elf64_fbsd_vec, l1om_elf64_vec and l1om_elf64_fbsd_vec.
+		* Makefile.in: Regenerate.
+		* bfd-in2.h: Likewise.
+		* configure: Likewise.
+
+	opcodes/
+
+		* configure.ac: Remove bfd_arch_l1om/bfd_arch_k1om references.
+		* disassemble.c (disassembler): Likewise.
+		* configure: Regenerate.
+
+2022-04-01  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/ctf: pass partial symtab's filename to buildsym_compunit
+	I noticed that the CTF symbol reader passes the objfile's name to all
+	buildsym_compunit instances it creates.  The result is that all
+	compunit_symtabs created have the same name, that of the objfile:
+
+	    { objfile /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct objfile *) 0x613000005d00)
+	      { ((struct compunit_symtab *) 0x621000286760)
+	        debugformat ctf
+	        producer (null)
+	        name libbabeltrace2.so.0.0.0
+	        dirname (null)
+	        blockvector ((struct blockvector *) 0x6210003911d0)
+	        user ((struct compunit_symtab *) (null))
+	            { symtab /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct symtab *) 0x6210003911f0)
+	              fullname (null)
+	              linetable ((struct linetable *) 0x0)
+	            }
+	      }
+	      { ((struct compunit_symtab *) 0x621000275c10)
+	        debugformat ctf
+	        producer (null)
+	        name libbabeltrace2.so.0.0.0
+	        dirname (null)
+	        blockvector ((struct blockvector *) 0x621000286710)
+	        user ((struct compunit_symtab *) (null))
+	            { symtab /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct symtab *) 0x621000286730)
+	              fullname (null)
+	              linetable ((struct linetable *) 0x0)
+	            }
+	      }
+
+	Notice the two "name libbabeltrace2.so.0.0.0".
+
+	Change it to pass the partial_symtab's filename instead.  The output
+	becomes:
+
+	    { objfile /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct objfile *) 0x613000005d00)
+	      { ((struct compunit_symtab *) 0x621000295610)
+	        debugformat ctf
+	        producer (null)
+	        name libbabeltrace2.so.0.0.0
+	        dirname (null)
+	        blockvector ((struct blockvector *) 0x6210003a15d0)
+	        user ((struct compunit_symtab *) (null))
+	            { symtab /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct symtab *) 0x6210003a15f0)
+	              fullname (null)
+	              linetable ((struct linetable *) 0x0)
+	            }
+	      }
+	      { ((struct compunit_symtab *) 0x621000288700)
+	        debugformat ctf
+	        producer (null)
+	        name current-thread.c
+	        dirname (null)
+	        blockvector ((struct blockvector *) 0x6210002955c0)
+	        user ((struct compunit_symtab *) (null))
+	            { symtab /home/simark/src/babeltrace/src/lib/current-thread.c ((struct symtab *) 0x6210002955e0)
+	              fullname (null)
+	              linetable ((struct linetable *) 0x0)
+	            }
+	      }
+
+	Note that the first compunit_symtab still has libbabeltrace2.so.0.0.0 as
+	its name.  This is because the CTF symbol reader really creates a
+	partial symtab named like this.  It appears to be because the debug info
+	contains information that has been factored out of all CUs and is at the
+	"top-level" of the objfile, outside any real CU.  So it creates a
+	partial symtab and an artificial CU that's named after the objfile.
+
+	Change-Id: I576316bab2a3668adf87b4e6cebda900a8159b1b
+
+2022-04-01  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: print compunit_symtab name in "maint info symtabs"
+	I think it would make sense to print a compunit_symtab's name in "maint
+	info symtabs".  If you are looking for a given CU in the list, that's
+	probably the field you will be looking at.  As the doc of
+	compunit_symtab::name says, it is not meant to be a reliable file name,
+	it is for debugging purposes (and "maint info symtabs" exists for
+	debugging purposes).
+
+	Sample output with the new field:
+
+	    (gdb) maintenance info symtabs
+	    { objfile /home/simark/build/binutils-gdb-one-target/gdb/a.out ((struct objfile *) 0x613000005d00)
+	      { ((struct compunit_symtab *) 0x621000131630)
+	        debugformat DWARF 5
+	        producer GNU C17 11.2.0 -mtune=generic -march=x86-64 -g3 -O0
+	        name test.c
+	        dirname /home/simark/build/binutils-gdb-one-target/gdb
+	        blockvector ((struct blockvector *) 0x621000131d10)
+	        user ((struct compunit_symtab *) (null))
+	            { symtab test.c ((struct symtab *) 0x6210001316b0)
+	              fullname (null)
+	              linetable ((struct linetable *) 0x621000131d40)
+	            }
+	            { symtab /home/simark/build/binutils-gdb-one-target/gdb/test.h ((struct symtab *) 0x6210001316e0)
+	              fullname (null)
+	              linetable ((struct linetable *) 0x0)
+	            }
+	            { symtab /usr/include/stdc-predef.h ((struct symtab *) 0x621000131710)
+	              fullname (null)
+	              linetable ((struct linetable *) 0x0)
+	            }
+	      }
+	      { ((struct compunit_symtab *) 0x6210001170a0)
+	        debugformat DWARF 5
+	        producer GNU C17 11.2.0 -mtune=generic -march=x86-64 -g3 -O0
+	        name foo.c
+	        dirname /home/simark/build/binutils-gdb-one-target/gdb
+	        blockvector ((struct blockvector *) 0x621000131580)
+	        user ((struct compunit_symtab *) (null))
+	            { symtab foo.c ((struct symtab *) 0x621000117120)
+	              fullname (null)
+	              linetable ((struct linetable *) 0x6210001315b0)
+	            }
+	            { symtab /usr/include/stdc-predef.h ((struct symtab *) 0x621000117150)
+	              fullname (null)
+	              linetable ((struct linetable *) 0x0)
+	            }
+	      }
+	    }
+
+	Change-Id: I17b87adfac2f6551cb5bda30d59f6c6882789211
+
+2022-04-01  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/ctf: don't create a buildsym_compunit when building partial symbols
+	I am trying to do some changes to buildsym_compunit, so I am auditing
+	the current uses.  Something seems odd with this use of
+	buildsym_compunit (that this patch removes).
+
+	A buildsym_compunit is normally used when building a compunit_symtab.
+	That is, when expanding a partial symtab into a full compunit symtab.
+	In ctfread.c, a buildsym_compunit is created in ctf_start_archive, which
+	is only used when creating partial symtabs.  At this moment, I don't
+	see how that's useful.  ctf_start_archive creates a new
+	buildsym_compunit and starts a subfile.  But that buildsym_compunit is
+	never used again.  It's just overriden in ctf_start_symtab, which means
+	we leak the old buildsym_compunit, I suppose.
+
+	Remove ctf_start_archive completely.  Add an assert in
+	ctf_start_symtab to verify that we are not overwriting an existing
+	buildsym_compunit (meaning we'd leak the existing one).  This assert
+	triggers without the other part of the fix.  When doing:
+
+	  $ ./gdb --data-directory=data-directory /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0
+	  ...
+	  (gdb) maintenance expand-symtabs
+	  /home/simark/src/binutils-gdb/gdb/ctfread.c:1255: internal-error: ctf_start_symtab: Assertion `!ccp->builder' failed.
+
+	Change-Id: I666d146454a019f08e7305f3a1c4a974d27b4592
+
+2022-04-01  Tom Tromey  <tom@tromey.com>
+
+	Style URLs in GDB output
+	I noticed that GDB will display URLs in a few spots.  This changes
+	them to be styled.  Originally I thought I'd introduce a new "url"
+	style, but there aren't many places to use this, so I just reused
+	filename styling instead.  This patch also changes the debuginfod URL
+	list to be printed one URL per line.  I think this is probably a bit
+	easier to read.
+
+2022-04-01  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-31  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: initialize ctf_context::builder in create_partial_symtab
+	I built a random project with -gctf, in order to test the CTF support in
+	GDB.  With my ASan/UBSan/etc-enabled build of GDB, I get:
+
+	    $ ./gdb --data-directory=data-directory /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0
+	    ...
+	    Reading symbols from /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0...
+	    /home/simark/src/binutils-gdb/gdb/ctfread.c:1545:31: runtime error: member call on misaligned address 0xbebebebebebebebe for type 'struct buildsym_compunit', which requires 8 byte alignment
+	    0xbebebebebebebebe: note: pointer points here
+
+	The 0xbebebebebebebebe value is a sign that the ctf_context::builder
+	field is uninitialized.  The problem probably goes under the radar if
+	the field happens to be zero-initialized, because ctf_start_archive
+	contains this code:
+
+	  if (ccx->builder == nullptr)
+	    {
+	      ccx->builder = new buildsym_compunit (of,
+			      of->original_name, nullptr, language_c, 0);
+
+	If the field was zero-initialized (by chance), this will create a new
+	buildsym_compunit.  But if the field was purposely filled with random
+	bytes by one of the sanitizers, we won't create a buildsym_compunit here
+	and we'll continue with ccx->builder equal to 0xbebebebebebebebe.
+
+	Fix this the easy way by initializing ccx->builder where the other
+	ctf_context fields are initialized (yeah, this code could be made nicer
+	C++, but I am going for the obvious fix here).
+
+	With this patch, this passes cleanly on my system:
+
+	  $ make check TESTS="gdb.ctf/*.exp" RUNTESTFLAGS="CC_FOR_TARGET=/opt/gcc/git/bin/gcc"
+	  # of expected passes            40
+
+	... where /opt/gcc/git/bin/gcc is a gcc with CTF support, given my
+	system gcc does not have it.
+
+	Change-Id: Idea1b0cf3e3708b72ecb16b1b60222439160f9b9
+
+2022-03-31  Tom Tromey  <tromey@adacore.com>
+
+	Remove dbx mode
+	This patch removes gdb's dbx mode.  Regression tested on x86-64 Fedora
+	34.
+
+2022-03-31  H.J. Lu  <hjl.tools@gmail.com>
+
+	gdb: Consolidate 32bit-pkeys.xml and 64bit-pkeys.xml
+	1. Since 32bit-pkeys.xml and 64bit-pkeys.xml are identical, consolidate
+	them into a single keys.xml.
+	2. Enable PKU for x32 to fix:
+
+	$ gdbserver :123456 x32-program
+	...
+	.../gdbserver/regcache.cc:255: A problem internal to GDBserver has been detected
+	.
+	Unknown register pkru requested
+
+	on Tiger Lake.
+
+2022-03-31  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/linux-nat: remove check based on current_inferior in linux_handle_extended_wait
+	The check removed by this patch, using current_inferior, looks wrong.
+	When debugging multiple inferiors with the Linux native target and
+	linux_handle_extended_wait is called, there's no guarantee about which
+	is the current inferior.  The vfork-done event we receive could be for
+	any inferior.  If the vfork-done event is for a non-current inferior, we
+	end up wrongfully ignoring it.  As a result, the core never processes a
+	TARGET_WAITKIND_VFORK_DONE event, program_space::breakpoints_not_allowed
+	is never cleared, and breakpoints are never reinserted.  However,
+	because the Linux native target decided to ignore the event, it resumed
+	the thread - while breakpoints out.  And that's bad.
+
+	The proposed fix is to remove this check.  Always report vfork-done
+	events and let infrun's logic decide if it should be ignored.  We don't
+	save much cycles by filtering the event here.
+
+	Add a test that replicates the situation described above.  See comments
+	in the test for more details.
+
+	Change-Id: Ibe33c1716c3602e847be6c2093120696f2286fbf
+
+2022-03-31  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdbserver/linux: set lwp !stopped when failing to resume
+	I see some failures, at least in gdb.multi/multi-re-run.exp and
+	gdb.threads/interrupted-hand-call.exp.  Running `stress -C $(nproc)` at
+	the same time as the test makes those tests relatively frequent.
+
+	Let's take gdb.multi/multi-re-run.exp as an example.  The failure looks
+	like this, an unexpected "no resumed":
+
+	    continue
+	    Continuing.
+	    No unwaited-for children left.
+	    (gdb) FAIL: gdb.multi/multi-re-run.exp: re_run_inf=2: iter=1: continue until exit
+
+	The situation is:
+
+	 - Inferior 1 is stopped somewhere, it won't really play a role here.
+	 - Inferior 2 has 2 threads, both stopped.
+	 - We resume inferior 2, the leader thread is expected to exit, making
+	   the process exit.
+
+	From GDB's perspective, a failing run looks like this:
+
+	    [infrun] fetch_inferior_event: enter
+	      [infrun] scoped_disable_commit_resumed: reason=handling event
+	      [infrun] do_target_wait: Found 2 inferiors, starting at #1
+	      [infrun] random_pending_event_thread: None found.
+	      [remote] wait: enter
+	        [remote] Packet received: T0506:20dcffffff7f0000;07:20dcffffff7f0000;10:9551555555550000;thread:pae4cd.ae4cd;core:e;
+	      [remote] wait: exit
+	      [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
+	      [infrun] print_target_wait_results:   713933.713933.0 [Thread 713933.713933],
+	      [infrun] print_target_wait_results:   status->kind = STOPPED, sig = GDB_SIGNAL_TRAP
+	      [infrun] handle_inferior_event: status->kind = STOPPED, sig = GDB_SIGNAL_TRAP
+	      [infrun] clear_step_over_info: clearing step over info
+	      [infrun] context_switch: Switching context from 0.0.0 to 713933.713933.0
+	      [infrun] handle_signal_stop: stop_pc=0x555555555195
+	      [infrun] start_step_over: enter
+	        [infrun] start_step_over: stealing global queue of threads to step, length = 0
+	        [infrun] operator(): step-over queue now empty
+	      [infrun] start_step_over: exit
+	      [infrun] process_event_stop_test: no stepping, continue
+	      [remote] Sending packet: $Z0,555555555194,1#8e
+	      [remote] Packet received: OK
+	      [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [713933.713933.0] at 0x555555555195
+	      [remote] Sending packet: $QPassSignals:e;10;14;17;1a;1b;1c;21;24;25;2c;4c;97;#0a
+	      [remote] Packet received: OK
+	      [remote] Sending packet: $vCont;c:pae4cd.-1#9f
+	      [infrun] prepare_to_wait: prepare_to_wait
+	      [infrun] reset: reason=handling event
+	      [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote
+	      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
+	      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
+	    [infrun] fetch_inferior_event: exit
+	    [infrun] fetch_inferior_event: enter
+	      [infrun] scoped_disable_commit_resumed: reason=handling event
+	      [infrun] do_target_wait: Found 2 inferiors, starting at #0
+	      [infrun] random_pending_event_thread: None found.
+	      [remote] wait: enter
+	        [remote] Packet received: N
+	      [remote] wait: exit
+	      [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
+	      [infrun] print_target_wait_results:   -1.0.0 [process -1],
+	      [infrun] print_target_wait_results:   status->kind = NO_RESUMED
+	      [infrun] handle_inferior_event: status->kind = NO_RESUMED
+	      [remote] Sending packet: $Hgp0.0#ad
+	      [remote] Packet received: OK
+	      [remote] Sending packet: $qXfer:threads:read::0,1000#92
+	      [remote] Packet received: l<threads>\n<thread id="pae4cb.ae4cb" core="3" name="multi-re-run-1" handle="40c7c6f7ff7f0000"/>\n<thread id="pae4cb.ae4cc" core="2" name="multi-re-run-1" handle="40b6c6f7ff7f0000"/>\n<thread id="pae4cd.ae4ce" core="1" name="multi-re-run-2" handle="40b6c6f7ff7f0000"/>\n</threads>\n
+	      [infrun] stop_waiting: stop_waiting
+	      [remote] Sending packet: $qXfer:threads:read::0,1000#92
+	      [remote] Packet received: l<threads>\n<thread id="pae4cb.ae4cb" core="3" name="multi-re-run-1" handle="40c7c6f7ff7f0000"/>\n<thread id="pae4cb.ae4cc" core="2" name="multi-re-run-1" handle="40b6c6f7ff7f0000"/>\n<thread id="pae4cd.ae4ce" core="1" name="multi-re-run-2" handle="40b6c6f7ff7f0000"/>\n</threads>\n
+	      [infrun] infrun_async: enable=0
+	      [infrun] reset: reason=handling event
+	      [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote
+	      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
+	      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
+	    [infrun] fetch_inferior_event: exit
+
+	We can see that we resume the inferior with vCont;c, but got NO_RESUMED.
+	When the test passes, we get an EXITED status to indicate the process
+	has exited.
+
+	From GDBserver's point of view, it looks like this.  The logs contain
+	some logging I added and that are part of this patch.
+
+	    [remote] getpkt: getpkt ("vCont;c:pae4cf.-1");  [no ack sent]
+	    [threads] resume: enter
+	      [threads] thread_needs_step_over: Need step over [LWP 713931]? Ignoring, should remain stopped
+	      [threads] thread_needs_step_over: Need step over [LWP 713932]? Ignoring, should remain stopped
+	      [threads] get_pc: pc is 0x555555555195
+	      [threads] thread_needs_step_over: Need step over [LWP 713935]? No, no breakpoint found at 0x555555555195
+	      [threads] get_pc: pc is 0x7ffff7d35a95
+	      [threads] thread_needs_step_over: Need step over [LWP 713936]? No, no breakpoint found at 0x7ffff7d35a95
+	      [threads] resume: Resuming, no pending status or step over needed
+	      [threads] resume_one_thread: resuming LWP 713935
+	      [threads] proceed_one_lwp: lwp 713935
+	      [threads] resume_one_lwp_throw:   continue from pc 0x555555555195
+	      [threads] resume_one_lwp_throw: Resuming lwp 713935 (continue, signal 0, stop not expected)
+	      [threads] resume_one_lwp_throw: NOW ptid=713935.713935.0 stopped=0 resumed=0
+	      [threads] resume_one_thread: resuming LWP 713936
+	      [threads] proceed_one_lwp: lwp 713936
+	      [threads] resume_one_lwp_throw:   continue from pc 0x7ffff7d35a95
+	      [threads] resume_one_lwp_throw: Resuming lwp 713936 (continue, signal 0, stop not expected)
+	      [threads] resume_one_lwp_throw: ptrace errno = 3 (No such process)
+	    [threads] resume: exit
+	    [threads] wait_1: enter
+	      [threads] wait_1: [<all threads>]
+	      [threads] wait_for_event_filtered: waitpid(-1, ...) returned 0, ERRNO-OK
+	      [threads] resume_stopped_resumed_lwps: resuming stopped-resumed LWP LWP 713935.713936 at 7ffff7d35a95: step=0
+	      [threads] resume_one_lwp_throw:   continue from pc 0x7ffff7d35a95
+	      [threads] resume_one_lwp_throw: Resuming lwp 713936 (continue, signal 0, stop not expected)
+	      [threads] resume_one_lwp_throw: ptrace errno = 3 (No such process)
+	      [threads] operator(): check_zombie_leaders: leader_pid=713931, leader_lp!=NULL=1, num_lwps=2, zombie=0
+	      [threads] operator(): check_zombie_leaders: leader_pid=713935, leader_lp!=NULL=1, num_lwps=2, zombie=1
+	      [threads] operator(): Thread group leader 713935 zombie (it exited, or another thread execd).
+	      [threads] delete_lwp: deleting 713935
+	      [threads] wait_for_event_filtered: exit (no unwaited-for LWP)
+	    sigchld_handler
+	      [threads] wait_1: ret = null_ptid, TARGET_WAITKIND_NO_RESUMED
+	    [threads] wait_1: exit
+
+	What happens is:
+
+	 - We resume the leader (713935) successfully.
+	 - The leader exits.
+	 - We resume the secondary thread (713936), we get ESRCH.  This is
+	   expected this the leader has exited.
+	 - resume_one_lwp_throw throws, it's caught by resume_one_lwp.
+	 - resume_one_lwp checks with check_ptrace_stopped_lwp_gone that the
+	   failure can be explained by the LWP becoming zombie, and swallows the
+	   error.
+	 - Note that this means that the secondary lwp still has stopped==1.
+	 - wait_1 is called, probably because linux_process_target::resume marks
+	   the async pipe at the end.
+	 - The exit event isn't ready yet, probably because the machine is under
+	   load, so waitpid returns nothing.
+	 - check_zombie_leaders detects that the leader is zombie and deletes
+	 - We try to find a resumed (non-stopped) LWP to get an event from,
+	   there's none since the leader (that was resumed) is now deleted, and
+	   the secondary thread is still marked stopped.
+	   wait_for_event_filtered returns -1, causing wait_1 to return
+	   NO_RESUMED.
+
+	What I notice here is that there is some kind of race between the
+	availability of the process' exit notification and the call to wait_1
+	that results from marking the async pipe at the end of resume.
+
+	I think what we want from this wait_1 invocation is to keep waiting, as
+	we will eventually get thread exit notifications for both of our
+	threads.
+
+	The fix I came up with is to mark the secondary thread as !stopped (or
+	resumed) when we fail to resume it.  This makes wait_1 see that there is
+	at least one resume lwp, so it won't return NO_RESUMED.  I think this
+	makes sense to consider it resumed, because we are going to receive an
+	exit event for it.  Here's the GDBserver logs with the fix applied:
+
+	    [threads] resume: enter
+	      [threads] thread_needs_step_over: Need step over [LWP 724595]? Ignoring, should remain stopped
+	      [threads] thread_needs_step_over: Need step over [LWP 724596]? Ignoring, should remain stopped
+	      [threads] get_pc: pc is 0x555555555195
+	      [threads] thread_needs_step_over: Need step over [LWP 724597]? No, no breakpoint found at 0x555555555195
+	      [threads] get_pc: pc is 0x7ffff7d35a95
+	      [threads] thread_needs_step_over: Need step over [LWP 724598]? No, no breakpoint found at 0x7ffff7d35a95
+	      [threads] resume: Resuming, no pending status or step over needed
+	      [threads] resume_one_thread: resuming LWP 724597
+	      [threads] proceed_one_lwp: lwp 724597
+	      [threads] resume_one_lwp_throw:   continue from pc 0x555555555195
+	      [threads] resume_one_lwp_throw: Resuming lwp 724597 (continue, signal 0, stop not expected)
+	      [threads] resume_one_lwp_throw: NOW ptid=724597.724597.0 stopped=0 resumed=0
+	      [threads] resume_one_thread: resuming LWP 724598
+	      [threads] proceed_one_lwp: lwp 724598
+	      [threads] resume_one_lwp_throw:   continue from pc 0x7ffff7d35a95
+	      [threads] resume_one_lwp_throw: Resuming lwp 724598 (continue, signal 0, stop not expected)
+	      [threads] resume_one_lwp_throw: ptrace errno = 3 (No such process)
+	    [threads] resume: exit
+	    [threads] wait_1: enter
+	      [threads] wait_1: [<all threads>]
+	    sigchld_handler
+	      [threads] wait_for_event_filtered: waitpid(-1, ...) returned 0, ERRNO-OK
+	      [threads] operator(): check_zombie_leaders: leader_pid=724595, leader_lp!=NULL=1, num_lwps=2, zombie=0
+	      [threads] operator(): check_zombie_leaders: leader_pid=724597, leader_lp!=NULL=1, num_lwps=2, zombie=1
+	      [threads] operator(): Thread group leader 724597 zombie (it exited, or another thread execd).
+	      [threads] delete_lwp: deleting 724597
+	      [threads] wait_for_event_filtered: sigsuspend'ing
+	    sigchld_handler
+	      [threads] wait_for_event_filtered: waitpid(-1, ...) returned 724598, ERRNO-OK
+	      [threads] wait_for_event_filtered: waitpid 724598 received 0 (exited)
+	      [threads] filter_event: 724598 exited
+	      [threads] wait_for_event_filtered: waitpid(-1, ...) returned 724597, ERRNO-OK
+	      [threads] wait_for_event_filtered: waitpid 724597 received 0 (exited)
+	      [threads] wait_for_event_filtered: waitpid(-1, ...) returned 0, ERRNO-OK
+	    sigchld_handler
+	      [threads] wait_1: ret = LWP 724597.724598, exited with retcode 0
+	    [threads] wait_1: exit
+
+	Change-Id: Idf0bdb4cb0313f1b49e4864071650cc83fb3c100
+
+2022-03-31  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb/testsuite/tui: implement _csi_P proc
+	Since commit 3cd522938792 ("Change the pager to a ui_file"), I see these
+	errors when running gdb.tui/scroll.exp:
+
+	    ERROR: invalid command name "_csi_P"
+	        while executing
+	    "::gdb_tcl_unknown _csi_P 2"
+	        ("uplevel" body line 1)
+	        invoked from within
+	    "uplevel 1 ::gdb_tcl_unknown $args"
+	        (procedure "::unknown" line 5)
+	        invoked from within
+	    "_csi_P 2"
+	        ("eval" body line 1)
+	        invoked from within
+	    "eval _csi_$cmd $params"
+
+	It looks like GDB is emitting a CSI that it did not emit before, the
+	"Delete character" one:
+
+	  https://vt100.net/docs/vt510-rm/DCH.html
+
+	Implement it.
+
+	Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
+	Change-Id: I5bf86b6104d51b0623a26a69df83d1ca9a4851b7
+
+2022-03-31  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: fix use of fprintf_filtered in top.c
+	A race condition in how patches were pushed causes this build failure:
+
+	      CXX    top.o
+	    /home/simark/src/binutils-gdb/gdb/top.c: In function ‘void print_gdb_configuration(ui_file*)’:
+	    /home/simark/src/binutils-gdb/gdb/top.c:1622:3: error: ‘fprintf_filtered’ was not declared in this scope; did you mean ‘printf_unfiltered’?
+	     1622 |   fprintf_filtered (stream, _("\
+	          |   ^~~~~~~~~~~~~~~~
+
+	fprintf_filtered has been removed, gdb_printf must be used now.  Fix
+	this.
+
+	Change-Id: I6a172ba0d53dab2e7cc43ed0ed2696c82925245b
+
+2022-03-31  Richard Sandiford  <richard.sandiford@arm.com>
+
+	aarch64: Relax check for RNG system registers
+	FEAT_RNG is an optional Armv8.5-A extension, but it can be backported
+	to earlier architectures as well.  GAS previously made the RNG registers
+	conditional on having both armv8.5-a and +rng, but only +rng should be
+	required.
+
+	This seems to be the only feature that was handled like this.
+
+	opcodes/
+		* aarch64-opc.c (SR_RNG): Don't require V8_5.
+
+	gas/
+		* testsuite/gas/aarch64/rng-1.s, testsuite/gas/aarch64/rng-1.d: New
+		test.
+
+2022-03-31  Eli Zaretskii  <eliz@gnu.org>
+
+	* gdb/top.c (print_gdb_configuration): Announce --enable-threading.
+	This includes the reporting of --enable/disable-threading as part of
+	the GDB configuration description.
+
+2022-03-31  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb/infrun: add reason parameter to stop_all_threads
+	Add a "reason" parameter, only used to show in debug messages what is
+	the reason for stopping all threads.  This helped me understand the
+	debug logs while adding some new uses of stop_all_threads, so I am
+	proposing to merge it.
+
+	Change-Id: I66c8c335ebf41836a7bc3d5fe1db92c195f65e55
+
+2022-03-31  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb/testsuite: update copyright years in gdb.base/vfork-follow-parent.*
+	I forgot to do this before pushing the previous commit.
+
+	Change-Id: Ia343f702e8357d0fd109e9ddd778973e91862805
+
+2022-03-31  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: test vfork + follow-fork-mode=parent + detach-on-fork=off
+	The particular behavior we have when using that combination of settings
+	doesn't seem tested at all (at least, I don't find it if I grep for "Can
+	not resume the parent process").  Add a simple test for that.
+
+	Change-Id: Ib9454a615abba661b42f1b15056df73ed1bcd4c5
+
+2022-03-31  Nick Clifton  <nickc@redhat.com>
+
+	Accept the + character as part of filenames for MRI scripts.
+
+2022-03-31  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
+
+	Fix procfs.c compilation
+	procfs.c doesn't compile on Solaris:
+
+	/vol/src/gnu/gdb/hg/master/local/gdb/procfs.c: In member function ‘virtual bool procfs_target::info_proc(const char*, info_proc_what)’:
+	/vol/src/gnu/gdb/hg/master/local/gdb/procfs.c:3302:3: error: ‘gdb_argv’ was not declared in this scope
+	 3302 |   gdb_argv built_argv (args);
+	      |   ^~~~~~~~
+	/vol/src/gnu/gdb/hg/master/local/gdb/procfs.c:3303:20: error: ‘built_argv’ was not declared in this scope; did you mean ‘buildargv’?
+	 3303 |   for (char *arg : built_argv)
+	      |                    ^~~~~~~~~~
+	      |                    buildargv
+
+	Fixed by including  "gdbsupport/buildargv.h".
+
+	Tested on amd64-pc-solaris2.11, sparcv9-sun-solaris2.11.
+
+2022-03-31  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-30  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/testsuite: add tests for Term
+	While trying to review Andrew's patch here [1], I thought I spotted a
+	bug in the handling of a CSI, but I had no way to know for sure.  So I
+	thought it would be useful to have unit tests for the handling of
+	control characters and control sequences of our toy terminal
+	implementation.  It might help avoid chasing bugs in the GDB TUI when in
+	reality it's a problem with the testsuite's terminal implementation.
+
+	Add the gdb.tui/tuiterm.exp file to do that.  All currently supported
+	control sequences and characters are tested, except _csi_m (the one that
+	handles colors and stuff).  _csi_m should probably be tested too, but it
+	will require more work.
+
+	Fix a few issues that the tests spotted:
+
+	 - backspace: according to [3] (table 4-1), a backspace when the cursor
+	   is at the beginning of a line should have no effect.  Our
+	   implementation did wrap to the end of the previous line.  Change our
+	   implementation to match the doc (and the test).
+	 - insert character: this control sequence is supposed to insert blank
+	   characters, shifting all the rest of the line right.  The current
+	   implementation moves N characters right, but it overwrites the
+	   characters on the right instead of shifting them.  It also doesn't
+	   insert blank characters at the cursor.
+	 - Cursor down, forward, next line: off-by-one error when reaching the
+	   end of the display.
+	 - erase in display, line: off-by-one errors.
+	 - vertical line position absolute: allowed setting the cursor outside
+	   the display, when it should clamp it to the display size.
+
+	I found that this web page [2] gave some good clues on the expected
+	behavior of some control characters or sequences that some other pages
+	didn't.
+
+	[1] https://sourceware.org/pipermail/gdb-patches/2022-March/186433.html
+	[2] https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences
+	[3] https://vt100.net/docs/vt510-rm/chapter4.html#S4.3.3
+
+	Change-Id: Iab4141fdcfb7459d1b7c45cc63bd1fcb50a78d5d
+
+2022-03-30  Tom Tromey  <tom@tromey.com>
+
+	Only allow QUIT on the main thread
+	Pedro pointed out that gdb worker threads should not react to quits.
+	While I don't think that the new DWARF reader can call QUIT from a
+	worker thread (and I don't think the existing minsym threading code
+	can either), it seems safest to address this before checking in the
+	new code.  This patch arranges for the QUIT macro to only work on the
+	main thread.
+
+2022-03-30  Tom Tromey  <tromey@adacore.com>
+
+	Use gdb_printf and gdb_vprintf in more places
+	Luis pointed out that I missed a spot in the gdb_printf conversion --
+	namely aarch64-nat.c.  While looking at this, I found another spot in
+	darwin-nat.c that I also missed.  I can't build either of these, but I
+	think this patch should fix the problems.
+
+	Consolidate definition of current_directory
+	I noticed that both gdbserver and gdb define current_directory.
+	However, as it is referenced by gdbsupport, it seemed better to define
+	it there as well.  This patch also moves the declaration to
+	pathstuff.h.  Tested by rebuilding.
+
+2022-03-30  Tom Tromey  <tromey@adacore.com>
+
+	Decode "dynamic" interface types in Ada
+	In Ada, if a class implements an interface and has a dynamic
+	superclass, then the "offset to top" -- the offset that says how to
+	turn a pointer to the interface into a pointer to the whole object --
+	is stored in the object itself.  This patch changes GDB to understand
+	this.
+
+	Because this only touches Ada code, and because Joel already reviewed
+	it internally, I am checking it in.
+
+2022-03-30  Jeff Law  <jeffreyalaw@gmail.com>
+
+	Fix for MUL instruction on the v850
+		* sim/v850/simops.c (Multiply64): Properly test if we need to
+		negate either of the operands.
+
+		* sim/testsuite/v850/mul.cgs: New test.
+
+2022-03-30  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-29  Tom Tromey  <tom@tromey.com>
+
+	Remove two unused hooks
+	I noticed that a couple of deprecated hooks aren't ever called, so
+	they can't really be used by Insight.  This patch removes them
+	entirely.  I checked the Insight sources, and these aren't mentioned
+	there, either.
+
+2022-03-29  Tom Tromey  <tom@tromey.com>
+
+	Remove unnecessary calls to wrap_here and gdb_flush
+	Various spots in gdb currently know about the wrap buffer, and so are
+	careful to call wrap_here to be certain that all output has been
+	flushed.
+
+	Now that the pager is just an ordinary stream, this isn't needed, and
+	a simple call to gdb_flush is enough.
+
+	Similarly, there are places where gdb prints to gdb_stderr, but first
+	flushes gdb_stdout.  stderr_file already flushes gdb_stdout, so these
+	aren't needed.
+
+2022-03-29  Tom Tromey  <tom@tromey.com>
+
+	Minor comment updates in utils.h
+	This patch updates some comments in utils.h to more closely reflect
+	the new reality.
+
+	Remove vfprintf_styled
+	Nothing calls vfprintf_styled any more, so remove it.
+
+	Remove ui_out_flag::unfiltered_output
+	There is no longer any need for ui_out_flag::unfiltered_output --
+	nothing ever sets this flag.  This used to be needed to make the
+	_unfiltered output work, but now only printf_unfiltered can be used,
+	and it uses the puts_unfiltered method.  This patch removes the flag
+	and the dead code.
+
+	Rename fprintf_symbol_filtered
+	fprintf_symbol_filtered is misnamed, because whether filtering happens
+	is now up to the stream.  This renames it to fprintf_symbol, which
+	isn't a great name (the first "f" doesn't mean much and the second one
+	is truly meaningless here), but "print_symbol" was already taken.
+
+	Rename puts_filtered_tabular
+	puts_filtered_tabular is now misnamed, because whether filtering
+	happens is now up to the stream.  So, rename it.  (This function is
+	pretty weird, and should probably be rewritten to avoid using the
+	chars_printed global, and moved into objc-lang.c.  However, I haven't
+	done so.)
+
+	Rename print_spaces_filtered
+	print_spaces_filtered is now misnamed, because whether filtering
+	happens is up to the stream.  So, rename it.
+
+	Unify gdb printf functions
+	Now that filtered and unfiltered output can be treated identically, we
+	can unify the printf family of functions.  This is done under the name
+	"gdb_printf".  Most of this patch was written by script.
+
+	Unify gdb putc functions
+	Now that filtered and unfiltered output can be treated identically, we
+	can unify the putc family of functions.  This is done under the name
+	"gdb_putc".  Most of this patch was written by script.
+
+	Unify gdb puts functions
+	Now that filtered and unfiltered output can be treated identically, we
+	can unify the puts family of functions.  This is done under the name
+	"gdb_puts".  Most of this patch was written by script.
+
+	Unify vprintf functions
+	Now that filtered and unfiltered output can be treated identically, we
+	can unify the vprintf family of functions: vprintf_filtered,
+	vprintf_unfiltered, vfprintf_filtered and vfprintf_unfiltered.  (For
+	the gdb_stdout variants, recall that only printf_unfiltered gets truly
+	unfiltered output at this point.)  This removes one such function and
+	renames the remaining two to "gdb_vprintf".  All callers are updated.
+	Much of this patch was written by script.
+
+	Remove fputs_styled_unfiltered
+	fputs_styled_unfiltered is only called from cli_ui_out, so remove it.
+	This area will be further simplified in future patches.
+
+2022-03-29  Tom Tromey  <tom@tromey.com>
+
+	Change the pager to a ui_file
+	This rewrites the output pager as a ui_file implementation.
+
+	A new header is introduced to declare the pager class.  The
+	implementation remains in utils.c for the time being, because there
+	are some static globals there that must be used by this code.  (This
+	could be cleaned up at some future date.)
+
+	I went through all the text output in gdb to ensure that this change
+	should be ok.  There are a few cases:
+
+	* Any existing call to printf_unfiltered is required to be avoid the
+	  pager.  This is ensured directly in the implementation.
+
+	* All remaining calls to the f*_unfiltered functions -- the ones that
+	  take an explicit ui_file -- either send to an unfiltered stream
+	  (e.g., gdb_stderr), which is obviously ok; or conditionally send to
+	  gdb_stdout
+
+	  I investigated all such calls by searching for:
+
+	    grep -e '\bf[a-z0-9_]*_unfiltered' *.[chyl] */*.[ch] | grep -v gdb_stdlog | grep -v gdb_stderr
+
+	  This yields a number of candidates to check.
+
+	  * The breakpoint _print_recreate family, and
+	    save_trace_state_variables.  These are used for "save" commands
+	    and so are fine.
+
+	  * Things printing to a temporary stream.  Obviously ok.
+
+	  * Disassembly selftests.
+
+	  * print_gdb_help - this is non-obvious, but ok because paging isn't
+	    yet enabled at this point during startup.
+
+	  * serial.c - doens't use gdb_stdout
+
+	  * The code in compile/.  This is all printing to a file.
+
+	  * DWARF DIE dumping - doesn't reference gdb_stdout.
+
+	* Calls to the _filtered form -- these are all clearly ok, because if
+	  they are using gdb_stdout, then filtering will still apply; and if
+	  not, then filtering never applied and still will not.
+
+	Therefore, at this point, there is no longer any distinction between
+	all the other _filtered and _unfiltered calls, and they can be
+	unified.
+
+	In this patch, take special note of the vfprintf_maybe_filtered and
+	ui_file::vprintf change.  This is one instance of the above idea,
+	erasing the distinction between filtered and unfiltered -- in this
+	part of the change, the "unfiltered_output" flag is never passe to
+	cli_ui_out.  Subsequent patches will go much further in this
+	direction.
+
+	Also note the can_emit_style_escape changes in ui-file.c.  Checking
+	against gdb_stdout or gdb_stderr was always a bit of a hack; and now
+	it is no longer needed, because this is decision can be more fully
+	delegated to the particular ui_file implementation.
+
+	ui_file::can_page is removed, because this patch removed the only call
+	to it.
+
+	I think this is the main part of fixing PR cli/7234.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7234
+
+2022-03-29  Tom Tromey  <tom@tromey.com>
+
+	Remove vfprintf_styled_no_gdbfmt
+	This removes vfprintf_styled_no_gdbfmt, inlining it at the sole point
+	of call.
+
+	Add style-escape methods to ui_file
+	This adds emit_style_escape and reset_style methods to ui_file.  These
+	aren't used yet, but they will be once the pager is converted to be a
+	ui_file subclass.
+
+	Add puts_unfiltered method to ui_file
+	When the pager is rewritten as a ui_file, gdb will still need a way to
+	bypass the filtering.  After examining a few approaches, I chose this
+	patch, which adds a puts_unfiltered method to ui_file.  For most
+	implementations of ui_file, this will just delegate to puts.  This
+	patch also switches printf_unfiltered to use the new method.
+
+	Only have one API for unfiltered output
+	At the end of this series, the use of unfiltered output will be very
+	restricted -- only places that definitely need it will use it.  To
+	this end, I thought it would be good to reduce the number of
+	_unfiltered APIs that are exposed.  This patch changes gdb so that
+	only printf_unfiltered exists.  (After this patch, the f* variants
+	still exist as well, but those will be removed later.)
+
+2022-03-29  Tom Tromey  <tom@tromey.com>
+
+	Remove some uses of printf_unfiltered
+	A number of spots call printf_unfiltered only because they are in code
+	that should not be interrupted by the pager.  However, I believe these
+	cases are all handled by infrun's blanket ban on paging, and so can be
+	converted to the default (_filtered) API.
+
+	After this patch, I think all the remaining _unfiltered calls are ones
+	that really ought to be.  A few -- namely in complete_command -- could
+	be replaced by a scoped assignment to pagination_enabled, but for the
+	remainder, the code seems simple enough like this.
+
+2022-03-29  Tom Tromey  <tom@tromey.com>
+
+	Use unfiltered output in annotate.c
+	It seems to me that annotations should not be filtered.  While it
+	might be weird for an annotation-based UI to use the pager, it's not,
+	I think, out of the question.  This patch makes this change.
+
+2022-03-29  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>
+	    Aleksandar Paunovic  <aleksandar.paunovic@intel.com>
+
+	gdb/remote: use current_inferior in read_ptid if multi-process not supported
+	When parsing the ptid out of a reply package, if the multi-process
+	extensions are not supported, use current_inferior's pid as the pid of
+	the reported thread, instead of inferior_ptid.  This is needed because
+	the inferior_ptid may be null_ptid although a legit context exists,
+	due to a prior context switch via switch_to_inferior_no_thread.
+
+	Below is a scenario that illustrates what could go wrong.  First,
+	setup a multi-target scenario.  This is needed, because in a
+	multi-target setting, the inferior_ptid is cleared out before waiting
+	on targets.  The second inferior below sits on top of a remote target.
+	Multi-process packets are disabled.
+
+	  $ # First, spawn a process with PID 26253 to attach to later.
+	  $ gdb-up a.out
+	  Reading symbols from a.out...
+	  (gdb) maint set target-non-stop on
+	  (gdb) set remote multiprocess-feature-packet off
+	  (gdb) start
+	  ...
+	  (gdb) add-inferior -no-connection
+	  [New inferior 2]
+	  Added inferior 2
+	  (gdb) inferior 2
+	  [Switching to inferior 2 [<null>] (<noexec>)]
+	  (gdb) target extended-remote | gdbserver --multi -
+	  Remote debugging using | gdbserver --multi -
+	  Remote debugging using stdio
+	  (gdb) attach 26253
+	  Attaching to Remote target
+	  Attached; pid = 26253
+	  [New Thread 26253]
+	  [New inferior 3]
+	  Reading /tmp/a.out from remote target...
+	  ...
+	  [New Thread 26253]
+	  ...
+	  Reading /usr/local/lib/debug/....debug from remote target...
+	  >>> GDB seems to hang here.
+
+	After attaching to a process and reading some library files, GDB
+	seems to hang.  One interesting thing to note is that
+
+	  [New Thread 26253]
+
+	appears twice.  We also see
+
+	  [New inferior 3]
+
+	Running the same scenario with "debug infrun on" reveals more details.
+
+	  ...
+	  (gdb) attach 26253
+	  [infrun] scoped_disable_commit_resumed: reason=attaching
+	  Attaching to Remote target
+	  Attached; pid = 26253
+	  [New Thread 26253]
+	  [infrun] infrun_async: enable=1
+	  [infrun] attach_command: immediately after attach:
+	  [infrun] attach_command:   thread 26253.26253.0, executing = 1, resumed = 0, state = RUNNING
+	  [infrun] clear_proceed_status_thread: 26253.26253.0
+	  [infrun] reset: reason=attaching
+	  [infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target native, no resumed threads
+	  [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote
+	  [infrun] fetch_inferior_event: enter
+	    [infrun] scoped_disable_commit_resumed: reason=handling event
+	    [infrun] do_target_wait: Found 2 inferiors, starting at #1
+	    [infrun] random_pending_event_thread: None found.
+	    [infrun] print_target_wait_results: target_wait (-1.0.0 [Thread 0], status) =
+	    [infrun] print_target_wait_results:   26253.26253.0 [Thread 26253],
+	    [infrun] print_target_wait_results:   status->kind = STOPPED, sig = GDB_SIGNAL_0
+	    [infrun] handle_inferior_event: status->kind = STOPPED, sig = GDB_SIGNAL_0
+	    [infrun] start_step_over: enter
+	      [infrun] start_step_over: stealing global queue of threads to step, length = 0
+	      [infrun] operator(): step-over queue now empty
+	    [infrun] start_step_over: exit
+	    [infrun] context_switch: Switching context from 0.0.0 to 26253.26253.0
+	    [infrun] handle_signal_stop: stop_pc=0x7f849d8cf151
+	    [infrun] stop_waiting: stop_waiting
+	    [infrun] stop_all_threads: starting
+	    [infrun] stop_all_threads: pass=0, iterations=0
+	  [New inferior 3]
+	  Reading /tmp/a.out from remote target...
+	  warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
+	  Reading /tmp/a.out from remote target...
+	  Reading symbols from target:/tmp/a.out...
+	  [New Thread 26253]
+	    [infrun] stop_all_threads:   4723.4723.0 not executing
+	    [infrun] stop_all_threads:   26253.26253.0 not executing
+	    [infrun] stop_all_threads:   42000.26253.0 executing, need stop
+	    [infrun] print_target_wait_results: target_wait (-1.0.0 [Thread 0], status) =
+	    [infrun] print_target_wait_results:   -1.0.0 [Thread 0],
+	    [infrun] print_target_wait_results:   status->kind = IGNORE
+	    [infrun] print_target_wait_results: target_wait (-1.0.0 [Thread 0], status) =
+	    [infrun] print_target_wait_results:   -1.0.0 [Thread 0],
+	    [infrun] print_target_wait_results:   status->kind = IGNORE
+
+	GDB tried to stop Thread 42000.26253.0, which does not exist, and we
+	are waiting for a stop event that will never happen.  The PID in
+	'42000.26253.0', namely 42000, is the PID of magic_null_ptid.
+	It comes from gdb/remote.c:read_ptid:
+
+	  /* Since the stub is not sending a process id, then default to
+	     what's in inferior_ptid, unless it's null at this point.  If so,
+	     then since there's no way to know the pid of the reported
+	     threads, use the magic number.  */
+	  if (inferior_ptid == null_ptid)
+	    pid = magic_null_ptid.pid ();
+	  else
+	    pid = inferior_ptid.pid ();
+
+	  if (obuf)
+	    *obuf = pp;
+	  return ptid_t (pid, tid);
+
+	Because multi-process was turned off, GDB did not parse an explicitly
+	specified PID.  Furthermore, inferior_ptid == null_ptid, and
+	eventually GDB picked the PID from magic_null_ptid.
+
+	If target-non-stop is not turned on at the beginning, the same bug
+	reveals itself as a duplicated thread as shown below.
+
+	  # Same setup as above, without 'maint set target-non-stop on'.
+	  ...
+	  (gdb) attach 26253
+	  Attaching to Remote target
+	  Attached; pid = 26253
+	  [New inferior 3]
+	  ...
+	  [New Thread 26253]
+	  ...
+	  (gdb) info threads
+	    Id   Target Id             Frame
+	    1.1  process 13517 "a.out" main () at test.c:3
+	  * 2.1  Thread 26253 "a.out"  0x00007f12750c5151 in read () from target:/lib/x86_64-linux-gnu/libc.so.6
+	    3.1  Thread 26253 "a.out"  Remote 'g' packet reply is too long (expected 560 bytes, got 2496 bytes): 00feffffffffffff000a3a75127f000051510c75127f0000000400000000000060d24ef6af5500000000000000000000680d000000000000b85b31e3fc7f0000c0283a75127f000000e55b75127f000010d04ef6af550000460200000000000060c73975127f0000a0d23975127f0000000a3a75127f0000000000000000000051510c75127f000046020000330000002b0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f03000000000000ffff0000000000000000000000000000000000000000000080143a75127f000080143a75127f000040143a75127f000040143a75127f00007d0000007e0000007f00000080000000300c3a75127f0000300c3a75127f00000e000000000000000e0000000000000000000000000000000000000000000000ffffffffffffffffffffffffffffffff0400000004000000040000000400000020143a75127f000020143a75127f000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000000000000000000000e55b75127f0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
+	  (gdb)
+
+	Fix the problem by preferring current_inferior()'s pid instead of
+	magic_null_ptid.
+
+	Regression-tested on X86-64 Linux.
+
+2022-03-29  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: fix test failure when building against readline v7
+	The test added in the commit:
+
+	  commit a6b413d24ccc5d76179bab866834e11fd6fec294
+	  Date:   Fri Mar 11 14:44:03 2022 +0000
+
+	      gdb: work around prompt corruption caused by bracketed-paste-mode
+
+	Was not written with readline 7 in mind, only readline 8+.  Between
+	readline 7 and 8 the escape sequence used to disable bracketed paste
+	mode changed, an additional '\r' character was added to the end.  In
+	fact, it was the addition of this '\r' character that triggered the
+	issue for which the above commit is part of the solution.
+
+	Anyway, the test tries to spot the case where the output from GDB is
+	not perfect, but does have the above work around applied.  However,
+	the pattern in the test assumes that the problematic '\r' will be
+	present, and this is only true for readline 8+.  With readline 7 the
+	test was failing.
+
+	In this commit I generalise the pattern a little so that the test will
+	still KFAIL with readline 7.
+
+	It's a little unfortunate that the test is KFAILing with readline 7,
+	as without the problematic '\r' there's actually no reason that GDB
+	couldn't "do the right thing" in this case, in which case, the test
+	would PASS, but that would require changes within GDB itself.
+
+	My preference then is that initially we patch the test to get it
+	KFAILing, then in a separate commit I can modify GDB so that it can
+	PASS with readline 7.
+
+2022-03-29  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: fix copy & paste error in gdb.python/py-format-address.exp
+	The test gdb.python/py-format-address.exp, added in commit:
+
+	  commit 25209e2c6979c3838e14e099f0333609810db280
+	  Date:   Sat Oct 23 09:59:25 2021 +0100
+
+	      gdb/python: add gdb.format_address function
+
+	included 3 copy & paste errors where the wrong address was used in the
+	expected output patterns.
+
+	The test compiles two almost identical test binaries (one function
+	changes its name, that's the only difference), two inferiors are
+	created, each inferior using one of the test binaries.
+
+	We then take the address of the name changing function in both
+	inferiors ('foo' in inferior 1 and 'bar' in inferior 2) and the tests
+	are carried out using these addresses.
+
+	What we're checking for is that symbols 'foo' and 'bar' show up in the
+	correct inferior, and that (as this test is for a Python API feature),
+	the user can have one inferior selected, but ask about the other
+	inferior, and see the correct symbol in the result.
+
+	The hope is that the two binaries will be laid out identically by the
+	compiler, and that 'foo' and 'bar' will be at the same address.  This
+	is fine, unless the executable is compiled as PIE (position
+	independent executable), in which case there is a problem.
+
+	The problem is that though inferior 1 is set running, the inferior 2
+	never is.  If the executables are compiled as PIE, then the address in
+	the inferior 2 will not have been resolved, while the address in the
+	inferior 1 will have been, and so the two addresses we use in the
+	tests will be different.
+
+	This issue was reported here:
+
+	  https://sourceware.org/pipermail/gdb-patches/2022-March/186911.html
+
+	The first part of the fix is to use the correct address variable in
+	the expected output patterns, with this change the tests pass even
+	when the executables are compiled as PIE.
+
+	A second part of this fix is to pass the 'nopie' option when we
+	compile the tests, this should ensure that the address obtained in
+	inferior 2 is the same as the address from inferior 1, which makes the
+	test more useful.
+
+2022-03-29  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/mi: fix use after free of frame_info causing spurious notifications
+	In commit:
+
+	  commit a2757c4ed693cef4ecc4dcdcb2518353eb6b3c3f
+	  Date:   Wed Mar 16 15:08:22 2022 +0000
+
+	      gdb/mi: consistently notify user when GDB/MI client uses -thread-select
+
+	Changes were made to GDB to address some inconsistencies in when
+	notifications are sent from a MI terminal to a CLI terminal (when
+	multiple terminals are in use, see new-ui command).
+
+	Unfortunately, in order to track when the currently selected frame has
+	changed, that commit grabs a frame_info pointer before and after an MI
+	command has executed, and compares the pointers to see if the frame
+	has changed.
+
+	This is not safe.
+
+	If the frame cache is deleted for any reason then the frame_info
+	pointer captured before the command started, is no longer valid, and
+	any comparisons based on that pointer are undefined.
+
+	This was leading to random test failures for some folk, see:
+
+	  https://sourceware.org/pipermail/gdb-patches/2022-March/186867.html
+
+	This commit changes GDB so we no longer hold frame_info pointers, but
+	instead store the frame_id and frame_level, this is safe even when the
+	frame cache is flushed.
+
+2022-03-29  Jan Beulich  <jbeulich@suse.com>
+
+	bfd/Dwarf2: gas doesn't mangle names
+	Include the language identifier emitted by gas in the set of ones where
+	no mangled names are expected. Even if there could be "hand-mangled"
+	names, gas doesn't emit DW_AT_linkage_name in the first place.
+
+	bfd/Dwarf2: make find-nearest-line returned function name consistent
+	Prior to entering the enclosing "else if()" the earlier associated if()
+	checks function->is_linkage and, if set, uses function->name. The
+	comment in patch context precedes (and explains) the setting
+	function->is_linkage. Yet with the flag set, we should then also return
+	the function name, just like said earlier if() would do when we came
+	here a 2nd time for the same "addr". And indeed passing the same address
+	twice on addr2line's command line would resolve the function for the 2nd
+	instance, but not for the 1st (if this code path is taken). (This,
+	obviously, is particularly relevant when there's no ELF symbol table in
+	the first place, like would be the case - naturally - in PE/COFF
+	binaries, for example.)
+
+	gas/Dwarf: special-case .linefile only for macros
+	Restrict the PR gas/16908 workaround to just macros, matching the
+	original intention as well as the comment there. For constructs like
+	.irp or .rept the reasoning doesn't apply, as there's no separate
+	"invocation" point which may be of interest to record (for, as said
+	there, short macros).
+
+2022-03-29  Jan Beulich  <jbeulich@suse.com>
+
+	RISC-V: correct FCVT.Q.L[U]
+	While the spec isn't explicit about this, it pointing out the similarity
+	with the D extension ought to extend to the ignoring of a meaningless
+	rounding mode: "Note FCVT.D.W[U] always produces an exact result and is
+	unaffected by rounding mode." Hence the chosen encodings also ought to
+	match.
+
+	Note that to avoid breaking existing code the forms with a 3rd operand
+	are not removed, which means there continues to be a difference to
+	FCVT.D.W[U].
+
+2022-03-29  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: add arch/.gdbinit stub scripts
+	Make it easy to load the common gdbinit script even when running in
+	the arch/ subdir instead of the top-level sim dir.
+
+2022-03-29  Alan Modra  <amodra@gmail.com>
+
+	asan: heap buffer overflow in pa_chk_field_selector
+	The buffer overflow showed up running the gas "all macro" test.
+
+		PR 29005
+		* config/tc-hppa.c (pa_chk_field_selector): Don't read past end
+		of line.
+
+2022-03-29  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-28  Tom Tromey  <tom@tromey.com>
+
+	Add Rust parser check for end of expression
+	I noticed that "print 5," passed in Rust -- the parser wasn't checking
+	that the entire input was used.  This patch fixes the problem.  This
+	in turn pointed out another bug in the parser, namely that it didn't
+	lex the next token after handling a string token.  This is also fixed
+	here.
+
+2022-03-28  Tom Tromey  <tom@tromey.com>
+
+	Switch gdb_stdlog to use timestamped_file
+	Currently, timestamps for logging are done by looking for the use of
+	gdb_stdlog in vfprintf_unfiltered.  This seems potentially buggy, in
+	that during logging or other redirects (like execute_fn_to_ui_file) we
+	might have gdb_stdout==gdb_stdlog and so, conceivably, wind up with
+	timestamps in a log when they were not desired.
+
+	It seems better, instead, for timestamps to be a property of the
+	ui_file itself.
+
+	This patch changes gdb to use the new timestamped_file for gdb_stdlog
+	where appropriate, and removes the special case from
+	vfprintf_unfiltered.
+
+	Note that this may somewhat change the output in some cases -- in
+	particular, when going through execute_fn_to_ui_file (or the _string
+	variant), timestamps won't be emitted.  This could be fixed in those
+	functions, but it wasn't clear to me whether this is really desirable.
+
+	Note also that this changes the TUI to send gdb_stdlog to gdb_stderr.
+	I imagine that the previous use of gdb_stdout here was inadvertent.
+	(And in any case it probably doesn't matter.)
+
+2022-03-28  Tom Tromey  <tom@tromey.com>
+
+	Add new timestamped_file class
+	This adds a "timestamped_file" subclass of ui_file.  This class adds a
+	timestamp to its output when appropriate.  That is, it follows the
+	rule already used in vfprintf_unfiltered of adding a timestamp at most
+	once per write.
+
+	The new class is not yet used.
+
+2022-03-28  Tom Tromey  <tom@tromey.com>
+
+	Use unique_ptr in CLI logging code
+	This changes the CLI logging code to avoid manual memory management
+	(to the extent possible) by using unique_ptr in a couple of spots.
+	This will come in handy in a later patch.
+
+2022-03-28  Tom Tromey  <tom@tromey.com>
+
+	Simplify the CLI set_logging logic
+	The CLI's set_logging logic seemed unnecessarily complicated to me.
+	This patch simplifies it, with an eye toward changing it to use RAII
+	objects in a subsequent patch.
+
+	I did not touch the corresponding MI code.  That code seems incorrect
+	(nothing ever uses raw_stdlog, and nothing ever sets
+	saved_raw_stdlog).  I didn't attempt to fix this, because I question
+	whether this is even useful for MI.
+
+2022-03-28  Tom Tromey  <tromey@adacore.com>
+
+	Handle multiple addresses in call_site_target
+	A large customer program has a function that is partitioned into hot
+	and cold parts.  A variable in a callee of this function is described
+	using DW_OP_GNU_entry_value, but gdb gets confused when trying to find
+	the caller.  I tracked this down to dwarf2_get_pc_bounds interpreting
+	the function's changes so that the returned low PC is the "wrong"
+	function.
+
+	Intead, when processing DW_TAG_call_site, the low PC of each range in
+	DW_AT_ranges should be preserved in the call_site_target.  This fixes
+	the variable lookup in the test case I have.
+
+	I didn't write a standalone test for this as it seemed excessively
+	complicated.
+
+2022-03-28  Tom Tromey  <tromey@adacore.com>
+
+	Change call_site_target to iterate over addresses
+	In order to handle the case where a call site target might refer to
+	multiple addresses, we change the code to use a callback style.  Any
+	spot using call_site_target::address now passes in a callback function
+	that may be called multiple times.
+
+2022-03-28  Tom Tromey  <tromey@adacore.com>
+
+	Change call_site_find_chain_1 to work recursively
+	call_site_find_chain_1 has a comment claiming that recursive calls
+	would be too expensive.  However, I doubt this is so expensive; and
+	furthermore the explicit state management approach here is difficult
+	both to understand and to modify.  This patch changes this code to use
+	explicit recursion, so that a subsequent patch can generalize this
+	code without undue trauma.
+
+	Additionally, I think this patch detects a latent bug in the recursion
+	code.  (It's hard for me to be completely certain.)  The bug is that
+	when a new target_call_site is entered, the code does:
+
+		  if (target_call_site)
+		    {
+		      if (addr_hash.insert (target_call_site->pc ()).second)
+			{
+			  /* Successfully entered TARGET_CALL_SITE.  */
+
+			  chain.push_back (target_call_site);
+			  break;
+			}
+		    }
+
+	Here, if entering the target_call_site fails, then any tail_call_next
+	elements in this call site are not visited.  However, if this code
+	does happen to enter a call site, then the tail_call_next elements
+	will be visited during backtracking.  This applies when doing the
+	backtracking as well -- it will only continue through a given chain as
+	long as each element in the chain can successfully be visited.
+
+	I'd appreciate some review of this.  If this behavior is intentional,
+	it can be added to the new implementation.
+
+2022-03-28  Tom Tromey  <tromey@adacore.com>
+
+	Constify chain_candidate
+	While investigating this bug, I wasn't sure if chain_candidate might
+	update 'chain'.  I changed it to accept a const reference, making it
+	clear that it cannot.  This simplifies the code a tiny bit as well.
+
+	Make call_site_target members private
+	This makes the data members of call_site_target 'private'.  This lets
+	us remove most of its public API.  call_site_to_target_addr is changed
+	to be a method of this type.  This is a preparatory refactoring for
+	the fix at the end of this series.
+
+	Change call_site_target to use custom type and enum
+	call_site_target reuses field_loc_kind and field_location.  However,
+	it has never used the full range of the field_loc_kind enum.  In a
+	subsequent patch, I plan to add a new 'kind' here, so it seemed best
+	to avoid this reuse and instead introduce new types here.
+
+2022-03-28  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-27  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-26  Tom Tromey  <tom@tromey.com>
+
+	Remove an unused declaration from value.h
+	value.h has a declaration of value_print_array_elements that is
+	incorrect.  In C, this would have been an error, but in C++ this is a
+	declaration of an overload that is neither defined nor used.  This
+	patch removes the declaration.
+
+2022-03-26  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-25  Nick Alcock  <nick.alcock@oracle.com>
+
+	libtool.m4: fix the NM="/nm/over/here -B/option/with/path" case
+	My previous nm patch handled all cases but one -- if the user set NM in
+	the environment to a path which contained an option, libtool's nm
+	detection tries to run nm against a copy of nm with the options in it:
+	e.g. if NM was set to "nm --blargle", and nm was found in /usr/bin, the
+	test would try to run "/usr/bin/nm --blargle /usr/bin/nm --blargle".
+	This is unlikely to be desirable: in this case we should run
+	"/usr/bin/nm --blargle /usr/bin/nm".
+
+	Furthermore, as part of this nm has to detect when the passed-in $NM
+	contains a path, and in that case avoid doing a path search itself.
+	This too was thrown off if an option contained something that looked
+	like a path, e.g. NM="nm -B../prev-gcc"; libtool then tries to run
+	"nm -B../prev-gcc nm" which rarely works well (and indeed it looks
+	to see whether that nm exists, finds it doesn't, and wrongly concludes
+	that nm -p or whatever does not work).
+
+	Fix all of these by clipping all options (defined as everything
+	including and after the first " -") before deciding whether nm
+	contains a path (but not using the clipped value for anything else),
+	and then removing all options from the path-modified nm before
+	looking to see whether that nm existed.
+
+	NM=my-nm now does a path search and runs e.g.
+	  /usr/bin/my-nm -B /usr/bin/my-nm
+
+	NM=/usr/bin/my-nm now avoids a path search and runs e.g.
+	  /usr/bin/my-nm -B /usr/bin/my-nm
+
+	NM="my-nm -p../wombat" now does a path search and runs e.g.
+	  /usr/bin/my-nm -p../wombat -B /usr/bin/my-nm
+
+	NM="../prev-binutils/new-nm -B../prev-gcc" now avoids a path search:
+	  ../prev-binutils/my-nm -B../prev-gcc -B ../prev-binutils/my-nm
+
+	This seems to be all combinations, including those used by GCC bootstrap
+	(which, before this commit, fails to bootstrap when configured
+	--with-build-config=bootstrap-lto, because the lto plugin is now using
+	--export-symbols-regex, which requires libtool to find a working nm,
+	while also using -B../prev-gcc to point at the lto plugin associated
+	with the GCC just built.)
+
+	Regenerate all affected configure scripts.
+
+		* libtool.m4 (LT_PATH_NM): Handle user-specified NM with
+		options, including options containing paths.
+
+2022-03-25  Alan Modra  <amodra@gmail.com>
+
+	Re: gas/Dwarf: improve debug info generation from .irp and alike blocks
+	am33_2.0-linux is a mn10300 target.
+
+		* testsuite/gas/elf/dwarf-5-irp.d: xfail am33.
+
+2022-03-25  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-24  Aaron Merey  <amerey@redhat.com>
+
+	Remove download size from debuginfod progress messages if unavailable
+	Currently debuginfod progress update messages include the size of
+	each download:
+
+	  Downloading 7.5 MB separate debug info for /lib/libxyz.so.0
+
+	This value originates from the Content-Length HTTP header of the
+	transfer.  However this header is not guaranteed to be present for
+	each download.  This can happen when debuginfod servers compress files
+	on-the-fly at the time of transfer.  In this case gdb wrongly prints
+	"-0.00 MB" as the size.
+
+	This patch removes download sizes from progress messages when they are
+	not available.  It also removes usage of the progress bar until
+	a more thorough reworking of progress updating is implemented. [1]
+
+	[1] https://sourceware.org/pipermail/gdb-patches/2022-February/185798.html
+
+2022-03-24  Reuben Thomas  <rrt@sc3d.org>
+
+	sim: fix a comment typo in sim-load.c
+	Fix a typo where the documentation refers to a function parameter by the
+	wrong name.
+
+	Change-Id: I99494efe62cd4aa76fb78a0bd5da438d35740ebe
+
+2022-03-24  Reuben Thomas  <rrt@sc3d.org>
+
+	sim: fix “alligned” typos
+	Change-Id: Ifd574e38524dd4f1cf0fc003e0c5c7499abc84a0
+
+2022-03-24  Jan Beulich  <jbeulich@suse.com>
+
+	x86: mention dropped L1OM/K1OM support in ld/ as well
+	This amends e961c696dcb2 ("x86: drop L1OM/K1OM support from ld"). Also
+	remove the marker that I mistakenly added in c085ab00c7b2 ("x86: drop
+	L1OM/K1OM support from gas").
+
+2022-03-24  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb/testsuite: remove gdb.python/pretty-print-call-by-hand.exp
+	This test was added without a corresponding fix, with some setup_kfails.
+	However, it results in UNRESOLVED results when GDB is built with ASan.
+
+	  ERROR: GDB process no longer exists
+	  GDB process exited with wait status 1946871 exp7 0 1
+	  UNRESOLVED: gdb.python/pretty-print-call-by-hand.exp: frame print: backtrace test (PRMS gdb/28856)
+
+	Remove the test from the tree, I'll attach it to the Bugzilla bug
+	instead [1].
+
+	[1] https://sourceware.org/bugzilla/show_bug.cgi?id=28856
+
+	Change-Id: Id95d8949fb8742874bd12aeac758aa4d7564d678
+
+2022-03-24  Jan Beulich  <jbeulich@suse.com>
+
+	x86: drop L1OM/K1OM support from ld
+	This was only rudimentary support anyway; none of the sub-architecture
+	specific insns were ever supported.
+
+	x86: drop L1OM special case from disassembler
+	There wasn't any real support anyway: None of the sub-architecture
+	specific insns were ever supported.
+
+2022-03-24  Jan Beulich  <jbeulich@suse.com>
+
+	MAINTAINERS: add myself
+	I much appreciate Nick offering this role to me. Nevertheless there's
+	still a lot for me to learn here.
+
+	At this occasion also update my email address in the pre-existing, much
+	more narrow entry.
+
+2022-03-24  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-23  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: address test failures in gdb.mi/mi-multi-commands.exp
+	The gdb.mi/mi-multi-commands.exp test was added in commit:
+
+	  commit d08cbc5d3203118da5583296e49273cf82378042
+	  Date:   Wed Dec 22 12:57:44 2021 +0000
+
+	      gdb: unbuffer all input streams when not using readline
+
+	And then tweaked in commit:
+
+	  commit 144459531dd68a1287905079aaa131b777a8cc82
+	  Date:   Mon Feb 7 20:35:58 2022 +0000
+
+	      gdb/testsuite: relax pattern in new gdb.mi/mi-multi-commands.exp test
+
+	The second of these commits was intended to address periodic test
+	failures that I was seeing, and this change did fix some problems,
+	but, unfortunately, introduced other issues.
+
+	The problem is that the test relies on sending two commands to GDB in
+	a single write.  As the characters that make these two commands arrive
+	they are echoed to GDB's console.  However, there is a race between
+	how quickly the characters are echoed and how quickly GDB decides to
+	act on the incoming commands.
+
+	Usually, both commands are echoed in full before GDB acts on the first
+	command, but sometimes this is not the case, and GDB can execute the
+	first command before both commands are fully echoed to the console.
+	In this case, the output of the first command will be mixed in with
+	the echoing of the second command.
+
+	This mixing of the command echoing and the first command output is
+	what was causing failures in the original version of the test.
+
+	The second commit relaxed the expected output pattern a little, but
+	was still susceptible to failures, so this commit further relaxes the
+	pattern.
+
+	Now, we look for the first command output with no regard to what is
+	before, or after the command.  Then we look for the first mi prompt to
+	indicate that the first command has completed.
+
+	I believe that this change should make the test more stable than it
+	was before.
+
+2022-03-23  Nick Alcock  <nick.alcock@oracle.com>
+
+	libctf: add LIBCTF_WRITE_FOREIGN_ENDIAN debugging option
+	libctf has always handled endianness differences by detecting
+	foreign-endian CTF dicts on the input and endian-flipping them: dicts
+	are always written in native endianness.  This makes endian-awareness
+	very low overhead, but it means that the foreign-endian code paths
+	almost never get routinely tested, since "make check" usually reads in
+	dicts ld has just written out: only a few corrupted-CTF tests are
+	actually in fixed endianness, and even they only test the foreign-
+	endian code paths when you run make check on a big-endian machine.
+	(And the fix is surely not to add more .s-based tests like that, because
+	they are a nightmare to maintain compared to the C-code-based ones.)
+
+	To improve on this, add a new environment variable,
+	LIBCTF_WRITE_FOREIGN_ENDIAN, which causes libctf to unconditionally
+	endian-flip at ctf_write time, so the output is always in the wrong
+	endianness.  This then tests the foreign-endian read paths properly
+	at open time.
+
+	Make this easier by restructuring the writeout code in ctf-serialize.c,
+	which duplicates the maybe-gzip-and-write-out code three times (once
+	for ctf_write_mem, with thresholding, and once each for
+	ctf_compress_write and ctf_write just so those can avoid thresholding
+	and/or compression).  Instead, have the latter two call the former
+	with thresholds of 0 or (size_t) -1, respectively.
+
+	The endian-flipping code itself gains a bit of complexity, because
+	one single endian-flipper (flip_types) was assuming the input to be
+	in foreign-endian form and assuming it could pull things out of the
+	input once they had been flipped and make sense of them. At the
+	cost of a few lines of duplicated initializations, teach it to
+	read before flipping if we're flipping to foreign-endianness instead
+	of away from it.
+
+	libctf/
+		* ctf-impl.h (ctf_flip_header): No longer static.
+		(ctf_flip): Likewise.
+		* ctf-open.c (flip_header): Rename to...
+		(ctf_flip_header): ... this, now it is not private to one file.
+		(flip_ctf): Rename...
+		(ctf_flip): ... this too.  Add FOREIGN_ENDIAN arg.
+		(flip_types): Likewise.  Use it.
+		(ctf_bufopen_internal): Adjust calls.
+		* ctf-serialize.c (ctf_write_mem): Add flip_endian path via
+		a newly-allocated bounce buffer.
+		(ctf_compress_write): Move below ctf_write_mem and reimplement
+		in terms of it.
+		(ctf_write): Likewise.
+		(ctf_gzwrite): Note that this obscure writeout function does not
+		support endian-flipping.
+
+2022-03-23  Nick Alcock  <nick.alcock@oracle.com>
+
+	libctf, ld: diagnose corrupted CTF header cth_strlen
+	The last section in a CTF dict is the string table, at an offset
+	represented by the cth_stroff header field.  Its length is recorded in
+	the next field, cth_strlen, and the two added together are taken as the
+	size of the CTF dict.  Upon opening a dict, we check that none of the
+	header offsets exceed this size, and we check when uncompressing a
+	compressed dict that the result of the uncompression is the same length:
+	but CTF dicts need not be compressed, and short ones are not.
+	Uncompressed dicts just use the ctf_size without checking it.  This
+	field is thankfully almost unused: it is mostly used when reserializing
+	a dict, which can't be done to dicts read off disk since they're
+	read-only.
+
+	However, when opening an uncompressed foreign-endian dict we have to
+	copy it out of the mmaped region it is stored in so we can endian-
+	swap it, and we use ctf_size when doing that.  When the cth_strlen is
+	corrupt, this can overrun.
+
+	Fix this by checking the ctf_size in all uncompressed cases, just as we
+	already do in the compressed case.  Add a new test.
+
+	This came to light because various corrupted-CTF raw-asm tests had an
+	incorrect cth_strlen: fix all of them so they produce the expected
+	error again.
+
+	libctf/
+		PR libctf/28933
+		* ctf-open.c (ctf_bufopen_internal): Always check uncompressed
+		CTF dict sizes against the section size in case the cth_strlen is
+		corrupt.
+
+	ld/
+		PR libctf/28933
+		* testsuite/ld-ctf/diag-strlen-invalid.*: New test,
+		derived from diag-cttname-invalid.s.
+		* testsuite/ld-ctf/diag-cttname-invalid.s: Fix incorrect cth_strlen.
+		* testsuite/ld-ctf/diag-cttname-null.s: Likewise.
+		* testsuite/ld-ctf/diag-cuname.s: Likewise.
+		* testsuite/ld-ctf/diag-parlabel.s: Likewise.
+		* testsuite/ld-ctf/diag-parname.s: Likewise.
+
+2022-03-23  Nick Alcock  <nick.alcock@oracle.com>
+
+	include, libctf, ld: extend variable section to contain functions too
+	The CTF variable section is an optional (usually-not-present) section in
+	the CTF dict which contains name -> type mappings corresponding to data
+	symbols that are present in the linker input but not in the output
+	symbol table: the idea is that programs that use their own symbol-
+	resolution mechanisms can use this section to look up the types of
+	symbols they have found using their own mechanism.
+
+	Because these removed symbols (mostly static variables, functions, etc)
+	all have names that are unlikely to appear in the ELF symtab and because
+	very few programs have their own symbol-resolution mechanisms, a special
+	linker flag (--ctf-variables) is needed to emit this section.
+
+	Historically, we emitted only removed data symbols into the variable
+	section.  This seemed to make sense at the time, but in hindsight it
+	really doesn't: functions are symbols too, and a C program can look them
+	up just like any other type.  So extend the variable section so that it
+	contains all static function symbols too (if it is emitted at all), with
+	types of kind CTF_K_FUNCTION.
+
+	This is a little fiddly.  We relied on compiler assistance for data
+	symbols: the compiler simply emits all data symbols twice, once into the
+	symtypetab as an indexed symbol and once into the variable section.
+
+	Rather than wait for a suitably adjusted compiler that does the same for
+	function symbols, we can pluck unreported function symbols out of the
+	symtab and add them to the variable section ourselves.  While we're at
+	it, we do the same with data symbols: this is redundant right now
+	because the compiler does it, but it costs very little time and lets the
+	compiler drop this kludge and save a little space in .o files.
+
+	include/
+		* ctf.h: Mention the new things we can see in the variable
+		section.
+
+	ld/
+		* testsuite/ld-ctf/data-func-conflicted-vars.d: New test.
+
+	libctf/
+		* ctf-link.c (ctf_link_deduplicating_variables): Duplicate
+		symbols into the variable section too.
+		* ctf-serialize.c (symtypetab_delete_nonstatic_vars): Rename
+		to...
+		(symtypetab_delete_nonstatics): ... this.  Check the funchash
+		when pruning redundant variables.
+		(ctf_symtypetab_sect_sizes): Adjust accordingly.
+		* NEWS: Describe this change.
+
+2022-03-23  Nick Alcock  <nick.alcock@oracle.com>
+
+	ld, testsuite: improve CTF-availability test
+	The test for -gctf support in the compiler is used to determine when to
+	run the ld-ctf tests and most of those in libctf.  Unfortunately,
+	because it uses check_compiler_available and compile_one_cc, it will
+	fail whenever the compiler emits anything on stderr, even if it
+	actually does support CTF perfectly well.
+
+	So, instead, ask the compiler to emit assembler output and grep it for
+	references to ".ctf": this is highly unlikely to be present if the
+	compiler does not support CTF.  (This will need adjusting when CTF grows
+	support for non-ELF platforms that don't dot-prepend their section
+	names, but right now the linker doesn't link CTF on any such platforms
+	in any case.)
+
+	With this in place we can do things like run all the libctf tests under
+	leak sanitizers etc even if those spray warnings on simple CTF
+	compilations, rather than being blocked from doing so just when we would
+	most like to.
+
+	ld/
+		* testsuite/lib/ld-lib.exp (check_ctf_available): detect CTF
+		even if a CTF-capable compiler emits warnings.
+
+2022-03-23  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb/python: remove Python 2/3 compatibility macros
+	New in this version:
+
+	 - Rebase on master, fix a few more issues that appeared.
+
+	python-internal.h contains a number of macros that helped make the code
+	work with both Python 2 and 3.  Remove them and adjust the code to use
+	the Python 3 functions.
+
+	Change-Id: I99a3d80067fb2d65de4f69f6473ba6ffd16efb2d
+
+2022-03-23  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/python: remove Python 2 support
+	New in this version:
+
+	 - Add a PY_MAJOR_VERSION check in configure.ac / AC_TRY_LIBPYTHON.  If
+	   the user passes --with-python=python2, this will cause a configure
+	   failure saying that GDB only supports Python 3.
+
+	Support for Python 2 is a maintenance burden for any patches touching
+	Python support.  Among others, the differences between Python 2 and 3
+	string and integer types are subtle.  It requires a lot of effort and
+	thinking to get something that behaves correctly on both.  And that's if
+	the author and reviewer of the patch even remember to test with Python
+	2.
+
+	See this thread for an example:
+
+	  https://sourceware.org/pipermail/gdb-patches/2021-December/184260.html
+
+	So, remove Python 2 support.  Update the documentation to state that GDB
+	can be built against Python 3 (as opposed to Python 2 or 3).
+
+	Update all the spots that use:
+
+	 - sys.version_info
+	 - IS_PY3K
+	 - PY_MAJOR_VERSION
+	 - gdb_py_is_py3k
+
+	... to only keep the Python 3 portions and drop the use of some
+	now-removed compatibility macros.
+
+	I did not update the configure script more than just removing the
+	explicit references to Python 2.  We could maybe do more there, like
+	check the Python version and reject it if that version is not
+	supported.  Otherwise (with this patch), things will only fail at
+	compile time, so it won't really be clear to the user that they are
+	trying to use an unsupported Python version.  But I'm a bit lost in the
+	configure code that checks for Python, so I kept that for later.
+
+	Change-Id: I75b0f79c148afbe3c07ac664cfa9cade052c0c62
+
+2022-03-23  Jan Beulich  <jbeulich@suse.com>
+
+	x86: reject relocations involving registers
+	To prevent fatal or even internal errors, add a simple check to
+	i386_validate_fix(), rejecting relocations when their target symbol is
+	an equate of a register (or resolved to reg_section for any other
+	reason).
+
+	x86: improve resolution of register equates
+	Allow transitive (or recursive) equates to work in addition to direct
+	ones. The only requirements are that
+	- the equate being straight of a register, i.e. no expressions involved
+	  (albeit I'm afraid something like "%eax + 0" will be viewed as %eax),
+	- at the point of use there's no forward ref left which cannot be
+	  resolved, yet.
+
+	Revert "PR28977 tc-i386.c internal error in parse_register"
+	This reverts commit 5fac3f02edacfca458f7eeaaaa33a87e26e0e332,
+	which was superceeded / replaced by 4faaa10f3fab.
+
+2022-03-23  Jan Beulich  <jbeulich@suse.com>
+
+	x86: don't attempt to resolve equates and alike from i386_parse_name()
+	PR gas/28977
+
+	Perhaps right from its introduction in 4d1bb7955a8b it was wrong for
+	i386_parse_name() to call parse_register(). This being a hook from the
+	expression parser, it shouldn't be resolving e.g. equated symbols.
+	That's relevant only for all other callers of parse_register().
+
+	To compensate, in Intel syntax mode check_register() needs calling;
+	perhaps not doing so was an oversight right when the function was
+	introduced. This is necessary in particular to force EVEX encoding when
+	VRex registers are used (but of course also to reject bad uses of
+	registers, i.e. fully matching what parse_register() needs it for).
+
+2022-03-23  Luis Machado  <luis.machado@arm.com>
+
+	Update the list of recognized m-profile TAG_CPU_ARCH_*
+	Check 3 additional variants previously not recognized:
+
+	- TAG_CPU_ARCH_V7E_M
+	- TAG_CPU_ARCH_V8M_BASE
+	- TAG_CPU_ARCH_V8M_MAIN
+
+2022-03-23  Jan Beulich  <jbeulich@suse.com>
+
+	gas/Dwarf5: re-use file 0 line string table entry when faking file 0
+	No need to emit the same string a 2nd time for file 1 in this case.
+
+	gas/Dwarf5: adjust .debug_line file 0 checking
+	First of all when a table entry has a NULL filename, the two inner if()s
+	are better done the other way around: The 2nd doesn't depend on what the
+	first does. This then renders redundant half of the conditions of the
+	other if() and clarifies that subsequently only entry 0 is dealt with
+	(indicating that part of the comment was wrong). Finally for there to be
+	a usable name in slot 1, files_in_use needs to be larger than 1 and slot
+	1's (rather than slot 0's) name needs to be non-NULL.
+
+2022-03-23  Jan Beulich  <jbeulich@suse.com>
+
+	gas/Dwarf5: drop dead code
+	Commit 3417bfca676f ("GAS: DWARF-5: Ensure that the 0'th entry in the
+	directory table contains the current... ") added a "dwarf_level < 5"
+	check to out_dir_and_file_list(). This rendered dead that branch of the
+	construct, due to the enclosing if()'s "DWARF2_LINE_VERSION >= 5".
+	Delete that code as well as the corresponding part of the comment.
+
+	While there also drop a redundant "dirs != NULL": "dirs" will always be
+	non-NULL when dirs_in_use is not zero.
+
+2022-03-23  Jan Beulich  <jbeulich@suse.com>
+
+	gas/Dwarf: improve debug info generation from .irp and alike blocks
+	Tying the bumping of the logical line number to reading from the
+	original source file looks wrong: Upon finishing of the processing of an
+	sb the original values will be restored anyway. Yet without bumping the
+	line counter uses of .line inside e.g. an .irp construct won't have the
+	intended effect: Such uses may be necessary to ensure proper debug info
+	is emitted in particular when switching sections inside the .irp body,
+	as dwarf2_gen_line_info() would bail without doing anything when it
+	finds the line number unchanged from what it saw last.
+
+2022-03-23  Jan Beulich  <jbeulich@suse.com>
+
+	ELF32: don't silently truncate relocation addends
+	At least x86-64's x32 sub-mode and RISC-V's 32-bit mode calculate
+	addends as 64-bit values, but store them in signed 32-bit fields when
+	generating the file without encountering any earlier error. When the
+	relocated field is a 64-bit one, the value resulting after processing
+	the relocation record when linking (or the latest when loading) may
+	thus be wrong due to the truncation.
+
+	With the code change in place, one x32 testcase actually triggers the
+	new diagnostic. That one case of too large a (negative) addend is being
+	adjusted alongside the addition of a new testcase to actually trigger
+	the new error. (Note that due to internal BFD behavior the relocation in
+	.data doesn't get processed anymore after the errors in .text.)
+
+	Note that in principle it is possible to express 64-bit relocations in
+	ELF32, but this would require .rel relocations, i.e. with the addend
+	stored in the 64-bit field being relocated. But I guess it would be a
+	lot of effort for little gain to actually support this.
+
+2022-03-23  Jan Beulich  <jbeulich@suse.com>
+
+	gas: retain whitespace between strings
+	Macro arguments may be separated by commas or just whitespace. Macro
+	arguments may also be quoted (where one level of quotes is removed in
+	the course of determining the values for the respective formal
+	parameters). Furthermore this quote removal knows _two_ somewhat odd
+	escaping mechanisms: One, apparently in existence forever, is that a
+	pair of quotes counts as the escaping of a quote, with the pair being
+	transformed to a single quote in the course of quote removal. The other
+	(introduced by c06ae4f232e6) looks more usual on the surface in that it
+	deals with \" sequences, but it _retains_ the escaping \. Hence only the
+	former mechanism is suitable when the value to be used by the macro body
+	is to contain a quote. Yet this results in ambiguity of what "a""b" is
+	intended to mean; elsewhere (e.g. for .ascii) it represents two
+	successive string literals. However, in any event is the above different
+	from "a" "b": I don't think this can be viewed the same as "a""b" when
+	processing macro arguments.
+
+	Change the scrubber to retain such whitespace, by making the processing
+	of strings more similar to that of symbols. And indeed this appears to
+	make sense when taking into account that for quite a while gas has been
+	supporting quoted symbol names.
+
+	Taking a more general view, however, the change doesn't go quite far
+	enough. There are further cases where significant whitespace is removed
+	by the scrubber. The new testcase enumerates a few in its ".if 0"
+	section. I'm afraid the only way that I see to deal with this would be
+	to significantly simplify the scrubber, such that it wouldn't do much
+	more than collapse sequences of unquoted whitespace into a single blank.
+	To be honest problems in this area aren't really surprising when seeing
+	that there's hardly any checking of .macro use throughout the testsuite
+	(and in particular in the [relatively] generic tests under all/).
+
+2022-03-23  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+	Only .so files are used in libcollector. Remove the other files.
+		* libcollector/Makefile.am (install-data-local): Remove the *.la
+		and *.a libraries.
+		* libcollector/Makefile.in: Regenerate.
+
+2022-03-23  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: testsuite: use gdb_attach to fix jit-elf.exp
+	If /proc/sys/kernel/yama/ptrace_scope is 1, when execute the following
+	command without superuser:
+
+	  make check-gdb TESTS="gdb.base/jit-elf.exp"
+
+	we can see the following messages in gdb/testsuite/gdb.log:
+
+	  (gdb) attach 1650108
+	  Attaching to program: /home/yangtiezhu/build/gdb/testsuite/outputs/gdb.base/jit-elf/jit-elf-main, process 1650108
+	  ptrace: Operation not permitted.
+	  (gdb) FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach
+
+	use gdb_attach to fix the above issue, at the same time, the clean_reattach
+	proc should return a value to indicate whether it worked, and the callers
+	should return early as well on failure.
+
+2022-03-23  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: testsuite: use gdb_attach to fix attach-pie-noexec.exp
+	If /proc/sys/kernel/yama/ptrace_scope is 1, when execute the following
+	command without superuser:
+
+	  make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
+
+	we can see the following messages in gdb/testsuite/gdb.log:
+
+	  (gdb) attach 6500
+	  Attaching to process 6500
+	  ptrace: Operation not permitted.
+	  (gdb) PASS: gdb.base/attach-pie-noexec.exp: attach
+
+	It is obviously wrong, the expected result should be UNSUPPORTED in such
+	a case.
+
+	With this patch, we can see "Operation not permitted" in the log info,
+	and then we can do the following processes to test:
+	(1) set ptrace_scope as 0
+	    $ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
+	    $ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
+	(2) use sudo
+	    $ sudo make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
+
+2022-03-23  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: testsuite: add new gdb_attach to check "attach" command
+	This commit adds new gdb_attach to centralize the failure checking of
+	"attach" command. Return 0 if attach failed, otherwise return 1.
+
+2022-03-23  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: testsuite: remove attach test from can_spawn_for_attach
+	As Pedro Alves said, caching procs should not issue pass/fail [1],
+	this commit removes attach test from can_spawn_for_attach, at the
+	same time, use "verbose -log" instead of "unsupported" to get a
+	trace about why a test run doesn't support spawning for attach.
+
+	[1] https://sourceware.org/pipermail/gdb-patches/2022-March/186311.html
+
+2022-03-23  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-22  John Baldwin  <jhb@FreeBSD.org>
+
+	Add support for hardware breakpoints/watchpoints on FreeBSD/Aarch64.
+	This shares aarch64-nat.c and nat/aarch64-hw-point.c with the Linux
+	native target.  Since FreeBSD writes all of the debug registers in one
+	ptrace op, use an unordered_set<> to track the "dirty" state for
+	threads rather than bitmasks of modified registers.
+
+	fbsd-nat: Add a low_prepare_to_resume virtual method.
+	This method can be overridden by architecture-specific targets to
+	perform additional work before a thread is resumed.
+
+2022-03-22  John Baldwin  <jhb@FreeBSD.org>
+
+	fbsd-nat: Add a low_delete_thread virtual method.
+	This method can be overridden by architecture-specific targets to
+	perform additional work when a thread is deleted.
+
+	Note that this method is only invoked on systems supporting LWP
+	events, but the pending use case (aarch64 debug registers) is not
+	supported on older kernels that do not support LWP events.
+
+2022-03-22  John Baldwin  <jhb@FreeBSD.org>
+
+	fbsd-nat: Add helper routine to fetch siginfo_t for a ptid.
+
+2022-03-22  John Baldwin  <jhb@FreeBSD.org>
+
+	aarch64: Add an aarch64_nat_target mixin class.
+	This class includes platform-independent target methods for hardware
+	breakpoints and watchpoints using routines from
+	nat/aarch64-hw-point.c.
+
+	stopped_data_address is not platform-independent since the FAR
+	register holding the address for a breakpoint hit must be fetched in a
+	platform-specific manner.  However, aarch64_stopped_data_address is
+	provided as a helper routine which performs platform-independent
+	validation given the value of the FAR register.
+
+	For tracking the per-process debug register mirror state, use an
+	unordered_map indexed by pid as recently adopted in x86-nat.c rather
+	than a manual linked-list.
+
+2022-03-22  John Baldwin  <jhb@FreeBSD.org>
+
+	nat: Split out platform-independent aarch64 debug register support.
+	Move non-Linux-specific support for hardware break/watchpoints from
+	nat/aarch64-linux-hw-point.c to nat/aarch64-hw-point.c.  Changes
+	beyond a simple split of the code are:
+
+	- aarch64_linux_region_ok_for_watchpoint and
+	  aarch64_linux_any_set_debug_regs_state renamed to drop linux_ as
+	  they are not platform specific.
+
+	- Platforms must implement the aarch64_notify_debug_reg_change
+	  function which is invoked from the platform-independent code when a
+	  debug register changes for a given debug register state.  This does
+	  not use the indirection of a 'low' structure as is done for x86.
+
+	- The handling for kernel_supports_any_contiguous_range is not
+	  pristine.  For non-Linux it is simply defined to true.  Some uses of
+	  this could perhaps be implemented as new 'low' routines for the
+	  various places that check it instead?
+
+	- Pass down ptid into aarch64_handle_breakpoint and
+	  aarch64_handle_watchpoint rather than using current_lwp_ptid which
+	  is only defined on Linux.  In addition, pass the ptid on to
+	  aarch64_notify_debug_reg_change instead of the unused state
+	  argument.
+
+2022-03-22  John Baldwin  <jhb@FreeBSD.org>
+
+	x86-fbsd-nat: Copy debug register state on fork.
+	Use the FreeBSD native target low_new_fork hook to copy the
+	per-process debug state from the parent to the child on fork.
+
+	fbsd-nat: Add a low_new_fork virtual method.
+	This method can be overridden by architecture-specific targets to
+	perform additional work when a new child process is forked.
+
+2022-03-22  John Baldwin  <jhb@FreeBSD.org>
+
+	Add an x86_fbsd_nat_target mixin class for FreeBSD x86 native targets.
+	This class implements debug register support common between the i386
+	and amd64 native targets.
+
+	While here, remove #ifdef's for HAVE_PT_GETDBREGS in FreeBSD-specific
+	code.  The ptrace request has been present on FreeBSD x86
+	architectures since 4.0 (released in March 2000).  The last FreeBSD
+	release without this support is 3.5 released in June 2000.
+
+2022-03-22  John Baldwin  <jhb@FreeBSD.org>
+
+	x86-nat: Add x86_lookup_debug_reg_state.
+	This function returns nullptr if debug register state does not yet
+	exist for a given process rather than creating new state.
+
+	x86-nat: Use an unordered_map to store per-pid debug reg state.
+	This replaces a manual linked list which used O(n) lookup and removal.
+
+	Remove USE_SIGTRAP_SIGINFO condition for FreeBSD/x86 debug regs support.
+	For BSD x86 targets, stopped_by_hw_breakpoint doesn't check siginfo_t
+	but inspects the DR6 register directly via PT_GETDBREGS.
+
+2022-03-22  Tom Tromey  <tom@tromey.com>
+
+	Remove two unused variables
+	I found a couple of spots that declare a symtab_and_line but don't
+	actually use it.  I think this probably isn't detected as unused
+	because it has a constructor.
+
+2022-03-22  Steiner H Gunderson  <steinar+sourceware@gunderson.no>
+
+	Fix return code in _bfd_dwarf2_find_nearest_line().
+		* dwarf2.c (_bfd_dwarf2_find_nearest_line): if a function name is
+		found, but no line number info, then return a result of 2.
+
+2022-03-22  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb/python: add gdb.format_address function
+	Add a new function, gdb.format_address, which is a wrapper around
+	GDB's print_address function.
+
+	This method takes an address, and returns a string with the format:
+
+	  ADDRESS <SYMBOL+OFFSET>
+
+	Where, ADDRESS is the original address, formatted as hexadecimal,
+	SYMBOL is a symbol with an address lower than ADDRESS, and OFFSET is
+	the offset from SYMBOL to ADDRESS in decimal.
+
+	If there's no SYMBOL suitably close to ADDRESS then the
+	<SYMBOL+OFFSET> part is not included.
+
+	This is useful if a user wants to write a Python script that
+	pretty-prints addresses, the user no longer needs to do manual symbol
+	lookup, or worry about correctly formatting addresses.
+
+	Additionally, there are some settings that effect how GDB picks
+	SYMBOL, and whether the file name and line number should be included
+	with the SYMBOL name, the gdb.format_address function ensures that the
+	users Python script also benefits from these settings.
+
+	The gdb.format_address by default selects SYMBOL from the current
+	inferiors program space, and address is formatted using the
+	architecture for the current inferior.  However, a user can also
+	explicitly pass a program space and architecture like this:
+
+	  gdb.format_address(ADDRESS, PROGRAM_SPACE, ARCHITECTURE)
+
+	In order to format an address for a different inferior.
+
+	Notes on the implementation:
+
+	In py-arch.c I extended arch_object_to_gdbarch to add an assertion for
+	the type of the PyObject being worked on.  Prior to this commit all
+	uses of arch_object_to_gdbarch were guaranteed to pass this function a
+	gdb.Architecture object, but, with this commit, this might not be the
+	case.
+
+	So, with this commit I've made it a requirement that the PyObject be a
+	gdb.Architecture, and this is checked with the assert.  And in order
+	that callers from other files can check if they have a
+	gdb.Architecture object, I've added the new function
+	gdbpy_is_architecture.
+
+	In py-progspace.c I've added two new function, the first
+	progspace_object_to_program_space, converts a PyObject of type
+	gdb.Progspace to the associated program_space pointer, and
+	gdbpy_is_progspace checks if a PyObject is a gdb.Progspace or not.
+
+2022-03-22  Luis Machado  <luis.machado@arm.com>
+
+	Fix some stale header names from dwarf files
+	Some of these references were not updated when they were moved to a separate
+	directory.
+
+2022-03-22  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+	Install gprofng libraries under $(pkglibdir)
+	gprofng/ChangeLog
+	2022-03-21  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+	        PR gprofng/28972
+		* gprofng/libcollector/Makefile.am: Rename lib_LTLIBRARIES to
+		pkglib_LTLIBRARIES. Add install-data-local.
+		* gprofng/src/Makefile.am: Likewise.
+		* gprofng/src/envsets.cc (putenv_libcollector_ld_misc): New location of
+		the gprofng libraries.
+		* gprofng/configure.ac: Removed an unused GPROFNG_LIBDIR.
+		* gprofng/Makefile.am: Removed an unused GPROFNG_LIBDIR.  Add
+		install-data-local.
+		* gprofng/configure: Regenerate.
+		* gprofng/Makefile.in: Likewise.
+		* gprofng/doc/Makefile.in: Likewise.
+		* gprofng/gp-display-htmllibcollector/Makefile.in: Likewise.
+		* gprofng/libcollector/Makefile.in: Likewise.
+		* gprofng/src/Makefile.in: Likewise.
+
+2022-03-22  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-21  Roland McGrath  <mcgrathr@google.com>
+
+	gdb: Add missing #include in solib.h
+	The gdb_bfd_ref_ptr type is used in solib.h declarations.
+
+2022-03-21  Aaron Merey  <amerey@redhat.com>
+
+	PR gdb/27570: missing support for debuginfod in core_target::build_file_mappings
+	Add debuginfod support to core_target::build_file_mappings and
+	locate_exec_from_corefile_build_id to enable the downloading of
+	missing executables and shared libraries referenced in core files.
+
+	Also add debuginfod support to solib_map_sections so that previously
+	downloaded shared libraries can be retrieved from the local debuginfod
+	cache.
+
+	When core file shared libraries are found locally, verify that their
+	build-ids match the corresponding build-ids found in the core file.
+	If there is a mismatch, attempt to query debuginfod for the correct
+	build and print a warning if unsuccessful:
+
+	  warning: Build-id of /lib64/libc.so.6 does not match core file.
+
+	Also disable debuginfod when gcore invokes gdb.  Debuginfo is not
+	needed for core file generation so debuginfod queries will slow down
+	gcore unnecessarily.
+
+2022-03-21  Aaron Merey  <amerey@redhat.com>
+
+	gdb: Add soname to build-id mapping for core files
+	Since commit aa2d5a422 gdb has been able to read executable and shared
+	library build-ids within core files.
+
+	Expand this functionality so that each core file bfd maintains a map of
+	soname to build-id for each shared library referenced in the core file.
+
+	This feature may be used to verify that gdb has found the correct shared
+	libraries for core files and to facilitate downloading shared libaries via
+	debuginfod.
+
+2022-03-21  Pedro Alves  <pedro@palves.net>
+
+	Watchpoint followed by catchpoint misreports watchpoint (PR gdb/28621)
+	If GDB reports a watchpoint hit, and then the next event is not
+	TARGET_WAITKIND_STOPPED, but instead some event for which there's a
+	catchpoint, such that GDB calls bpstat_stop_status, GDB mistakenly
+	thinks the watchpoint triggered.  Vis, using foll-fork.c:
+
+	  (gdb) awatch v
+	  Hardware access (read/write) watchpoint 2: v
+	  (gdb) catch fork
+	  Catchpoint 3 (fork)
+	  (gdb) c
+	  Continuing.
+
+	  Hardware access (read/write) watchpoint 2: v
+
+	  Old value = 0
+	  New value = 5
+	  main () at gdb.base/foll-fork.c:16
+	  16        pid = fork ();
+	  (gdb)
+	  Continuing.
+
+	  Hardware access (read/write) watchpoint 2: v      <<<<
+	                                                    <<<< these lines are spurious
+	  Value = 5                                         <<<<
+
+	  Catchpoint 3 (forked process 1712369), arch_fork (ctid=0x7ffff7fa4810) at arch-fork.h:49
+	  49      arch-fork.h: No such file or directory.
+	  (gdb)
+
+	The problem is that when we handle the fork event, nothing called
+	watchpoints_triggered before calling bpstat_stop_status.  Thus, each
+	watchpoint's watchpoint_triggered field was still set to
+	watch_triggered_yes from the previous (real) watchpoint stop.
+	watchpoint_triggered is only current called in the handle_signal_stop
+	path, when handling TARGET_WAITKIND_STOPPED.
+
+	This fixes it by adding watchpoint_triggered calls in the other events
+	paths that call bpstat_stop_status.  But instead of adding them
+	explicitly, it adds a new function bpstat_stop_status_nowatch that
+	wraps bpstat_stop_status and calls watchpoint_triggered, and then
+	replaces most calls to bpstat_stop_status with calls to
+	bpstat_stop_status_nowatch.
+
+	This required constifying watchpoints_triggered.
+
+	New test included, which fails without the fix.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28621
+
+	Change-Id: I282b38c2eee428d25319af3bc842f9feafed461c
+
+2022-03-21  Pedro Alves  <pedro@palves.net>
+
+	gdbserver: Fixup previous patch
+	The previous prepare_resume_reply change missed updating the 'buf'
+	reference that overwrites the 'T', so if 'buf' was advanced, we'd
+	still overwrite the wrong character.  This fixes it.
+
+	Change-Id: Ia8ce433366b85af4e268c1c49e7b447da3130a4d
+
+2022-03-21  Pedro Alves  <pedro@palves.net>
+
+	gdbserver: Fix incorrect assertion
+	While playing with adding a new event kind, I noticed that
+	prepare_resume_reply TARGET_WAITKIND_FORKED, etc. advance 'buf', so if
+	we force-disable the T packet, we'd fail the *buf == 'T' assertion.
+
+	Fix it by tweaking the assertion to always look at the beginning of
+	the buffer.
+
+	Change-Id: I8c38e32353db115edcde418b3b1e8ba12343c22b
+
+2022-03-21  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: re-generate config.in
+	I'm getting this diff when running `autoreconf -vf`.
+
+	Change-Id: Id5f009d0f0481935c1ee9df5332cb4bf45fbd32d
+
+2022-03-21  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/x86: handle stap probe arguments in xmm registers
+	On x86 machines with xmm register, and with recent versions of
+	systemtap (and gcc?), it can occur that stap probe arguments will be
+	placed into xmm registers.
+
+	I notice this happening on a current Fedora Rawhide install with the
+	following package versions installed:
+
+	  $ rpm -q glibc systemtap gcc
+	  glibc-2.35.9000-10.fc37.x86_64
+	  systemtap-4.7~pre16468670g9f253544-1.fc37.x86_64
+	  gcc-12.0.1-0.12.fc37.x86_64
+
+	If I check the probe data in libc, I see this:
+
+	  $ readelf -n /lib64/libc.so.6
+	  ...
+	  stapsdt              0x0000004d       NT_STAPSDT (SystemTap probe descriptors)
+	    Provider: libc
+	    Name: pthread_start
+	    Location: 0x0000000000090ac3, Base: 0x00000000001c65c4, Semaphore: 0x0000000000000000
+	    Arguments: 8@%xmm1 8@1600(%rbx) 8@1608(%rbx)
+	  stapsdt              0x00000050       NT_STAPSDT (SystemTap probe descriptors)
+	    Provider: libc
+	    Name: pthread_create
+	    Location: 0x00000000000912f1, Base: 0x00000000001c65c4, Semaphore: 0x0000000000000000
+	    Arguments: 8@%xmm1 8@%r13 8@8(%rsp) 8@16(%rsp)
+	  ...
+
+	Notice that for both of these probes, the first argument is a uint64_t
+	stored in the xmm1 register.
+
+	Unfortunately, if I try to use this probe within GDB, then I can't
+	view the first argument.  Here's an example session:
+
+	  $ gdb $(which gdb)
+	  (gdb) start
+	  ...
+	  (gdb) info probes stap  libc pthread_create
+	  ...
+	  (gdb) break *0x00007ffff729e2f1       # Use address of probe.
+	  (gdb) continue
+	  ...
+	  (gdb) p $_probe_arg0
+	  Invalid cast.
+
+	What's going wrong?  If I re-run my session, but this time use 'set
+	debug stap-expression 1', this is what I see:
+
+	  (gdb) set debug stap-expression 1
+	  (gdb) p $_probe_arg0
+	  Operation: UNOP_CAST
+	   Operation: OP_REGISTER
+	    String: xmm1
+	   Type: uint64_t
+	  Operation: UNOP_CAST
+	   Operation: OP_REGISTER
+	    String: r13
+	   Type: uint64_t
+	  Operation: UNOP_CAST
+	   Operation: UNOP_IND
+	    Operation: UNOP_CAST
+	     Operation: BINOP_ADD
+	      Operation: OP_LONG
+	       Type: long
+	       Constant: 0x0000000000000008
+	      Operation: OP_REGISTER
+	       String: rsp
+	     Type: uint64_t *
+	   Type: uint64_t
+	  Operation: UNOP_CAST
+	   Operation: UNOP_IND
+	    Operation: UNOP_CAST
+	     Operation: BINOP_ADD
+	      Operation: OP_LONG
+	       Type: long
+	       Constant: 0x0000000000000010
+	      Operation: OP_REGISTER
+	       String: rsp
+	     Type: uint64_t *
+	   Type: uint64_t
+	  Invalid cast.
+	  (gdb)
+
+	The important bit is this:
+
+	  Operation: UNOP_CAST
+	   Operation: OP_REGISTER
+	    String: xmm1
+	   Type: uint64_t
+
+	Which is where we cast the xmm1 register to uint64_t.  And the final
+	piece of the puzzle is:
+
+	  (gdb) ptype $xmm1
+	  type = union vec128 {
+	      v8bf16 v8_bfloat16;
+	      v4f v4_float;
+	      v2d v2_double;
+	      v16i8 v16_int8;
+	      v8i16 v8_int16;
+	      v4i32 v4_int32;
+	      v2i64 v2_int64;
+	      uint128_t uint128;
+	  }
+
+	So, we are attempting to cast a union type to a scalar type, which is
+	not supporting in C/C++, and as a consequence GDB's expression
+	evaluator throws an error when we attempt to do this.
+
+	The first approach I considered for solving this problem was to try
+	and make use of gdbarch_stap_adjust_register.  We already have a
+	gdbarch method (gdbarch_stap_adjust_register) that allows us to tweak
+	the name of the register that we access.  Currently only x86
+	architectures use this to transform things like ax to eax in some
+	cases.
+
+	I wondered, what if we change gdbarch_stap_adjust_register to do more
+	than just change the register names?  What if this method instead
+	became gdbarch_stap_read_register.  This new method would return a
+	operation_up, and would take the register name, and the type we are
+	trying to read from the register, and return the operation that
+	actually reads the register.
+
+	The default implementation of this method would just use
+	user_reg_map_name_to_regnum, and then create a register_operation,
+	like we already do in stap_parse_register_operand.  But, for x86
+	architectures this method would fist possibly adjust the register
+	name, then do the default action to read the register.  Finally, for
+	x86 this method would spot when we were accessing an xmm register,
+	and, based on the type being pulled from the register, would extract
+	the correct field from the union.
+
+	The benefit of this approach is that it would work with the expression
+	types that GDB currently supports.  The draw back would be that this
+	approach would not be very generic.  We'd need code to handle each
+	sub-field size with an xmm register.  If other architectures started
+	using vector registers for probe arguments, those architectures would
+	have to create their own gdbarch_stap_read_register method.  And
+	finally, the type of the xmm registers comes from the type defined in
+	the target description, there's a risk that GDB might end up
+	hard-coding the names of type sub-fields, then if a target uses a
+	different target description, with different field names for xmm
+	registers, the stap probes would stop working.
+
+	And so, based on all the above draw backs, I rejected this first
+	approach.
+
+	My second plan involves adding a new expression type to GDB called
+	unop_extract_operation.  This new expression takes a value and a type,
+	during evaluation the value contents are fetched, and then a new value
+	is extracted from the value contents (based on type).  This is similar
+	to the following C expression:
+
+	  result_value = *((output_type *) &input_value);
+
+	Obviously we can't actually build this expression in this case, as the
+	input_value is in a register, but hopefully the above makes it clearer
+	what I'm trying to do.
+
+	The benefit of the new expression approach is that this code can be
+	shared across all architectures, and it doesn't care about sub-field
+	names within the union type.
+
+	The draw-backs that I see are potential future problems if arguments
+	are not stored within the least significant bytes of the register.
+	However if/when that becomes an issue we can adapt the
+	gdbarch_stap_read_register approach to allow architectures to control
+	how a value is extracted.
+
+	For testing, I've extended the existing gdb.base/stap-probe.exp test
+	to include a function that tries to force an argument into an xmm
+	register.  Obviously, that will only work on a x86 target, so I've
+	guarded the new function with an appropriate GCC define.  In the exp
+	script we use readelf to check if the probe exists, and is using the
+	xmm register.
+
+	If the probe doesn't exist then the associated tests are skipped.
+
+	If the probe exists, put isn't using the xmm register (which will
+	depend on systemtap/gcc versions), then again, the tests are skipped.
+
+	Otherwise, we can run the test.  I think the cost of running readelf
+	is pretty low, so I don't feel too bad making all the non-xmm targets
+	running this step.
+
+	I found that on a Fedora 35 install, with these packages installed, I
+	was able to run this test and have the probe argument be placed in an
+	xmm register:
+
+	  $ rpm -q systemtap gcc glibc
+	  systemtap-4.6-4.fc35.x86_64
+	  gcc-11.2.1-9.fc35.x86_64
+	  glibc-2.34-7.fc35.x86_64
+
+	Finally, as this patch adds a new operation type, then I need to
+	consider how to generate an agent expression for the new operation
+	type.
+
+	I have kicked the can down the road a bit on this.  In the function
+	stap_parse_register_operand, I only create a unop_extract_operation in
+	the case where the register type is non-scalar, this means that in
+	most cases I don't need to worry about generating an agent expression
+	at all.
+
+	In the xmm register case, when an unop_extract_operation will be
+	created, I have sketched out how the agent expression could be
+	handled, however, this code is currently not reached.  When we try to
+	generate the agent expression to place the xmm register on the stack,
+	GDB hits this error:
+
+	  (gdb) trace -probe-stap test:xmmreg
+	  Tracepoint 1 at 0x401166
+	  (gdb) actions
+	  Enter actions for tracepoint 1, one per line.
+	  End with a line saying just "end".
+	  >collect $_probe_arg0
+	  Value not scalar: cannot be an rvalue.
+
+	This is because GDB doesn't currently support placing non-scalar types
+	on the agent expression evaluation stack.  Solving this is clearly
+	related to the original problem, but feels a bit like a second
+	problem.  I'd like to get feedback on whether my approach to solving
+	the original problem is acceptable or not before I start looking at
+	how to handle xmm registers within agent expressions.
+
+2022-03-21  Steiner H Gunderson  <steinar+sourceware@gunderson.no>
+
+	Reduce O(n2) performance overhead when parsing DWARF unit information.
+		PR 28978
+		* dwarf2.c (scan_unit_for_symbols): When performing second pass,
+		check to see if the function or variable being processed is the
+		same as the previous one.
+
+2022-03-21  Jan Beulich  <jbeulich@suse.com>
+
+	x86: don't suppress overflow diagnostics in x32 mode
+	Unlike in 64-bit mode, where values wrap at the 64-bit boundary anyway,
+	there's no wrapping at the 32-bit boundary here, and hence overflow
+	detection shouldn't be suppressed just because rela relocations are
+	going to be used.
+
+	The extra check against NO_RELOC is actually a result of an ilp32 test
+	otherwise failing. But thinking about it, reporting overflows for
+	not-really-relocations (typically because of earlier errors) makes
+	little sense in general. Perhaps this should even be extended to non-
+	64-bit modes.
+
+2022-03-21  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb/testsuite: reformat gdb.python/pretty-print-call-by-hand.py
+	Run black on the file.
+
+	Change-Id: Ifb576137fb7158a0227173f61c1202f0695b3685
+
+2022-03-21  Bruno Larsen  <blarsen@redhat.com>
+
+	[gdb/testsuite] test a function call by hand from pretty printer
+	The test case added here is testing the bug gdb/28856, where calling a
+	function by hand from a pretty printer makes GDB crash. There are 6
+	mechanisms to trigger this crash in the current test, using the commands
+	backtrace, up, down, finish, step and continue. Since the failure happens
+	because of use-after-free (more details below) the tests will always
+	have a chance of passing through sheer luck, but anecdotally they seem
+	to fail all of the time.
+
+	The reason GDB is crashing is a use-after-free problem. The above
+	mentioned functions save a pointer to the current frame's information,
+	then calls the pretty printer, and uses the saved pointer for different
+	reasons, depending on the function. The issue happens because
+	call_function_by_hand needs to reset the obstack to get the current
+	frame, invalidating the saved pointer.
+
+2022-03-21  Pedro Alves  <pedro@palves.net>
+
+	gdb/testsuite: Installed-GDB testing & data-directory
+	In testsuite/README, we suggest that you can run the testsuite against
+	some other GDB binary by using:
+
+	    make check RUNTESTFLAGS=GDB=/usr/bin/gdb
+
+	However, that example isn't fully correct, because with that command
+	line, the testsuite will still pass
+
+	  -data-directory=[pwd]/../data-directory
+
+	to /usr/bin/gdb, like e.g.:
+
+	  ...
+	  builtin_spawn /usr/bin/gdb -nw -nx -data-directory /home/pedro/gdb/build/gdb/testsuite/../data-directory -iex set height 0 -iex set width 0
+	  ...
+
+	while if you're testing an installed GDB (the system GDB being the
+	most usual scenario), then you should normally let it use its own
+	configured directory, not the just-built GDB's data directory.
+
+	This commit improves the status quo with the following two changes:
+
+	 - if the user specifies GDB on the command line, then by default,
+	   don't start GDB with the -data-directory command line option.
+	   I.e., let the tested GDB use its own configured data directory.
+
+	 - let the user override the data directory, via a new
+	   GDB_DATA_DIRECTORY global.  This replaces the existing
+	   BUILD_DATA_DIRECTORY variable in testsuite/lib/gdb.exp, which
+	   wasn't overridable, and was a bit misnamed for the new purpose.
+
+	So after this, the following commands I believe behave intuitively:
+
+	 # Test the non-installed GDB in some build dir:
+
+	    make check \
+	      RUNTESTFLAGS="GDB=/path/to/other/build/gdb \
+	                    GDB_DATA_DIRECTORY=/path/to/other/build/gdb/data-directory"
+
+	 # Test the GDB installed in some prefix:
+
+	    make check \
+	      RUNTESTFLAGS="GDB=/opt/gdb/bin/gdb"
+
+	 # Test the built GDB with some alternative data directory, e.g., the
+	   system GDB's data directory:
+
+	    make check \
+	      RUNTESTFLAGS="GDB_DATA_DIRECTORY=/usr/share/gdb"
+
+	Change-Id: Icdc21c85219155d9564a9900961997e6624b78fb
+
+2022-03-21  Nick Clifton  <nickc@redhat.com>
+
+	z80 assembler: Fix new unexpected overflow warning in v2.37
+		PR 28791
+		* config/tc-z80.c (emit_data_val): Do not warn about overlarge
+		constants generated by bit manipulation operators.
+		* testsuite/gas/z80/pr28791.s: New test source file.
+		* testsuite/gas/z80/pr28791.d: New test driver file.
+
+2022-03-21  Andreas Schwab  <schwab@linux-m68k.org>
+
+	Add support for readline 8.2
+	In readline 8.2 the type of rl_completer_word_break_characters changed to
+	include const.
+
+2022-03-21  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-20  Andreas Schwab  <schwab@linux-m68k.org>
+
+	RISC-V: Fix misplaced @end table
+	Move the csr-check and arch items inside the table for the .option directive.
+
+2022-03-20  Alan Modra  <amodra@gmail.com>
+
+	PR28979, internal error in demand_empty_rest_of_line
+	The change in read_a_source_file prevents the particular testcase in
+	the PR from triggering the assertion in demand_empty_rest_of_line.
+	I've also removed the assertion.  Nothing much goes wrong with gas if
+	something else triggers it, so it's not worthy of an abort.
+
+	I've also changed my previous patch to ignore_rest_of_line to allow
+	that function to increment input_line_pointer past buffer_limit, like
+	demand_empty_rest_of_line:  The two functions ought to behave the
+	same in that respect.  Finally, demand_empty_rest_of_line gets a
+	little hardening to prevent accesses past buffer_limit plus one.
+
+		PR 28979
+		* read.c (read_a_source_file): Calculate known size for sbuf
+		rather than calling strlen.
+		(demand_empty_rest_of_line): Remove "know" check.  Expand comment.
+		Don't dereference input_line_pointer when past buffer_limit.
+		(ignore_rest_of_line): Allow input_line_pointer to increment to
+		buffer_limit plus one.  Expand comment.
+
+2022-03-20  Joel Brobecker  <brobecker@adacore.com>
+
+	Update gdb/NEWS after GDB 12 branch creation.
+	This commit a new section for the next release branch, and renames
+	the section of the current branch, now that it has been cut.
+
+2022-03-20  Joel Brobecker  <brobecker@adacore.com>
+
+	Bump version to 13.0.50.DATE-git.
+	Now that the GDB 12 branch has been created,
+	this commit bumps the version number in gdb/version.in to
+	13.0.50.DATE-git
+
+	For the record, the GDB 12 branch was created
+	from commit 2be64de603f8b3ae359d2d3fbf5db0e79869f32b.
+
+	Also, as a result of the version bump, the following changes
+	have been made in gdb/testsuite:
+
+		* gdb.base/default.exp: Change $_gdb_major to 13.
+
+2022-03-20  liuzhensong  <liuzhensong@loongson.cn>
+
+	ld:LoongArch: Add test cases to adapt to LoongArch32 and LoongArch64
+	  ld/testsuite/ld-loongarch-elf
+
+	  *  ld-loongarch-elf.exp:  Test LoongArch32 and LoongArch64 testcases respectively.
+	  *  jmp_op.d: Fix bug in test LoongArch32.
+	  *  disas-jirl-32.d: New test case for LoongArch32.
+	  *  disas-jirl-32.s: New test case for LoongArch32.
+	  *  disas-jirl.d: Skip test case LoongArch32.
+	  *  macro_op_32.d: New test case for LoongArch32.
+	  *  macro_op_32.s: New test case for LoongArch32.
+	  *  macro_op.d: Skip test case LoongArch32.
+
+2022-03-20  liuzhensong  <liuzhensong@loongson.cn>
+
+	gas:LoongArch: Fix "make check" pr21884 fail in LoongArch32.
+	  gas/config/
+	    * tc-loongarch.c: Add function to select target mach.
+	    * tc-loongarch.h: Define macro TARGET_MACH.
+
+	ld: loongarch: Skip unsupport test cases.
+	  ld/testsuite/ld-elf/
+	    * eh5.d		Skip loongarch64 target.
+	    * pr21884.d		Skip loongarch* targets.
+	    * pr26936.d		Skip loongarch* targets.
+
+2022-03-20  liuzhensong  <liuzhensong@loongson.cn>
+
+	LoongArch: Fix LD check fails.
+	  Some test cases about ifunc.
+
+	  bfd/
+	    * elfnn-loongarch.c
+	    * elfxx-loongarch.h
+
+	   === ld Summary ===
+	  of expected passes             1430
+	  of expected failures           11
+	  of untested testcases          1
+	  of unsupported tests           154
+
+2022-03-20  liuzhensong  <liuzhensong@loongson.cn>
+
+	LoongArch: Update ABI eflag in elf header.
+	  Update LoongArch ABI eflag in elf header.
+	    ilp32s  0x5
+	    ilp32f  0x6
+	    ilp32d  0x7
+	    lp64s   0x1
+	    lp64f   0x2
+	    lp64d   0x3
+
+	  bfd/
+	    * elfnn-loongarch.c Check object flags while ld.
+
+	  gas/
+	    * tc-loongarch.c Write eflag to elf header.
+
+	  include/elf
+	        * loongarch.h Define ABI number.
+
+2022-03-20  liuzhensong  <liuzhensong@loongson.cn>
+
+	gas:LoongArch: Fix wrong line number in .debug_line
+	  The dwarf2_emit_insn() can create debuginfo of line. But it is called
+	  too late in append_fixp_and_insn. It causes extra offs when debuginfo
+	  of line sets address.
+
+	  gas/config/
+	    * tc-loongarch.c
+
+2022-03-20  liuzhensong  <liuzhensong@loongson.cn>
+
+	gas:LoongArch: Fix segment error in compilation due to too long symbol name.
+	  Change "char buffer[8192];" into "char *buffer =
+	  (char *) malloc(1000 +  6 * len_str);" in function
+	  loongarch_expand_macro_with_format_map.
+
+	  gas/
+	    * config/tc-loongarch.c
+
+	  include/
+	    * opcode/loongarch.h
+
+	  opcodes/
+	    * loongarch-coder.c
+
+2022-03-20  liuzhensong  <liuzhensong@loongson.cn>
+
+	LoongArch: Use functions instead of magic numbers.
+	  Replace the magic numbers in gas(tc-loongarch.c) and
+	  bfd(elfnn-loongarch.c) with the functions defined in
+	  the howto table(elfxx-loongarch.c).
+
+	  gas/
+	    * config/tc-loongarch.c: use functions.
+
+	  bfd/
+	    * elfnn-loongarch.c: use functions.
+	    * elfxx-loongarch.c: define functions.
+	    * elfxx-loongarch.h
+
+2022-03-20  liuzhensong  <liuzhensong@loongson.cn>
+
+	ubsan: loongarch : signed integer shift overflow.
+	   opcodes/
+		* loongarch-coder.c :
+		  int32_t ret = 0;
+		  ret <<= sizeof (ret) * 8 - len;
+		  ret >>= sizeof (ret) * 8 - len;
+		  ...
+		  Avoid ubsan warning.
+
+2022-03-20  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-19  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb/python: remove gdb._mi_commands dict
+	The motivation for this patch is the fact that py-micmd.c doesn't build
+	with Python 2, due to PyDict_GetItemWithError being a Python 3-only
+	function:
+
+	      CXX    python/py-micmd.o
+	    /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’:
+	    /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’?
+	      430 |   PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (),
+	          |                    ^~~~~~~~~~~~~~~~~~~~~~~
+	          |                    PyDict_GetItemString
+
+	A first solution to fix this would be to try to replace
+	PyDict_GetItemWithError equivalent Python 2 code.  But I looked at why
+	we are doing this in the first place: it is to maintain the
+	`gdb._mi_commands` Python dictionary that we use as a `name ->
+	gdb.MICommand object` map.  Since the `gdb._mi_commands` dictionary is
+	never actually used in Python, it seems like a lot of trouble to use a
+	Python object for this.
+
+	My first idea was to replace it with a C++ map
+	(std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>).  While
+	implementing this, I realized we don't really need this map at all.  The
+	mi_command_py objects registered in the main MI command table can own
+	their backing micmdpy_object (that's a gdb.MICommand, but seen from the
+	C++ code).  To know whether an mi_command is an mi_command_py, we can
+	use a dynamic cast.  Since there's one less data structure to maintain,
+	there are less chances of messing things up.
+
+	 - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is
+	   now what keeps the MICommand alive.
+	 - Set micmdpy_object::mi_command in the constructor of mi_command_py.
+	   If mi_command_py manages setting/clearing that field in
+	   swap_python_object, I think it makes sense that it also takes care of
+	   setting it initially.
+	 - Move a bunch of checks from micmdpy_install_command to
+	   swap_python_object, and make them gdb_asserts.
+	 - In micmdpy_install_command, start by doing an mi_cmd_lookup.  This is
+	   needed to know whether there's a Python MI command already registered
+	   with that name.  But we can already tell if there's a non-Python
+	   command registered with that name.  Return an error if that happens,
+	   rather than waiting for insert_mi_cmd_entry to fail.  Change the
+	   error message to "name is already in use" rather than "may already be
+	   in use", since it's more precise.
+
+	I asked Andrew about the original intent of using a Python dictionary
+	object to hold the command objects.  The reason was to make sure the
+	objects get destroyed when the Python runtime gets finalized, not later.
+	Holding the objects in global C++ data structures and not doing anything
+	more means that the held Python objects will be decref'd after the
+	Python interpreter has been finalized.  That's not desirable.  I tried
+	it and it indeed segfaults.
+
+	Handle this by adding a gdbpy_finalize_micommands function called in
+	finalize_python.  This is the mirror of gdbpy_initialize_micommands
+	called in do_start_initialization.  In there, delete all Python MI
+	commands.  I think it makes sense to do it this way: if it was somehow
+	possible to unload Python support from GDB in the middle of a session
+	we'd want to unregister any Python MI command.  Otherwise, these MI
+	commands would be backed with a stale PyObject or simply nothing.
+
+	Delete tests that were related to `gdb._mi_commands`.
+
+	Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
+	Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
+
+2022-03-19  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-18  Pedro Alves  <pedro@palves.net>
+
+	Fix crash with stepi, no debug info, and "set debug infrun 1"
+	A stepi in a function without debug info with "set debug infrun 1"
+	crashes GDB since commit c8353d682f69 (gdb/infrun: some extra infrun
+	debug print statements), due to a reference to
+	"tp->current_symtab->filename" when tp->current_symtab is null.
+
+	This commit adds the missing null check.  The output in this case
+	becomes:
+
+	  [infrun] set_step_info: symtab = <null>, line = 0, step_frame_id = {stack=0x7fffffffd980,code=0x0000000000456c30,!special}, step_stack_frame_id = {stack=0x7fffffffd980,code=0x0000000000456c30,!special}
+
+	Change-Id: I5171a9d222bc7e15b9dba2feaba7d55c7acd99f8
+
+2022-03-18  Tom Tromey  <tromey@adacore.com>
+
+	Implement gdbarch_stack_frame_destroyed_p for aarch64
+	The internal AdaCore testsuite has a test that checks that an
+	out-of-scope watchpoint is deleted.  This fails on some aarch64
+	configurations, reporting an extra stop:
+
+	    (gdb) continue
+	    Continuing.
+
+	    Thread 3 hit Watchpoint 2: result
+
+	    Old value = 64
+	    New value = 0
+	    0x0000000040021648 in pck.get_val (seed=0, off_by_one=false) at [...]/pck.adb:13
+	    13	   end Get_Val;
+
+	I believe what is happening here is that the variable is stored at:
+
+	    <efa>   DW_AT_location    : 2 byte block: 91 7c 	(DW_OP_fbreg: -4)
+
+	and the extra stop is reported just before a return, when the ldp
+	instruction is executed:
+
+	   0x0000000040021644 <+204>:	ldp	x29, x30, [sp], #48
+	   0x0000000040021648 <+208>:	ret
+
+	This instruction modifies the frame base calculation, and so the test
+	picks up whatever memory is pointed to in the callee frame.
+
+	Implementing the gdbarch hook gdbarch_stack_frame_destroyed_p fixes
+	this problem.
+
+	As usual with this sort of patch, it has passed internal testing, but
+	I don't have a good way to try it with dejagnu.  So, I don't know
+	whether some existing test covers this.  I suspect there must be one,
+	but it's also worth noting that this test passes for aarch64 in some
+	configurations -- I don't know what causes one to fail and another to
+	succeed.
+
+2022-03-18  Nick Clifton  <nickc@redhat.com>
+
+	Fix Build issues due to patch "gprofng: a new GNU profiler"
+	  Find and fix more places where clock_gettime() and CLOCK_MONOTONIC_RAW are used.
+
+2022-03-18  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: run black to format some Python files
+	Seems like some leftovers from previous commits.
+
+	Change-Id: I7155ccdf7a4fef83bcb3d60320252c3628efdb83
+
+2022-03-18  Viorel Preoteasa  <viorel.preoteasa@gmail.com>
+
+	Fix ld-arm bug in encoding of blx calls jumping from thumb to arm instructions
+		PR 28924
+		* elf32-arm.c (THM_MAX_FWD_BRANCH_OFFSET): Fix definition.
+		(THM2_MAX_FWD_BRANCH_OFFSET): Likewise.
+
+2022-03-18  Jan Beulich  <jbeulich@suse.com>
+
+	x86: also fold remaining multi-vector-size shift insns
+	By slightly relaxing the checking in operand_type_register_match() we
+	can fold the vector shift insns with an XMM source as well. While
+	strictly speaking an overlap in just one size (see the code comment) is
+	not enough (both operands could have multiple sizes with just a single
+	common one), this is good enough for all templates we have, or which
+	could sensibly / usefully appear (within the scope of the present
+	operand matching model).
+
+	Tightening this a little would be possible, but would require broadcast
+	related information to be passed into the function.
+
+2022-03-18  Jan Beulich  <jbeulich@suse.com>
+
+	x86: drop stray CheckRegSize from VEXTRACT{F,I}32X4
+	They have only a single operand allowing multiple sizes, hence there are
+	no pairs of operands to check for consistent size.
+
+	x86: fold certain AVX2 templates into their AVX counterparts
+	Like for AVX512VL we can make the handling of operand sizes a little
+	more flexible to allow reducing the number of templates we have.
+
+2022-03-18  Tsukasa OI  <research_trasio@irq.a4lg.com>
+
+	RISC-V: Cache management instructions
+	This commit adds 'Zicbom' / 'Zicboz' instructions.
+
+	bfd/ChangeLog:
+
+		* elfxx-riscv.c (riscv_multi_subset_supports): Add handling for
+		new instruction classes.
+
+	include/ChangeLog:
+
+		* opcode/riscv-opc.h (MATCH_CBO_CLEAN, MASK_CBO_CLEAN,
+		MATCH_CBO_FLUSH, MASK_CBO_FLUSH, MATCH_CBO_INVAL,
+		MASK_CBO_INVAL, MATCH_CBO_ZERO, MASK_CBO_ZERO): New macros.
+		* opcode/riscv.h (enum riscv_insn_class): Add new instruction
+		classes INSN_CLASS_ZICBOM and INSN_CLASS_ZICBOZ.
+
+	opcodes/ChangeLog:
+
+		* riscv-opc.c (riscv_opcodes): Add cache-block management
+		instructions.
+
+2022-03-18  Tsukasa OI  <research_trasio@irq.a4lg.com>
+
+	RISC-V: Prefetch hint instructions and operand set
+	This commit adds 'Zicbop' hint instructions.
+
+	bfd/ChangeLog:
+
+		* elfxx-riscv.c (riscv_multi_subset_supports): Add handling for
+		new instruction class.
+
+	gas/ChangeLog:
+
+		* config/tc-riscv.c (riscv_ip): Add handling for new operand
+		type 'f' (32-byte aligned pseudo S-type immediate for prefetch
+		hints).
+		(validate_riscv_insn): Likewise.
+
+	include/ChangeLog:
+
+		* opcode/riscv-opc.h (MATCH_PREFETCH_I, MASK_PREFETCH_I,
+		MATCH_PREFETCH_R, MASK_PREFETCH_R, MATCH_PREFETCH_W,
+		MASK_PREFETCH_W): New macros.
+		* opcode/riscv.h (enum riscv_insn_class): Add new instruction
+		class INSN_CLASS_ZICBOP.
+
+	opcodes/ChangeLog:
+
+		* riscv-dis.c (print_insn_args): Add handling for new operand
+		type.
+		* riscv-opc.c (riscv_opcodes): Add prefetch hint instructions.
+
+2022-03-18  Alan Modra  <amodra@gmail.com>
+
+	PR28977 tc-i386.c internal error in parse_register
+		PR 28977
+		* config/tc-i386.c (parse_register): Handle X_op not O_register
+		as for a non-reg_section symbol.  Simplify array bounds check.
+
+2022-03-18  Alan Modra  <amodra@gmail.com>
+
+	Tidy gas current_frame before exit
+	Releases some obstack memory on an error path.
+
+		* cond.c (cond_finish_check): Call cond_exit_macro.
+
+2022-03-18  Alan Modra  <amodra@gmail.com>
+
+	ubsan: logical_input_line signed integer overflow
+	To avoid a completely useless fuzzing ubsan "bug" report, I decided to
+	make logical_input_line unsigned.
+
+		* input-scrub.c (logical_input_line): Make unsigned.
+		(struct input_save): Here too.
+		(input_scrub_reinit, input_scrub_close, bump_line_counters),
+		(as_where): Adjust to suit.
+
+2022-03-18  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-17  H.J. Lu  <hjl.tools@gmail.com>
+
+	gprofng: Skip jsynprog with a broken javac
+	On CET enabled Linux/x86-64 machines, one can get
+
+	$ javac simple.java
+	Error: dl failure on line 894
+	Error: failed /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.322.b06-6.fc35.x86_64/jre/lib/amd64/server/libjvm.so, because /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.322.b06-6.fc35.x86_64/jre/lib/amd64/server/libjvm.so: rebuild shared object with SHSTK support enabled
+
+	Set GPROFNG_BROKEN_JAVAC to "yes" only with a broken javac and skip the
+	jsynprog test with a broken javac.
+
+		PR gprofng/28965
+		* Makefile.am (GPROFNG_BROKEN_JAVAC): New.
+		(check-DEJAGNU): Pass GPROFNG_BROKEN_JAVAC to runtest.
+		* configure.ac (GPROFNG_BROKEN_JAVAC): New AC_SUBST.  Set to yes
+		with a broken javac.
+		* Makefile.in: Regenerate.
+		* configure: Likewise.
+		* testsuite/gprofng.display/display.exp: Skip jsynprog with a
+		broken javac.
+
+2022-03-17  John Baldwin  <jhb@FreeBSD.org>
+
+	Remove fall throughs in core_target::xfer_partial.
+	The cases for TARGET_OBJECT_LIBRARIES and TARGET_OBJECT_LIBRARIES_AIX
+	can try to fetch different data objects (such as
+	TARGET_OBJECT_SIGNAL_INFO) if gdbarch methods for the requested data
+	aren't present.  Return with TARGET_XFER_E_IO if the gdbarch method
+	isn't present instead.
+
+2022-03-17  Pedro Alves  <pedro@palves.net>
+
+	gdb: Remove support for S+core
+	GCC removed support for score back in 2014 already.  Back then, we
+	basically agreed about removing it from GDB too, but it ended up being
+	forgotten.  See:
+
+	 https://sourceware.org/pipermail/gdb/2014-October/044643.html
+
+	Following through this time around.
+
+	Change-Id: I5b25a1ff7bce7b150d6f90f4c34047fae4b1f8b4
+
+2022-03-17  Tom Tromey  <tromey@adacore.com>
+
+	Add another test for Ada Wide_Wide_String
+	In an earlier patch, I had written that I wanted to add this test:
+
+	      ptype Wide_Wide_String'("literal")
+
+	... but that it failed with the distro GNAT.  Further investigation
+	showed that it could be made to work by adding a function using
+	Wide_Wide_String to the program -- this caused the type to end up in
+	the debug info.
+
+	This patch adds the test.  I'm checking this in.
+
+2022-03-17  Alan Modra  <amodra@gmail.com>
+
+	ubsan: Null dereference in parse_module
+		* vms-alpha.c (parse_module): Sanity check that DST__K_RTNBEG
+		has set module->func_table for DST__K_RTNEND.  Check return
+		of bfd_zalloc.
+
+2022-03-17  Alan Modra  <amodra@gmail.com>
+
+	asan: Buffer overflow in evax_bfd_print_dst
+	With "name" a char*, the length at name[0] might be negative, escaping
+	buffer limit checks.
+
+		* vms-alpha.c (evax_bfd_print_dst): Make name an unsigned char*.
+		(evax_bfd_print_emh): Likewise.
+
+2022-03-17  Alan Modra  <amodra@gmail.com>
+
+	asan: Buffer overflow in som_set_reloc_info
+		* som.c (som_set_reloc_info): Add symcount parameter.  Don't
+		access symbols past symcount.  Don't access fixup past end_fixups.
+		(som_slurp_reloc_table): Adjust som_set_reloc_info calls.
+
+2022-03-17  Alan Modra  <amodra@gmail.com>
+
+	asan: use of uninitialized value in buffer_and_nest
+	More occurences of the same as commit d12b8d620c6a.
+
+		* macro.c (buffer_and_nest): Sanity check length in buffer
+		before calling strncasecmp.
+
+2022-03-17  Alan Modra  <amodra@gmail.com>
+
+	gprofng configure target tests
+	${target} in configure.ac should be the canonical target, so that for
+	example, someone configuring with --target=x86_64-linux will match
+	x86_64-*-linux*.
+
+		* configure.ac: Invoke AC_CANONICAL_TARGET.
+		* libcollector/configure.ac: Likewise.
+		* Makefile.in: Regenerate.
+		* configure: Regenerate.
+		* doc/Makefile.in: Regenerate.
+		* gp-display-html/Makefile.in: Regenerate.
+		* libcollector/Makefile.in: Regenerate.
+		* libcollector/configure: Regenerate.
+		* src/Makefile.in: Regenerate.
+
+2022-03-17  Alan Modra  <amodra@gmail.com>
+
+	Re: asan: buffer overflow in peXXigen.c
+	In the process of fixing a buffer overflow in commit fe69d4fcf0194a,
+	I managed to introduce a fairly obvious NULL pointer dereference..
+
+		* peXXigen.c (_bfd_XX_bfd_copy_private_bfd_data_common): Don't
+		segfault on not finding section.  Wrap overlong lines.
+
+2022-03-17  Alan Modra  <amodra@gmail.com>
+
+	asan: buffer overflows after calling ignore_rest_of_line
+	operand() is not a place that should be calling ignore_rest_of_line.
+	ignore_rest_of_line shouldn't increment input_line_pointer if already
+	at buffer limit.
+
+		* expr.c (operand): Don't call ignore_rest_of_line.
+		* read.c (s_mri_common): Likewise.
+		(ignore_rest_of_line): Don't increment input_line_pointer if
+		already at buffer_limit.
+
+2022-03-17  Alan Modra  <amodra@gmail.com>
+
+	Re: bfd: add AMDGCN architecture
+		* po/SRC-POTFILES.in: Regenerate.
+
+2022-03-17  Jan Beulich  <jbeulich@suse.com>
+
+	x86: don't accept base architectures as extensions
+	The -march= intentions are quite clear: A base architecture may be
+	followed by any number of extensions. Accepting a base architecture in
+	place of an extension will at best result in confusion, as the first of
+	the two (or more) items specified simply would not take effect, due to
+	being overridden by the later one(s).
+
+2022-03-17  Jan Beulich  <jbeulich@suse.com>
+
+	x86: never set i386_cpu_flags' "unused" field
+	Setting this field risks cpu_flags_all_zero() mistakenly returning
+	"false" when the object passed in was e.g. the result of ANDing together
+	two objects which had the bit set, or ANDNing together an object with
+	the field set and one with the field clear.
+
+	While there also avoid setting CpuNo64: Like Cpu64 this is driven
+	differently anyway and hence shouldn't be set anywhere by default.
+
+	Note that the moving of the two items in i386-gen.c's cpu_flags[] is
+	only for documentation purposes (and slight reducing of overhead), as
+	the fields are sorted anyway upon program start.
+
+2022-03-17  Jan Beulich  <jbeulich@suse.com>
+
+	x86: unify CPU flag on/off processing
+	There's no need for the arbitrary special "unknown" token: Simply
+	recognize the leading ~ and process everything else the same, merely
+	recording whether to set individual fields to 1 or 0.
+
+	While there exclude CpuIAMCU from CPU_UNKNOWN_FLAGS - CPU_IAMCU_FLAGS
+	override cpu_arch_flags anyway when -march=iamcu is passed, and there's
+	no reason to have the stray flag set even if no insn actually is keyed
+	to it.
+
+2022-03-17  Jan Beulich  <jbeulich@suse.com>
+
+	x86: add another IAMCU testcase
+	Now that {L,K}1OM support is gone, and with it the brokenness in
+	check_cpu_arch_compatible(), put in place a test making sure that only
+	extensions can be enabled via .arch for IAMCU, and that the base
+	architecture cannot be changed.
+
+	x86: drop L1OM/K1OM support from gas
+	This was only rudimentary support anyway; none of the sub-architecture
+	specific insns were ever supported.
+
+	x86: assorted IAMCU CPU checking fixes
+	The checks done by check_cpu_arch_compatible() were halfway sensible
+	only at the time where only L1OM support was there. The purpose,
+	however, has always been to prevent bad uses of .arch (turning off the
+	base CPU "feature" flag) while at the same time permitting extensions to
+	be enabled / disabled. In order to achieve this (and to prevent
+	regressions when L1OM and K1OM support are removed)
+	- set CpuIAMCU in CPU_IAMCU_FLAGS,
+	- adjust the IAMCU check in the function itself (the other two similarly
+	  broken checks aren't adjusted as they're slated to be removed anyway),
+	- avoid calling the function for extentions (which would never have the
+	  base "feature" flag set),
+	- add a new testcase actually exercising ".arch iamcu" (which would also
+	  regress with the planned removal).
+
+2022-03-17  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-16  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: work around prompt corruption caused by bracketed-paste-mode
+	In this commit:
+
+	  commit b4f26d541aa7224b70d363932e816e6e1a857633
+	  Date:   Tue Mar 2 13:42:37 2021 -0700
+
+	      Import GNU Readline 8.1
+
+	We imported readline 8.1 into GDB.  As a consequence bug PR cli/28833
+	was reported.  This bug spotted that, when the user terminated GDB by
+	sending EOF (usually bound to Ctrl+d), the last prompt would become
+	corrupted.  Here's what happens, the user is sat at a prompt like
+	this:
+
+	  (gdb)
+
+	And then the user sends EOF (Ctrl+d), we now see this:
+
+	  quit)
+	  ... gdb terminates, and we return to the shell ...
+
+	Notice the 'quit' was printed over the prompt.
+
+	This problem is a result of readline 8.1 enabling bracketed paste mode
+	by default.  This problem is present in readline 8.0 too, but in that
+	version of readline bracketed paste mode is off by default, so a user
+	will not see the bug unless they specifically enable the feature.
+
+	Bracketed paste mode is available in readline 7.0 too, but the bug
+	is not present in this version of readline, see below for why.
+
+	What causes this problem is how readline disables bracketed paste
+	mode.  Bracketed paste mode is a terminal feature that is enabled and
+	disabled by readline emitting a specific escape sequence.  The problem
+	for GDB is that the escape sequence to disable bracketed paste mode
+	includes a '\r' character at the end, see this thread for more
+	details:
+
+	  https://lists.gnu.org/archive/html/bug-bash/2018-01/msg00097.html
+
+	The change to add the '\r' character to the escape sequence used to
+	disable bracketed paste mode was introduced between readline 7.0 and
+	readline 8.0, this is why the bug would not occur when using older
+	versions of readline (note: I don't know if its even possible to build
+	GDB using readline 7.0.  That really isn't important, I'm just
+	documenting the history of this issue).
+
+	So, the escape sequence to disable bracketed paste mode is emitted
+	from the readline function rl_deprep_terminal, this is called after
+	the user has entered a complete command and pressed return, or, if the
+	user sends EOF.
+
+	However, these two cases are slightly different.  In the first case,
+	when the user has entered a command and pressed return, the cursor
+	will have moved to the next, empty, line, before readline emits the
+	escape sequence to leave bracketed paste mode.  The final '\r'
+	character moves the cursor back to the beginning of this empty line,
+	which is harmless.
+
+	For the EOF case though, this is not what happens.  Instead, the
+	escape sequence to leave bracketed paste mode is emitted on the same
+	line as the prompt.  The final '\r' moves the cursor back to the start
+	of the prompt line.  This leaves us ready to override the prompt.
+
+	It is worth noting, that this is not the intended behaviour of
+	readline, in rl_deprep_terminal, readline should emit a '\n' character
+	when EOF is seen.  However, due to a bug in readline this does not
+	happen (the _rl_eof_found flag is never set).  This is the first
+	readline bug that effects GDB.
+
+	GDB prints the 'quit' message from command_line_handler (in
+	event-top.c), this function is called (indirectly) from readline to
+	process the complete command line, but also in the EOF case (in which
+	case the command line is set to nullptr).  As this is part of the
+	callback to process a complete command, this is called after readline
+	has disabled bracketed paste mode (by calling rl_deprep_terminal).
+
+	And so, when bracketed paste mode is in use, rl_deprep_terminal leaves
+	the cursor at the start of the prompt line (in the EOF case), and
+	command_line_handler then prints 'quit', which overwrites the prompt.
+
+	The solution to this problem is to print the 'quit' message earlier,
+	before rl_deprep_terminal is called.  This is easy to do by using the
+	rl_deprep_term_function hook.  It is this hook that usually calls
+	rl_deprep_terminal, however, if we replace this with a new function,
+	we can print the 'quit' string, and then call rl_deprep_terminal
+	ourselves.  This allows the 'quit' to be printed before
+	rl_deprep_terminal is called.
+
+	The problem here is that there is no way in rl_deprep_terminal to know
+	if readline is processing EOF or not, and as a result, we don't know
+	when we should print 'quit'.  This is the second readline bug that
+	effects GDB.
+
+	Both of these readline issues are discussed in this thread:
+
+	  https://lists.gnu.org/archive/html/bug-readline/2022-02/msg00021.html
+
+	The result of that thread was that readline was patched to address
+	both of these issues.
+
+	Now it should be easy to backport the readline fix to GDB's in tree
+	copy of readline, and then change GDB to make use of these fixes to
+	correctly print the 'quit' string.
+
+	However, we are just about to branch GDB 12, and there is concern from
+	some that changing readline this close to a new release is a risky
+	idea, see this thread:
+
+	  https://sourceware.org/pipermail/gdb-patches/2022-March/186391.html
+
+	So, this commit doesn't change readline at all.  Instead, this commit
+	is the smallest possible GDB change in order to avoid the prompt
+	corruption.
+
+	In this commit I change GDB to print the 'quit' string on the line
+	after the prompt, but only when bracketed paste mode is on.  This
+	avoids the overwriting issue, the user sees this:
+
+	  (gdb)
+	  quit
+	  ... gdb terminates, and returns to the shell ...
+
+	This isn't ideal, but is better than the existing behaviour.  After
+	GDB 12 has branched, we can backport the readline fix, and apply a
+	real fix to GDB.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28833
+
+2022-03-16  Fangrui Song  <i@maskray.me>
+
+	objcopy --weaken-symbol: apply to STB_GNU_UNIQUE symbols
+	    PR binutils/28926
+	    * objcopy.c (filter_symbols): Apply weaken to STB_GNU_UNIQUE symbols
+	    * NEWS: Mention feature.
+	    * testsuite/binutils-all/objcopy.exp (objcopy_test_symbol_manipulation): New test.
+	    * testsuite/binutils-all/weaken-gnu-unique.s: New.
+
+2022-03-16  Tom Tromey  <tromey@adacore.com>
+
+	Reimplement array concatenation for Ada and D
+	This started as a patch to implement string concatenation for Ada.
+	However, while working on this, I looked at how this code could
+	possibly be called.  It turns out there are only two users of
+	concat_operation: Ada and D.  So, in addition to implementing this for
+	Ada, this patch rewrites value_concat, removing the odd "concatenate
+	or repeat" semantics, which were completely unused.  As Ada and D both
+	seem to represent strings using TYPE_CODE_ARRAY, this removes the
+	TYPE_CODE_STRING code from there as well.
+
+	Remove eval_op_concat
+	eval_op_concat has code to search for an operator overload of
+	BINOP_CONCAT.  However, the operator overloading code is specific to
+	C++, which does not have this operator.  And,
+	binop_types_user_defined_p rejects this case right at the start, and
+	value_x_binop does not handle this case.  I think this code has been
+	dead for a very long time.  This patch removes it and hoists the
+	remaining call into concatenation::evaluate, removing eval_op_concat
+	entirely.
+
+2022-03-16  Tom Tromey  <tromey@adacore.com>
+
+	Ada support for wide strings
+	This adds some basic support for Wide_String and Wide_Wide_String to
+	the Ada expression evaluator.  In particular, a string literal may be
+	converted to a wide or wide-wide string depending on context.
+
+	The patch updates an existing test case.  Note that another test,
+	namely something like:
+
+	    ptype Wide_Wide_String'("literal")
+
+	... would be nice to add, but when tested against a distro GNAT, this
+	did not work (probably due to lack of debuginfo); so, I haven't
+	included it here.
+
+2022-03-16  Tom Tromey  <tromey@adacore.com>
+
+	Remove eval_op_string
+	eval_op_string is only used in a single place -- the implementation of
+	string_operation.  This patch turns it into the
+	string_operation::evaluate method, removing a bit of extraneous code.
+
+2022-03-16  Carl Love  <cel@us.ibm.com>
+
+	Powerpc fix for gdb.base/ending-run.exp
+	The last two tests in gdb.base/ending-run.exp case fail on Powerpc when the
+	system does not have the needed glibc debug-info files loaded.  In this
+	case, gdb is not able to determine where execution stopped.  This behavior
+	looks as follows for the test case:
+
+	The next to the last test does a next command when the program is stopped
+	at the closing bracket for main.  The message printed is:
+
+	0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6
+
+	which fails to match any of the test_multiple options.
+
+	The test then does another next command.  On Powerpc, the
+	message printed it:
+
+	Cannot find bounds of current function
+
+	The test fails as the output does not match any of the options for the
+	gdb_test_multiple.
+
+	I checked the behavior on Powerpc to see if this is typical.
+	I ran gdb on the following simple program as shown below.
+
+	#include <stdio.h>
+	int
+	main(void)
+	{
+	  printf("Hello, world!\n");
+	  return 0;
+	}
+
+	gdb ./hello_world
+	<snip the gdb start info>
+
+	Type "apropos word" to search for commands related to "word"...
+	Reading symbols from ./hello_world...
+	(No debugging symbols found in ./hello_world)
+	(gdb) break main
+	Breakpoint 1 at 0x818
+	(gdb) r
+
+	Starting program: /home/carll/hello_world
+	[Thread debugging using libthread_db enabled]
+	Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1".
+
+	Breakpoint 1, 0x0000000100000818 in main ()
+	(gdb) n
+	Single stepping until exit from function main,
+	which has no line number information.
+	Hello, world!
+	0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6
+	(gdb) n
+	Cannot find bounds of current function
+
+	So it would seem that the messages seen from the test case are
+	"normal" output for Powerpc when the debug-info is not available.
+
+	The following patch adds the output from Powerpc as an option
+	to the gdb_test_multiple statement, identifying the output as the expected
+	output on Powerpc without the needed debug-info files installed.
+
+	The patch has been tested on a Power 10 system and an Intel
+	64-bit system.  No additional regression failures were seen on
+	either platform.
+
+2022-03-16  Martin Storsj?  <martin@martin.st>
+
+	dlltool: Use the output name as basis for deterministic temp prefixes
+		PR 28885
+		* dlltool.c (main): use imp_name rather than dll_name when
+		generating a temporary file name.
+
+2022-03-16  Jan Vrany  <jan.vrany@labware.com>
+	    Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/mi: consistently notify user when GDB/MI client uses -thread-select
+	GDB notifies users about user selected thread changes somewhat
+	inconsistently as mentioned on gdb-patches mailing list here:
+
+	  https://sourceware.org/pipermail/gdb-patches/2022-February/185989.html
+
+	Consider GDB debugging a multi-threaded inferior with both CLI and GDB/MI
+	interfaces connected to separate terminals.
+
+	Assuming inferior is stopped and thread 1 is selected, when a thread
+	2 is selected using '-thread-select 2' command on GDB/MI terminal:
+
+	    -thread-select 2
+	    ^done,new-thread-id="2",frame={level="0",addr="0x00005555555551cd",func="child_sub_function",args=[],file="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",fullname="/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c",line="30",arch="i386:x86-64"}
+	    (gdb)
+
+	and on CLI terminal we get the notification (as expected):
+
+	    [Switching to thread 2 (Thread 0x7ffff7daa640 (LWP 389659))]
+	    #0  child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30
+	    30        volatile int dummy = 0;
+
+	However, now that thread 2 is selected, if thread 1 is selected
+	using 'thread-select --thread 1 1' command on GDB/MI terminal
+	terminal:
+
+	   -thread-select --thread 1 1
+	   ^done,new-thread-id="1",frame={level="0",addr="0x0000555555555294",func="main",args=[],file="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",fullname="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",line="66",arch="i386:x86-64"}
+	   (gdb)
+
+	but no notification is printed on CLI terminal, despite the fact
+	that user selected thread has changed.
+
+	The problem is that when `-thread-select --thread 1 1` is executed
+	then thread is switched to thread 1 before mi_cmd_thread_select () is
+	called, therefore the condition "inferior_ptid != previous_ptid"
+	there does not hold.
+
+	To address this problem, we have to move notification logic up to
+	mi_cmd_execute () where --thread option is processed and notify
+	user selected contents observers there if context changes.
+
+	However, this in itself breaks GDB/MI because it would cause context
+	notification to be sent on MI channel. This is because by the time
+	we notify, MI notification suppression is already restored (done in
+	mi_command::invoke(). Therefore we had to lift notification suppression
+	logic also up to mi_cmd_execute (). This change in made distinction
+	between mi_command::invoke() and mi_command::do_invoke() unnecessary
+	as all mi_command::invoke() did (after the change) was to call
+	do_invoke(). So this patches removes do_invoke() and moves the command
+	execution logic directly to invoke().
+
+	With this change, all gdb.mi tests pass, tested on x86_64-linux.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20631
+
+2022-03-16  H.J. Lu  <hjl.tools@gmail.com>
+
+	gprofng: Use symver attribute if available
+	Use symver attribute if available, instead of asm statement, to support
+	LTO build.
+
+		PR gprof/28962
+		* libcollector/dispatcher.c (timer_create@@GLIBC_2.3.3): Use
+		SYMVER_ATTRIBUTE.
+		(timer_create@GLIBC_2.2): Likewise.
+		(timer_create@GLIBC_2.2.5): Likewise.
+		(pthread_create@@GLIBC_2.1): Likewise.
+		(pthread_create@GLIBC_2.0): Likewise.
+		* libcollector/iotrace.c (open64@@GLIBC_2.2): Likewise.
+		(open64@GLIBC_2.1): Likewise.
+		(fopen@@GLIBC_2.1): Likewise.
+		(fopen@GLIBC_2.0): Likewise.
+		(fclose@@GLIBC_2.1): Likewise.
+		(fclose@GLIBC_2.0): Likewise.
+		(fdopen@@GLIBC_2.1): Likewise.
+		(fdopen@GLIBC_2.0): Likewise.
+		(pread@@GLIBC_2.2): Likewise.
+		(pread@GLIBC_2.1): Likewise.
+		(pwrite@@GLIBC_2.2): Likewise.
+		(pwrite@GLIBC_2.1): Likewise.
+		(pwrite64@@GLIBC_2.2): Likewise.
+		(pwrite64@GLIBC_2.1): Likewise.
+		(fgetpos@@GLIBC_2.2): Likewise.
+		(fgetpos@GLIBC_2.0): Likewise.
+		(fgetpos64@@GLIBC_2.2): Likewise.
+		(fgetpos64@GLIBC_2.1): Likewise.
+		(fsetpos@@GLIBC_2.2): Likewise.
+		(fsetpos@GLIBC_2.0): Likewise.
+		(fsetpos64@@GLIBC_2.2): Likewise.
+		(fsetpos64@GLIBC_2.1): Likewise.
+		* libcollector/linetrace.c (posix_spawn@@GLIBC_2.15): Likewise.
+		(posix_spawn@GLIBC_2.2): Likewise.
+		(posix_spawn@GLIBC_2.2.5): Likewise.
+		(posix_spawnp@@GLIBC_2.15): Likewise.
+		(posix_spawnp@GLIBC_2.2): Likewise.
+		(posix_spawnp@GLIBC_2.2.5): Likewise.
+		(popen@@GLIBC_2.1): Likewise.
+		(popen@GLIBC_2.0): Likewise.
+		(_popen@@GLIBC_2.1): Likewise.
+		(_popen@GLIBC_2.0): Likewise.
+		* libcollector/mmaptrace.c (dlopen@@GLIBC_2.1): Likewise.
+		(dlopen@GLIBC_2.0): Likewise.
+		* libcollector/synctrace.c (pthread_cond_wait@@GLIBC_2.3.2):
+		Likewise.
+		(pthread_cond_wait@GLIBC_2.0): Likewise.
+		(pthread_cond_wait@GLIBC_2.2.5): Likewise.
+		(pthread_cond_wait@GLIBC_2.2): Likewise.
+		(pthread_cond_timedwait@@GLIBC_2.3.2): Likewise.
+		(pthread_cond_timedwait@GLIBC_2.0): Likewise.
+		(pthread_cond_timedwait@GLIBC_2.2.5): Likewise.
+		(pthread_cond_timedwait@GLIBC_2.2): Likewise.
+		(sem_wait@@GLIBC_2.1): Likewise.
+		(sem_wait@GLIBC_2.0): Likewise.
+		* src/collector_module.h (SYMVER_ATTRIBUTE): New.
+
+2022-03-16  H.J. Lu  <hjl.tools@gmail.com>
+
+	gprofng: Don't hardcode -Wno-format-truncation/-Wno-switch
+	Use -Wno-format-truncation and -Wno-switch only if they are supported.
+
+		PR gprof/28969
+		* configure.ac (GPROFNG_NO_FORMAT_TRUNCATION_CFLAGS): New
+		AC_SUBST for -Wno-format-truncation.
+		(GPROFNG_NO_SWITCH_CFLAGS): New AC_SUBST for -Wno-switch.
+		* Makefile.in: Regenerate.
+		* configure: Likewise.
+		* src/Makefile.am (AM_CFLAGS): Replace -Wno-format-truncation
+		and -Wno-switch with GPROFNG_NO_FORMAT_TRUNCATION_CFLAGS and
+		GPROFNG_NO_SWITCH_CFLAGS.
+		* src/Makefile.in: Regenerate.
+
+2022-03-16  H.J. Lu  <hjl.tools@gmail.com>
+
+	gprofng: Don't hardcode -Wno-nonnull-compare
+	Use -Wno-nonnull-compare only if it is supported.
+
+		PR gprof/28969
+		* libcollector/Makefile.am (AM_CFLAGS): Replace
+		-Wno-nonnull-compare with GPROFNG_NO_NONNULL_COMPARE_CFLAGS.
+		* libcollector/configure.ac (GPROFNG_NO_NONNULL_COMPARE_CFLAGS):
+		New AC_SUBST for -Wno-nonnull-compare.
+		* libcollector/Makefile.in: Regenerate.
+		* libcollector/aclocal.m4: Likewise.
+		* libcollector/configure: Likewise.
+
+2022-03-16  H.J. Lu  <hjl.tools@gmail.com>
+
+	gprofng: Define ATTRIBUTE_FALLTHROUGH
+	Define ATTRIBUTE_FALLTHROUGH to __attribute__ ((fallthrough)) only for
+	GCC 7 or above.
+
+		PR gprof/28969
+		* common/gp-defs.h (ATTRIBUTE_FALLTHROUGH): New.
+		* src/gp-collect-app.cc (collect::check_args): Replace
+		/* FALLTHROUGH */ with ATTRIBUTE_FALLTHROUGH.
+
+2022-03-16  Simon Marchi  <simon.marchi@efficios.com>
+
+	binutils/readelf: handle AMDGPU relocation types
+	Make readelf recognize AMDGPU relocation types, as documented here:
+
+	  https://llvm.org/docs/AMDGPUUsage.html#amdgpu-relocation-records
+
+	The user-visible change looks like:
+
+	    -000000000004  000400000001 unrecognized: 1       0000000000000000 SCRATCH_RSRC_DWORD0
+	    -00000000000c  000500000001 unrecognized: 1       0000000000000000 SCRATCH_RSRC_DWORD1
+	    -000000000014  000600000007 unrecognized: 7       0000000000000000 global_var0
+	    -00000000001c  000700000008 unrecognized: 8       0000000000000000 global_var1
+	    -000000000024  000800000009 unrecognized: 9       0000000000000000 global_var2
+	    -00000000002c  00090000000a unrecognized: a       0000000000000000 global_var3
+	    -000000000034  000a0000000b unrecognized: b       0000000000000000 global_var4
+	    +000000000004  000400000001 R_AMDGPU_ABS32_LO 0000000000000000 SCRATCH_RSRC_DWORD0
+	    +00000000000c  000500000001 R_AMDGPU_ABS32_LO 0000000000000000 SCRATCH_RSRC_DWORD1
+	    +000000000014  000600000007 R_AMDGPU_GOTPCREL 0000000000000000 global_var0
+	    +00000000001c  000700000008 R_AMDGPU_GOTPCREL 0000000000000000 global_var1
+	    +000000000024  000800000009 R_AMDGPU_GOTPCREL 0000000000000000 global_var2
+	    +00000000002c  00090000000a R_AMDGPU_REL32_LO 0000000000000000 global_var3
+	    +000000000034  000a0000000b R_AMDGPU_REL32_HI 0000000000000000 global_var4
+
+	binutils/ChangeLog:
+
+		* readelf.c (dump_relocations): Handle EM_AMDGPU.
+
+	include/ChangeLog:
+
+		* elf/amdgpu.h: Add relocation values.
+
+	Change-Id: I2ed4589f4cd37ea11ad2e0cb38d4b682271e1334
+
+2022-03-16  Simon Marchi  <simon.marchi@efficios.com>
+
+	binutils/readelf: build against msgpack, dump NT_AMDGPU_METADATA note contents
+	The AMDGPU HSA OS ABI (code object v3 and above) defines the
+	NT_AMDGPU_METADATA ELF note [1].  The content is a msgpack object
+	describing, among other things, the kernels present in the code object
+	and how to call them.
+
+	I think it would be useful for readelf to be able to display the content
+	of those notes.  msgpack is a structured format, a bit like JSON, except
+	not text-based.  It is therefore possible to dump the contents in
+	human-readable form without knowledge of the specific layout of the
+	note.
+
+	Add configury to binutils to optionally check for the msgpack C library
+	[2].  Add There is a new --with{,out}-msgpack configure flag, and the actual
+	library lookup is done using pkg-config.
+
+	If msgpack support is enabled, dumping a NT_AMDGPU_METADATA note looks
+	like:
+
+	    $ readelf --notes amdgpu-code-object
+	    Displaying notes found in: .note
+	      Owner                Data size        Description
+	      AMDGPU               0x0000040d       NT_AMDGPU_METADATA (code object metadata)
+	        {
+	          "amdhsa.kernels": [
+	            {
+	              ".args": [
+	                {
+	                  ".address_space": "global",
+	                  ".name": "out.coerce",
+	                  ".offset": 0,
+	                  ".size": 8,
+	                  ".value_kind": "global_buffer",
+	                },
+	      <snip>
+
+	If msgpack support is disabled, dump the contents as hex, as is done
+	with notes that are not handled in a special way.  This allows one to
+	decode the contents manually (maybe using a command-line msgpack
+	decoder) if really needed.
+
+	[1] https://llvm.org/docs/AMDGPUUsage.html#code-object-metadata
+	[2] https://github.com/msgpack/msgpack-c/tree/c_master
+
+	binutils/ChangeLog:
+
+		* Makefile.am (readelf_CFLAGS): New.
+		(readelf_LDADD): Add MSGPACK_LIBS.
+		* Makefile.in: Re-generate.
+		* config.in: Re-generate.
+		* configure: Re-generate.
+		* configure.ac: Add --with-msgpack flag and check for msgpack
+		using pkg-config.
+		* readelf.c: Include msgpack.h if HAVE_MSGPACK.
+		(print_note_contents_hex): New.
+		(print_indents): New.
+		(dump_msgpack_obj): New.
+		(dump_msgpack): New.
+		(print_amdgpu_note): New.
+		(process_note): Handle NT_AMDGPU_METADATA note contents.
+		Use print_note_contents_hex.
+
+	Change-Id: Ia60a654e620bc32dfdb1bccd845594e2af328b84
+
+2022-03-16  Simon Marchi  <simon.marchi@efficios.com>
+
+	binutils/readelf: handle NT_AMDGPU_METADATA note name
+	Handle the NT_AMDGPU_METADATA note, which is described here:
+
+	  https://llvm.org/docs/AMDGPUUsage.html#code-object-v3-note-records
+
+	As of this patch, just print out the name, not the contents, which is in
+	the msgpack format.
+
+	binutils/ChangeLog:
+
+		* readelf.c (get_amdgpu_elf_note_type): New.
+		(process_note): Handle "AMDGPU" notes.
+
+	include/ChangeLog:
+
+		* elf/amdgcn.h (NT_AMDGPU_METADATA): New.
+
+	Change-Id: Id2dba2e2aeaa55ef7464fb35aee9c7d5f96ddb23
+
+2022-03-16  Simon Marchi  <simon.marchi@efficios.com>
+
+	binutils/readelf: decode AMDGPU-specific e_flags
+	Decode and print the AMDGPU-specific fields of e_flags, as documented
+	here:
+
+	  https://llvm.org/docs/AMDGPUUsage.html#header
+
+	That is:
+
+	 - The specific GPU model
+	 - Whether the xnack and sramecc features are enabled
+
+	The result looks like:
+
+	-  Flags:                             0x52f
+	+  Flags:                             0x52f, gfx906, xnack any, sramecc any
+
+	The flags for the "HSA" OS ABI are properly versioned and documented on
+	that page.  But the NONE, PAL and MESA3D OS ABIs are not well documented
+	nor versioned.  Taking a peek at the LLVM source code, we see that they
+	encode their flags the same way as HSA v3.  For example, for PAL:
+
+	  https://github.com/llvm/llvm-project/blob/c8b614cd74a92d85936aed5ac7c642af75ffdc29/llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp#L601
+
+	So for those other OS ABIs, we read them the same as HSA v3.
+
+	binutils/ChangeLog:
+
+		* readelf.c: Include elf/amdgcn.h.
+		(decode_AMDGPU_machine_flags): New.
+		(get_machine_flags): Handle flags for EM_AMDGPU machine type.
+
+	include/ChangeLog:
+
+		* elf/amdgcn.h: Add EF_AMDGPU_MACH_AMDGCN_* and
+		EF_AMDGPU_FEATURE_* defines.
+
+	Change-Id: Ib5b94df7cae0719a22cf4e4fd0629330e9485c12
+
+2022-03-16  Simon Marchi  <simon.marchi@efficios.com>
+
+	binutils/readelf: handle AMDGPU OS ABIs
+	When the machine is EM_AMDGPU, handle the various OS ABIs described
+	here:
+
+	  https://llvm.org/docs/AMDGPUUsage.html#header
+
+	For a binary with the HSA OS ABI, the change looks like:
+
+	-  OS/ABI:                            <unknown: 40>
+	+  OS/ABI:                            AMD HSA
+
+	binutils/ChangeLog:
+
+		* readelf.c (get_osabi_name): Handle EM_AMDGPU OS ABIs.
+
+	include/ChangeLog:
+
+		* elf/common.h (ELFOSABI_AMDGPU_PAL, ELFOSABI_AMDGPU_MESA3D):
+		New.
+
+	Change-Id: I383590c390f7dc2fe0f902f50038735626d71863
+
+2022-03-16  Simon Marchi  <simon.marchi@efficios.com>
+
+	opcodes: handle bfd_amdgcn_arch in configure script
+	There isn't an actual opcodes implementation for the AMDGCN arch (yet),
+	this is just the bare minimum to get
+
+	  $ ./configure --target=amdgcn-hsa-amdhsa --disable-gas
+	  $ make all-binutils
+
+	working later in this series.
+
+	opcodes/ChangeLog:
+
+		* configure.ac: Handle bfd_amdgcn_arch.
+		* configure: Re-generate.
+
+	Change-Id: Ib7d7c5533a803ed8b2a293e9275f667ed781ce79
+
+2022-03-16  Simon Marchi  <simon.marchi@efficios.com>
+
+	bfd: add AMDGCN architecture
+	Add support for the AMDGCN architecture to BFD.
+
+	This is the bare minimum to get
+
+	  $ ./configure --target=amdgcn-hsa-amdhsa --disable-gas
+	  $ make all-binutils
+
+	working later in this series.
+
+	The specific AMDGCN models added here are a bit arbitrary, based on
+	what we intend to initially support in GDB.  This list will need to be
+	updated in the future anyway.  The complete up-to-date list of existing
+	AMDGPU models can be found here:
+
+	  https://llvm.org/docs/AMDGPUUsage.html#processors
+
+	The ELF format for this architecture is documented here:
+
+	  https://llvm.org/docs/AMDGPUUsage.html#elf-code-object
+
+	The flags for the "HSA" OS ABI are properly versioned and documented on
+	that page.  But the NONE, PAL and MESA3D OS ABIs are not well documented
+	nor versioned.  Taking a peek at the LLVM source code, we see that they
+	encode their flags the same way as HSA v3.  For example, for PAL:
+
+	  https://github.com/llvm/llvm-project/blob/c8b614cd74a92d85936aed5ac7c642af75ffdc29/llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp#L601
+
+	So at least, we know that all AMDGPU objects (of which AMDGCN objects
+	are a subset of) at the time of writing encode the specific GPU model in
+	the EF_AMDGPU_MACH field of e_flags.
+
+	bfd/ChangeLog:
+
+		* Makefile.am (ALL_MACHINES, ALL_MACHINES_CFILES):
+		Add cpu-amdgcn.c.
+		(BFD64_BACKENDS): Add elf64-amdgcn.lo.
+		(BFD64_BACKENDS_CFILES): Add elf64-amdgcn.c.
+		* Makefile.in: Re-generate.
+		* cpu-amdgcn.c: New.
+		* elf64-amdgcn.c: New.
+		* archures.c (bfd_architecture): Add bfd_arch_amdgcn and related
+		mach defines.
+		(bfd_amdgcn_arch): New.
+		(bfd_archures_list): Add bfd_amdgcn_arch.
+		* bfd-in2.h: Re-generate.
+		* config.bfd: Handle amdgcn* target.
+		* configure.ac: Handle amdgcn_elf64_le_vec.
+		* configure: Re-generate.
+		* elf-bfd.h (elf_target_id): Add AMDGCN_ELF_DATA.
+		* targets.c (amdgcn_elf64_le_vec): New.
+		(_bfd_target_vector): Add amdgcn_elf64_le_vec.
+
+	include/ChangeLog:
+
+		* elf/amdgpu.h: New.
+		* elf/common.h (ELFOSABI_AMDGPU_HSA): Add.
+
+	Change-Id: I969f7b14960797e88891c308749a6e341eece5b2
+
+2022-03-16  Nick Clifton  <nickc@redhat.com>
+
+	Updated Serbian (for binutils/) and Russian (for gprof/) translations
+
+2022-03-16  Pedro Alves  <pedro@palves.net>
+
+	Make gdb.fortran/{array-slices,lbound-ubound} work against gdbserver
+	gdb.fortran/array-slices.exp and gdb.fortran/lbound-ubound.exp were
+	recently disabled unless testing with the native target, because they
+	rely on inferior I/O.  However, when testing against gdbserver using
+	the native-gdbserver/native-extended-gdbserver boards, we do have
+	access to inferior I/O.
+
+	The right way to check whether the board can do I/O, is via checking
+	the gdb,noinferiorio board variable.  Switch to using that.
+
+	And then, tweak the testcases to expect output to appear in
+	inferior_spawn_id, instead of gdb_spawn_id.  When testing against the
+	native target, inferior_spawn_id is the same as gdb_spawn_id.  When
+	testing against gdbserver, it maps to gdbserver_spawn_id.
+
+	This exposed a buglet in gdb.fortran/array-slices.f90's show_1d
+	subroutine -- it was missing printing newline at the end of the
+	"Expected GDB Output" text, leading to a test timeout.  All other
+	subroutines end with advance=yes, except this one.  Fix it by using
+	advance=yes here too.
+
+	Change-Id: I4640729f334431cfc24b0917e7d3977b677c6ca5
+
+2022-03-16  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-15  Alan Modra  <amodra@gmail.com>
+
+	Delete PowerPC macro insn support
+	Let's hope this stays dead, but it's here as a patch separate from
+	those that removed use of powerpc_macros just in case it needs to be
+	resurrected.
+
+	include/
+		* opcode/ppc.h (struct powerpc_macro): Delete declaration.
+		(powerpc_macros, powerpc_num_macros): Likewise..
+	opcodes/
+		* ppc-opc.c (powerpc_macros, powerpc_num_macros): Delete.
+	gas/
+		* config/tc-ppc.c (ppc_macro): Delete function.
+		(ppc_macro_hash): Delete.
+		(ppc_setup_opcodes, md_assemble): Delete macro support.
+
+2022-03-15  Alan Modra  <amodra@gmail.com>
+
+	PowerPC SPE/SPE2 aliases in powerpc_macros
+		* ppc-opc.c (powerpc_macros): Move "evsadd", "evssub", "evsabs",
+		"evsnabs", "evsneg", "evsmul", "evsdiv", "evscmpgt", "evsgmplt",
+		"evsgmpeq", "evscfui", "evscfsi", "evscfuf", "evscfsf", "evsctui",
+		"evsctsi", "evsctuf", "evsctsf", "evsctuiz", "evsctsiz",
+		"evststgt", "evststlt", "evststeq"..
+		(powerpc_opcodes): ..to here.
+		(powerpc_macros): Move "evdotphsssi", "evdotphsssia", "evdotpwsssi",
+		and "evdotpwsssia"..
+		(spe2_opcodes): ..to here.
+
+2022-03-15  Alan Modra  <amodra@gmail.com>
+
+	PowerPC VLE extended instructions in powerpc_macros
+	This moves VLE insn out of the macro table.  "e_slwi" and "e_srwi"
+	already exist in vle_opcodes as distinct instructions rather than
+	encodings of e_rlwinm.
+
+	opcodes/
+		* ppc-opc.c (vle_opcodes): Typo fix e_rlwinm operand.
+		Add "e_inslwi", "e_insrwi", "e_rotlwi", "e_rotrwi", "e_clrlwi",
+		"e_clrrwi", "e_extlwi", "e_extrwi", and "e_clrlslwi".
+		(powerpc_macros): Delete same.  Delete "e_slwi" and "e_srwi" too.
+	gas/
+		* testsuite/gas/ppc/vle-simple-5.d: Update.
+
+2022-03-15  Alan Modra  <amodra@gmail.com>
+
+	PowerPC32 extended instructions in powerpc_macros
+	As for PowerPC64, move instructions to the main opcode table.
+
+	opcodes/
+		* ppc-opc.c (insert_crwn, extract_crwn, insert_elwn, extract_elwn),
+		(insert_erwn, extract_erwn, insert_erwb, extract_erwb),
+		(insert_cslwn, extract_cslwb, insert_ilwb, extract_ilwn),
+		(insert_irwb, extract_irwn, insert_rrwn, extract_rrwn),
+		(insert_slwn, extract_slwn, insert_srwn, extract_srwn): New functions.
+		(CRWn, ELWn, ERWn, ERWb, CSLWb, CSLWn, ILWn, ILWb, IRWn, IRWb),
+		(RRWn, SLWn, SRWn): Define and add powerpc_operands entries.
+		(MMB_MASK, MME_MASK, MSHMB_MASK): Define.
+		(powerpc_opcodes): Add "inslwi", "insrwi", "rotrwi", "clrrwi",
+		"slwi", "srwi", "extlwi", "extrwi", "sli", "sri" and corresponding
+		record (ie. dot suffix) forms.
+		(powerpc_macros): Delete same.
+	gas/
+		* testsuite/gas/ppc/476.d: Update.
+		* testsuite/gas/ppc/simpshft.d: Update.
+
+2022-03-15  Alan Modra  <amodra@gmail.com>
+
+	PowerPC64 extended instructions in powerpc_macros
+	The extended instructions implemented in powerpc_macros aren't used by
+	the disassembler.  That means instructions like "sldi r3,r3,2" appear
+	in disassembly as "rldicr r3,r3,2,61", which is annoying since many
+	other extended instructions are shown.
+
+	Note that some of the instructions moved out of the macro table to the
+	opcode table won't appear in disassembly, because they are aliases
+	rather than a subset of the underlying raw instruction.  If enabled,
+	rotrdi, extrdi, extldi, clrlsldi, and insrdi would replace all
+	occurrences of rotldi, rldicl, rldicr, rldic and rldimi.  (Or many
+	occurrences in the case of clrlsldi if n <= b was added to the extract
+	functions.)
+
+	The patch also fixes a small bug in opcode sanity checking.
+
+	include/
+		* opcode/ppc.h (PPC_OPSHIFT_SH6): Define.
+	opcodes/
+		* ppc-opc.c (insert_erdn, extract_erdn, insert_eldn, extract_eldn),
+		(insert_crdn, extract_crdn, insert_rrdn, extract_rrdn),
+		(insert_sldn, extract_sldn, insert_srdn, extract_srdn),
+		(insert_erdb, extract_erdb, insert_csldn, extract_csldb),
+		(insert_irdb, extract_irdn): New functions.
+		(ELDn, ERDn, ERDn, RRDn, SRDn, ERDb, CSLDn, CSLDb, IRDn, IRDb):
+		Define and add associated powerpc_operands entries.
+		(powerpc_opcodes): Add "rotrdi", "srdi", "extrdi", "clrrdi",
+		"sldi", "extldi", "clrlsldi", "insrdi" and corresponding record
+		(ie. dot suffix) forms.
+		(powerpc_macros): Delete same from here.
+	gas/
+		* config/tc-ppc.c (insn_validate): Don't modify value passed
+		to operand->insert for PPC_OPERAND_PLUS1 when calculating mask.
+		Handle PPC_OPSHIFT_SH6.
+		* testsuite/gas/ppc/prefix-reloc.d: Update.
+		* testsuite/gas/ppc/simpshft.d: Update.
+	ld/
+		* testsuite/ld-powerpc/elfv2so.d: Update.
+		* testsuite/ld-powerpc/notoc.d: Update.
+		* testsuite/ld-powerpc/notoc3.d: Update.
+		* testsuite/ld-powerpc/tlsdesc2.d: Update.
+		* testsuite/ld-powerpc/tlsget.d: Update.
+		* testsuite/ld-powerpc/tlsget2.d: Update.
+		* testsuite/ld-powerpc/tlsopt5.d: Update.
+		* testsuite/ld-powerpc/tlsopt6.d: Update.
+
+2022-03-15  Tom Tromey  <tom@tromey.com>
+
+	Do not capture updated 'pc' in add_local_symbols
+	Simon pointed out that commit 13835d88 ("Use function view when
+	iterating over block symbols") caused a regression.  The bug is that
+	the new closure captures 'pc' by reference, but later code updates
+	this variable -- but the earlier code did not update the callback
+	structure with the new value.
+
+	This patch restores the old behavior by using a new varible name in an
+	inner scope.
+
+2022-03-15  Jose E. Marchesi  <jose.marchesi@oracle.com>
+
+	gprofng: avoid using `fallthrough' attributes
+	gprofng didn't build with gcc 6.3 due to the usage of __attribute__
+	((fallthrough)).  This patch uses /* FALLTHROUGH */ instead.
+
+	2022-03-15  Jose E. Marchesi  <jose.marchesi@oracle.com>
+
+		* gprofng/src/gp-collect-app.cc (collect::check_args): Use
+		fallthrough comment instead of attribute.
+
+2022-03-15  Tom Tromey  <tromey@adacore.com>
+
+	Fix bug in dwarf-mode.el
+	I noticed that, occasionally, dwarf-mode would think that the objdump
+	subprocess was still running after it had clearly exited.  I managed
+	to reliably reproduce this today and learned that a process sentinel
+	is not guaranteed to be run with the current buffer set to the process
+	buffer.  This patch fixes the problem.
+
+	I've bumped the version number of dwarf-mode.el to make it easier to
+	install for users who already have an earlier one installed.
+
+	I'm checking this in.
+
+	2022-03-15  Tom Tromey  <tromey@adacore.com>
+
+		* dwarf-mode.el: Now 1.7.
+		(dwarf--sentinel): Switch to the process buffer.
+
+2022-03-15  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: rename a proc and fix a typo
+	Rename a proc in gdb.mi/user-selected-context-sync.exp, I think the
+	old name was most likely a typo.  The old name
+	match_re_or_ensure_not_output seems (to me) to imply we're in some way
+	checking that the regexp was not output.  But that's not what we are
+	doing, we're checking either for the regexp, or for no output, hence
+	the new name match_re_or_ensure_no_output.
+
+	Additionally, I found a definite typo in one of the comments that I've
+	also fixed.
+
+	I also updated some test names.  These tests (probably due to copy &
+	paste errors) has 'on MI' on their name, when they were actually
+	checking CLI output.  For these test I changed the name to use 'on
+	CLI'.
+
+	There should be no change in what is tested after this commit.
+
+2022-03-15  Nick Clifton  <nickc@redhat.com>
+
+	gprofng: Add a configure test for clock_gettime and a use of the test in getthrtime.c
+
+2022-03-15  H.J. Lu  <hjl.tools@gmail.com>
+
+	gprofng: Don't generate gprofng.info in source
+	Add info-in-builddir to AUTOMAKE_OPTIONS.
+
+		PR gprof/28967
+		* doc/Makefile.am (AUTOMAKE_OPTIONS): Add info-in-builddir.
+		* doc/Makefile.in: Regenerate.
+
+2022-03-15  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: LoongArch: fix failed testcases in gdb.base/align-c.exp
+	When execute the following command on LoongArch:
+
+	  make check-gdb TESTS="gdb.base/align-c.exp"
+
+	there exist some failed testcases:
+
+	  ...
+	  FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_long_double_x_float)
+	  FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_long_double_x_double)
+	  FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_long_double_x_long_double)
+	  ...
+
+	According to LoongArch ELF ABI specification [1], set the target data types
+	of floating-point to fix the above failed testcases.
+
+	[1] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html
+
+2022-03-15  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-14  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/python/mi: create MI commands using python
+	This commit allows a user to create custom MI commands using Python
+	similarly to what is possible for Python CLI commands.
+
+	A new subclass of mi_command is defined for Python MI commands,
+	mi_command_py. A new file, gdb/python/py-micmd.c contains the logic
+	for Python MI commands.
+
+	This commit is based on work linked too from this mailing list thread:
+
+	  https://sourceware.org/pipermail/gdb/2021-November/049774.html
+
+	Which has also been previously posted to the mailing list here:
+
+	  https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html
+
+	And was recently reposted here:
+
+	  https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html
+
+	The version in this patch takes some core code from the previously
+	posted patches, but also has some significant differences, especially
+	after the feedback given here:
+
+	  https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html
+
+	A new MI command can be implemented in Python like this:
+
+	  class echo_args(gdb.MICommand):
+	      def invoke(self, args):
+	          return { 'args': args }
+
+	  echo_args("-echo-args")
+
+	The 'args' parameter (to the invoke method) is a list
+	containing (almost) all command line arguments passed to the MI
+	command (--thread and --frame are handled before the Python code is
+	called, and removed from the args list).  This list can be empty if
+	the MI command was passed no arguments.
+
+	When used within gdb the above command produced output like this:
+
+	  (gdb)
+	  -echo-args a b c
+	  ^done,args=["a","b","c"]
+	  (gdb)
+
+	The 'invoke' method of the new command must return a dictionary.  The
+	keys of this dictionary are then used as the field names in the mi
+	command output (e.g. 'args' in the above).
+
+	The values of the result returned by invoke can be dictionaries,
+	lists, iterators, or an object that can be converted to a string.
+	These are processed recursively to create the mi output.  And so, this
+	is valid:
+
+	  class new_command(gdb.MICommand):
+	      def invoke(self,args):
+	          return { 'result_one': { 'abc': 123, 'def': 'Hello' },
+	                   'result_two': [ { 'a': 1, 'b': 2 },
+	                                   { 'c': 3, 'd': 4 } ] }
+
+	Which produces output like:
+
+	  (gdb)
+	  -new-command
+	  ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}]
+	  (gdb)
+
+	I have required that the fields names used in mi result output must
+	match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes).
+	This restriction was never written down anywhere before, but seems
+	sensible to me, and we can always loosen this rule later if it proves
+	to be a problem.  Much harder to try and add a restriction later, once
+	people are already using the API.
+
+	What follows are some details about how this implementation differs
+	from the original patch that was posted to the mailing list.
+
+	In this patch, I have changed how the lifetime of the Python
+	gdb.MICommand objects is managed.  In the original patch, these object
+	were kept alive by an owned reference within the mi_command_py object.
+	As such, the Python object would not be deleted until the
+	mi_command_py object itself was deleted.
+
+	This caused a problem, the mi_command_py were held in the global mi
+	command table (in mi/mi-cmds.c), which, as a global, was not cleared
+	until program shutdown.  By this point the Python interpreter has
+	already been shutdown.  Attempting to delete the mi_command_py object
+	at this point was causing GDB to try and invoke Python code after
+	finalising the Python interpreter, and we would crash.
+
+	To work around this problem, the original patch added code in
+	python/python.c that would search the mi command table, and delete the
+	mi_command_py objects before the Python environment was finalised.
+
+	In contrast, in this patch, I have added a new global dictionary to
+	the gdb module, gdb._mi_commands.  We already have several such global
+	data stores related to pretty printers, and frame unwinders.
+
+	The MICommand objects are placed into the new gdb.mi_commands
+	dictionary, and it is this reference that keeps the objects alive.
+	When GDB's Python interpreter is shut down gdb._mi_commands is deleted,
+	and any MICommand objects within it are deleted at this point.
+
+	This change avoids having to make the mi_cmd_table global, and walk
+	over it from within GDB's python related code.
+
+	This patch handles command redefinition entirely within GDB's python
+	code, though this does impose one small restriction which is not
+	present in the original code (detailed below), I don't think this is a
+	big issue.  However, the original patch relied on being able to
+	finish executing the mi_command::do_invoke member function after the
+	mi_command object had been deleted.  Though continuing to execute a
+	member function after an object is deleted is well defined, it is
+	also (IMHO) risky, its too easy for someone to later add a use of the
+	object without realising that the object might sometimes, have been
+	deleted.  The new patch avoids this issue.
+
+	The one restriction that is added to avoid this, is that an MICommand
+	object can't be reinitialised with a different command name, so:
+
+	  (gdb) python cmd = MyMICommand("-abc")
+	  (gdb) python cmd.__init__("-def")
+	  can't reinitialize object with a different command name
+
+	This feels like a pretty weird edge case, and I'm happy to live with
+	this restriction.
+
+	I have also changed how the memory is managed for the command name.
+	In the most recently posted patch series, the command name is moved
+	into a subclass of mi_command, the python mi_command_py, which
+	inherits from mi_command is then free to use a smart pointer to manage
+	the memory for the name.
+
+	In this patch, I leave the mi_command class unchanged, and instead
+	hold the memory for the name within the Python object, as the lifetime
+	of the Python object always exceeds the c++ object stored in the
+	mi_cmd_table.  This adds a little more complexity in py-micmd.c, but
+	leaves the mi_command class nice and simple.
+
+	Next, this patch adds some extra functionality, there's a
+	MICommand.name read-only attribute containing the name of the command,
+	and a read-write MICommand.installed attribute that can be used to
+	install (make the command available for use) and uninstall (remove the
+	command from the mi_cmd_table so it can't be used) the command.  This
+	attribute will be automatically updated if a second command replaces
+	an earlier command.
+
+	This patch adds additional error handling, and makes more use the
+	gdbpy_handle_exception function.
+
+	Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
+
+2022-03-14  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/gdbarch: compare some fields against 0 verify_gdbarch
+	After the previous commit, which removes the predicate function
+	gdbarch_register_type_p, I noticed that the gdbarch->register_type
+	field was not checked at in the verify_gdbarch function.
+
+	More than not being checked, the field wasn't mentioned at all.
+
+	I find this strange, I would expect that every field would at least be
+	mentioned - we already generate comments for some fields saying that
+	this field is _not_ being checked, so the fact that this field isn't
+	being checked looks (to me), like this field is somehow slipping
+	through the cracks.
+
+	The comment at the top of gdbarch-components.py tries to explain how
+	the validation is done.  I didn't understand this comment completely,
+	but, I think this final sentence:
+
+	  "Otherwise, the check is done against 0 (really NULL for function
+	  pointers, but same idea)."
+
+	Means that, if non of the other cases apply, then the field should be
+	checked against 0, with 0 indicating that the field is invalid (was
+	not set by the tdep code).  However, this is clearly not being done.
+
+	Looking in gdbarch.py at the code to generate verify_gdbarch we do
+	find that there is a case that is not handled, the case where the
+	'invalid' field is set true True, but non of the other cases apply.
+
+	In this commit I propose two changes:
+
+	 1. Handle the case where the 'invalid' field of a property is set to
+	 True, this should perform a check for the field of gdbarch still
+	 being set to 0, and
+
+	 2. If the if/else series that generates verify_gdbarch doesn't handle
+	 a property then we should raise an exception.  This means that if a
+	 property is added which isn't handled, we should no longer silently
+	 ignore it.
+
+	After doing this, I re-generated the gdbarch files and saw that the
+	following gdbarch fields now had new validation checks:
+
+	  register_type
+	  believe_pcc_promotion
+	  register_to_value
+	  value_to_register
+	  frame_red_zone_size
+	  displaced_step_restore_all_in_ptid
+	  solib_symbols_extension
+
+	Looking at how these are currently set in the various -tdep.c files, I
+	believe the only one of these that is required to be set for all
+	architectures is the register_type field.
+
+	And so, for all of the other fields, I've changed the property
+	definition on gdbarch-components.py, setting the 'invalid' field to
+	False.
+
+	Now, after re-generation, the register_type field is checked against
+	0, thus an architecture that doesn't set_gdbarch_register_type will
+	now fail during validation.  For all the other fields we skip the
+	validation, in which case, it is find for an architecture to not set
+	this field.
+
+	My expectation is that there should be no user visible changes after
+	this commit.  Certainly for all fields except register_type, all I've
+	really done is cause some extra comments to be generated, so I think
+	that's clearly fine.
+
+	For the register_type field, my claim is that any architecture that
+	didn't provide this would fail when creating its register cache, and I
+	couldn't spot an architecture that doesn't provide this hook.  As
+	such, I think this change should be fine too.
+
+2022-03-14  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/gdbarch: remove the predicate function for gdbarch_register_type
+	I don't believe that the gdbarch_register_type_p predicate is called
+	anywhere in GDB, and the gdbarch_register_type function is called
+	without checking the gdbarch_register_type_p predicate function
+	everywhere it is used, for example in
+	init_regcache_descr (regcache.c).
+
+	My claim is that the gdbarch_register_type function is required for
+	every architecture, and GDB will not work if this function is not
+	supplied.
+
+	And so, in this commit, I remove the 'predicate=True' from
+	gdbarch-components.py for the 'register_type' field, and regenerate
+	the gdbarch files.
+
+	There should be no user visible changes after this commit.
+
+2022-03-14  Patrick Monnerat  <patrick@monnerat.net>
+
+	Replace deprecated_target_wait_hook by observers
+	Commit b60cea7 (Make target_wait options use enum flags) broke
+	deprecated_target_wait_hook usage: there's a commit comment telling
+	this hook has not been converted.
+
+	Rather than trying to mend it, this patch replaces the hook by two
+	target_wait observers:
+
+	target_pre_wait (ptid_t ptid)
+	target_post_wait (ptid_t event_ptid)
+
+	Upon target_wait entry, target_pre_wait is notified with the ptid
+	passed to target_wait. Upon exit, target_post_wait is notified with
+	the event ptid returned by target_wait. Should an exception occur,
+	event_ptid is null_ptid.
+
+	This change benefits to Insight (out-of-tree): there's no real use of the
+	late hook in gdb itself.
+
+2022-03-14  Tom Tromey  <tromey@adacore.com>
+
+	Correctly print subrange types in generic_value_print
+	I noticed that generic_value_print assumes that a subrange type is
+	always a subrange of an integer type.  However, this isn't necessarily
+	the case.  In Ada, for example, one has subranges of character and
+	enumeration types.
+
+	This code isn't often exercised, I think, because languages with real
+	subrange types tend to implement their own printers.  However, it
+	still seemed worth fixing.
+
+2022-03-14  Luis Machado  <luis.machado@arm.com>
+
+	[aarch64/arm] Properly extract the return value returned in memory
+	When running gdb.cp/non-trivial-retval.exp, the following shows up for
+	both aarch64-linux and armhf-linux:
+
+	Breakpoint 3, f1 (i1=23, i2=100) at src/gdb/testsuite/gdb.cp/non-trivial-retval.cc:35
+	35        A a;
+	(gdb) finish
+	Run till exit from #0  f1 (i1=23, i2=100) at src/gdb/testsuite/gdb.cp/non-trivial-retval.cc:35
+	main () at /src/gdb/testsuite/gdb.cp/non-trivial-retval.cc:163
+	163       B b = f2 (i1, i2);
+	Value returned is $6 = {a = -11952}
+	(gdb)
+
+	The return value should be {a = 123} instead. This happens because the
+	backends don't extract the return value from the correct location. GDB should
+	fetch a pointer to the memory location from X8 for aarch64 and r0 for armhf.
+
+	With the patch, gdb.cp/non-trivial-retval.exp has full passes on
+	aarch64-linux and armhf-linux on Ubuntu 20.04/18.04.
+
+	The problem only shows up with the "finish" command. The "call" command
+	works correctly and displays the correct return value.
+
+	This is also related to PR gdb/28681
+	(https://sourceware.org/bugzilla/show_bug.cgi?id=28681) and fixes FAIL's in
+	gdb.ada/mi_var_array.exp.
+
+	A new testcase is provided, and it exercises GDB's ability to "finish" a
+	function that returns a large struct (> 16 bytes) and display the
+	contents of this struct correctly. This has always been incorrect for
+	these backends, but no testcase exercised this particular scenario.
+
+2022-03-14  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-13  Alan Modra  <amodra@gmail.com>
+
+	PR28959, obdump doesn't disassemble mftb instruction
+	Without a -M cpu option given, powerpc objdump defaults currently to
+	-Mpower10 but -Many is also given.  Commit 1ff6a3b8e562 regressed
+	-Many disassembly of instructions that are encoded differently
+	depending on cpu, such as mftb which has pre- and post-power4
+	encodings.
+
+		PR 28959
+		* ppc-dis.c (lookup_powerpc): Revert 2021-05-28 change.  Instead
+		only look at deprecated PPC_OPCODE_RAW bit when -Many.
+
+2022-03-13  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-12  Tom Tromey  <tom@tromey.com>
+
+	Relax regexp in gdb.rust/unsized.exp
+	With nightly rustc, gdb.rust/unsized.exp fails:
+
+	    (gdb) ptype *us
+	    Structure has no component named operator*.
+
+	rustc changed to emit a bit more debug info for unsized types.
+	Because the original test is just to make sure that ptype of an
+	unsized array looks right, this patch relaxes the regexp and changes
+	the expression.  I think this keeps the original test meaning, but
+	also works with nightly.  I also tested stable and 1.48.
+
+2022-03-12  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-11  Tom Tromey  <tromey@adacore.com>
+
+	Avoid crash with cross-linux core file
+	An internal test case creates a core file using gcore, then restarts
+	gdb with that core.  When run with a cross-linux gdb (in this case,
+	x86-64 host with ppc64-linux target), the test fails:
+
+	    | (gdb) core core
+	    | [New LWP 18437]
+	    | warning: `/lib64/libc.so.6': Shared library architecture unknown is not compatible with target architecture powerpc:common64.
+	    | warning: Could not load shared library symbols for /lib64/ld64.so.1.
+	    | Do you need "set solib-search-path" or "set sysroot"?
+	    | ../../src/gdb/gdbarch.c:3388: internal-error: int gdbarch_elf_make_msymbol_special_p(gdbarch*): Assertion `gdbarch != NULL' failed.
+	    | A problem internal to GDB has been detected,
+	    | further debugging may prove unreliable.
+	    | Quit this debugging session? (y or n) y
+
+	What's happening here is that the core file lists some shared
+	libraries.  These aren't available via the solib search path, and so
+	gdb finds the local (x86-64) libraries.  This is not ideal, but on the
+	other hand, it is what was asked for -- while the test does set
+	solib-search-path, it does not set the sysroot.
+
+	But, because gdb isn't configured to handle these libraries, it
+	crashes.
+
+	It seems to me that it's better to avoid the crash by having
+	solib_bfd_open fail in the case where a library is incompatible.  That
+	is what this patch does.  Now it looks like:
+
+	    | [New LWP 15488]
+	    | Error while mapping shared library sections:
+	    | `/lib64/libc.so.6': Shared library architecture unknown is not compatible with target architecture powerpc:common64.
+
+	... and does not crash gdb.
+
+	I don't have a good setup for testing this using dejagnu, so I don't
+	know whether an existing gdb test covers this scenario.
+
+2022-03-11  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: remove duplicates from gdb.base/stap-probe.exp
+	Remove the duplicate test names from gdb.base/stap-probe.exp, this is
+	done by actually passing a unique test name in a couple of
+	places (rather than using the command as the test name), and in
+	another couple of places, a test has a duplicate name due to a cut &
+	paste error, which I've fixed.
+
+	There's no change in what is actually being tested after this commit.
+
+2022-03-11  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+	gprofng: a new GNU profiler
+	top-level
+		* Makefile.def: Add gprofng module.
+		* configure.ac: Add --enable-gprofng option.
+		* src-release.sh: Add gprofng.
+		* Makefile.in: Regenerate.
+		* configure: Regenerate.
+		* gprofng: New directory.
+
+	binutils
+		* MAINTAINERS: Add gprofng maintainer.
+		* README-how-to-make-a-release: Add gprofng.
+
+	include.
+		* collectorAPI.h: New file.
+		* libcollector.h: New file.
+		* libfcollector.h: New file.
+
+2022-03-11  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-10  Aaron Merey  <amerey@redhat.com>
+
+	gdb/auto-load: Remove repeating "auto-load" from debug message
+	Remove "auto-load:" from a format string passed to auto_load_debug_printf.
+	It is unnecessary since this function will prefix the string with "[auto-load]"
+	when printing it.
+
+2022-03-10  Tom Tromey  <tromey@adacore.com>
+
+	Change how "print/x" displays floating-point value
+	Currently, "print/x" will display a floating-point value by first
+	casting it to an integer type.  This yields weird results like:
+
+	    (gdb) print/x 1.5
+	    $1 = 0x1
+
+	This has confused users multiple times -- see PR gdb/16242, where
+	there are several dups.  I've also seen some confusion from this
+	internally at AdaCore.
+
+	The manual says:
+
+	    'x'
+		 Regard the bits of the value as an integer, and print the integer
+		 in hexadecimal.
+
+	... which seems more useful.  So, perhaps what happened is that this
+	was incorrectly implemented (or maybe correctly implemented and then
+	regressed, as there don't seem to be any tests).
+
+	This patch fixes the bug.
+
+	There was a previous discussion where we agreed to preserve the old
+	behavior:
+
+	    https://sourceware.org/legacy-ml/gdb-patches/2017-06/msg00314.html
+
+	However, I think it makes more sense to follow the manual.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16242
+
+2022-03-10  Tom Tromey  <tromey@adacore.com>
+
+	Simplify the ui-out progress API
+	I noticed that 'progress' is a method on ui-out, but it seems to me
+	that it would be better if the only API were via the progress_meter
+	class.  This patch makes this change, changing progress to be a method
+	on the meter itself.
+
+2022-03-10  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/gdbarch: fix typo in gdbarch-components.py
+	Fixes a minor typo, in a comment, in the gdbarch-components.py script.
+
+	There should be no user visible changes after this commit.
+
+2022-03-10  Lancelot SIX  <lancelot.six@amd.com>
+
+	Process exit status is leader exit status testcase
+	This adds a multi-threaded testcase that has all threads in the
+	process exit with a different exit code, and ensures that GDB reports
+	the thread group leader's exit status as the whole-process exit
+	status.  Before this set of patches, this would randomly report the
+	exit code of some other thread, and thus fail.
+
+	Tested on Linux-x86_64, native and gdbserver.
+
+	Co-Authored-By: Pedro Alves <pedro@palves.net>
+	Change-Id: I30cba2ff4576fb01b5169cc72667f3268d919557
+
+2022-03-10  Pedro Alves  <pedro@palves.net>
+
+	Re-add zombie leader on exit, gdbserver/linux
+	Same as the previous patch, but for GDBserver.
+
+	In summary, the current zombie leader detection code in linux-low.cc
+	has a race -- if a multi-threaded inferior exits just before
+	check_zombie_leaders finds that the leader is now zombie via checking
+	/proc/PID/status, check_zombie_leaders deletes the leader, assuming we
+	won't get an event for that exit (which we won't in some scenarios,
+	but not in this one), which is a false-positive scenario, where the
+	whole process is simply exiting.  Later when we see the last LWP in
+	our list exit, we report that LWP's exit status as exit code, even
+	though for the (real) parent process, the exit code that counts is the
+	child's leader thread's exit code.
+
+	Like for GDB, the solution here is to:
+
+	   - only report whole-process exit events for the leader.
+	   - re-add the leader back to the LWP list when we finally see it
+	     exit.
+
+	Change-Id: Id2d7bbb51a415534e1294fff1d555b7ecaa87f1d
+
+2022-03-10  Pedro Alves  <pedro@palves.net>
+
+	Re-add zombie leader on exit, gdb/linux
+	The current zombie leader detection code in linux-nat.c has a race --
+	if a multi-threaded inferior exits just before check_zombie_leaders
+	finds that the leader is now zombie via checking /proc/PID/status,
+	check_zombie_leaders deletes the leader, assuming we won't get an
+	event for that exit (which we won't in some scenarios, but not in this
+	one).  That might seem mostly harmless, but it has some downsides:
+
+	 - later when we continue pulling events out of the kernel, we will
+	   collect the exit event of the non-leader threads, and once we see
+	   the last lwp in our list exit, we return _that_ lwp's exit code as
+	   whole-process exit code to infrun, instead of the leader's exit
+	   code.
+
+	 - this can cause a hang in stop_all_threads in infrun.c.  Say there
+	   are 2 threads in the process.  stop_all_threads stops each of those
+	   threads, and then waits for two stop or exit events, one for each
+	   thread.  If the whole process exits, and check_zombie_leaders hits
+	   the false-positive case, linux-nat.c will only return one event to
+	   GDB (the whole-process exit returned when we see the last thread,
+	   the non-leader thread, exit), making stop_all_threads hang forever
+	   waiting for a second event that will never come.
+
+	However, in this false-positive scenario, where the whole process is
+	exiting, as opposed to just the leader (with pthread_exit(), for
+	example), we _will_ get an exit event shortly for the leader, after we
+	collect the exit event of all the other non-leader threads.  Or put
+	another way, we _always_ get an event for the leader after we see it
+	become zombie.
+
+	I tried a number of approaches to fix this:
+
+	#1 - My first thought to address the race was to make GDB always
+	report the whole-process exit status for the leader thread, not for
+	whatever is the last lwp in the list.  We _always_ get a final exit
+	(or exec) event for the leader, and when the race triggers, we're not
+	collecting it.
+
+	#2 - My second thought was to try to plug the race in the first place.
+
+	I thought of making GDB call waitpid/WNOHANG for all non-leader
+	threads immediately when the zombie leader is detected, assuming there
+	would be an exit event pending for each of them waiting to be
+	collected.  Turns out that that doesn't work -- you can see the leader
+	become zombie _before_ the kernel kills all other threads.  Waitpid in
+	that small time window returns 0, indicating no-event.  Thankfully we
+	hit that race window all the time, which avoided trading one race for
+	another.  Looking at the non-leader thread's status in /proc doesn't
+	help either, the threads are still in running state for a bit, for the
+	same reason.
+
+	#3 - My next attempt, which seemed promising, was to synchronously
+	stop and wait for the stop for each of the non-leader threads.  For
+	the scenario in question, this will collect all the exit statuses of
+	the non-leader threads.  Then, if we are left with only the zombie
+	leader in the lwp list, it means we either have a normal while-process
+	exit or an exec, in which case we should not delete the leader.  If
+	_only_ the leader exited, like in gdb.threads/leader-exit.exp, then
+	after pausing threads, we will still have at least one live non-leader
+	thread in the list, and so we delete the leader lwp.  I got this
+	working and polished, and it was only after staring at the kernel code
+	to convince myself that this would really work (and it would, for the
+	scenario I considered), that I realized I had failed to account for
+	one scenario -- if any non-leader thread is _already_ stopped when
+	some thread triggers a group exit, like e.g., if you have some threads
+	stopped and then resume just one thread with scheduler-locking or
+	non-stop, and that thread exits the process.  I also played with
+	PTRACE_EVENT_EXIT, see if it would help in any way to plug the race,
+	and I couldn't find a way that it would result in any practical
+	difference compared to looking at /proc/PID/status, with respect to
+	having a race.
+
+	So I concluded that there's no way to plug the race, we just have to
+	deal with it.  Which means, going back to approach #1.  That is the
+	approach taken by this patch.
+
+	Change-Id: I6309fd4727da8c67951f9cea557724b77e8ee979
+
+2022-03-10  Pedro Alves  <pedro@palves.net>
+
+	gdbserver: Reindent check_zombie_leaders
+	This fixes the indentation of
+	linux_process_target::check_zombie_leaders, which will help with
+	keeping its comments in sync with the gdb/linux-nat.c counterpart.
+
+	Change-Id: I37332343bd80423d934249e3de2d04feefad1891
+
+2022-03-10  Pedro Alves  <pedro@palves.net>
+
+	gdbserver: Reorganize linux_process_target::filter_event
+	Reorganize linux-low.cc:linux_process_target::filter_event such that
+	all the handling for events for LWPs not in the LWP list is together.
+	This helps make a following patch clearer.  The comments and debug
+	messages have also been tweaked to have them synchronized with the GDB
+	counterpart.
+
+	Change-Id: If9019635f63a846607cfda44b454b4254a404019
+
+2022-03-10  Pedro Alves  <pedro@palves.net>
+
+	gdb: Reorganize linux_nat_filter_event
+	Reorganize linux-nat.c:linux_nat_filter_event such that all the
+	handling for events for LWPs not in the LWP list is together.  This
+	helps make a following patch clearer.  The comments and debug messages
+	have also been tweaked - the end goal is to have them synchronized
+	with the gdbserver counterpart.
+
+	Change-Id: I8586d8dcd76d8bd3795145e3056fc660e3b2cd22
+
+2022-03-10  Pedro Alves  <pedro@palves.net>
+
+	Fix gdb.threads/current-lwp-dead.exp race
+	If we make GDB report the process EXIT event for the leader thread, as
+	will be done in a latter patch of this series, then
+	gdb.threads/current-lwp-dead.exp starts failing:
+
+	 (gdb) break fn_return
+	 Breakpoint 2 at 0x5555555551b5: file /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/current-lwp-dead.c, line 45.
+	 (gdb) continue
+	 Continuing.
+	 [New LWP 2138466]
+	 [Inferior 1 (process 2138459) exited normally]
+	 (gdb) FAIL: gdb.threads/current-lwp-dead.exp: continue to breakpoint: fn_return (the program exited)
+
+	The inferior exit reported is actually correct.  The main thread has
+	indeed exited, and that's the thread that has the right exit code to
+	report to the user, as that's the exit code that is reported to the
+	program's parent.  In this case, GDB managed to collect the exit code
+	for the leader thread before reaping the other thread, because in
+	reality, the testcase isn't creating standard threads, it is using raw
+	clone, and the new clones are put in their own thread group.
+
+	Fix it by making the main "thread" not exit until the scenario we're
+	exercising plays out.  Also, run the program to completion for
+	completeness.
+
+	The original program really wanted the leader thread to exit before
+	the fn_return function was reached -- it was important that the
+	current thread as pointed by inferior_ptid was gone when infrun got
+	the breakpoint event.  I've tweaked the testcase to ensure that that
+	condition is still held, though it is no longer the main thread that
+	exits.  This required a bit of synchronization between the threads,
+	which required using CLONE_VM unconditionally.  The #ifdef guards were
+	added as a fix for
+	https://sourceware.org/bugzilla/show_bug.cgi?id=11214, though I don't
+	think they were necessary because the program is not using TLS.  If it
+	turns out they were necessary, we can link the testcase with "-z now"
+	instead, which was mentioned as an alternative workaround in that
+	Bugzilla.
+
+	Change-Id: I7be2f0da4c2fe8f80a60bdde5e6c623d8bd5a0aa
+
+2022-03-10  Pedro Alves  <pedro@palves.net>
+
+	Fix gdb.threads/clone-new-thread-event.exp race
+	If we make GDB report the process EXIT event for the leader thread,
+	instead of whatever is the last thread in the LWP list, as will be
+	done in a latter patch of this series, then
+	gdb.threads/current-lwp-dead.exp starts failing:
+
+	 (gdb) FAIL: gdb.threads/clone-new-thread-event.exp: catch SIGUSR1 (the program exited)
+
+	This is a testcase race -- the main thread does not wait for the
+	spawned clone "thread" to finish before exiting, so the main program
+	may exit before the second thread is scheduled and reports its
+	SIGUSR1.  With the change to make GDB report the EXIT for the leader,
+	the race is 100% reproducible by adding a sleep(), like so:
+
+	 --- c/gdb/testsuite/gdb.threads/clone-new-thread-event.c
+	 +++ w/gdb/testsuite/gdb.threads/clone-new-thread-event.c
+	 @@ -51,6 +51,7 @@ local_gettid (void)
+	  static int
+	  fn (void *unused)
+	  {
+	 +  sleep (1);
+	    tkill (local_gettid (), SIGUSR1);
+	    return 0;
+	  }
+
+	Resulting in:
+
+	 Breakpoint 1, main (argc=1, argv=0x7fffffffd418) at gdb.threads/clone-new-thread-event.c:65
+	 65        stack = malloc (STACK_SIZE);
+	 (gdb) continue
+	 Continuing.
+	 [New LWP 3715562]
+	 [Inferior 1 (process 3715555) exited normally]
+	 (gdb) FAIL: gdb.threads/clone-new-thread-event.exp: catch SIGUSR1 (the program exited)
+
+	That inferior exit reported is actually correct.  The main thread has
+	indeed exited, and that's the thread that has the right exit code to
+	report to the user, as that's the exit code that is reported to the
+	program's parent.  In this case, GDB managed to collect the exit code
+	for the leader thread before reaping the other thread, because in
+	reality, the testcase isn't creating standard threads, it is using raw
+	clone, and the new clones are put in their own thread group.
+
+	Fix it by making the main thread wait for the child to exit.  Also,
+	run the program to completion for completeness.
+
+	Change-Id: I315cd3dc2b9e860395dcab9658341ea868d7a6bf
+
+2022-03-10  Pedro Alves  <pedro@palves.net>
+
+	Fix gdbserver/linux target_waitstatus logging assert
+	Turning on debug output in gdbserver leads to an assertion failure if
+	gdbserver reports a non-signal event:
+
+	    [threads] wait_1: LWP 3273770: extended event with waitstatus status->kind = EXECD, execd_pathname = gdb.threads/non-ldr-exc-1/non-ldr-exc-1
+	    [threads] wait_1: Hit a non-gdbserver trap event.
+	  ../../src/gdbserver/../gdb/target/waitstatus.h:365: A problem internal to GDBserver has been detected.
+	  sig: Assertion `m_kind == TARGET_WAITKIND_STOPPED || m_kind == TARGET_WAITKIND_SIGNALLED' failed.
+
+	Fix it in the obvious way, using target_waitstatus::to_string(),
+	resulting in, for example:
+
+	  [threads] wait_1: ret = LWP 1542412.1542412, status->kind = STOPPED, sig = GDB_SIGNAL_TRAP
+
+	Change-Id: Ia4832f9b4fa39f4af67fcaf21fd4d909a285a645
+
+2022-03-10  Nick Clifton  <nickc@redhat.com>
+
+	Add option to objdump/readelf to disable access to debuginfod servers.
+		* dwarf.c (use_debuginfod): New variable.  Set to 1.
+		(load_separate_debug_info): Only call
+		debuginfod_fetch_separate_debug_info is use_debuginfod is true.
+		(dwarf_select_sections_by_names): Add do-not-use-debuginfod and
+		use-debuginfod options.
+		(dwarf_select_sections_by_letters): Add D and E options.
+		* dwarf.h (use_debuginfod): New extern.
+		* objdump.c (usage): Mention the new options.
+		* readelf.c (usage): Likewise.
+		* doc/binutils.texi: Document the new options.
+		* doc/debug-options.texi: Describe the new options.
+		* NEWS: Mention the new feature.
+		* testsuite/binutils-all/debuginfod.exp: Add tests of the new
+		options.
+
+2022-03-10  Alan Modra  <amodra@gmail.com>
+
+	Re: ld: Add a before_plugin_all_symbols_read hook
+		* testsuite/ld-plugin/pr28849.d: Adjust for powerpc64 function
+		descriptors.
+
+2022-03-10  H.J. Lu  <hjl.tools@gmail.com>
+
+	ld: Add a before_plugin_all_symbols_read hook
+	Add a before_plugin_all_symbols_read hook to load symbol references from
+	DT_NEEDED entries, included from --copy-dt-needed-entries, before reading
+	plugin symbols to properly resolve plugin symbol references.
+
+	bfd/
+
+		PR ld/28849
+		* elf-bfd.h (elf_link_hash_table): Add handling_dt_needed.
+		* elflink.c (_bfd_elf_merge_symbol): Don't set non_ir_ref_dynamic
+		before plugin 'all symbols read' hook is called.
+
+	ld/
+
+		PR ld/28849
+		* ldelf.c (ldelf_handle_dt_needed): New function.
+		(ldelf_before_plugin_all_symbols_read): Likewise.
+		(ldelf_after_open): Call ldelf_handle_dt_needed.
+		* ldelf.h (ldelf_before_plugin_all_symbols_read): New.
+		* ldemul.c (ldemul_before_plugin_all_symbols_read): Likewise.
+		* ldemul.h (ldemul_before_plugin_all_symbols_read): Likewise.
+		(ld_emulation_xfer_struct): Add before_plugin_all_symbols_read.
+		* ldlang.c (lang_process): Call
+		ldemul_before_plugin_all_symbols_read before calling
+		plugin_call_all_symbols_read.
+		* emultempl/elf.em
+		(gld${EMULATION_NAME}_before_plugin_all_symbols_read): New.
+		(LDEMUL_BEFORE_PLUGIN_ALL_SYMBOLS_READ): New.
+		* emultempl/emulation.em (ld_${EMULATION_NAME}_emulation):
+		Initialize the before_plugin_all_symbols_read field.
+		* testsuite/ld-plugin/lto.exp: Run PR ld/28849 tests.
+		* testsuite/ld-plugin/pr28849.d: New file.
+		* testsuite/ld-plugin/pr28849a.c: Likewise.
+		* testsuite/ld-plugin/pr28849b.c: Likewise.
+
+2022-03-10  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-09  Hans-Peter Nilsson  <hp@axis.com>
+
+	toplevel: Makefile.def: Make configure-sim depend on all-readline
+	Without this, a "make all-sim" without the equivalent of
+	libreadline-dev installed on the build system, won't
+	properly pick up the in-tree readline build, and you'll see:
+
+	mkdir -p -- ./sim
+	Configuring in ./sim
+	configure: creating cache ./config.cache
+	checking build system type... x86_64-pc-linux-gnu
+	checking host system type... x86_64-pc-linux-gnu
+	checking target system type... cris-axis-elf
+	checking for x86_64-pc-linux-gnu-gcc... gcc
+	checking whether the C compiler works... yes
+	...
+	checking for library containing tgetent... -ltermcap
+	checking for readline in -lreadline... no
+	configure: error: the required "readline" library is missing
+	make[1]: *** [Makefile:11188: configure-sim] Error 1
+	make[1]: Leaving directory '/home/hp/sim/b'
+
+	The sim dependency on readline is apparently (nominally)
+	valid as there's a readline call in sim/erc32/sis.c.
+
+	2022-02-21  Hans-Peter Nilsson  <hp@axis.com>
+
+		* Makefile.def (dependencies): Make configure-sim depend on
+		all-readline.
+
+2022-03-09  Maciej W. Rozycki  <macro@embecosm.com>
+
+	GDB/testsuite: Fix a "displayed" typo in gdb.base/default.exp
+	Fix a typo, s/dislayed/displayed/ in default.exp at the top level.
+
+	GDB/testsuite: Remove a stray backslash from gdb.base/settings.exp
+	Remove a stray trailing backslash from `test-integer' in settings.exp.
+	It is harmless as only white space follows in the next line before the
+	closing brace, so it merely swallows the newline character, but it may
+	look confusing to the reader.
+
+2022-03-09  Christina Schimpe  <christina.schimpe@intel.com>  (tiny change)
+
+	* gdb/doc/gdb.texinfo (Requirements): Fix a typo.
+
+2022-03-09  Alan Modra  <amodra@gmail.com>
+
+	Constant fold view increment expressions
+	The idea here is to replace expressions like v + 1 + 1 + 1 with v + 3.
+
+		* dwarf2dbg.c (set_or_check_view): Remove useless assertion.
+		Resolve multiple view increments.
+		* testsuite/gas/elf/dwarf2-18.d: Don't xfail mep.
+
+2022-03-09  Alan Modra  <amodra@gmail.com>
+
+	Reduce duplicated symbol_clone_if_forward_ref work
+		* symbol.c (struct symbol_flags): Add forward_resolved.
+		(symbol_entry_find): Update needle initialisation.
+		(symbol_clone_if_forward_ref): Do no work when forward_resolved
+		is already set.  Set forward_resolved.
+
+2022-03-09  Aaron Merey  <amerey@redhat.com>
+
+	gdb: Try searching for auto-load script using .gnu_debuglink
+	If an auto-load script cannot be found and objfile is a separate
+	debuginfo whose filename does not match the name found in the parent
+	file's .gnu_debuglink section, then repeat the search using the
+	parent's filename where the last component is replaced with the
+	.gnu_debuglink name.
+
+	For example if the parent's filename is "/usr/lib/libxyz.so" and the
+	name in its .gnu_debuglink section is "libxyz.so.debug", then
+	if no auto-load script is otherwise found the search will be
+	repeated with the filename "/usr/lib/libxyz.so.debug".
+
+	This helps gdb locate auto-load scripts when debuginfo files do not have
+	the expected filename, such as when they are aquired from debuginfod.
+
+2022-03-09  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-08  Aaron Merey  <amerey@redhat.com>
+
+	PR gdb/27876 - debuginfod-downloaded source files don't pass proper fullname across mi / (gdb)info source
+	Source files downloaded from debuginfod currently use their original DWARF
+	filename as their "fullname".  This causes a mismatch between the fullname
+	and the actual location of the source file in the debuginfod client cache.
+
+	MI consumers such as VSCode will fail to open debuginfod-downloaded
+	source files due to this.  Also 'info source' will fail to include the
+	true paths of these files.
+
+	To fix this, use the debuginfod cache path as the fullname for debuginfod-
+	downloaded source files.
+
+2022-03-08  Jan Vrany  <jan.vrany@labware.com>
+
+	gdb/mi: preserve user selected thread and frame when invoking MI commands
+	Fix for PR gdb/20684.  When invoking MI commands with --thread and/or
+	--frame, the user selected thread and frame was not preserved:
+
+	  (gdb)
+	  info thread
+	  &"info thread\n"
+	  ~"  Id   Target Id                                           Frame \n"
+	  ~"* 1    Thread 0x7ffff7c30740 (LWP 19302) \"user-selected-c\" main () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60\n"
+	  ~"  2    Thread 0x7ffff7c2f700 (LWP 19306) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
+	  ~"  3    Thread 0x7ffff742e700 (LWP 19307) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
+	  ^done
+	  (gdb)
+	  info frame
+	  &"info frame\n"
+	  ~"Stack level 0, frame at 0x7fffffffdf90:\n"
+	  ~" rip = 0x555555555207 in main (/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60); saved rip = 0x7ffff7c5709b\n"
+	  ~" source language c.\n"
+	  ~" Arglist at 0x7fffffffdf80, args: \n"
+	  ~" Locals at 0x7fffffffdf80, Previous frame's sp is 0x7fffffffdf90\n"
+	  ~" Saved registers:\n "
+	  ~" rbp at 0x7fffffffdf80, rip at 0x7fffffffdf88\n"
+	  ^done
+	  (gdb)
+	  -stack-info-depth --thread 3
+	  ^done,depth="4"
+	  (gdb)
+	  info thread
+	  &"info thread\n"
+	  ~"  Id   Target Id                                           Frame \n"
+	  ~"  1    Thread 0x7ffff7c30740 (LWP 19302) \"user-selected-c\" main () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60\n"
+	  ~"  2    Thread 0x7ffff7c2f700 (LWP 19306) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
+	  ~"* 3    Thread 0x7ffff742e700 (LWP 19307) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
+	  ^done
+	  (gdb)
+	  info frame
+	  &"info frame\n"
+	  ~"Stack level 0, frame at 0x7ffff742dee0:\n"
+	  ~" rip = 0x555555555169 in child_sub_function (/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30); saved rip = 0x555555555188\n"
+	  ~" called by frame at 0x7ffff742df00\n"
+	  ~" source language c.\n"
+	  ~" Arglist at 0x7ffff742ded0, args: \n"
+	  ~" Locals at 0x7ffff742ded0, Previous frame's sp is 0x7ffff742dee0\n"
+	  ~" Saved registers:\n "
+	  ~" rbp at 0x7ffff742ded0, rip at 0x7ffff742ded8\n"
+	  ^done
+	  (gdb)
+
+	This caused problems for frontends that provide access to CLI because UI
+	may silently change the context for CLI commands (as demonstrated above).
+
+	This commit fixes the problem by restoring thread and frame in
+	mi_cmd_execute (). With this change, there are only two GDB/MI commands
+	that can change user selected context: -thread-select and -stack-select-frame.
+	This allows us to remove all and rather complicated logic of notifying
+	about user selected context change from mi_execute_command (), leaving it
+	to these two commands themselves to notify.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20684
+
+2022-03-08  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: announce upcoming removal of Python 2 support from gdb
+	As has been discussed here:
+
+	  https://sourceware.org/pipermail/gdb-patches/2022-January/184910.html
+
+	Python 2 support will be removed from GDB after GDB 12 has branched.
+	This commit places an entry in the NEWS file to inform users of this
+	decision.
+
+2022-03-08  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: add new test for comparing char types in Python
+	There's an interesting property of the 'char' type in C and C++, the
+	three types 'char', 'unsigned char', and 'signed char', are all
+	considered distinct.
+
+	In contrast, and 'int' is signed by default, and so 'int' and 'signed
+	int' are considered the same type.
+
+	This commit adds a test to ensure that this edge case is visible to a
+	user from Python.
+
+	It is worth noting that for any particular compiler implementation (or
+	the flags a compiler was invoked with), a 'char' will be either signed
+	or unsigned; it has to be one or the other, and a user can access this
+	information by using the Type.is_signed property.  However, for
+	something like function overload resolution, the 'char' type is
+	considered distinct from the signed and unsigned variants.
+
+	There's no change to GDB with this commit, this is just adding a new
+	test to guard some existing functionality.
+
+2022-03-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/python: add Type.is_signed property
+	Add a new read-only property, Type.is_signed, which is True for signed
+	types, and False otherwise.
+
+	This property should only be read on types for which Type.is_scalar is
+	true, attempting to read this property for non-scalar types will raise
+	a ValueError.
+
+	I chose 'is_signed' rather than 'is_unsigned' in order to match the
+	existing Architecture.integer_type method, which takes a 'signed'
+	parameter.  As far as I could find, that was the only existing
+	signed/unsigned selector in the Python API, so it seemed reasonable to
+	stay consistent.
+
+2022-03-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/python: add Type.is_scalar property
+	Add a new read-only property which is True for scalar types,
+	otherwise, it's False.
+
+2022-03-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/mi: add --no-connection to MI -add-inferior command
+	Following on from the previous commit, where the -add-inferior command
+	now uses the same connection as the current inferior, this commit adds
+	a --no-connection option to -add-inferior.
+
+	This new option matches the existing option of the same name for the
+	CLI version of add-inferior; the new inferior is created with no
+	connection.
+
+	I've added a new 'connection' field to the MI output of -add-inferior,
+	which includes the connection number and short name.  I haven't
+	included the longer description field, this is the MI after all.  My
+	expectation would be that if the frontend wanted to display all the
+	connection details then this would be looked up from 'info
+	connection' (or the MI equivalent if/when such a command is added).
+
+	The existing -add-inferior tests are updated, as are the docs.
+
+2022-03-07  Umair Sair  <umair_sair@hotmail.com>
+
+	gdb/mi: fix regression in mi -add-inferior command
+	Prior to the multi-target support commit:
+
+	  commit 5b6d1e4fa4fc6827c7b3f0e99ff120dfa14d65d2
+	  Date:   Fri Jan 10 20:06:08 2020 +0000
+
+	      Multi-target support
+
+	When a new inferior was added using the MI -add-inferior command, the
+	new inferior would be using the same target as all the other
+	inferiors.  This makes sense, GDB only supported a single target stack
+	at a time.
+
+	After the above commit, each inferior has its own target stack.
+
+	To maintain backward compatibility, for the CLI add-inferior command,
+	when a new inferior is added the above commit has the new inferior
+	inherit a copy of the target stack from the current inferior.
+
+	Unfortunately, this same backward compatibility is missing for the MI.
+
+	This commit fixes this oversight.
+
+	Now, when the -add-inferior MI command is used, the new inferior will
+	inherit a copy of the target stack from the current inferior.
+
+2022-03-07  Tom Tromey  <tromey@adacore.com>
+
+	Deprecate dbx mode
+	GDB has a dbx emulation mode that adds a few aliases and helper
+	commands.  This mode is barely documented and is very superficial
+	besides.  I suspect it is rarely used, and I would like to propose
+	deprecating it for GDB 12, and then removing it in GDB 13.
+
+2022-03-07  Pedro Alves  <pedro@palves.net>
+
+	Remove unnecessary inferior lookup in infrun:handle_one
+	infrun.c:handle_one calls find_inferior_ptid unnecessarily, since we
+	already have a thread pointer handy, and the thread has a pointer to
+	the inferior.  This commit removes the unnecessary lookup.
+
+	Change-Id: I2ae18601dd75346c6c91068e9a4f9a6484fb3339
+
+2022-03-07  Tom Tromey  <tromey@adacore.com>
+
+	Fix bug in ada_print_floating
+	ada_print_floating rewrites a floating-point string representation to
+	conform to Ada syntax.  However, if you managed to get a floating
+	point error, you might see:
+
+	    (gdb) print whatever
+	    $2 = <invalid float valu.0e>
+
+	What's happening here is that ada_print_floating doesn't recognize
+	this error case, and proceeds to modify the error text.
+
+	This patch fixes this problem.
+
+2022-03-07  Tom Tromey  <tromey@adacore.com>
+
+	Implement real literal extension for Ada
+	Sometimes it is convenient to be able to specify the exact bits of a
+	floating-point literal.  For example, you may want to set a
+	floating-point register to a denormalized value, or to a particular
+	NaN.
+
+	In C, you can do this by combining the "{}" cast with an array
+	literal, like:
+
+	    (gdb) p {double}{0x576488BDD2AE9FFE}
+	    $1 = 9.8765449999999996e+112
+
+	This patch adds a somewhat similar idea to Ada.  It extends the lexer
+	to allow "l" and "f" suffixes in a based literal.  The "f" indicates a
+	floating-point literal, and the "l"s control the size of the
+	floating-point type.
+
+	Note that this differs from Ada's based real literals.  I believe
+	those can also be used to control the bits of a floating-point value,
+	but they are a bit more cumbersome to use (simplest is binary but
+	that's also very lengthy).  Also, these aren't implemented in GDB.
+
+	I chose not to allow this extension to work with based integer
+	literals with exponents.  That didn't seem very useful.
+
+2022-03-07  Tom Tromey  <tromey@adacore.com>
+
+	Fix Ada integer literals with exponents
+	While working on another patch, I noticed that Ada integer literals
+	with exponents did not work.  For example, with one form you get an
+	error:
+
+	    (gdb) print 8e2
+	    Invalid digit `e' in based literal
+
+	And with another form you get an incorrect value:
+
+	    (gdb) print 16#8#e2
+	    $2 = 8
+
+	This patch fixes the bugs and adds tests.
+
+2022-03-07  Tom Tromey  <tromey@adacore.com>
+
+	Fix gdb.ada/arrayptr.exp results
+	PR ada/28115 points out that gdb.ada/arrayptr.exp works with GNAT 12,
+	but fails with minimal encodings in earlier versions.
+
+	This patch updates the test to try to report the results correctly.  I
+	tried this with the Fedora 34 system gcc (GCC 11) and with a GCC 12
+	built from git trunk sometime relatively recently.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28115
+
+2022-03-07  Tom Tromey  <tromey@adacore.com>
+
+	Handle non-ASCII identifiers in Ada
+	Ada allows non-ASCII identifiers, and GNAT supports several such
+	encodings.  This patch adds the corresponding support to gdb.
+
+	GNAT encodes non-ASCII characters using special symbol names.
+
+	For character sets like Latin-1, where all characters are a single
+	byte, it uses a "U" followed by the hex for the character.  So, for
+	example, thorn would be encoded as "Ufe" (0xFE being lower case
+	thorn).
+
+	For wider characters, despite what the manual says (it claims
+	Shift-JIS and EUC can be used), in practice recent versions only
+	support Unicode.  Here, characters in the base plane are represented
+	using "Wxxxx" and characters outside the base plane using
+	"WWxxxxxxxx".
+
+	GNAT has some further quirks here.  Ada is case-insensitive, and GNAT
+	emits symbols that have been case-folded.  For characters in ASCII,
+	and for all characters in non-Unicode character sets, lower case is
+	used.  For Unicode, however, characters that fit in a single byte are
+	converted to lower case, but all others are converted to upper case.
+
+	Furthermore, there is a bug in GNAT where two symbols that differ only
+	in the case of "Y WITH DIAERESIS" (and potentially others, I did not
+	check exhaustively) can be used in one program.  I chose to omit
+	handling this case from gdb, on the theory that it is hard to figure
+	out the logic, and anyway if the bug is ever fixed, we'll regret
+	having a heuristic.
+
+	This patch introduces a new "ada source-charset" setting.  It defaults
+	to Latin-1, as that is GNAT's default.  This setting controls how "U"
+	characters are decoded -- W/WW are always handled as UTF-32.
+
+	The ada_tag_name_from_tsd change is needed because this function will
+	read memory from the inferior and interpret it -- and this caused an
+	encoding failure on PPC when running a test that tries to read
+	uninitialized memory.
+
+	This patch implements its own UTF-32-based case folder.  This avoids
+	host platform quirks, and is relatively simple.  A short Python
+	program to generate the case-folding table is included.  It simply
+	relies on whatever version of Unicode is used by the host Python,
+	which seems basically acceptable.
+
+	Test cases for UTF-8, Latin-1, and Latin-3 are included.  This
+	exercises most of the new code paths, aside from Y WITH DIAERESIS as
+	noted above.
+
+2022-03-07  Tom Tromey  <tromey@adacore.com>
+
+	Define HOST_UTF32 in charset.h
+	rust-parse.c has a #define for the host-specific UTF-32 charset name.
+	A later patch needs the same thing, so this patch moves the definition
+	to charset.h for easier reuse.
+
+2022-03-07  Tom Tromey  <tromey@adacore.com>
+
+	Let phex and phex_nz handle sizeof_l==1
+	Currently, neither phex nor phex_nz handle sizeof_l==1 -- they let
+	this case fall through to the default case.  However, a subsequent
+	patch in this series needs this case to work correctly.
+
+	I looked at all calls to these functions that pass a 1 for the
+	sizeof_l parameter.  The only such case seems to be correct with this
+	change.
+
+2022-03-07  Tom Tromey  <tromey@adacore.com>
+
+	Don't pre-size result string in ada_decode
+	Currently, ada_decode pre-sizes the output string, filling it with 'X'
+	characters.  However, it's a bit simpler and more flexible to let
+	std::string do the work here, and simply append characters to the
+	string as we go.  This turns out to be useful for a subsequent patch.
+
+	Simplify a regular expression in ada-lex.l
+	ada-lex.l uses "%option case-insensitive", so there is no need for
+	regular expressions to match upper case.
+
+2022-03-07  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-06  Maciej W. Rozycki  <macro@orcam.me.uk>
+
+	MIPS/opcodes: Fix alias annotation for branch instructions
+	Correct issues with INSN2_ALIAS annotation for branch instructions:
+
+	- regular MIPS BEQZ/L and BNEZ/L assembly instructions are idioms for
+	  BEQ/L and BNE/L respectively with the `rs' operand equal to $0,
+
+	- microMIPS 32-bit BEQZ and BNEZ assembly instructions are idioms for
+	  BEQ and BNE respectively with the `rt' operand equal to $0,
+
+	- regular MIPS BAL assembly instruction is an idiom for architecture
+	  levels of up to the MIPSr5 ISA and a machine instruction on its own
+	  from the MIPSr6 ISA up.
+
+	Add missing annotation to BEQZ/L and BNEZ/L accordingly then and add a
+	new entry for BAL for the MIPSr6 ISA, correcting a disassembly bug:
+
+	$ mips-linux-gnu-objdump -m mips:isa64r6 -M no-aliases -d bal.o
+
+	bal.o:     file format elf32-tradlittlemips
+
+	Disassembly of section .text:
+
+	00000000 <foo>:
+	   0:	04110000 	0x4110000
+		...
+	$
+
+	Add test cases accordingly.
+
+	Parts for regular MIPS BEQZ/L and BNEZ/L instructions from Sagar Patel.
+
+	2022-03-06  Maciej W. Rozycki  <macro@orcam.me.uk>
+
+		binutils/
+		* testsuite/binutils-all/mips/mips1-branch-alias.d: New test.
+		* testsuite/binutils-all/mips/mips1-branch-noalias.d: New test.
+		* testsuite/binutils-all/mips/mips2-branch-alias.d: New test.
+		* testsuite/binutils-all/mips/mips2-branch-noalias.d: New test.
+		* testsuite/binutils-all/mips/mips32r6-branch-alias.d: New test.
+		* testsuite/binutils-all/mips/mips32r6-branch-noalias.d: New
+		test.
+		* testsuite/binutils-all/mips/micromips-branch-alias.d: New
+		test.
+		* testsuite/binutils-all/mips/micromips-branch-noalias.d: New
+		test.
+		* testsuite/binutils-all/mips/mips-branch-alias.s: New test
+		source.
+		* testsuite/binutils-all/mips/micromips-branch-alias.s: New test
+		source.
+		* testsuite/binutils-all/mips/mips.exp: Run the new tests.
+
+	2022-03-06  Sagar Patel  <sagarmp@cs.unc.edu>
+		    Maciej W. Rozycki  <macro@orcam.me.uk>
+
+		opcodes/
+		* mips-opc.c (mips_builtin_opcodes): Fix INSN2_ALIAS annotation
+		for "bal", "beqz", "beqzl", "bnez" and "bnezl" instructions.
+		* micromips-opc.c (micromips_opcodes): Likewise for "beqz" and
+		"bnez" instructions.
+
+2022-03-06  Tom Tromey  <tom@tromey.com>
+
+	Use function view when iterating over block symbols
+	This changes iterate_over_block_local_vars and
+	iterate_over_block_arg_vars to take a gdb::function_view rather than a
+	function pointer and a user-data.  In one spot, this allows us to
+	remove a helper structure and helper function.  In another spot, this
+	looked more complicated, so I changed the helper function to be an
+	"operator()" -- also a simplification, just not as big.
+
+2022-03-06  Tom Tromey  <tom@tromey.com>
+
+	Simplify hppa-tdep.c use of objfile_key
+	I happened to notice a couple of unnecessary casts in hppa-tdep.c, and
+	then I saw that the use of objfile_key could be simplified -- removing
+	some code and using the default deleter rather than noop_deleter.
+
+	Tested by rebuilding.  Let me know what you think.
+
+2022-03-06  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: constify parameter of value_copy
+	In a following patch, I have a const value I want to copy using a
+	value_copy.  However, value_copy takes a non-const source value, at the
+	moment.  Change the paramter to be const,
+
+	If the source value is not lazy, we currently call
+	value_contents_all_raw, which calls allocate_value_contents, to get a
+	view on the contents.  They both take a non-const value, that's a
+	problem.  My first attempt at solving it was to add a const version of
+	value_contents_all_raw, make allocate_value_contents take a const value,
+	and either:
+
+	 - make value::contents mutable
+	 - make allocate_value_contents cast away the const
+
+	The idea being that allocating the value contents buffer does modify the
+	value at the bit level, but logically that doesn't change its state.
+
+	That was getting a bit complicated, so what I ended up doing is make
+	value_copy not call value_contents_all_raw.  We know at this point that
+	the value is not lazy, so value::contents must have been allocate
+	already.
+
+	Change-Id: I3741ab362bce14315f712ec24064ccc17e3578d4
+
+2022-03-06  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove internalvar_funcs::destroy
+	No kind of internal var uses it remove it.  This makes the transition to
+	using a variant easier, since we don't need to think about where this
+	should be called (in a destructor or not), if it can throw, etc.
+
+	Change-Id: Iebbc867d1ce6716480450d9790410d6684cbe4dd
+
+2022-03-06  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-05  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-04  Tom Tromey  <tromey@adacore.com>
+
+	Mark vDSO as not a file
+	The vDSO objfile is not a real file, so mark it as such.  I noticed
+	this because, when playing with debuginfod, I saw:
+
+	Downloading 0.01 MB separate debug info for /tmp/system-supplied DSO at 0x7ffff7fc9000
+
+	That "/tmp" is wrong -- it's just gdb's cwd.  This patch corrects the
+	problem, resulting in:
+
+	Downloading 0.01 MB separate debug info for system-supplied DSO at 0x7ffff7fc9000
+
+	Regression tested on x86-64 Fedora 34.
+
+2022-03-04  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	binutils/readelf: fix indentation in process_dynamic_section
+	Clangd shows a warning about misleading indentation in this file, fix
+	it.
+
+	binutils/ChangeLog:
+
+		* readelf.c (process_dynamic_section): Fix indentation.
+
+	Change-Id: I43a7f4f4c75dd080af614222b980526f5debf297
+
+2022-03-04  Christina Schimpe  <christina.schimpe@intel.com>
+
+	gdb: Use a typedef's scoped type name to identify local typedefs
+	GDB prints the wrong type for typedefs in case there is another typedef
+	available for the same raw type (gdb/16040).  The reason is that the
+	current hashmap based substitution mechanism always compares the target
+	type of a typedef and not its scoped name.
+
+	The original output of GDB for a program like
+
+	~~~~
+	namespace ns
+	{
+	  typedef double scoped_double;
+	}
+
+	typedef double global_double;
+
+	class TypedefHolder
+	{
+	public:
+	  double a;
+	  ns::scoped_double b;
+	  global_double c;
+
+	private:
+	  typedef double class_double;
+	  class_double d;
+
+	  double method1(ns::scoped_double) { return 24.0; }
+	  double method2(global_double) { return 24.0; }
+	};
+
+	int main()
+	{
+	  TypedefHolder th;
+	  return 0;
+	}
+	~~~~
+
+	is
+	~~~~
+
+	(gdb) b 27
+	Breakpoint 1 at 0x1131: file TypedefHolder.cc, line 27.
+	(gdb) r
+	Starting program: /tmp/typedefholder
+
+	Breakpoint 1, main () at TypedefHolder.cc:27
+	27	  return 0;
+	(gdb) ptype th
+	type = class TypedefHolder {
+	  public:
+	    class_double a;
+	    class_double b;
+	    class_double c;
+	  private:
+	    class_double d;
+
+	    class_double method1(class_double);
+	    class_double method2(class_double);
+
+	    typedef double class_double;
+	}
+	~~~~
+
+	Basically all attributes of a class which have the raw type "double" are
+	substituted by "class_double".
+
+	With the patch the output is the following
+
+	~~~~
+	type = class TypedefHolder {
+	  public:
+	    double a;
+	    ns::scoped_double b;
+	    global_double c;
+	  private:
+	    class_double d;
+
+	    double method1(ns::scoped_double);
+	    double method2(global_double);
+
+	    typedef double class_double;
+	}
+	~~~~
+
+2022-03-04  Jan Beulich  <jbeulich@suse.com>
+
+	RISC-V: make .insn actually work for 64-bit insns
+	Presently in this case, due to an undefined behavior shift, at least
+	with x86 cross builds I'm observing:
+
+	Error: value conflicts with instruction length `8,0x0000003f'
+
+	Eliminate the UB and extend the respective testcase.
+
+2022-03-04  Jan Beulich  <jbeulich@suse.com>
+
+	x86: drop redundant x86-64-code16-2 test
+	The code16-2 test is already meaningless enough as a gas test, identical
+	to this one, and is run uniformly for all ELF targets anyway.
+
+2022-03-04  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-03  Roland McGrath  <mcgrathr@google.com>
+
+	Fix typo in last change.
+
+2022-03-03  Roland McGrath  <mcgrathr@google.com>
+
+	Avoid conflict with gnulib open/close macros.
+	On some systems, the gnulib configuration will decide to define open
+	and/or close as macros to replace the POSIX C functions.  This
+	interferes with using those names in C++ class or namespace scopes.
+
+	gdbsupport/
+		* event-pipe.cc (event_pipe::open): Renamed to ...
+		(event_pipe::open_pipe): ... this.
+		(event_pipe::close): Renamed to ...
+		(event_pipe::close_pipe): ... this.
+		* event-pipe.h (class event_pipe): Updated.
+	gdb/
+		* inf-ptrace.h (async_file_open, async_file_close): Updated.
+	gdbserver/
+		* gdbserver/linux-low.cc (linux_process_target::async): Likewise.
+
+2022-03-03  Alan Modra  <amodra@gmail.com>
+
+	Adjust ld ctf test for 32-bit targets
+	powerpc-linux, and I suspect other 32-bit targets, report "aligned at
+	0x4" for this test.
+
+		* testsuite/ld-ctf/nonrepresentable.d: Accept any alignment.
+
+2022-03-03  Luis Machado  <luis.machado@arm.com>
+
+	Update my e-mail address in the MAINTAINERS file
+	Update the information accordingly.
+
+2022-03-03  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: testsuite: fix failed testcases in gdb.base/gdb-caching-proc.exp
+	When execute the following command:
+
+	  make check-gdb TESTS="gdb.base/gdb-caching-proc.exp"
+
+	we can see there exist some failed testcases:
+
+	  FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 0: can spawn for attach (got interactive prompt)
+	  FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 1: can spawn for attach (got interactive prompt)
+	  FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 2: can spawn for attach (got interactive prompt)
+	  FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 3: can spawn for attach (got interactive prompt)
+	  FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 4: can spawn for attach (got interactive prompt)
+	  FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 5: can spawn for attach (got interactive prompt)
+	  FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 6: can spawn for attach (got interactive prompt)
+	  FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 7: can spawn for attach (got interactive prompt)
+	  FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 8: can spawn for attach (got interactive prompt)
+	  FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 9: can spawn for attach (got interactive prompt)
+
+	here are the detailed messages in gdb/testsuite/gdb.log:
+
+	  attach 873776
+	  A program is being debugged already.  Kill it? (y or n) n
+	  Not killed.
+	  (gdb) FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 0: can spawn for attach (got interactive prompt)
+
+	so handle the case "A program is being debugged already.  Kill it" in
+	can_spawn_for_attach to fix the failed testcases.
+
+2022-03-03  Alan Modra  <amodra@gmail.com>
+
+	comment typo fix
+
+2022-03-03  Alan Modra  <amodra@gmail.com>
+
+	PowerPC64 DT_RELR relative reloc addresses
+	Section addresses can change between ppc64_elf_size_stubs and
+	ppc64_elf_build_stubs due to .eh_frame editing.  The idea of stashing
+	r_offset final addresses calculated in ppc64_elf_size_stubs for use by
+	ppc64_elf_build_stubs was never a good idea.  Instead, we need to keep
+	section/offset pairs.
+
+		* elf64-ppc.c (struct ppc_link_hash_table): Delete relr_addr.
+		Add relr section/offset array.
+		(append_relr_off): Rewrite.  Update all callers.
+		(sort_relr): New function.
+		(ppc64_elf_size_stubs): Adjust to suit new relative reloc stash.
+		(ppc64_elf_build_stubs): Likewise.
+
+2022-03-03  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-02  John Baldwin  <jhb@FreeBSD.org>
+
+	configure: Stop checking for PT_GETXMMREGS.
+	This request is present on all modern *BSD/i386 systems (those
+	released since mid-2006), and the *BSD/i386 targets now assume it is
+	present unconditionally.
+
+	i386-bsd-nat: Assume PT_GETXMMREGS is present.
+	NetBSD has included PT_GETXMMREGS since 1.6 released in September
+	2002.  OpenBSD has included PT_GETXMMREGS since 3.8 released in
+	November 2005.
+
+	i386-fbsd-nat: Assume PT_GETXMMREGS is present.
+	PT_GETXMMREGS was first added in FreeBSD 6.0 released in November 2005.
+	The last FreeBSD release without support was 5.5 released in May 2006.
+
+2022-03-02  John Baldwin  <jhb@FreeBSD.org>
+
+	fbsd-tdep: Implement the vsyscall_range gdbarch hook.
+	FreeBSD recently added a real vDSO in its shared page for the amd64
+	architecture.  The vDSO is mapped at the address given by the
+	AT_KPRELOAD ELF auxiliary vector entry.  To find the end of the
+	mapping range, parse the list of virtual map entries used by 'info
+	proc mappings' either from the NT_PROCSTAT_VMMAP core dump note, or
+	via the kinfo_getvmmap function for native targets (fetched from the
+	native target as the TARGET_OBJECT_FREEBSD_VMMAP object).
+
+	This silences warnings on recent FreeBSD/amd64 kernels due to not
+	finding symbols for the vdso:
+
+	warning: Could not load shared library symbols for [vdso].
+	Do you need "set solib-search-path" or "set sysroot"?
+
+2022-03-02  Tom Tromey  <tromey@adacore.com>
+
+	Rewrite make-target-delegates in Python
+	I think gdb is probably better off having fewer languages involved
+	when generating code.  'sh' is unavoidable for build-time generation,
+	but for other things, let's use Python.
+
+	This rewrites make-target-delegates in Python.  I've stuck pretty
+	closely to the original code in this rewrite, so it may look slightly
+	weird from a Python perspective.
+
+	The only output difference is that a copyright header is now
+	generated, using the code introduced in the previous patch.
+
+	make-target-delegates.py is simpler to invoke, as it knows the correct
+	input file to scan and it creates the output file itself.
+
+2022-03-02  Tom Tromey  <tromey@adacore.com>
+
+	Move copyright code from gdbarch.py to new file
+	This moves the copyright code from gdbarch.py to a new Python source
+	file, gdbcopyright.py.  The function in this file will find the
+	copyright dates by scanning the calling script.  This will be reused
+	in a future patch.
+
+	This involved minor changes to the output of gdbarch.py.  Also, I've
+	updated copyright.py to remove the reference to gdbarch.sh.  We don't
+	need to mention gdbarch.py there, either.
+
+2022-03-02  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-03-01  Tom Tromey  <tom@tromey.com>
+
+	Some "distclean" fixes in gdb
+	PR build/12440 points out that "make distclean" is broken in gdb.
+	Most of the breakage comes from other projects in the tree, but we can
+	fix some of the issues, which is what this patch does.
+
+	Note that the yacc output files, like c-exp.c, are left alone.  In a
+	source distribution, these are included in the tarball, and if the
+	user builds in-tree, we would not want to remove them.
+
+	While that seems a bit obscure, it seems to me that "distclean" is
+	only really useful for in-tree builds anyway -- out-of-tree I simply
+	delete the entire build directory and start over.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12440
+
+2022-03-01  Tom Tromey  <tom@tromey.com>
+
+	Fix typo in the "alias" example
+	PR cli/17332, filed around 8 years ago, points out a typo in the docs
+	-- in one example, the command and its output are obviously out of
+	sync.  This patch fixes it.  I'm checking this in as obvious.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17332
+
+2022-03-01  Nick Clifton  <nickc@redhat.com>
+
+	Fix a typo in the previous delta to bfdio.c.
+		PR 25713
+		* bfdio.c (_bfd_real_fopen): Fix typo.
+
+2022-03-01  Alan Modra  <amodra@gmail.com>
+
+	Revert "Check thin archive element file size against archive header"
+	This reverts commit 48e3e6aec8a4f37d00ea6c0da3ab45e76490e3db.
+
+		PR 28929
+		* archive.c (_bfd_get_elt_at_filepos): Don't check thin archive
+		element file size.
+
+2022-03-01  Nick Clifton  <nickc@redhat.com>
+
+	Fix linker tests to compile with gcc-12.
+		PR 21964
+		* testsuite/ld-elf/pr21964-1a.c: Fix array comparisons.
+		* testsuite/ld-elf/pr21964-1b.c: Likewise.
+		* testsuite/ld-elf/pr21964-1c.c: Likewise.
+		* testsuite/ld-elf/pr21964-2a.c: Likewise.
+		* testsuite/ld-elf/pr21964-2b.c: Likewise.
+		* testsuite/ld-elf/pr21964-3a.c: Likewise.
+
+	Prevent an assertion from being triggered when linking an ARM object file with incorrectly set build attributes.
+		PR 28848
+		PR 28859
+		* elf32-arm.c (elf32_arm_merge_eabi_attributes): If the first
+		input bfd has a Tag_ABI_HardFP_use set to 3 but does not also have
+		TAG_FP_arch set then reset the TAG_ABI_HardFP_use.
+
+2022-03-01  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: testsuite: fix wrong expected result in attach-pie-noexec.exp
+	If /proc/sys/kernel/yama/ptrace_scope is 1, when execute the test case
+	gdb.base/attach-pie-noexec.exp without superuser, the gdb.log shows the
+	following info:
+
+	  (gdb) attach 6500
+	  Attaching to process 6500
+	  ptrace: Operation not permitted.
+	  (gdb) PASS: gdb.base/attach-pie-noexec.exp: attach
+
+	It is obviously wrong, the expected result should be UNSUPPORTED in such
+	a case.
+
+	It is better to make can_spawn_for_attach to return false for this case.
+	It would have to setup a small test program, compile it to exec, spawn it
+	and try to attach to it.
+
+	With this patch, we can see "Operation not permitted" in the log info,
+	and then we can do the following processes to test:
+	(1) set ptrace_scope as 0
+	    $ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
+	    $ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
+	(2) use sudo
+	    $ sudo make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
+
+	Additionally, handle the other cases when test with RUNTESTFLAGS=
+	"--target_board=native-extended-gdbserver".
+
+2022-03-01  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: testsuite: print explicit test result in can_spawn_for_attach
+	In the current code, there is no test result when execute the following
+	commands:
+
+	  $ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp" RUNTESTFLAGS="--target_board=remote-gdbserver-on-localhost"
+	  $ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp" RUNTESTFLAGS="--target_board=native-gdbserver"
+
+	It is better to print explicit test result in can_spawn_for_attach.
+
+2022-03-01  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: add Tiezhu Yang as LoongArch maintainer
+	The patch series "gdb: Add basic support for LoongArch" has been
+	merged into master, list Tiezhu Yang as LoongArch maintainer.
+
+2022-03-01  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-28  Keith Seitz  <keiths@redhat.com>
+
+	Fix "spawn id XYZ not open" errors in gdb.mi/mi-exec-run.exp
+	Running mi-exec-run.exp on native-extended-gdbserver/-m{32,64}
+	causes several Tcl errors to appear. For example,
+
+	(gdb)
+	ERROR: : spawn id exp20 not open
+	    while executing
+	"expect {
+	-i exp11 -timeout 10
+	                -i "$inferior_spawn_id"
+	                -re ".*Cannot exec.*Permission denied" {
+	                    set saw_perm_error 1
+	                    verbose -log "saw..."
+	    ("uplevel" body line 1)
+	    invoked from within
+	"uplevel $body" NONE : spawn id exp20 not open
+	UNRESOLVED: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=1: run failure detected (eof)
+
+	This is happening because of the way this test is implemented:
+
+	        while {1} {
+	            gdb_expect {
+	                -i "$inferior_spawn_id"
+	                -re ".*Cannot exec.*Permission denied" {
+	                    set saw_perm_error 1
+	                    verbose -log "saw mi error"
+	                }
+	                -i "$gdb_spawn_id"
+	                -re "\\^error,msg=\"During startup program exited with code 127" {
+	                    set saw_mi_error 1
+	                    verbose -log "saw mi error"
+	                }
+	               # and so on
+	            }
+	        }
+
+	The first time this loop is executed, `inferior_spawn_id' is valid. When the
+	first branch of the expect statement is reached, gdbserver has exited, closing
+	the spawn_id.  Since we haven't seen the gdb-side error yet, the loop is executed
+	again.  The first branch now refers to a non-existent spawn_id, leading to the error.
+
+	This can be fixed by using exp_continue to loop in expect instead of looping around
+	expect, which is the approach I have used[1].  Note I've had to update the expected
+	message for the "During startup..." error message when running with gdbserver.
+
+	One other small change I've made is to add a log entry which spills the values of
+	the two variables, saw_mi_error and saw_perm_error (and updated the log output
+	for the later).  This should make the log output clearer about why the test failed.
+
+	With this patch installed, all the ERRORs disappear, leaving previously masked
+	FAILs (which I have not attempted to fix).
+
+	[1] Anyone know why this test doesn't simply use gdb_test_multiple? I can only
+	assume that it was intentionally written this way, and I've modified the code with
+	that assumption. I have tested a version using gdb_test_multiple, and that appears
+	to work fine, too, if that is preferred. [It still employs exp_continue to fix the
+	spawn_id errors.]
+
+2022-02-28  Tom Tromey  <tromey@adacore.com>
+
+	Add more filename styling
+	I found a few spots where filename styling ought to be applied, but is
+	not.
+
+2022-02-28  Tom Tromey  <tromey@adacore.com>
+
+	Fix maybe-uninitialized warning in py-infthread.c
+	I got this warning from py-infthread.c using the Fedora 34 system GCC:
+
+	../../binutils-gdb/gdb/python/py-infthread.c:102:30: warning: ‘extra_info’ may be used uninitialized in this function [-Wmaybe-uninitialized]
+
+	I think this happens because GDB_PY_HANDLE_EXCEPTION expands to an
+	'if' whose condition is always true -- but GCC can't know this.  This
+	patch avoids the warning by adding a harmless initialization.
+
+2022-02-28  Tom Tromey  <tromey@adacore.com>
+
+	Handle multi-byte bracket sequences in Ada lexer
+	As noted in an earlier patch, the Ada lexer does not handle multi-byte
+	bracket sequences.  This patch adds support for these for character
+	literals.  gdb does not generally seem to handle the Ada wide string
+	types, so for the time being these continue to be excluded -- but an
+	explicit error is added to make this more clear.
+
+2022-02-28  Tom Tromey  <tromey@adacore.com>
+
+	Handle 'QWW' encoding case in Ada enums
+	In Ada, an enum can contain character literals.  GNAT encodes these
+	values in a special way.  For example, the Unicode character U+0178
+	would be represented as 'QW0178' in the DWARF:
+
+	 <3><112f>: Abbrev Number: 2 (DW_TAG_enumerator)
+	    <1130>   DW_AT_name        : (indirect string, offset: 0x19ff): QW0178
+	    <1134>   DW_AT_const_value : 2
+
+	gdb handles this reasonably well, but failed to handle the 'QWW'
+	encoding, which is used for characters outside the base plane.
+
+	Also, while working on this, I noticed that gdb will print the decimal
+	value for an enum character constant:
+
+	    (gdb) print Char_X
+	    $2 = 1 'x'
+
+	This is a nice feature, IMO, because in this situation the 'x' enum
+	constant does not have its usual decimal value -- it has the value
+	that's assigned based on the enumeration type.
+
+	However, gdb did not do this when it decided to print the constant
+	using the bracket notation:
+
+	    (gdb) print Char_Thorn
+	    $3 = ["de"]
+
+	This patch changes gdb to print the decimal value here as well, and to
+	put the bracket notation in single quotes -- otherwise gdb will be
+	printing something that it can't then read.  Now it looks like:
+
+	    (gdb) print Char_Thorn
+	    $3 = 4 '["de"]'
+
+	Note that gdb can't read longer bracket notations, like the other ones
+	printed in this test case:
+
+	    (gdb) print Char_King
+	    $4 = 3 '["01fa00"]'
+
+	While I think this is a bug, I plan to fix it separately.
+
+	Finally, in the new test case, the copyright dates are chosen this way
+	because this all started as a copy of an existing test.
+
+2022-02-28  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/python: Add gdb.InferiorThread.details attribute
+	This adds a new read-only attribute gdb.InferiorThread.details, this
+	attribute contains a string, the results of target_extra_thread_info
+	for the thread, or None, if target_extra_thread_info returns nullptr.
+
+	As the string returned by target_extra_thread_info is unstructured,
+	this attribute is only really useful for echoing straight through to
+	the user, but, if a user wants to write a command that displays the
+	same, or a similar 'Thread Id' to the one seen in 'info threads', then
+	they need access to this string.
+
+	Given that the string produced by target_extra_thread_info varies by
+	target, there's only minimal testing of this attribute, I check that
+	the attribute can be accessed, and that the return value is either
+	None, or a string.
+
+2022-02-28  Keith Seitz  <keiths@redhat.com>
+
+	Error when gdb_is_target_1 is called without running gdb instance
+	This is a snafu that I encountered while implementing the previous
+	patch, which attempted to use gdb_is_target_native.  This proc and
+	gdb_is_target_remote both rely on gdb_is_target_1, which actually
+	cannot be called without gdb already running.
+
+	This patch adds appropriate warning comments to these procs and
+	causes gdb_is_target_1 to issue a Tcl error if it is called without a
+	gdb instance already running.  This should prevent unwitting callers
+	from using this at the wrong time.
+
+2022-02-28  Keith Seitz  <keiths@redhat.com>
+
+	Fix gdb.fortran "failed to extract expected results" errors
+	When running the gdb.fortran tests array-slices.exp and lbound-ubound.exp,
+	the test suite throws several ERRORs on native-gdbserver/-m{32,64},
+	and native-extended-gdbsever/-m{32,64}:
+
+	[on native-extended-gdbserver/-m64]
+	Running /home/keiths/work/gdb/branches/testsuite-errors/linux/gdb/testsuite/../../../src/gdb/testsuite/gdb.fortran/array-slices.exp ...
+	ERROR: failed to extract expected results
+	ERROR: failed to extract expected results
+	Running /home/keiths/work/gdb/branches/testsuite-errors/linux/gdb/testsuite/../../../src/gdb/testsuite/gdb.fortran/lbound-ubound.exp ...
+	ERROR: failed to extract expected results for lbound
+
+	This occurs because the tests require inferior I/O which we do not have
+	access to while using these targets.
+
+	This patch skips these tests when running on non-native targets.
+
+2022-02-28  Torbj?rn Svensson  <torbjorn.svensson@st.com>
+
+	Further correct the handling of long pathnames on Windows hosts.
+		PR 25713
+		* bfdio.c (_bfd_real_fopen): Fix handling of parhs longer than 260
+		characters on Windows hosts.
+
+2022-02-28  Nick Clifton  <nickc@redhat.com>
+
+	Clarify the wording of the error message when an obsolete configuration is encountered.
+		PR 28886
+		* config.bfd: Update error message for obsolete configurations.
+
+2022-02-28  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-27  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-26  Kevin Buettner  <kevinb@redhat.com>
+
+	Handle recursive internal problem in gdb_internal_error_resync
+	I came across this problem when testing gdb.base/gdb-sigterm.exp
+	on a machine with a pre-release version of glib-2.34 installed:
+
+	A problem internal to GDB has been detected,
+	further debugging may prove unreliable.
+	Quit this debugging session? (y or n) Recursive internal problem.
+	FAIL: gdb.base/gdb-sigterm.exp: expect eof #0 (GDB internal error)
+	Resyncing due to internal error.
+	ERROR: : spawn id exp11 not open
+	    while executing
+	"expect {
+	-i exp11 -timeout 10
+		    -re "Quit this debugging session\\? \\(y or n\\) $" {
+			send_gdb "n\n" answer
+			incr count
+		    }
+		    -re "Create..."
+	    ("uplevel" body line 1)
+	    invoked from within
+	"uplevel $body" NONE : spawn id exp11 not open
+	ERROR: Could not resync from internal error (timeout)
+	gdb.base/gdb-sigterm.exp: expect eof #0: stepped 9 times
+	UNRESOLVED: gdb.base/gdb-sigterm.exp: 50 SIGTERM passes
+
+	I don't have a problem with the latter ERROR nor the UNRESOLVED
+	messages.  However the first ERROR regarding the exp11 spawn id
+	not being open is not especially useful.
+
+	This commit handles the "Recursive internal problem" case, avoiding
+	the problematic ERROR shown above.
+
+	With this commit in place, the log messages look like this instead:
+
+	A problem internal to GDB has been detected,
+	further debugging may prove unreliable.
+	Quit this debugging session? (y or n) Recursive internal problem.
+	FAIL: gdb.base/gdb-sigterm.exp: expect eof #15 (GDB internal error)
+	Resyncing due to internal error.
+	ERROR: Could not resync from internal error (recursive internal problem)
+	gdb.base/gdb-sigterm.exp: expect eof #15: stepped 12 times
+	UNRESOLVED: gdb.base/gdb-sigterm.exp: 50 SIGTERM passes
+
+	gdb/testsuite/ChangeLog:
+
+		* lib/gdb.exp (gdb_internal_error_resync): Handle "Recursive
+		internal problem".
+
+2022-02-26  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-25  Aaron Merey  <amerey@redhat.com>
+
+	gdb-add-index: disable debuginfod
+	gdb-add-index may trigger debuginfod's first-use notice.  The notice
+	is misleading in this case.  It instructs the user to modify .gdbinit
+	in order to permanently enable/disable debuginfod but gdb-add-index
+	invokes gdb with -nx which ignores .gdbinit.
+
+	Additionally debuginfod is not needed for gdb-add-index since the
+	symbol file is given as an argument and should already be present
+	locally.
+
+	Fix this by disabling debuginfod when gdb-add-index invokes gdb.
+
+2022-02-25  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: add operator+= and operator+ overload for std::string
+	This commit adds operator+= and operator+ overloads for adding
+	gdb::unique_xmalloc_ptr<char> to a std::string.  I could only find 3
+	places in GDB where this was useful right now, and these all make use
+	of operator+=.
+
+	I've also added a self test for gdb::unique_xmalloc_ptr<char>, which
+	makes use of both operator+= and operator+, so they are both getting
+	used/tested.
+
+	There should be no user visible changes after this commit, except when
+	running 'maint selftest', where the new self test is visible.
+
+2022-02-25  Tom Tromey  <tromey@adacore.com>
+
+	Print MI prompt on interrupted command
+	Joel noticed that if the remote dies unexpectedly during a command --
+	you can simulate this by using "continue" and then killing gdbserver
+	-- then the CLI will print a new prompt, but MI will not.  Later, we
+	found out that this was also filed in bugzilla as PR mi/23820.
+
+	The output looks something like this:
+
+	    | (gdb)
+	    | cont
+	    | &"cont\n"
+	    | ~"Continuing.\n"
+	    | ^running
+	    | *running,thread-id="all"
+	    | (gdb)
+	    | [... some output from GDB during program startup...]
+	    | =thread-exited,id="1",group-id="i1"
+	    | =thread-group-exited,id="i1"
+	    | &"Remote connection closed\n"
+
+	Now, what about that "(gdb)" in the middle?
+
+	That prompt comes from this questionable code in
+	mi-interp.c:mi_on_resume_1:
+
+	      /* This is what gdb used to do historically -- printing prompt
+		 even if it cannot actually accept any input.  This will be
+		 surely removed for MI3, and may be removed even earlier.  */
+	      if (current_ui->prompt_state == PROMPT_BLOCKED)
+		fputs_unfiltered ("(gdb) \n", mi->raw_stdout);
+
+	... which seems like something to remove.  But maybe the intent here
+	is that this prompt is sufficient, and MI clients must be ready to
+	handle output coming after a prompt.  On the other hand, if this code
+	*is* removed, then nothing would print a prompt in this scenario.
+
+	Anyway, the CLI and the TUI handle emitting the prompt here by hooking
+	into gdb::observers::command_error, but MI doesn't install an observer
+	here.
+
+	This patch adds the missing observer and arranges to show the MI
+	prompt.  Regression tested on x86-64 Fedora 34.
+
+	It seems like this area could be improved a bit, by having
+	start_event_loop call the prompt-displaying code directly, rather than
+	indirecting through an observer.  However, I haven't done this.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23820
+
+2022-02-25  Andrew Burgess  <aburgess@redhat.com>
+	    Tom Tromey  <tromey@adacore.com>
+
+	gdb/testsuite: fix list.exp test cases
+	PR testsuite/7142 -- old enough to have been converted from Gnats --
+	points out that test_list_filename_and_function in gdb.base/list.exp
+	has "fails" that are unmatched with passes.  This patch cleans this up
+	a little.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7142
+
+2022-02-25  Tsukasa OI  <research_trasio@irq.a4lg.com>
+
+	RISC-V: Remove a loop in the ISA parser
+	Since commit e601909a3287bf541c6a7d82214bb387d2c76d82 ("RISC-V: Support
+	to parse the multi-letter prefix in the architecture string.") changed
+	so that all prefixed extensions are parsed in single
+	riscv_parse_prefixed_ext call, a "while" loop on riscv_parse_subset
+	is no longer required.
+
+	bfd/ChangeLog:
+
+		* elfxx-riscv.c (riscv_parse_subset): Remove unnecessary loop.
+
+2022-02-25  Tsukasa OI  <research_trasio@irq.a4lg.com>
+
+	RISC-V: Fix mask for some fcvt instructions
+	This commit fixes incorrect uses of mask values in 'fcvt' instruction
+	family.
+
+	opcodes/ChangeLog:
+
+		* riscv-opc.c (riscv_opcodes): Fix incorrect uses of mask values
+		in 'fcvt' instruction family.
+
+2022-02-25  Keith Seitz  <keiths@redhat.com>
+
+	Support template lookups in strncmp_iw_with_mode
+	This patch adds support for wild template parameter list matches, similar
+	to how ABI tags or function overloads are now handled.
+
+	With this patch, users will be able to "gloss over" the details of matching
+	template parameter lists.  This is accomplished by adding (yet more) logic
+	to strncmp_iw_with_mode to skip parameter lists if none is explicitly given
+	by the user.
+
+	Here's a simple example using gdb.linespec/cpls-ops.exp:
+
+	Before
+	------
+	(gdb) ptype test_op_call
+	type = struct test_op_call {
+	  public:
+	    void operator()(void);
+	    void operator()(int);
+	    void operator()(long);
+	    void operator()<int>(int *);
+	}
+	(gdb) b test_op_call::operator()
+	Breakpoint 1 at 0x400583: test_op_call::operator(). (3 locations)
+	(gdb) i b
+	Num     Type           Disp Enb Address            What
+	1       breakpoint     keep y   <MULTIPLE>
+	1.1                         y     0x400583 in test_op_call::operator()(int)
+	                                                   at cpls-ops.cc:43
+	1.2                         y     0x40058e in test_op_call::operator()()
+	                                                   at cpls-ops.cc:47
+	1.3                         y     0x40059e in test_op_call::operator()(long)
+	                                                   at cpls-ops.cc:51
+
+	The breakpoint at test_op_call::operator()<int> was never set.
+
+	After
+	-----
+	(gdb) b test_op_call::operator()
+	Breakpoint 1 at 0x400583: test_op_call::operator(). (4 locations)
+	(gdb) i b
+	Num     Type           Disp Enb Address            What
+	1       breakpoint     keep y   <MULTIPLE>
+	1.1                         y     0x400583 in test_op_call::operator()(int)
+	                                                   at cpls-ops.cc:43
+	1.2                         y     0x40058e in test_op_call::operator()()
+	                                                   at cpls-ops.cc:47
+	1.3                         y     0x40059e in test_op_call::operator()(long)
+	                                                   at cpls-ops.cc:51
+	1.4                         y     0x4008d0 in test_op_call::operator()<int>(int*)
+	                                                   at cpls-ops.cc:57
+
+	Similar to how scope lookups work, passing "-qualified" to the break command
+	will cause a literal lookup of the symbol.  In the example immediately above,
+	this will cause GDB to only find the three non-template functions.
+
+2022-02-25  Keith Seitz  <keiths@redhat.com>
+
+	Unit tests for strncmp_iw_with_mode
+	This patch attempts to make a start at adding unit tests for
+	strncmp_iw_with_mode.  While there is quite a bit of testing
+	of this function in other tests, these are currently end-to-end
+	tests.
+
+	This patch attempts to cover the basics of string matching, white
+	space, C++ ABI tags, and several other topics. However, one area
+	that is ostensibly missing is testing the `match_for_lcd' feature.
+	This is otherwise tested as part of our end-to-end DejaGNU-based
+	testing.
+
+2022-02-25  Keith Seitz  <keiths@redhat.com>
+
+	Move find_toplevel_char to cp-support.[ch]
+	find_toplevel_char is being used more and more outside of linespec.c, so
+	this patch moves it into cp-support.[ch].
+
+2022-02-25  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-24  Tom Tromey  <tom@tromey.com>
+	    Andrew Burgess  <aburgess@redhat.com>
+
+	Fix crash in Fortran code
+	PR fortran/28801 points out a gdb crash that can be provoked by
+	certain Fortran code.  The bug is that f77_get_upperbound assumes the
+	property is either a constant or undefined, but in this case it is
+	PROP_LOCEXPR.
+
+	This patch fixes the crash by making this function (and the
+	lower-bound one as well) do the correct check before calling
+	'const_val'.
+
+	Thanks to Andrew for writing the test case.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28801
+
+2022-02-24  John Baldwin  <jhb@FreeBSD.org>
+
+	Revert "do_target_wait_1: Clear TARGET_WNOHANG if the target isn't async."
+	Commit 14b3360508b1 ("do_target_wait_1: Clear
+	TARGET_WNOHANG if the target isn't async.") broke some multi-target
+	tests, such as gdb.multi/multi-target-info-inferiors.exp.  The symptom
+	is that execution just hangs at some point.  What happens is:
+
+	1. One remote inferior is started, and now sits stopped at a breakpoint.
+	   It is not "async" at this point (but it "can async").
+
+	2. We run a native inferior, the event loop gets woken up by the native
+	   target's fd.
+
+	3. In do_target_wait, we randomly choose an inferior to call target_wait
+	   on first, it happens to be the remote inferior.
+
+	4. Because the target is currently not "async", we clear
+	   TARGET_WNOHANG, resulting in synchronous wait.  We therefore block
+	   here:
+
+	  #0  0x00007fe9540dbb4d in select () from /usr/lib/libc.so.6
+	  #1  0x000055fc7e821da7 in gdb_select (n=15, readfds=0x7ffdb77c1fb0, writefds=0x0, exceptfds=0x7ffdb77c2050, timeout=0x7ffdb77c1f90) at /home/simark/src/binutils-gdb/gdb/posix-hdep.c:31
+	  #2  0x000055fc7ddef905 in interruptible_select (n=15, readfds=0x7ffdb77c1fb0, writefds=0x0, exceptfds=0x7ffdb77c2050, timeout=0x7ffdb77c1f90) at /home/simark/src/binutils-gdb/gdb/event-top.c:1134
+	  #3  0x000055fc7eda58e4 in ser_base_wait_for (scb=0x6250002e4100, timeout=1) at /home/simark/src/binutils-gdb/gdb/ser-base.c:240
+	  #4  0x000055fc7eda66ba in do_ser_base_readchar (scb=0x6250002e4100, timeout=-1) at /home/simark/src/binutils-gdb/gdb/ser-base.c:365
+	  #5  0x000055fc7eda6ff6 in generic_readchar (scb=0x6250002e4100, timeout=-1, do_readchar=0x55fc7eda663c <do_ser_base_readchar(serial*, int)>) at /home/simark/src/binutils-gdb/gdb/ser-base.c:444
+	  #6  0x000055fc7eda718a in ser_base_readchar (scb=0x6250002e4100, timeout=-1) at /home/simark/src/binutils-gdb/gdb/ser-base.c:471
+	  #7  0x000055fc7edb1ecd in serial_readchar (scb=0x6250002e4100, timeout=-1) at /home/simark/src/binutils-gdb/gdb/serial.c:393
+	  #8  0x000055fc7ec48b8f in remote_target::readchar (this=0x617000038780, timeout=-1) at /home/simark/src/binutils-gdb/gdb/remote.c:9446
+	  #9  0x000055fc7ec4da82 in remote_target::getpkt_or_notif_sane_1 (this=0x617000038780, buf=0x6170000387a8, forever=1, expecting_notif=1, is_notif=0x7ffdb77c24f0) at /home/simark/src/binutils-gdb/gdb/remote.c:9928
+	  #10 0x000055fc7ec4f045 in remote_target::getpkt_or_notif_sane (this=0x617000038780, buf=0x6170000387a8, forever=1, is_notif=0x7ffdb77c24f0) at /home/simark/src/binutils-gdb/gdb/remote.c:10037
+	  #11 0x000055fc7ec354d4 in remote_target::wait_ns (this=0x617000038780, ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/remote.c:8147
+	  #12 0x000055fc7ec38aa1 in remote_target::wait (this=0x617000038780, ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/remote.c:8337
+	  #13 0x000055fc7f1409ce in target_wait (ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/target.c:2612
+	  #14 0x000055fc7e19da98 in do_target_wait_1 (inf=0x617000038080, ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/infrun.c:3636
+	  #15 0x000055fc7e19e26b in operator() (__closure=0x7ffdb77c2f90, inf=0x617000038080) at /home/simark/src/binutils-gdb/gdb/infrun.c:3697
+	  #16 0x000055fc7e19f0c4 in do_target_wait (ecs=0x7ffdb77c33a0, options=...) at /home/simark/src/binutils-gdb/gdb/infrun.c:3716
+	  #17 0x000055fc7e1a31f7 in fetch_inferior_event () at /home/simark/src/binutils-gdb/gdb/infrun.c:4061
+
+	Before the aforementioned commit, we would not have cleared
+	TARGET_WNOHANG, the remote target's wait would have returned nothing,
+	and we would have consumed the native target's event.
+
+	After applying this revert, the testsuite state looks as good as before
+	for me on Ubuntu 20.04 amd64.
+
+	Change-Id: Ic17a1642935cabcc16c25cb6899d52e12c2f5c3f
+
+2022-02-24  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: use a range based for loop when iterating over an array
+	Make use of a range based for loop to iterate over a static global
+	array, removing the need to have a null entry at the end of the
+	array.
+
+	There should be no user visible changes after this commit.
+
+2022-02-24  Dominique Quatravaux  <dominique.quatravaux@epfl.ch>
+	    Louis-He  <1726110778@qq.com>
+	    Philippe Blain  <levraiphilippeblain@gmail.com>
+
+	gdb/darwin: skip over WIFSTOPPED wait4 status
+	On modern Darwin's, there appears to be a new circumstance in which a
+	MACH_NOTIFY_DEAD_NAME message can be received, and which was not
+	previously accounted for: to signal the WIFSTOPPED condition in the
+	debuggee. In that case the debuggee is not dead yet (and in fact,
+	counting it as dead would cause a zombie leak - A process in such a
+	state reparents to PID 1, but cannot be killed).
+
+	 - Read and ignore such messages (counting on the next exception message
+	   to let us know of the inferior's new state again)
+	 - Refactor logging so as to clearly distinguish between the
+	   MACH_NOTIFY_DEAD_NAME cases (WIFEXITED, WIFSTOPPED, signal, or
+	   something else), and warn in the last case
+
+	Change-Id: Ie86904a894e9bd154e6b674b1bfbfbaee7fde3e1
+
+2022-02-24  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/linux-tdep: move "Perms" column right
+	Commit 29ef4c0699e1 ("gdb/linux-tdep.c: Add Perms to the 'info proc
+	mappings' output") has broken test gdb.base/info-proc.exp on Linux,
+	because it changes the output of "info proc mappings" in a way that the
+	test does not expect (my bad for not testing before pushing).
+
+	I looked at how FreeBSD handles this, since I remembered it did show
+	permission flags.  It looks like this:
+
+	          Start Addr           End Addr       Size     Offset   Flags   File
+	            0x200000           0x243000    0x43000        0x0  r-- CN-- /usr/local/bin/tmux
+
+	(I think that `Flags` and the flags not being aligned is not
+	intentional)
+
+	The test passes on FreeBSD, because the test looks for four hex numbers
+	in a row and ignores the rest:
+
+	    ".*Mapped address spaces:.*${hex}${ws}${hex}${ws}${hex}${ws}${hex}.*"
+
+	I suggest fixing it on Linux by moving the flags column to the same
+	place as in the FreeBSD output.  It makes things a bit more consistent
+	between OSes, and we don't have to touch the test.
+
+	At the same time, make use of the actual length of the permission's
+	string to specify the number of characters to print.
+
+	Before this patch, the output looks like:
+
+	          Start Addr           End Addr   Perms       Size     Offset objfile
+	      0x55dd4b544000     0x55dd4b546000   r--p      0x2000        0x0 /usr/bin/sleep
+
+	and after, it looks like:
+
+	          Start Addr           End Addr       Size     Offset  Perms  objfile
+	      0x5622ae662000     0x5622ae664000     0x2000        0x0  r--p   /usr/bin/sleep
+
+	Change-Id: If0fc167b010b25f97a3c54e2f491df4973ccde8f
+
+2022-02-24  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/linux-tdep: make read_mapping return a structure
+	Change read_mapping to return a structure instead of taking many output
+	parameters.  Change the string + length output parameters (permissions
+	and device) to be gdb::string_view, since that's what string_view is
+	for (a non-NULL terminated view on a string).  No changes in behavior
+	expected.
+
+	Change-Id: I86e627d84d3dda8c9b835592b0f4de8d90d12112
+
+2022-02-24  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-23  Tom Tromey  <tromey@adacore.com>
+
+	Fix bug in C++ overload resolution
+	PR c++/28901 points out a bug in C++ overload resolution.  When
+	comparing two overloads, one might be better than the other for
+	certain parameters -- but, if that one also has some invalid
+	conversion, then it should never be considered the better choice.
+	Instead, a valid-but-not-apparently-quite-as-good overload should be
+	preferred.
+
+	This patch fixes this problem by changing how overload comparisons are
+	done.  I don't believe it should affect any currently valid overload
+	resolution; nor should it affect resolutions where all the choices are
+	equally invalid.
+
+2022-02-23  Dominik 'Disconnect3d' Czarnota  <dominik.b.czarnota@gmail.com>
+
+	gdb/linux-tdep.c: Add Perms to the 'info proc mappings' output
+	Fixes #28914 and so it adds a 'Perms' (permissions) column to the
+	'info proc mappings' command output. This will allow users to know
+	the memory pages permissions right away from GDB instead of having
+	to fetch them from the /proc/$pid/maps file (which is also what GDB
+	does internally, but it just did not print that column).
+
+	Below I am also showing how an example output looks like before and
+	after this commit in case someone wonders.
+
+	On i386 targets - before this commit:
+	```
+	(gdb) info proc mappings
+	process 3461464
+	Mapped address spaces:
+
+	    Start Addr   End Addr        Size     Offset objfile
+	    0x56555000 0x56556000      0x1000        0x0 /home/dc/src/binutils-gdb/build/a.out
+	    0x56556000 0x56557000      0x1000     0x1000 /home/dc/src/binutils-gdb/build/a.out
+	    0x56557000 0x56558000      0x1000     0x2000 /home/dc/src/binutils-gdb/build/a.out
+	    0x56558000 0x5655a000      0x2000     0x2000 /home/dc/src/binutils-gdb/build/a.out
+	    0xf7fc4000 0xf7fc8000      0x4000        0x0 [vvar]
+	    0xf7fc8000 0xf7fca000      0x2000        0x0 [vdso]
+	    0xf7fca000 0xf7fcb000      0x1000        0x0 /usr/lib/i386-linux-gnu/ld-2.33.so
+	    0xf7fcb000 0xf7fee000     0x23000     0x1000 /usr/lib/i386-linux-gnu/ld-2.33.so
+	    0xf7fee000 0xf7ffb000      0xd000    0x24000 /usr/lib/i386-linux-gnu/ld-2.33.so
+	    0xf7ffb000 0xf7ffe000      0x3000    0x30000 /usr/lib/i386-linux-gnu/ld-2.33.so
+	    0xfffdc000 0xffffe000     0x22000        0x0 [stack]
+	(gdb)
+	```
+
+	On i386 targets - after this commit:
+	```
+	(gdb) info proc mappings
+	process 3461464
+	Mapped address spaces:
+
+	    Start Addr   End Addr   Perms       Size     Offset objfile
+	    0x56555000 0x56556000   r--p      0x1000        0x0 /home/dc/src/binutils-gdb/build/a.out
+	    0x56556000 0x56557000   r-xp      0x1000     0x1000 /home/dc/src/binutils-gdb/build/a.out
+	    0x56557000 0x56558000   r--p      0x1000     0x2000 /home/dc/src/binutils-gdb/build/a.out
+	    0x56558000 0x5655a000   rw-p      0x2000     0x2000 /home/dc/src/binutils-gdb/build/a.out
+	    0xf7fc4000 0xf7fc8000   r--p      0x4000        0x0 [vvar]
+	    0xf7fc8000 0xf7fca000   r-xp      0x2000        0x0 [vdso]
+	    0xf7fca000 0xf7fcb000   r--p      0x1000        0x0 /usr/lib/i386-linux-gnu/ld-2.33.so
+	    0xf7fcb000 0xf7fee000   r-xp     0x23000     0x1000 /usr/lib/i386-linux-gnu/ld-2.33.so
+	    0xf7fee000 0xf7ffb000   r--p      0xd000    0x24000 /usr/lib/i386-linux-gnu/ld-2.33.so
+	    0xf7ffb000 0xf7ffe000   rw-p      0x3000    0x30000 /usr/lib/i386-linux-gnu/ld-2.33.so
+	    0xfffdc000 0xffffe000   rw-p     0x22000        0x0 [stack]
+	(gdb)
+	```
+
+	On amd64 targets - after this commit:
+	```
+	(gdb) info proc mappings
+	process 3461869
+	Mapped address spaces:
+
+	          Start Addr           End Addr   Perms       Size     Offset objfile
+	      0x555555554000     0x555555555000   r--p      0x1000        0x0 /home/dc/src/binutils-gdb/build/a.out
+	      0x555555555000     0x555555556000   r-xp      0x1000     0x1000 /home/dc/src/binutils-gdb/build/a.out
+	      0x555555556000     0x555555557000   r--p      0x1000     0x2000 /home/dc/src/binutils-gdb/build/a.out
+	      0x555555557000     0x555555559000   rw-p      0x2000     0x2000 /home/dc/src/binutils-gdb/build/a.out
+	      0x7ffff7fc3000     0x7ffff7fc7000   r--p      0x4000        0x0 [vvar]
+	      0x7ffff7fc7000     0x7ffff7fc9000   r-xp      0x2000        0x0 [vdso]
+	      0x7ffff7fc9000     0x7ffff7fca000   r--p      0x1000        0x0 /usr/lib/x86_64-linux-gnu/ld-2.33.so
+	      0x7ffff7fca000     0x7ffff7ff1000   r-xp     0x27000     0x1000 /usr/lib/x86_64-linux-gnu/ld-2.33.so
+	      0x7ffff7ff1000     0x7ffff7ffb000   r--p      0xa000    0x28000 /usr/lib/x86_64-linux-gnu/ld-2.33.so
+	      0x7ffff7ffb000     0x7ffff7fff000   rw-p      0x4000    0x31000 /usr/lib/x86_64-linux-gnu/ld-2.33.so
+	      0x7ffffffdd000     0x7ffffffff000   rw-p     0x22000        0x0 [stack]
+	  0xffffffffff600000 0xffffffffff601000   --xp      0x1000        0x0 [vsyscall]
+	(gdb)
+	```
+
+	Change-Id: I4991f6cc758cd532eae3ae98c29d22e7bd9d9c36
+
+2022-02-23  Patrick O'Neill  <patrick@rivosinc.com>
+
+	RISC-V: PR28733, add missing extension info to 'unrecognized opcode' error
+	Currently we report errors as "unrecognized opcode `fence.i'" when the
+	opcode isn't part of the selected extensions.
+	This patch expands that error message to include the missing extension
+	information. For example, now the error message would be "unrecognized
+	opcode `fence.i', extension `zifencei' required".
+	If the opcode is not a part of any extension, the error message reverts
+	to "unrecognized opcode `<op statement>'".
+
+
+	bfd/
+		pr 28733
+		* elfxx-riscv.c (riscv_multi_subset_supports_ext): New function,
+		used to return the extension string for each INSN_CLASS_*.
+		* elfxx-riscv.h: Added extern riscv_multi_subset_supports_ext.
+	gas/
+		pr 28733
+		* config/tc-riscv.c (struct riscv_ip_error): New structure,
+		contains information about errors that occur within the riscv_ip.
+		(riscv_ip): Use struct riscv_ip_error to report more detailed errors.
+		* testsuite/gas/riscv/c-fld-fsd-fail.l: Updated.
+		* testsuite/gas/riscv/march-imply-i2p1-01.: Likewise.
+
+2022-02-23  Patrick O'Neill  <patrick@rivosinc.com>
+
+	RISC-V: PR28733, add missing extension info to 'invalid CSR' error
+	Currently we report errors as "invalid CSR 'fscr' for the current ISA"
+	when the instruction isn't valid.
+
+	This patch expands that error message to include the missing extension
+	information. For example, now the error message would be "invalid CSR
+	'fscr' for the current ISA, CSR 'fscr' needs 'f' extension".
+
+
+	gas/
+		pr 28733
+		* config/tc-riscv.c (riscv_csr_address): Report more details
+		when the CSR is invalid.
+		* testsuite/gas/riscv/csr-version-1p10.l: Updated detailed errors.
+		* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
+		* testsuite/gas/riscv/csr-version-1p12.l: Likewise.
+		* testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
+
+2022-02-23  Alan Modra  <amodra@gmail.com>
+
+	binutils 2.38 vs. ppc32 linux kernel
+	Commit b25f942e18d6 made .machine more strict.  Weaken it again.
+
+		* config/tc-ppc.c (ppc_machine): Treat an early .machine specially,
+		keeping sticky options to work around gcc bugs.
+
+2022-02-23  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: Updated CSRs to privileged spec v1.12 and debug spec v1.0.
+	* Removed N extension CSRs,
+	ustatus, uie, utvec, uscratch, uepc, ucause, utval and uip.
+
+	* Removed two supervisor CSRs,
+	sedeleg and sideleg.
+
+	* Changed debug CSR address of scontext from 0x7aa to 0x5a8.  We cannot support
+	different versions of debug specs for now, so only supporting the latest one is
+	the only way to move forward.
+
+	* Added debug CSRs,
+	mscontext (0x7aa), mcontrol6 (0x7a1, tdata1) and tmexttrigger ((0x7a1, tdata1).
+
+	* Regarded hcontext as a debug CSR.
+
+	include/
+		* opcode/riscv-opc.h: Updated CSRs to privileged spec v1.12 and
+		debug spec v1.0.
+	gas/
+		* testsuite/gas/riscv/csr.s: Updated CSRs to privileged spec v1.12
+		and debug spec v1.0.
+		* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
+		* testsuite/gas/riscv/csr-version-1p10.d: Likewise.
+		* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
+		* testsuite/gas/riscv/csr-version-1p11.d: Likewise.
+		* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
+		* testsuite/gas/riscv/csr-version-1p12.d: Likewise.
+		* testsuite/gas/riscv/csr-version-1p12.l: Likewise.
+		* testsuite/gas/riscv/csr-version-1p9p1.d: Likewise.
+		* testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
+		* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
+		* testsuite/gas/riscv/csr-dw-regnums.s: Likewise.
+
+2022-02-23  Tsukasa OI  <research_trasio@irq.a4lg.com>
+
+	RISC-V: Add Privileged Architecture 1.12 CSRs
+	This commit adds,
+
+	* Most of CSRs as listed in the Privileged Architecture,
+	version 1.12 (except scontext and mscontext).
+
+	* Testcases for most CSRs added on the Privileged
+	Architecture, version 1.12 (except moved "scontext" and
+	new "mscontext").
+
+	include/ChangeLog:
+
+		* opcode/riscv-opc.h (CSR_SENVCFG, CSR_MCONFIGPTR, CSR_MENVCFG,
+		CSR_MSTATUSH, CSR_MENVCFGH, CSR_MTINST, CSR_MTVAL2, CSR_MSECCFG,
+		CSR_MSECCFGH, CSR_PMPCFG4, CSR_PMPCFG5, CSR_PMPCFG6,
+		CSR_PMPCFG7, CSR_PMPCFG8, CSR_PMPCFG9, CSR_PMPCFG10,
+		CSR_PMPCFG11, CSR_PMPCFG12, CSR_PMPCFG13, CSR_PMPCFG14,
+		CSR_PMPCFG15, CSR_PMPADDR16, CSR_PMPADDR17, CSR_PMPADDR18,
+		CSR_PMPADDR19, CSR_PMPADDR20, CSR_PMPADDR21, CSR_PMPADDR22,
+		CSR_PMPADDR23, CSR_PMPADDR24, CSR_PMPADDR25, CSR_PMPADDR26,
+		CSR_PMPADDR27, CSR_PMPADDR28, CSR_PMPADDR29, CSR_PMPADDR30,
+		CSR_PMPADDR31, CSR_PMPADDR32, CSR_PMPADDR33, CSR_PMPADDR34,
+		CSR_PMPADDR35, CSR_PMPADDR36, CSR_PMPADDR37, CSR_PMPADDR38,
+		CSR_PMPADDR39, CSR_PMPADDR40, CSR_PMPADDR41, CSR_PMPADDR42,
+		CSR_PMPADDR43, CSR_PMPADDR44, CSR_PMPADDR45, CSR_PMPADDR46,
+		CSR_PMPADDR47, CSR_PMPADDR48, CSR_PMPADDR49, CSR_PMPADDR50,
+		CSR_PMPADDR51, CSR_PMPADDR52, CSR_PMPADDR53, CSR_PMPADDR54,
+		CSR_PMPADDR55, CSR_PMPADDR56, CSR_PMPADDR57, CSR_PMPADDR58,
+		CSR_PMPADDR59, CSR_PMPADDR60, CSR_PMPADDR61, CSR_PMPADDR62,
+		CSR_PMPADDR63): New CSR macros.
+
+	gas/ChangeLog:
+
+		* testsuite/gas/riscv/csr-dw-regnums.s: Add new CSRs.
+		* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
+		* testsuite/gas/riscv/csr.s: Add new CSRs.
+		* testsuite/gas/riscv/csr-version-1p9p1.d: Likewise.
+		* testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
+		* testsuite/gas/riscv/csr-version-1p10.d: Likewise.
+		* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
+		* testsuite/gas/riscv/csr-version-1p11.d: Likewise.
+		* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
+		* testsuite/gas/riscv/csr-version-1p12.d: Likewise.
+		* testsuite/gas/riscv/csr-version-1p12.l: Likewise.
+
+2022-02-23  Tsukasa OI  <research_trasio@irq.a4lg.com>
+
+	RISC-V: Reorganize testcases for CFI directives
+	This commit reorganizes and adds some CSRs to csr-dw-regnums.[sd] to
+	make it test the same CSRs as csr.s.
+
+	gas/ChangeLog:
+
+		* testsuite/gas/riscv/csr-dw-regnums.s: Reorganize and add
+		defined CSRs tested in csr.s.
+		* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
+
+2022-02-23  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-22  John Baldwin  <jhb@FreeBSD.org>
+
+	NEWS: Note that the FreeBSD async target supports async mode.
+
+2022-02-22  John Baldwin  <jhb@FreeBSD.org>
+
+	inf-ptrace: Add an event_pipe to be used for async mode in subclasses.
+	Subclasses of inf_ptrace_target have to opt-in to using the event_pipe
+	by implementing the can_async_p and async methods.  For subclasses
+	which do this, inf_ptrace_target provides is_async_p, async_wait_fd
+	and closes the pipe in the close target method.
+
+	inf_ptrace_target also provides wrapper routines around the event pipe
+	(async_file_open, async_file_close, async_file_flush, and
+	async_file_mark) for use in target methods such as async.
+	inf_ptrace_target also exports a static async_file_mark_if_open
+	function which can be used in SIGCHLD signal handlers.
+
+2022-02-22  John Baldwin  <jhb@FreeBSD.org>
+
+	Enable async mode in the target in attach_cmd.
+	If the attach target supports async mode, enable it after the
+	attach target's ::attach method returns.
+
+	fbsd-nat: Return nullptr rather than failing ::thread_name.
+	ptrace on FreeBSD cannot be used against running processes and instead
+	fails with EBUSY.  This meant that 'info threads' would fail if any of
+	the threads were running (for example when using schedule-multiple=on
+	in gdb.base/fork-running-state.exp).  Instead of throwing errors, just
+	return nullptr as no thread name is better than causing info threads to
+	fail completely.
+
+2022-02-22  John Baldwin  <jhb@FreeBSD.org>
+
+	fbsd-nat: Various cleanups to the ::resume entry debug message.
+	Move the message from 'show debug fbsd-lwp' to 'show debug fbsd-nat'
+	since it is helpful for debugging async target support and not just
+	LWP support.
+
+	Use target_pid_to_str to format the ptid and log the step and signo
+	arguments.
+
+2022-02-22  John Baldwin  <jhb@FreeBSD.org>
+
+	fbsd-nat: Include ptrace operation in error messages.
+
+2022-02-22  John Baldwin  <jhb@FreeBSD.org>
+
+	fbsd-nat: Implement async target support.
+	This is a fairly simple version of async target support.
+
+	Synchronous mode still uses blocking waitpid() calls in
+	inf_ptrace::wait() unlike the Linux native target which always uses
+	WNOHANG and uses sigsuspend() for synchronous operation.
+
+	Asynchronous mode registers an event pipe with the core as a file
+	handle and writes to the pipe when SIGCHLD is raised.  TARGET_WNOHANG
+	is handled by inf_ptrace::wait().
+
+2022-02-22  John Baldwin  <jhb@FreeBSD.org>
+
+	inf-ptrace: Support async targets in inf_ptrace_target::wait.
+	- Handle TARGET_WNOHANG by passing WNOHANG to waitpid and returning
+	  TARGET_WAITKIND_IGNORE if there are no events to report.
+
+	- Handle a race in async mode where SIGCHLD might signal the event
+	  pipe for an event that has already been reported.  If the event was
+	  the exit of the last child process, waitpid() will fail with ECHILD
+	  rather than returning a pid of 0.  For this case, return
+	  TARGET_WAITKIND_NO_RESUMED.
+
+2022-02-22  John Baldwin  <jhb@FreeBSD.org>
+
+	inf-ptrace: Return an IGNORE event if waitpid() fails.
+	Previously this returned a TARGET_WAITKIND_SIGNALLED event for
+	inferior_ptid.  However, inferior_ptid is invalid during ::wait()
+	methods after the multi-target changes, so this was triggering an
+	assertion further up the stack.
+
+	do_target_wait_1: Clear TARGET_WNOHANG if the target isn't async.
+	Previously, TARGET_WNOHANG was cleared if a target supported async
+	mode even if async mode wasn't currently enabled.  This change only
+	permits TARGET_WNOHANG if async mode is enabled.
+
+2022-02-22  John Baldwin  <jhb@FreeBSD.org>
+
+	Don't enable async mode at the end of target ::resume methods.
+	Now that target_resume always enables async mode after target::resume
+	returns, these calls are redundant.
+
+	The other place that target resume methods are invoked outside of
+	target_resume are as the beneath target in record_full_wait_1.  In
+	this case, async mode should already be enabled when supported by the
+	target before the resume method is invoked due to the following:
+
+	  In general, targets which support async mode run as async until
+	  ::wait returns TARGET_WAITKIND_NO_RESUMED to indicate that there are
+	  no unwaited for children (either they have exited or are stopped).
+	  When that occurs, the loop in wait_one disables async mode.  Later
+	  if a stopped child is resumed, async mode is re-enabled in
+	  do_target_resume before waiting for the next event.
+
+	  In the case of record_full_wait_1, this function is invoked from the
+	  ::wait target method when fetching an event.  If the underlying
+	  target supports async mode, then an earlier call to do_target_resume
+	  to resume the child reporting an event in the loop in
+	  record_full_wait_1 would have already enabled async mode before
+	  ::wait was invoked.  In addition, nothing in the code executed in
+	  the loop in record_full_wait_1 disables async mode.  Async mode is
+	  only disabled higher in the call stack in wait_one after ::wait
+	  returns.
+
+	  It is also true that async mode can be disabled by an
+	  INF_EXEC_COMPLETE event passed to inferior_event_handle, but all of
+	  the places that invoke that are in the gdb core which is "above" a
+	  target ::wait method.
+
+	Note that there is an earlier call to enable async mode in
+	linux_nat_target::resume.  That call also marks the async event pipe
+	to report an existing event after enabling async mode, so it needs to
+	stay.
+
+2022-02-22  John Baldwin  <jhb@FreeBSD.org>
+
+	Enable async mode on supported targets in target_resume.
+	Enabling async mode above the target layer removes duplicate code in
+	::resume methods of async-capable targets.  Commit 5b6d1e4fa4f
+	("Multi-target support") enabled async mode in do_target_resume after
+	target_resume returns which is a step in this direction.  However,
+	other callers of target_resume such as target_continue do not enable
+	async mode.  Rather than enabling async mode in each of the callers
+	after target_resume returns, enable async mode at the end of
+	target_resume.
+
+	gdbserver linux-low: Convert linux_event_pipe to the event_pipe class.
+	Use event_pipe from gdbsupport in place of the existing file
+	descriptor array.
+
+	gdb linux-nat: Convert linux_nat_event_pipe to the event_pipe class.
+	Use event_pipe from gdbsupport in place of the existing file
+	descriptor array.
+
+2022-02-22  John Baldwin  <jhb@FreeBSD.org>
+
+	gdbsupport: Add an event-pipe class.
+	This pulls out the implementation of an event pipe used to implement
+	target async support in both linux-low.cc (gdbserver) and linux-nat.c
+	(gdb).
+
+	This will be used to replace the existing event pipe in linux-low.cc
+	and linux-nat.c in future commits.
+
+	Co-Authored-By: Lancelot SIX <lsix@lancelotsix.com>
+
+2022-02-22  Ruslan Kabatsayev  <b7.10110111@gmail.com>
+
+	gdb: fix detection of compilation and linking flags for source-highlight
+	Currently there are two problems with the detection of
+	source-highlight via pkg-config in GDB's configure script:
+
+	1. The LDFLAGS variable is used to pass the 'pkg-config --libs' output
+	to AC_LINK_IFELSE, which results in the "-L/some/path
+	-lsource-highlight" preceding the conftest.cpp, which can result in a
+	failure to find symbols referenced in conftest.cpp, if the linker is
+	using --as-needed by default.
+
+	2. The CFLAGS variable is used to pass the 'pkg-config --cflags'
+	output to AC_LINK_IFELSE.  However, as the current language is C++,
+	AC_LINK_IFELSE will actuall use CXXFLAGS, not CFLAGS, so any flags
+	returned from pkg-config will not be seen.
+
+	This patch fixes both of these mistakes, allowing GDB to correctly
+	configure and build using source-highlight installed into a custom
+	prefix, e.g. ~/opt/gdb-git (because the system version of
+	source-highlight is too old).
+
+2022-02-22  Philippe Blain  <levraiphilippeblain@gmail.com>
+
+	gdb/testsuite/README: point to default value of INTERNAL_GDBFLAGS
+	The INTERNAL_GDBFLAGS runtest variable was updated in 55c3ad88013
+	([gdb/testsuite] Prevent pagination in GDB_INTERNALFLAGS, 2020-10-26) to
+	disable pagination, and in aae1c79a03a (PR python/12227..., 2010-12-07)
+	to point to the data directory, but its default value mentioned in the
+	testsuite's README was not kept up to date.
+
+	To avoid it getting out of sync even more, point the reader to the
+	definition of the variable in lib/gdb.exp, and move the explanation of
+	the different flags there. Also adjust the example in the README
+	so it follows the flags added in 55c3ad88013.
+
+	Change-Id: I3533608a7d6ae5198af09c7dc7743bde24c19ed7
+
+2022-02-22  Kito Cheng  <kito.cheng@sifive.com>
+
+	RISC-V: Maintain a string to hold the canonical order
+	Using dummy entry in riscv_supported_std_ext cause confusing and wrongly
+	support `b` and `k` extensions.
+
+	bfd/
+		* elfxx-riscv.c (riscv_supported_std_ext): Drop unsupported
+		extensions.
+		(riscv_ext_canonical_order): New.
+		(riscv_init_ext_order): Use riscv_ext_canonical_order rather
+		than riscv_supported_std_ext to compute canonical order.
+
+	V2 Changes:
+
+	- Use `*ext` rather than `*ext != NULL` for checking is reach end of
+	  string.
+
+2022-02-22  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-21  Alan Modra  <amodra@gmail.com>
+
+	Re: ld: Support customized output section type
+	"DO NOT EDIT!" says the comment at the top of bfd-in2.h.  Move the new
+	type field where it belongs.
+
+		PR ld/28841
+		* section.c (struct bfd_section): Add type.  Formatting.
+		(BFD_FAKE_SECTION): Formatting.
+		* bfd-in2.h: Regenerate.
+
+2022-02-21  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: gdbinit: hoist setup to common code
+	This was left in subdirs because of the dynamic cgen usage.  However,
+	we can move this breakpoint call to runtime and let gdb detect whether
+	the symbol exists.
+
+2022-02-21  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: relax pattern in new gdb.mi/mi-multi-commands.exp test
+	I saw some failures in the test gdb.mi/mi-multi-commands.exp that I
+	added recently.  This test was added in commit:
+
+	  commit d08cbc5d3203118da5583296e49273cf82378042
+	  Date:   Wed Dec 22 12:57:44 2021 +0000
+
+	      gdb: unbuffer all input streams when not using readline
+
+	The failures I see only occurred when my machine was very heavily
+	loaded.
+
+	In this test I send multiple commands from dejagnu to gdb with a
+	single send_gdb call.  In a well behaving world what I want to happen
+	is that the gdb console sees both commands arrive and echos the text
+	of those commands.  Then gdb starts processing the first command,
+	prints the result, and then processes the second command, and prints
+	the result.
+
+	However, what I saw in my loaded environment was that only after
+	sending the two commands, only the first command was echoed to gdb's
+	terminal.  Then gdb started processing the first command, and started
+	to write the output.  Now, mixed in with the first command output, the
+	second command was echoed to gdb's terminal.  Finally, gdb would
+	finish printing the first command output, and would read and handle
+	the second command.
+
+	This mixing of command echoing with the first command output was
+	causing the test matching patterns to fail.
+
+	In this commit I change the command I use in the test from a CLI
+	command to an MI command, this reduces the number of lines of output
+	that come from the test, CLI commands sent through the MI interpreter
+	are echoed back like this:
+
+	  (gdb)
+	  set $a = "FIRST COMMAND"
+	  &"set $a = \"FIRST COMMAND\"\n"
+	  ^done
+	  (gdb)
+
+	While this is not the case for true MI command:
+
+	  (gdb)
+	  -data-evaluate-expression $a
+	  ^done,value="\"FIRST COMMAND\""
+	  (gdb)
+
+	Less output makes for simpler patterns to match against.
+
+	Next, when sending two command to gdb I was previously trying to spot
+	the output of the first command followed by the prompt with nothing
+	between.  This is not really needed, for the first command I can look
+	for just the ^done,value="\"FIRST COMMAND\"" string, then I can start
+	looking for the output of the second command.
+
+	So long as the second pattern matches up to the gdb prompt, then I can
+	be sure than nothing is left over in the expect buffer to muck up
+	later matches.
+
+	As to see the second command output gdb must have read in the second
+	command, the second command output never suffers from the corruption
+	that the first command output does.
+
+	Since making this change, I've not seen a failure in this test.
+
+2022-02-21  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: avoid nullptr access in dbxread.c from read_dbx_symtab
+	This fixes a GDB crash reported in bug pr/28900, related to reading in
+	some stabs debug information.
+
+	In this commit my goal is to stop GDB crashing.  I am not trying to
+	ensure that GDB makes the best possible use of the available stabs
+	debug information.  At this point I consider stabs a legacy debug
+	format, with only limited support in GDB.
+
+	So, the problem appears to be that, when reading in the stabs data, we
+	need to find a N_SO entry, this is the entry that defines the start of
+	a compilation unit (or at least the location of a corresponding source
+	file).
+
+	It is while handling an N_SO that GDB creates a psymtab to hold the
+	incoming debug information (symbols, etc).
+
+	The problem we hit in the bug is that we encounter some symbol
+	information (an N_PC entry) outside of an N_SO entry - that is we find
+	some symbol information that is not associated with any source file.
+
+	We already have some protection for this case, look (in
+	read_dbx_symtab) at the handling of N_PC entries of type 'F' and 'f',
+	if we have no psymtab (the pst variable is nullptr) then we issue a
+	complaint.  However, for whatever reason, in both 'f' and 'F'
+	handling, there is one place where we assume that the pst
+	variable (the psymtab) is not nullptr.  This is a mistake.
+
+	In this commit, I guard these two locations (in 'f' and 'F' handling)
+	so we no longer assume pst is not nullptr.
+
+	While I was at it, I audited all the other uses of pst in
+	read_dbx_symtab, and in every potentially dangerous case I added a
+	nullptr check, and issue a suitable complaint if pst is found to be
+	nullptr.
+
+	It might well be true that we could/should do something smarter if we
+	see a debug symbol outside of an N_SO entry, and if anyone wanted to
+	do that work, they're welcome too.  But this commit is just about
+	preventing the nullptr access, and the subsequent GDB crash.
+
+	I don't have any tests for this change, I have no idea how to generate
+	weird stabs data for testing.  The original binary from the bug report
+	now loads just fine without GDB crashing.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28900
+
+2022-02-21  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: make use of std::string in dbxread.c and xcoffread.c
+	While taking a look through dbxread.c I spotted a couple of places
+	where making use of std::string would remove the need for manual
+	memory allocation and memcpy.
+
+	During review Simon pointed out that the same code exists in
+	xcoffread.c, so I've applied the same fix there too.
+
+	There should be no user visible changes after this commit.
+
+2022-02-21  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-20  Lancelot SIX  <lancelot.six@amd.com>
+
+	gdb: Only paginate for filtered output in fputs_maybe_filtered
+	A have had situation where a unfiltered output (done using
+	fputs_unfiltered) ended up triggering pagination.  The backtrace for this was:
+
+	    ...
+	    #24 0x000055839377ee4e in check_async_event_handlers () at ../../gdb/async-event.c:335
+	    #25 0x0000558394b67b57 in gdb_do_one_event () at ../../gdbsupport/event-loop.cc:216
+	    #26 0x0000558394587454 in gdb_readline_wrapper (prompt=0x7ffd907712d0 "--Type <RET> for more, q to quit, c to continue without paging--") at ../../gdb/top.c:1148
+	    #27 0x0000558394707270 in prompt_for_continue () at ../../gdb/utils.c:1438
+	    #28 0x00005583947088b3 in fputs_maybe_filtered (linebuffer=0x60c0000f4000 "   [...quite big message...]", stream=0x60300028e9d0, filter=0) at ../../gdb/utils.c:1752
+	    #29 0x0000558394708e57 in fputs_unfiltered (linebuffer=0x60c0000f4000 "   [...quite big message...]", stream=0x60300028e9d0) at ../../gdb/utils.c:1811
+	    ...
+
+	This comes from what appears to be a oversight in fputs_maybe_filtered.  This
+	function has a FILTER parameter which if true makes the function pause after
+	every screenful (i.e. triggers pagination).
+
+	The filter parameter is correctly used to guard the first place where
+	prompt_for_continue.  There is a second place in the function which can call
+	prompt_for_continue, but is currently unguarded.  I believe that this is an
+	oversight, this patch fixes that.
+
+	Tested on Linux-x86_64, no regression observed.
+
+	Change-Id: Iad8ffd50a87cf20077500878e2564b5a7dc81ece
+
+2022-02-20  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-19  Dominique Quatravaux  <dominique.quatravaux@epfl.ch>
+
+	gdb/darwin: remove not-so-harmless spurious call to `wait4`
+	As seen in https://sourceware.org/bugzilla/show_bug.cgi?id=24069 this
+	code will typically wait4() a second time on the same process that was
+	already wait4()'d a few lines above. While this used to be
+	harmless/idempotent (when we assumed that the process already exited),
+	this now causes a deadlock in the WIFSTOPPED case.
+
+	The early (~2019) history of bug #24069 cautiously suggests to use
+	WNOHANG instead of outright deleting the call. However, tests on the
+	current version of Darwin (Big Sur) demonstrate that gdb runs just fine
+	without a redundant call to wait4(), as would be expected.
+	Notwithstanding the debatable value of conserving bug compatibility with
+	an OS release that is more than a decade old, there is scant evidence of
+	what that double-wait4() was supposed to achieve in the first place - A
+	cursory investigation with `git blame` pinpoints commits bb00b29d7802
+	and a80b95ba67e2 from the 2008-2009 era, but fails to answer the
+	"why" question conclusively.
+
+	Co-Authored-By: Philippe Blain <levraiphilippeblain@gmail.com>
+	Change-Id: Id4e4415d66d6ff6b3552b60d761693f17015e4a0
+
+2022-02-19  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-18  Tom Tromey  <tromey@adacore.com>
+
+	Add constructor to bound_minimal_symbol
+	This adds a constructor to bound_minimal_symbol, to avoid a build
+	failure with clang that Simon pointed out.
+
+	I also took the opportunity to remove some redundant initializations,
+	and to change one use of push_back to emplace_back, as suggested by
+	Simon.
+
+2022-02-18  Roland McGrath  <mcgrathr@google.com>
+
+	Fix typo in ld.texi
+	ld/
+		* ld.texi (Output Section Type): Fix typo in @code syntax.
+
+2022-02-18  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove newlines from some linux_nat_debug_printf calls
+	Change-Id: I80328fab7096221356864b5a4fb30858b48d2c10
+
+2022-02-18  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-17  Nick Clifton  <nickc@redhat.com>
+
+	Updated Serbian translations for the bfd, gold, ld and opcodes directories
+
+2022-02-17  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-16  Fangrui Song  <maskray@google.com>
+
+	ld: Support customized output section type
+	bfd/
+	    PR ld/28841
+	    * bfd-in2.h (struct bfd_section): Add type.
+	    (discarded_section): Add field.
+	    * elf.c (elf_fake_sections): Handle bfd_section::type.
+	    * section.c (BFD_FAKE_SECTION): Add field.
+	    * mri.c (mri_draw_tree): Update function call.
+
+	ld/
+	    PR ld/28841
+	    * ld.texi: Document new output section type.
+	    * ldlex.l: Add new token TYPE.
+	    * ldgram.y: Handle TYPE=exp.
+	    * ldlang.h: Add type_section to list of section types.
+	    * ldlang.c (lang_add_section): Handle type_section.
+	    (map_input_to_output_sections): Handle type_section.
+	    * testsuite/ld-scripts/output-section-types.t: Add tests.
+	    * testsuite/ld-scripts/output-section-types.d: Update.
+
+2022-02-16  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/tui: add a missing white space character
+	Just adds a missing space.  There should be no user visible changes
+	after this commit.
+
+	gdb: convert callback_handler_installed from int to bool
+	Simple int to bool conversion on callback_handler_installed in
+	event-top.c.  There should be no user visible changes after this
+	commit.
+
+2022-02-16  Alan Modra  <amodra@gmail.com>
+
+	gas local label and dollar label handling
+	Much of the gas source and older BFD source use "long" for function
+	parameters and variables, when other types would be more appropriate.
+	This patch fixes one of those cases.  Dollar labels and numeric local
+	labels do not need large numbers.  Small positive itegers are usually
+	all that is required.  Due to allowing longs, it was possible for
+	fb_label_name and dollar_label_name to overflow their buffers.
+
+		* symbols.c: Delete unnecessary forward declarations.
+		(dollar_labels, dollar_label_instances): Use unsigned int.
+		(dollar_label_defined, dollar_label_instance): Likewise.
+		(define_dollar_label): Likewise.
+		(fb_low_counter, fb_labels, fb_label_instances): Likewise.
+		(fb_label_instance_inc, fb_label_instance): Likewise.
+		(fb_label_count, fb_label_max): Make them size_t.
+		(dollar_label_name, fb_label_name): Rewrite using sprintf.
+		* symbols.h (dollar_label_defined): Update prototype.
+		(define_dollar_label, dollar_label_name): Likewise.
+		(fb_label_instance_inc, fb_label_name): Likewise.
+		* config/bfin-lex.l (yylex): Remove unnecessary casts.
+		* expr.c (integer_constant): Likewise.
+		* read.c (read_a_source_file): Limit numeric label range to int.
+
+2022-02-16  Alan Modra  <amodra@gmail.com>
+
+	ubsan: s_app_line integer overflow
+	There are quite a few ubsan warnings in gas.  This one disappears with
+	a code tidy.
+
+		* read.c (s_app_line): Rename 'l' to 'linenum'.  Avoid ubsan
+		warning.
+
+2022-02-16  Alan Modra  <amodra@gmail.com>
+
+	pe_ILF_make_a_symbol_reloc segfault
+	pei-aarch64-little apparently lacks support for BFD_RELOC_RVA.
+
+		* peicode.h (pe_ILF_make_a_symbol_reloc): Don't segfault on
+		NULL howto.
+
+2022-02-16  Alan Modra  <amodra@gmail.com>
+
+	What to do when sh_addralign isn't a power of two
+	BFD generally doesn't handle anything but a power of two section
+	alignment, and ELF sh_addralign is required to be an integral power of
+	two (or zero) by the ELF spec.  Of course this is ignored by fuzzers,
+	and because bfd_log2 rounds up, we can end up with alignment_power
+	being 32 on a 32-bit object or 64 on a 64-bit object.  That then
+	triggers ubsan warnings in places like bfd_update_compression_header
+	where we want to convert from alignment_power back to an alignment.
+	I suppose we could reject object files that have non-compliant
+	sh_addralign, but I think it's also reasonable to use the greatest
+	power of two divisor of sh_addralign, ie. the rightmost 1 bit.
+
+		* elf.c (_bfd_elf_make_section_from_shdr): Use greatest power
+		of two divisor of sh_addralign.
+		(_bfd_elf_assign_file_position_for_section): Likewise.
+		(assign_file_positions_for_non_load_sections): Likewise.
+
+2022-02-16  Alan Modra  <amodra@gmail.com>
+
+	asan: buffer overflow in vms-alpha.c
+		* vms-alpha.c (evax_bfd_print_dst): Sanity check another place
+		printing strings.
+
+	asan : use of uninitialized value in buffer_and_nest
+		* macro.c (buffer_and_nest): Don't read past end of string buffer.
+
+	asan: buffer overflow in peXXigen.c
+		* peXXigen.c (_bfd_XX_bfd_copy_private_bfd_data_common): Properly
+		sanity check DataDirectory[PE_DEBUG_DATA].Size.
+
+2022-02-16  Hans-Peter Nilsson  <hp@axis.com>
+
+	sim/common: Improve sim_dump_memory head comment
+	As requested by Mike.
+
+		* sim-memopt.c: Improve head comment.
+
+2022-02-16  Hans-Peter Nilsson  <hp@axis.com>
+
+	sim/testsuite/cris/c/stat3.c: Fix formatting nit
+	* c/stat3.c (main): Fix formatting nit.
+
+2022-02-16  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: testsuite: cleanup the istarget * logic
+	Now that the multitarget testing has settled, clean up the cases where
+	istarget * is used.  This ends up being mostly style unindenting.
+
+2022-02-16  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-15  H.J. Lu  <hjl.tools@gmail.com>
+
+	i386: Update I386_NEED_DYNAMIC_RELOC_TYPE_P for DT_TEXTREL
+	Update I386_NEED_DYNAMIC_RELOC_TYPE_P to allow R_386_TLS_IE for relocation
+	in read-only section.
+
+	bfd/
+
+		PR ld/28894
+		* elfxx-x86.h (I386_NEED_DYNAMIC_RELOC_TYPE_P): Allow
+		R_386_TLS_IE.
+
+	ld/
+		PR ld/28894
+		* testsuite/ld-i386/i386.exp: Run pr28894.
+		* testsuite/ld-i386/pr28894.d: New file.
+		* testsuite/ld-i386/pr28894.s: Likewise.
+
+2022-02-15  Hans-Peter Nilsson  <hp@axis.com>
+
+	sim/testsuite: Default global_cc_os and global_cc_works properly
+	There was an omission on 3e6dc39ed7a8 "sim/testsuite: Set
+	global_cc_os also when no compiler is found"; global_cc_os
+	wasn't set for other than the primary target, which means
+	that the "unguarded" use of global_cc_os in
+	testsuite/cris/c/c.exp caused the dreaded "ERROR: can't read
+	"global_cc_os": no such variable" when e.g. configuring for
+	pru-elf and doing "make check-sim".  Better initializing
+	both variables at the top to default values, rather than
+	adding another single 'set global_cc_os ""', to reduce the
+	risk of not setting them properly if or when that
+	if-statement-chain is made longer.
+
+	sim/testsuite:
+		* lib/sim-defs.exp (sim_init_toolchain): Default
+		global_cc_os and global_cc_works properly, before if-chain.
+
+2022-02-15  H.J. Lu  <hjl.tools@gmail.com>
+
+	x86: Add has_sib to struct instr_info
+	Add has_sib to struct instr_info and use SIB info only if ins->has_sib
+	is true.
+
+		PR binutils/28892
+		* i386-dis.c (instr_info): Add has_sib.
+		(get_sib): Set has_sib.
+		(OP_E_memory): Replace havesib with ins->has_sib.
+		(OP_VEX): Use ins->sib.index only if ins->has_sib is true.
+
+2022-02-15  Lancelot SIX  <lancelot.six@amd.com>
+
+	gdb: Respect the DW_CC_nocall attribute
+	It is possible for a compiler to optimize a function in a such ways that
+	the function does not follow the calling convention of the target.  In
+	such situation, the compiler can use the DW_AT_calling_convention
+	attribute with the value DW_CC_nocall to tell the debugger that it is
+	unsafe to call the function.  The DWARF5 standard states, in 3.3.1.1:
+
+	  > If the value of the calling convention attribute is the constant
+	  > DW_CC_nocall, the subroutine does not obey standard calling
+	  > conventions, and it may not be safe for the debugger to call this
+	  > subroutine.
+
+	Non standard calling convention can affect GDB's assumptions in multiple
+	ways, including how arguments are passed to the function, how values are
+	returned, and so on.  For this reason, it is unsafe for GDB to try to do
+	the following operations on a function with marked with DW_CC_nocall:
+
+	- call / print an expression requiring the function to be evaluated,
+	- inspect the value a function returns using the 'finish' command,
+	- force the value returned by a function using the 'return' command.
+
+	This patch ensures that if a command which relies on GDB's knowledge of
+	the target's calling convention is used on a function marked nocall, GDB
+	prints an appropriate message to the user and does not proceed with the
+	operation which is unreliable.
+
+	Note that it is still possible for someone to use a vendor specific
+	value for the DW_AT_calling_convention attribute for example to indicate
+	the use of an alternative calling convention.  This commit does not
+	prevent this, and target dependent code can be adjusted if one wanted to
+	support multiple calling conventions.
+
+	Tested on x86_64-Linux, with no regression observed.
+
+	Change-Id: I72970dae68234cb83edbc0cf71aa3d6002a4a540
+
+2022-02-15  Lancelot SIX  <lancelot.six@amd.com>
+	    Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: add a symbol* argument to get_return_value
+	Add an argument to the get_return_value function to indicate the symbol
+	of the function the debuggee is returning from.  This will be used by
+	the following patch.
+
+	Since the function return type can be deduced from the symbol remove the
+	value_type argument which becomes redundant.
+
+	No user visible change after this patch.
+
+	Tested on x86_64-linux.
+
+	Change-Id: Idf1279f1f7199f5022738a6679e0fa63fbd22edc
+
+2022-02-15  H.J. Lu  <hjl.tools@gmail.com>
+
+	x86-64: Use MAXPAGESIZE for the relro segment alignment
+	Adjust x86-64 linker tests after reverting
+
+	commit 31b4d3a16f200bf04db8439a63b72bba7af4e1be
+	Author: Alan Modra <amodra@gmail.com>
+	Date:   Thu Feb 3 08:57:47 2022 +1030
+
+	    PR28824, relro security issues, x86 keep COMMONPAGESIZE relro
+
+	to use MAXPAGESIZE for the end of the relro segment alignment, like other
+	ELF targets.
+
+		* testsuite/ld-x86-64/plt-main-bnd.dd: Updated.
+		* testsuite/ld-x86-64/plt-main-ibt-x32.dd: Likewise.
+		* testsuite/ld-x86-64/plt-main-ibt.dd: Likewise.
+		* testsuite/ld-x86-64/pr14207.d: Likewise.
+		* testsuite/ld-x86-64/pr18176.d: Likewise.
+		* testsuite/ld-x86-64/pr20830a-now.d: Likewise.
+		* testsuite/ld-x86-64/pr20830a.d: Likewise.
+		* testsuite/ld-x86-64/pr20830b-now.d: Likewise.
+		* testsuite/ld-x86-64/pr20830b.d: Likewise.
+		* testsuite/ld-x86-64/pr21038a-now.d: Likewise.
+		* testsuite/ld-x86-64/pr21038a.d: Likewise.
+		* testsuite/ld-x86-64/pr21038b-now.d: Likewise.
+		* testsuite/ld-x86-64/pr21038b.d: Likewise.
+		* testsuite/ld-x86-64/pr21038c-now.d: Likewise.
+		* testsuite/ld-x86-64/pr21038c.d: Likewise.
+
+2022-02-15  H.J. Lu  <hjl.tools@gmail.com>
+
+	Revert "PR28824, relro security issues, x86 keep COMMONPAGESIZE relro"
+	This reverts commit 31b4d3a16f200bf04db8439a63b72bba7af4e1be.
+
+2022-02-15  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-14  Hans-Peter Nilsson  <hp@axis.com>
+
+	sim/testsuite/cris: If failing compilation, mark C tests as errors
+	...when we know we have a working compiler.  This will reduce
+	the risk of faulty edits by exposing them rather than hiding
+	them as "unresolved".  It also harmonizes behavior with that of
+	run_sim_test.
+
+		* c/c.exp: Mark C tests failing compilation test errors.
+
+2022-02-14  Hans-Peter Nilsson  <hp@axis.com>
+
+	sim/testsuite/cris: Remove faulty use of basename in C tests
+	Calls to basename were added here as part of commit
+	e1e1ae6e9b5e "sim: testsuite: fix objdir handling", but that
+	commit missed adding "#include <libgen.h>" or the equivalent
+	GNU extension, see basename(3).  Fixing that shows a logical
+	error in the change to openpf1.c; the non-/-prefixed
+	code-path was changed instead of the "/"-prefixed code-path,
+	which is the one executed after that commit.
+
+	For "newlib" these tests failed linking after that commit.
+	Recent newlib has the (asm-renamed) GNU-extension-variant of
+	basename, but we're better off not using it at all.
+
+	Unfortunately, compilation failures for C tests run by the
+	machinery in c.exp are currently just marked "unresolved",
+	in contrast to C and assembler tests run by calling
+	run_sim_test.
+
+	The interaction of calling with the full program-path vs.
+	use of --sysroot exposes a consistency problem: when
+	--sysroot is used, argv[0] isn't the path by which the
+	program can find itself.  It's undecided whether argv[0] for
+	the program running in the simulator should be edited
+	(related to the naked argument to the simulator before
+	passing on to the simulated program) to remove a leading
+	--sysroot.  Either way, such a change would be out of scope
+	for this commit.
+
+		* c/stat3.c (mybasename): New macro.  Use it instead of basename.
+		* c/openpf1.c: Correct basename-related change and update related
+		comment.
+
+2022-02-14  Hans-Peter Nilsson  <hp@axis.com>
+
+	sim: Add sim_dump_memory for debugging
+	Intended to be called from the debugger tool.
+
+	sim/common:
+		* sim-memopt.c (sim_dump_memory): New function.
+
+2022-02-14  Hans-Peter Nilsson  <hp@axis.com>
+
+	sim: Fix use of out-of-tree assembler and linker when testing
+	With commit 7a259895bb2d "sim: testsuite: expand arch specific
+	toolchain settings", trying to use out-of-tree ld and as at test-time
+	broke for the "primary target", like when testing a release-tarball.
+
+	Subsequent to that commit, all assembler tests without in-tree-built
+	tools FAIL, getting errors when trying to call
+	$(abs_builddir)/../gas/as-new.  But, that isn't the actual culprint;
+	it's actually it's its immediate predecessor, commit 8996c21067373
+	"sim: testsuite: setup per-port toolchain settings for multitarget
+	build", which hardcodes in-tree-paths to those tools instead of
+	considering e.g. $(<X>_FOR_TARGET), the preferred overridable variable
+	for single-target builds, as set up by the toplevel Makefile.
+
+	This commit calls GCC_TARGET_TOOL (a deceptive name; gcc-specific
+	features aren't used) from toplev/config/acx.m4, somewhat like calls
+	in toplev/configure.ac but without the NCN_STRICT_CHECK_TARGET_TOOLS
+	step, for each X to find a value for $(<X>_FOR_TARGET).  N.B.: in-tree
+	tools still override any ${target}-${tool} found in $PATH, i.e. only
+	previously broken builds are affected.
+
+	The variables $(<X>_FOR_TARGET) are usually overridden by the toplevel
+	Makefile to the same value or better, but has to be set here too, as
+	automake "wants" Makefiles to be self-contained (you get an error
+	pointing out that the variable may be empty).  If it hadn't been for
+	that, SIM_AC_CHECK_TOOLCHAIN_FOR_PRIMARY_TARGET would not be needed.
+	This detail should only (positively) affect users invoking "make
+	check" in sim/ instead of "make check-sim" (or "make check") at the
+	toplevel.  Now the output from "configure" matches the target tools
+	actually used by sim at test-time, for the "primary target".
+
+	Using $(CC) for "example-" targets CC_FOR_TARGET is not changed, as
+	that appears to be a deliberate special-case.
+
+	Note that all tools still have to be installed and present in
+	$PATH at configure-time to be properly used at test-time.
+
+	sim:
+		* m4/sim_ac_toolchain.m4 (SIM_AC_CHECK_TOOLCHAIN_FOR_PRIMARY_TARGET):
+		New defun.
+		(SIM_TOOLCHAIN_VARS): Call it using AC_REQUIRE, and use variables
+		AS_FOR_TARGET, LD_FOR_TARGET and CC_FOR_TARGET instead of hard-coded
+		values.
+		* Makefile.in, configure: Regenerate.
+
+2022-02-14  Hans-Peter Nilsson  <hp@axis.com>
+
+	sim cris: Unbreak --disable-sim-hardware builds
+	With --disable-sim-hardware (--enable-sim-hardware=no),
+	whose default was changed to --enable-sim-hardware(=yes) in
+	commit 34cf51120683, building for cris-elf fails as
+	sim_hw_parse then doesn't exist.
+
+	A cris-elf simulator configured for --enable-sim-hardware
+	(or the default after to the mentioned commit) runs about
+	2.5x slower than one configured --disable-sim-hardware.
+	A further 2-5% performance regression was not investigated.
+
+	When sim_hw_parse doesn't exist, --cris-900000xx can't be
+	supported.  The best action here is to remove it completely,
+	so its absence can be identified through --help, but
+	avoiding littering the code with "#if WITH_HW".
+
+	sim/cris:
+		* sim-if.c (cris_options) [WITH_HW]: Conditionalize
+		support of option --cris-900000xx.
+		(sim_open) [WITH_HW]: Conditionalize sim_hw_parse
+		call.
+
+2022-02-14  Hans-Peter Nilsson  <hp@axis.com>
+
+	sim/testsuite/cris: As applicable, require simoption --cris-900000xx
+	Apply the new run_sim_test option "require" as in "#require
+	simoption --cris-900000xx" for all tests using that option.
+	This allows a clean test-suite-run for a build with
+	--disable-sim-hardware, where that option is not supported,
+	by skipping those tests as "untested".
+
+	sim/testsuite/cris:
+		* asm/io1.ms, asm/io2.ms, asm/io3.ms, asm/io6.ms,
+		asm/io7.ms: Call "#require: simoption --cris-900000xx".
+
+2022-02-14  Hans-Peter Nilsson  <hp@axis.com>
+
+	sim/testsuite: Support "requires: simoption <--name-of-option>"
+	Simulator features can be present or not, typically
+	depending on different-valued configure options, like
+	--enable-sim-hardware[=off|=on].  To avoid failures in
+	test-suite-runs when testing such configurations, a new
+	predicate is needed, as neither "target", "progos" nor
+	"mach" fits cleanly.
+
+	The immediate need was to check for presence of a simulator
+	option, but rather than a specialized "requires-simoption:"
+	predicate I thought I'd handle the general (parametrized)
+	need, so here's a generic predicate machinery and a (first)
+	predicate to use together with it; checking whether a
+	particular option is supported, by looking at "run --help"
+	output.  This was inspired by the check_effective_target_
+	machinery in the gcc test-suite.
+
+	Multiple "requires: <requirement> <parameter>" form a list of
+	predicates (with parameters), to be used as a conjunction.
+
+	sim/testsuite:
+		* lib/sim-defs.exp (sim_check_requires_simoption): New function.
+		(run_sim_test): Support "requires: <requirement> <parameter>".
+
+2022-02-14  Hans-Peter Nilsson  <hp@axis.com>
+
+	sim/testsuite/cris/hw/rv-n-cris/irq1.ms: Disable due to randomness
+	For reasons that remain largely to be investigated (besides
+	the apparent lack of synchronization between two processes),
+	this test fails randomly, with two different sets of common
+	outputs.  Curiously, that doesn't happen for the other
+	similar tests.  There's a comment that mentions this, though
+	that doesn't make it a sustainable part of a test-suite.
+	(Known-blinking tests should be disabled until fixed.)
+
+	sim/testsuite/cris:
+		* hw/rv-n-cris/irq1.ms: Disable by use of a never-matched
+		"progos" value.
+
+2022-02-14  Hans-Peter Nilsson  <hp@axis.com>
+
+	sim/testsuite/cris/c: Use -sim3 but only for newlib targets
+	Commit a39487c6685f "sim: cris: use -sim with C tests for cris-elf
+	targets" caused " -sim" to be appended to CFLAGS_FOR_TARGET for
+	cris*-*-elf, where testing had until then relied on
+	"RUNTESTFLAGS=--target_board=cris-sim" being passed when running "make
+	check-sim", adding the right options.  While "-sim" happens to work,
+	the baseboard-file cris-sim.exp uses "-sim3" so for consistency use
+	that instead.
+
+	Then commit b42f20d2ac72 "sim: testsuite: drop most specific istarget
+	checks" caused " -sim" to be appended for *all* targets, which just
+	doesn't work.  For example, for crisv32-linux-gnu, that's not a
+	recognized option and will cause a dejagnu error and further testing
+	in c.exp will be aborted.
+
+	While cris-sim.exp appends "-static" for *-linux-gnu, further changes
+	in the test-suite have caused "linux"-specific tests to break, so that
+	part will be tended to separately.
+
+	But, save and restore CFLAGS_FOR_TARGET around the modification and
+	use where needed, to not have the CRIS-specific modification affect a
+	continuing test-run (possibly for other targets).
+
+	sim/testsuite/cris:
+		* c/c.exp (CFLAGS_FOR_TARGET): Replace appended option " -sim"
+		with " -sim3", but do it conditionally for newlib targets.  Save
+		and restore CFLAGS_FOR_TARGET in saved_CFLAGS_FOR_TARGET such
+		that it doesn't affect the value of CFLAGS_FOR_TARGET outside
+		c.exp.
+
+2022-02-14  Hans-Peter Nilsson  <hp@axis.com>
+
+	sim/testsuite: Set global_cc_os also when no compiler is found
+	If we don't set this variable, it doesn't exist, and using "#progos:"
+	in an assembler-file will cause an error rather than just skipping the
+	test, viz:
+
+	Running /src/sim/testsuite/cris/hw/rv-n-cris/rvc.exp ...
+	ERROR: tcl error sourcing /src/sim/testsuite/cris/hw/rv-n-cris/rvc.exp.
+	ERROR: can't read "global_cc_os": no such variable
+	    while executing
+	"if { $opts(progos) != "" && $opts(progos) != $global_cc_os } {
+		untested $subdir/$name
+		return
+	    }"
+	    (procedure "run_sim_test" line 102)
+
+	Neither the commit introducing progos, nor the top comment
+	in run_sim_test, mentions progos as intended only for C
+	tests, or that its use must be gated on $global_cc_works !=
+	0, so (not) setting it in the no-working-compiler path seems
+	just overlooked.
+
+	Allowing it to be used for assembler tests makes it usable
+	for e.g. an always-false predicate and in expressions in
+	.exp files without gating on $global_cc_works != 0.
+
+	With this patch, global_cc_os is set to "", just as for "unknown OS".
+
+	    sim/testsuite:
+		* lib/sim-defs.exp (sim_init_toolchain): Set global_cc_os also when
+		no working target C compiler is found.
+
+2022-02-14  Hans-Peter Nilsson  <hp@axis.com>
+
+	sim/testsuite/cris: Assembler testcase for PRIx32 usage bug
+	Several C test-cases exposed the bug, but let's have one for
+	people who test using just the assembler and linker.
+
+		* asm/endmem1.ms: New test.
+
+2022-02-14  Hans-Peter Nilsson  <hp@axis.com>
+
+	sim cris: Correct PRIu32 to PRIx32
+	In 5ee0bc23a68f "sim: clean up bfd_vma printing" there was
+	an additional introduction of PRIx32 and PRIu32 but just in
+	sim/cris/sim-if.c.  One type of bug was fixed in commit
+	d16ce6e4d581 "sim: cris: fix memory setup typos" but one
+	remained; the PRIu32 usage is wrong, as hex output is
+	desired; note the 0x prefix.
+
+	Without this fix, you'll see output like:
+	 memory map 0:0x4000..0x5fff (8192 bytes) overlaps 0:0x0..0x16383 (91012 bytes)
+	 program stopped with signal 6 (Aborted).
+	for some C programs, like some of the ones in the sim/cris/c
+	testsuite from where the example is taken (freopen2.c).
+
+	The bug behavior was with memory allocation.  With an
+	attempt to allocate memory using the brk syscall such that
+	the room up to the next 8192-byte "page boundary" wasn't
+	sufficient, the simulator memory allocation machinery horked
+	on a consistency error when trying to allocate a memory
+	block to raise the "end of the data segment": there was
+	already memory allocated at that address.
+
+	Unfortunately, none of the programs in sim/cris/asm exposed
+	this bug at the time, but an assembler test-case is
+	committed after this fix.
+
+	sim/cris:
+		* sim-if.c (sim_open): Correct PRIu32 to PRIx32.
+
+2022-02-14  Sergei Trofimovich  <siarheit@google.com>
+
+	microblaze: fix fsqrt collicion to build on glibc-2.35
+		* microblaze-opcm.h: Renamed 'fsqrt' to 'microblaze_fsqrt'.
+		* microblaze-opc.h: Follow 'fsqrt' rename.
+
+2022-02-14  Tom Tromey  <tom@tromey.com>
+
+	Remove LA_PRINT_STRING
+	This removes the LA_PRINT_STRING macro, in favor of using ordinary
+	method calls.
+
+	Remove LA_PRINT_CHAR
+	This removes the LA_PRINT_CHAR macro, in favor of using ordinary
+	method calls.
+
+	Remove LA_PRINT_TYPE
+	This removes the LA_PRINT_TYPE macro, in favor of using ordinary
+	method calls.
+
+2022-02-14  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb/python: move styling support to gdb.styling
+	This commit moves the two Python functions that are used for styling
+	into a new module, gdb.styling, there's then a small update in
+	python.c so GDB can find the functions in their new location.
+
+	The motivation for this change is purely to try and reduce the clutter
+	in the top-level gdb module, and encapsulate related functions into
+	modules.  I did ponder documenting these functions as part of the
+	Python API, however, doing so would effectively "fix" the API, and I'm
+	still wondering if there's improvements that could be made, also, the
+	colorize function is only called in some cases now that GDB prefers
+	libsource-highlight, so it's not entirely sure how this would work as
+	part of a user facing API.
+
+	Still, despite these functions never having been part of a documented
+	API, it is possible that a user out there has overridden these to, in
+	some way, customize how GDB performs styling.  Moving the function as
+	I propose in this patch could break things for that user, however,
+	fixing this breakage is trivial, and, as these functions were never
+	documented, I don't think we should be obliged to not break user code
+	that relies on them.
+
+2022-02-14  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: use python to colorize disassembler output
+	This commit adds styling support to the disassembler output, as such
+	two new commands are added to GDB:
+
+	  set style disassembler enabled on|off
+	  show style disassembler enabled
+
+	In this commit I make use of the Python Pygments package to provide
+	the styling.  I did investigate making use of libsource-highlight,
+	however, I found the highlighting results to be inferior to those of
+	Pygments; only some mnemonics were highlighted, and highlighting of
+	register names such as r9d and r8d (on x86-64) was incorrect.
+
+	To enable disassembler highlighting via Pygments, I've added a new
+	extension language hook, which is then implemented for Python.  This
+	hook is very similar to the existing hook for source code
+	colorization.
+
+	One possibly odd choice I made with the new hook is to pass a
+	gdb.Architecture through, even though this is currently unused.  The
+	reason this argument is not used is that, currently, styling is
+	performed identically for all architectures.
+
+	However, even though the Python function used to perform styling of
+	disassembly output is not part of any documented API, I don't want
+	to close the door on a user overriding this function to provide
+	architecture specific styling.  To do this, the user would inevitably
+	require access to the gdb.Architecture, and so I decided to add this
+	field now.
+
+	The styling is applied within gdb_disassembler::print_insn, to achieve
+	this, gdb_disassembler now writes its output into a temporary buffer,
+	styling is then applied to the contents of this buffer.  Finally the
+	gdb_disassembler buffer is copied out to its final destination stream.
+
+	There's a new test to check that the disassembler output includes some
+	escape sequences, though I don't check for specific colours; the
+	precise colors will depend on which instructions are in the
+	disassembler output, and, I guess, how pygments is configured.
+
+	The only negative change with this commit is how we currently style
+	addresses in GDB.
+
+	Currently, when the disassembler wants to print an address, we call
+	back into GDB, and GDB prints the address value using the `address`
+	styling, and the symbol name using `function` styling.  After this
+	commit, if pygments is used, then all disassembler styling is done
+	through pygments, and this include the address and symbol name parts
+	of the disassembler output.
+
+	I don't know how much of an issue this will be for people.  There's
+	already some precedent for this in GDB when we look at source styling.
+	For example, function names in styled source listings are not styled
+	using the `function` style, but instead, either GNU Source Highlight,
+	or pygments gets to decide how the function name should be styled.
+
+	If the Python pygments library is not present then GDB will continue
+	to behave as it always has, the disassembler output is mostly
+	unstyled, but the address and symbols are styled using the `address`
+	and `function` styles, as they are today.
+
+	However, if the user does `set style disassembler enabled off`, then
+	all disassembler styling is switched off.  This obviously covers the
+	use of pygments, but also includes the minimal styling done by GDB
+	when pygments is not available.
+
+2022-02-14  H.J. Lu  <hjl.tools@gmail.com>
+
+	ld: Keep indirect symbol from IR if referenced from shared object
+	Don't change indirect symbol defined in IR to undefined if it is
+	referenced from shared object.
+
+	bfd/
+
+		PR ld/28879
+		* elflink.c (_bfd_elf_merge_symbol): Don't change indirect
+		symbol defined in IR to undefined if it is referenced from
+		shared object.
+
+	ld/
+
+		PR ld/28879
+		* testsuite/ld-plugin/lto.exp: Run PR ld/28879 tests.
+		* testsuite/ld-plugin/pr28879a.cc: New file.
+		* testsuite/ld-plugin/pr28879b.cc: Likewise.
+
+2022-02-14  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-13  Alan Modra  <amodra@gmail.com>
+
+	PR28882, build failure with gcc-4.2 due to use of 0b literals
+		PR 28882
+		* elf/loongarch.h: Replace binary literals with hex.
+
+2022-02-13  Alan Modra  <amodra@gmail.com>
+
+	Don't pass around expld.dataseg pointer
+	The better to see any code that accesses expld.dataseg.
+
+		* ldexp.c (fold_segment_end): Remove seg parameter.  Adjust calls.
+		(fold_segment_align, fold_segment_relro_end): Likewise.
+		* ldlang.c (lang_size_segment): Likewise.
+		(lang_size_relro_segment_1, lang_find_relro_sections_1): Likewise.
+
+2022-02-13  Alan Modra  <amodra@gmail.com>
+
+	Remove bfd ELF_RELROPAGESIZE
+	Now that ld properly aligns the end of the relro segment, the hack to
+	make relro work on powerpc can disappear.
+
+	bfd/
+		* bfd.c (bfd_emul_get_commonpagesize): Remove relro param.
+		Don't return bed->relropagesize.
+		* elf-bfd.h (struct elf_backend_data): Remove relropagesize.
+		* elfxx-target.h (ELF_RELROPAGESIZE): Remove.
+		* elf32-ppc.c (ELF_RELROPAGESIZE): Don't define.
+		* elf64-ppc.c: Likewise.
+		* bfd-in2.h: Regenerate.
+	ld/
+		* ldemul.c (after_parse_default): Adjust
+		bfd_emul_get_commonpagesize call.
+
+2022-02-13  Alan Modra  <amodra@gmail.com>
+
+	PR28824, relro security issues, x86 keep COMMONPAGESIZE relro
+	x86 treats MAXPAGESIZE as a memory optimisation parameter, actual
+	hardware paging is always COMMPAGESIZE of 4k.  Use COMMONPAGESIZE for
+	the end of the relro segment alignment.
+
+	The previous patch regresses pr18176, increasing the testcase file
+	size from 322208 to 2099872 bytes.  Fixing this on x86 will require
+	introducing a gap after the end of the relro segment (of up to
+	relropagesize-1 bytes).
+
+		PR 28824
+		PR 18176
+		* ld.h (ld_config_type): Add relro_use_commonpagesize field.
+		* ldexp.c (fold_segment_align): Set relropagesize depending on
+		relro_use_commonpagesize.
+		* emultempl/elf-x86.em (elf_x86_create_output_section_statements):
+		Set relro_use_commonpagesize.
+		* testsuite/ld-x86-64/pr18176.d: xfail.
+
+2022-02-13  Alan Modra  <amodra@gmail.com>
+
+	PR28824, relro security issues
+	Background
+	==========
+	There are constraints on layout of binaries to meet demand paging and
+	memory protection requirements.  Demand paged binaries must have file
+	offset mod pagesize equal to vma mod pagesize.  Memory protection
+	(executable, read, write status) can only change at page boundaries.
+	The linker's MAXPAGESIZE variable gives the page size for these layout
+	constraints.
+
+	In a typical basic executable with two memory segments, text (RE) and
+	data (RW), the data segment must start on a different page to the
+	last text segment page.  For example, with 64k pages and a small
+	executable of 48k text and 1k data, the text segment might start at
+	address 0x10000 and data at 0x20000 for a total of two 64k memory
+	pages.  Demand paging would require the image on disk to be 64k+1k
+	in size.  We can do better than that.  If the data segment instead
+	starts at 0x2c000 (the end of the text segment plus one 64k page) then
+	there are still only two memory pages, but the disk image is now
+	smaller, 48k+1k in size.  This is why the linker normally starts the
+	data segment at the end of the text segment plus one page.  That
+	simple heuristic isn't ideal in all cases.  Changing our simple
+	example to one with 64k-1 text size, following that heuristic would
+	result in data starting at 0x2ffff.  Now we have two 64k memory data
+	pages for a data segment of 1k!  If the data segment instead started
+	at 0x30000 we'd get a single data segment page at the cost of 1 byte
+	extra in the disk image, which is likely a good trade-off.  So the
+	linker does adjust the simple heuristic.  Just how much disk image
+	size increase is allowed is controlled by the linker's COMMONPAGESIZE
+	variable.
+
+	A PT_GNU_RELRO segment overlays the initial part of the data segment,
+	saying that those pages should be made read-only after relocation by
+	the dynamic loader.  Page granularity for memory protection means that
+	the end of the relro segment must be at a page boundary.
+
+	The problem
+	===========
+	Unfortunately most targets currently only align the end of the relro
+	segment to COMMONPAGESIZE.  That results in only partial relro
+	protection if an executable is running with MAXPAGESIZE pages, since
+	any part of the relro segment past the last MAXPAGESIZE boundary can't
+	be made read-only without also affecting sections past the end of the
+	relro segment.  I believe this problem arose because x86 always runs
+	with 4k (COMMPAGESIZE) memory pages, and therefore using a larger
+	MAXPAGESIZE on x86 is for reasons other than the demand paging and
+	memory page protection boundary requirements.
+
+	The solution
+	============
+	Always end the relro segment on a MAXPAGESIZE boundary, except for
+	x86.  Note that the relro segment, comprising of sections at the start
+	of the data segment, is sized according to how those sections are laid
+	out.  That means the start of the relro segment is fixed relative to
+	its end.  Which also means the start of the data segment must be at a
+	fixed address mod MAXPAGESIZE.  So for relro the linker can't play
+	games with the start of the data segment to save disk space.  At
+	least, not without introducing gaps between the relro sections.  In
+	fact, because the linker was starting layout using its simple
+	heuristic of starting the data segment at the end of the text segment
+	plus one page, it was sometimes introducing page gaps for no reason.
+	See pr28743.
+
+		PR 28824
+		PR 28734
+		* ldexp.c (fold_segment_align): When relro, don't adjust up by
+		offset within page.  Set relropagesize.
+		(fold_segment_relro_end): Align to relropagesize.
+		* ldexp.h (seg_align_type): Rename pagesize to commonpagesize.
+		Add relropagesize.  Comment.
+		* ldlang.c (lang_size_segment): Adjust to suit field renaming.
+		(lang_size_relro_segment_1): Align relro_end using relropagesize.
+
+2022-02-13  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-12  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-11  H.J. Lu  <hjl.tools@gmail.com>
+
+	x86: Disallow invalid relocation against protected symbol
+	I am checking this into master and will backport it to 2.38 branch.
+
+	H.J
+	----
+	On x86, GCC 12 supports -mno-direct-extern-access to enable canonical
+	reference to protected function and disable copy relocation.  With
+	-mno-direct-extern-access, the canonical protected function symbols must
+	be accessed via canonical reference and the protected data symbols in
+	shared libraries are non-copyable. Under glibc 2.35, non-canonical
+	reference to the canonical protected function will get the run-time error:
+
+	./y: internal_f: ./libfoo.so: non-canonical reference to canonical protected function
+
+	and copy relocations against the non-copyable protected symbols will get
+	the run-time error:
+
+	./x: internal_i: ./libfoo.so: copy relocation against non-copyable protected symbol
+
+	Update x86 linker to disallow non-canonical reference to the canonical
+	protected function:
+
+	ld: plt.o: non-canonical reference to canonical protected function `internal_f' in libfoo.so
+	ld: failed to set dynamic section sizes: bad value
+
+	and copy relocation against the non-copyable protected symbol:
+
+	ld: main.o: copy relocation against non-copyable protected symbol `internal_i' in libfoo.so
+
+	at link-time.
+
+	bfd/
+
+		PR ld/28875
+		* elf-properties.c (_bfd_elf_parse_gnu_properties): Don't skip
+		shared libraries for GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS.
+		* elf32-i386.c (elf_i386_scan_relocs): Disallow non-canonical
+		reference to canonical protected function.
+		* elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise.
+		* elfxx-x86.c (elf_x86_allocate_dynrelocs): Don't allow copy
+		relocation against non-copyable protected symbol.
+
+	ld/
+
+		PR ld/28875
+		* testsuite/ld-i386/i386.exp: Check non-canonical reference to
+		canonical protected function and check copy relocation against
+		non-copyable protected symbol.
+		* testsuite/ld-i386/pr21997-1.err: New file.
+		* testsuite/ld-i386/pr28875.err: Likewise.
+		* testsuite/ld-i386/pr28875a.c: Likewise.
+		* testsuite/ld-i386/pr28875b.c: Likewise.
+		* testsuite/ld-x86-64/pr21997-1a.err: Updated.
+		* testsuite/ld-x86-64/pr21997-1b.err: Likewise.
+		* testsuite/ld-x86-64/pr28875-data.err: New file.
+		* testsuite/ld-x86-64/pr28875-func.err: Likewise.
+		* testsuite/ld-x86-64/x86-64.exp: Check non-canonical reference
+		to canonical protected function and check copy relocation against
+		non-copyable protected symbol.
+
+2022-02-11  Tom Tromey  <tromey@adacore.com>
+
+	Add initializers to bound_minimal_symbol
+	This adds initializers to bound_minimal_symbol, allowing for the
+	removal of some calls to memset.
+
+2022-02-11  Bhuvanendra Kumar N  <Bhuvanendra.KumarN@amd.com>
+
+	gdb/fortran: support ptype and print commands for namelist variables
+	Gfortran supports namelists (a Fortran feature); it emits
+	DW_TAG_namelist and DW_TAG_namelist_item dies. But gdb does not
+	process these dies and does not support 'print' or 'ptype' commands on
+	namelist variables.
+
+	An attempt to print namelist variables results in gdb bailing out with
+	the error message as shown below.
+
+	  (gdb) print nml
+	  No symbol "nml" in current context.
+
+	This commit is to make the print and ptype commands work for namelist
+	variables and its items. Sample output of these commands is shared
+	below, with fixed gdb.
+
+	  (gdb) ptype nml
+	  type = Type nml
+	      integer(kind=4) :: a
+	      integer(kind=4) :: b
+	  End Type nml
+	  (gdb) print nml
+	  $1 = ( a = 10, b = 20 )
+
+2022-02-11  Bruno Larsen  <blarsen@redhat.com>
+
+	gdb: fix until behavior with trailing !is_stmt lines
+	When using the command "until", it is expected that GDB will exit a
+	loop if the current instruction is the last one related to that loop.
+	However, if there were trailing non-statement instructions, "until"
+	would just behave as "next".  This was noticeable in clang-compiled
+	code, but might happen with gcc-compiled as well.  PR gdb/17315 relates
+	to this problem, as running gdb.base/watchpoint.exp with clang
+	would fail for this reason.
+
+	To better understand this issue, consider the following source code,
+	with line numbers marked on the left:
+
+	  10:	for (i = 0; i < 10; ++i)
+	  11:     loop_body ();
+	  12:   other_stuff ();
+
+	If we transform this to pseudo-assembler, and generate a line table,
+	we could end up with something like this:
+
+	  Address | Pseudo-Assembler | Line | Is-Statement?
+
+	  0x100   | i = 0            | 10   | Yes
+	  0x104   | loop_body ()     | 11   | Yes
+	  0x108   | i = i + 1        | 10   | Yes
+	  0x10c   | if (i < 10):     | 10   | No
+	  0x110   |     goto 0x104   | 10   | No
+	  0x114   | other_stuff ()   | 12   | Yes
+
+	Notice the two non-statement instructions at the end of the loop.
+
+	The problem is that when we reach address 0x108 and use 'until',
+	hoping to leave the loop, GDB sets up a stepping range that runs from
+	the start of the function (0x100 in our example) to the end of the
+	current line table entry, that is 0x10c in our example.  GDB then
+	starts stepping forward.
+
+	When 0x10c is reached GDB spots that we have left the stepping range,
+	that the new location is not a statement, and that the new location is
+	associated with the same source line number as the previous stepping
+	range.  GDB then sets up a new stepping range that runs from 0x10c to
+	0x114, and continues stepping forward.
+
+	Within that stepping range the inferior hits the goto (at 0x110) and
+	loops back to address 0x104.
+
+	At 0x104 GDB spots that we have left the previous stepping range, that
+	the new address is marked as a statement, and that the new address is
+	for a different source line.  As a result, GDB stops and returns
+	control to the user.  This is not what the user was expecting, they
+	expected GDB to exit the loop.
+
+	The fix proposed in this patch, is that, when the user issues the
+	'until' command, and GDB sets up the initial stepping range, GDB will
+	check subsequent SALs (symtab_and_lines) to see if they are
+	non-statements associated with the same line number.  If they are then
+	the end of the initial stepping range is extended to the end of the
+	non-statement SALs.
+
+	In our example above, the user is at 0x108 and uses 'until', GDB now
+	sets up a stepping range from the start of the function 0x100 to
+	0x114, the first address associated with a different line.
+
+	Now as GDB steps around the loop it never leaves the initial stepping
+	range.  It is only when GDB exits the loop that we leave the stepping
+	range, and the stepping finishes at address 0x114.
+
+	This patch also adds a test case that can be run with gcc to test that
+	this functionality is not broken in the future.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17315
+
+2022-02-11  Richard Sandiford  <richard.sandiford@arm.com>
+
+	gas/doc: Fix "a true results" typo
+
+2022-02-11  Jan Vrany  <jan.vrany@labware.com>
+
+	gdb: extend the information printed by 'maint info jit'
+	This commit updates the output of 'maint info jit' to print not just
+	the jit_code_entry address, but also the symfile address, and the
+	symfile size.
+
+	The new information could be obtained by looking into target memory at
+	the contents of the jit_code_entry, but, by storing this information
+	within gdb at the time the jit object is loaded, it is now possible to
+	check if the jit_code_entry has been modified in target memory behind
+	gdb's back.
+
+	Additionally, the symfile address is the same address that is now used
+	in the objfile names after commit 4a620b7e.
+
+	One test that relies on the output of 'maint info jit' was updated to
+	allow for the new output format.
+
+2022-02-11  Michael Forney  <mforney@mforney.org>
+
+	bfd: Remove return with expression in void function
+	      * bfd.c (bfd_set_gp_value): Remove return with expression
+	        in void function.
+
+2022-02-11  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: LoongArch: Add Makefile, configure and NEWS
+	This commit adds Makefile, configure and NEWS for LoongArch.
+
+	gdb: LoongArch: Add initial native Linux support
+	This commit adds initial native Linux support for LoongArch.
+
+	gdb: LoongArch: Add initial Linux target support
+	This commit adds initial Linux target support for LoongArch.
+
+	gdb: LoongArch: Add initial baremetal support
+	This commit adds initial baremetal support for LoongArch.
+
+	gdb: LoongArch: Add initial target description support
+	This commit adds initial target description support for LoongArch.
+
+2022-02-11  Mike Frysinger  <vapier@gentoo.org>
+
+	libctf: delete unused libctf_TEXINFOS
+	It's not clear what this was meant for, but it's not used by anything,
+	and the info pages still generate fine without it.
+
+2022-02-11  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/linux: remove ptrace support check for exec, fork, vfork, vforkdone, clone, sysgood
+	I think it's safe to remove checking support for these ptrace features,
+	they have all been added in what is now ancient times (around the
+	beginning of Linux 2.6).  This allows removing a bit of complexity in
+	linux-nat.c and nat/linux-ptrace.c.
+
+	It also allows saving one extra fork every time we start debugging on
+	Linux: linux_check_ptrace_features forks a child process to test if some
+	ptrace features are supported.  That child process forks a grand-child,
+	to test whether ptrace reports an event for the fork by the child.  This
+	is no longer needed, if we assume the kernel supports reporting forks.
+
+	PTRACE_O_TRACEVFORKDONE was introduced in Linux in this change, in 2003:
+
+	  https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=45c1a159b85b3b30afd26a77b4be312226bba416
+
+	PTRACE_O_TRACESYSGOOD was supported at least as of this change, in 2002:
+
+	  https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=acc7088569c8eef04eeed0eff51d23bb5bcff964
+
+	PTRACE_O_TRACEFORK, PTRACE_O_TRACEVFORK, PTRACE_O_TRACEEXEC and
+	PTRACE_O_TRACECLONE were introduced in this change, in 2002:
+
+	  https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=a0691b116f6a4473f0fa264210ab9b95771a2b46
+
+	Change-Id: Iffb906549a89cc6b619427f976ec044706ab1e8d
+
+2022-02-11  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-10  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/infrun: some extra infrun debug print statements
+	While reviewing a different patch I wanted to know more about what was
+	going on during GDB's stepping.  I added some extra infrun debug print
+	calls, and I thought these might be useful to others.
+
+2022-02-10  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-09  Nick Clifton  <nickc@redhat.com>
+
+	Update the obsolete list and how-to-make-a-release documentation now that the 2.38 release is out.
+
+2022-02-09  Alan Modra  <amodra@gmail.com>
+
+	PR28763, SIGSEGV during processing of program headers via readelf
+		PR 28763
+		* readelf.c (process_file_header): Discard any cached program
+		headers if there is an extension field for e_phnum in first
+		section header.
+
+2022-02-09  Alan Modra  <amodra@gmail.com>
+
+	Work around gcc-4 warnings in elf64-ppc.c
+	elf64-ppc.c: In function 'ppc64_elf_size_dynamic_sections':
+	elf64-ppc.c:10309:45: error: value computed is not used [-Werror=unused-value]
+	     ++lgot_ents, ++lgot_masks, isym != NULL && isym++)
+
+	It is of course a silly warning, fixed in later versions of gcc.  I
+	wrote "isym != NULL && isym++" rather than the simpler "isym++" to
+	stop sanitisers complaining about incrementing a NULL pointer.  isym
+	is of course unused in any code path where it might start off as
+	NULL.  Sometimes you can't win.  So don't try to be clever in reading
+	local symbols only when needed.  99 times out of 100 they will be
+	cached anyway.
+
+		* elf64-ppc.c (ppc64_elf_size_dynamic_sections): Avoid annoying
+		warnings by always reading local syms.
+		(ppc64_elf_layout_multitoc): Likewise.
+
+2022-02-09  Peilin Ye  <peilin.ye@bytedance.com>
+
+	Test --only-keep-debug on ELF relocatables
+	Add a test for commit 7c4643efe7be, which fixed --only-keep-debug for ELF
+	relocatables.
+
+		* testsuite/binutils-all/objcopy.exp
+		(keep_debug_symbols_for_elf_relocatable): New test.
+
+2022-02-09  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-08  Palmer Dabbelt  <palmer@rivosinc.com>
+
+	RISC-V: Stop reporting warnings for mismatched extension versions
+	The extension version checking logic is really just too complicated to
+	encode into the linker, trying to do so causes more harm than good.
+	This removes the checks and the associated tests, leaving the logic to
+	keep the largest version of each extension linked into the target.
+
+	bfd/
+
+		* elfnn-riscv.c (riscv_version_mismatch): Rename to
+		riscv_update_subset_version, and stop reporting warnings on
+		version mismatches.
+		(riscv_merge_std_ext): Adjust calls to riscv_version_mismatch.
+		(riscv_merge_multi_letter_ext): Likewise.
+
+	ld/
+		* testsuite/ld-riscv-elf/attr-merge-arch-failed-01.d: Remove
+		* testsuite/ld-riscv-elf/attr-merge-arch-failed-01a.s: Likewise
+		* testsuite/ld-riscv-elf/attr-merge-arch-failed-01b.s: Likewise
+		* testsuite/ld-riscv-elf/attr-merge-arch-failed-02.d: Likewise
+		* testsuite/ld-riscv-elf/attr-merge-arch-failed-02a.s: Likewise
+		* testsuite/ld-riscv-elf/attr-merge-arch-failed-02b.s: Likewise
+		* testsuite/ld-riscv-elf/attr-merge-arch-failed-02c.s: Likewise
+		* testsuite/ld-riscv-elf/attr-merge-arch-failed-02d.s: Likewise
+		* testsuite/ld-riscv-elf/attr-merge-user-ext-01.d: New test.
+		* testsuite/ld-riscv-elf/attr-merge-user-ext-rv32i21_m2p0.s:
+		Likewise.
+		* testsuite/ld-riscv-elf/attr-merge-user-ext-rv32i21_m2p1.s:
+		Likewise.
+		* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Remove obselete
+		attr-merge-arch-failed-{01,02}, replace with
+		attr-merge-user-ext-01.
+
+2022-02-08  Alan Modra  <amodra@gmail.com>
+
+	PR28862, heap-buffer-overflow in parse_stab_string
+	I have no info on the format of a "SUNPRO C++ Namespace" stab, so am
+	relying on the previous code being correct in parsing these stabs.
+	Just don't allow NULs anywhere in the stab.
+
+		PR 28862
+		* stabs.c (parse_stab_string): Don't overrun buffer when parsing
+		'Y' stab.
+
+2022-02-08  Alan Modra  <amodra@gmail.com>
+
+	Re: elf: Check symbol version without any symbols
+		* testsuite/ld-elf/pr24718-1.d: Don't xfail for hppa64.
+
+2022-02-08  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: remove tailing newlines from index_cache_debug calls
+	I noticed that most of the calls to index_cache_debug include a
+	trailing newline.  As the new debug mechanism already adds a newline,
+	that means all of these debug calls result in a blank line being
+	printed, which I think is a mistake.
+
+	Remove all the trailing newlines.
+
+	I also reformatted one of the index_cache_debug where a string will
+	now fit onto a single line.
+
+	Unless 'set debug index-cache on' is used, there should be no visible
+	change in output after this commit.
+
+2022-02-08  H.J. Lu  <hjl.tools@gmail.com>
+
+	i386: Allow GOT32 relocations against ABS symbols
+	GOT32 relocations are allowed since absolute value + addend is stored in
+	the GOT slot.
+
+	Tested on glibc 2.35 build with GCC 11.2 and -Os.
+
+	bfd/
+
+		PR ld/28870
+		* elfxx-x86.c (_bfd_elf_x86_valid_reloc_p): Also allow GOT32
+		relocations.
+
+	ld/
+
+		PR ld/28870
+		* testsuite/ld-i386/i386.exp: Run pr28870.
+		* testsuite/ld-i386/pr28870.d: New file.
+		* testsuite/ld-i386/pr28870.s: Likewise.
+
+2022-02-08  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/python: allow Value.format_string to return styled output
+	Add a new argument to the gdb.Value.format_string method, 'styling'.
+	This argument is False by default.
+
+	When this argument is True, then the returned string can contain output
+	styling escape sequences.
+
+	When this argument is False, then the returned string will not contain
+	any styling escape sequences.
+
+	If the returned string is going to be printed to the user, then it is
+	often nice to retain the GDB styling.
+
+	For the testing, we need to adjust the TERM environment variable, as
+	we do for all the styling tests.  I'm now running all of the C tests
+	in gdb.python/py-format-string.exp in an environment where styling
+	could be generated, but only my new test should actually produce
+	styled output, hopefully this will catch the case where a bug might
+	cause format_string to always produce styled output.
+
+2022-02-07  Lancelot SIX  <lancelot.six@amd.com>
+
+	gdb: make thread_info::m_thread_fsm a std::unique_ptr
+	While working on function calls, I realized that the thread_fsm member
+	of struct thread_info is a raw pointer to a resource it owns.  This
+	commit changes the type of the thread_fsm member to a std::unique_ptr in
+	order to signify this ownership relationship and slightly ease resource
+	management (no need to manually call delete).
+
+	To ensure consistent use, the field is made a private member
+	(m_thread_fsm).  The setter method (set_thread_fsm) can then check
+	that it is incorrect to associate a FSM to a thread_info object if
+	another one is already in place.  This is ensured by an assertion.
+
+	The function run_inferior_call takes an argument as a pointer to a
+	call_thread_fsm and installs it in it in a thread_info instance.  Also
+	change this function's signature to accept a unique_ptr in order to
+	signify that the ownership of the call_thread_fsm is transferred during
+	the call.
+
+	No user visible change expected after this commit.
+
+	Tested on x86_64-linux with no regression observed.
+
+	Change-Id: Ia1224f72a4afa247801ce6650ce82f90224a9ae8
+
+2022-02-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: unbuffer all input streams when not using readline
+	This commit should fix PR gdb/28711.  What's actually going on is
+	pretty involved, and there's still a bit of the story that I don't
+	understand completely, however, from my observed results, I think that
+	the change I propose making here (or something very similar) is going
+	to be needed.
+
+	The original bug report involves using eclipse to drive gdb using mi
+	commands.  A separate tty is spun off in which to send gdb the mi
+	commands, this tty is created using the new-ui command.
+
+	The behaviour observed is that, given a particular set of mi commands
+	being sent to gdb, we sometimes see an ESPIPE error from a lseek
+	call, which ultimately results in gdb terminating.
+
+	The problems all originate from gdb_readline_no_editing_callback in
+	gdb/event-top.c, where we can (sometimes) perform calls to fgetc, and
+	allow glibc to perform buffering on the FILE object being used.
+
+	I say sometime, because, gdb_readline_no_editing_callback already
+	includes a call to disable the glibc buffering, but this is only done
+	if the input stream is not a tty.  In our case the input stream is a
+	tty, so the buffering is left in place.
+
+	The first step to understanding why this problem occurs is to
+	understand that eclipse sends multiple commands to gdb very quickly
+	without waiting for and answer to each command, eclipse plans to
+	collect all of the command results after sending all the commands to
+	gdb.  In fact, eclipse sends the commands to gdb that they appear to
+	arrive in the gdb process as a single block of data.  When reproducing
+	this issue within the testsuite I find it necessary to send multiple
+	commands using a single write call.
+
+	The next bit of the story gets a little involved, and this is where my
+	understanding is not complete.  I can describe the behaviour that I
+	observe, and (for me at least) I'm happy that what I'm seeing, if a
+	little strange, is consistent.  In order to fully understand what's
+	going on I think I would likely need to dive into kernel code, which
+	currently seems unnecessary given that I'm happy with the solution I'm
+	proposing.
+
+	The following description all relates to input from a tty in which I'm
+	not using readline.  I see the same problems either when using a
+	new-ui tty, or with gdb's standard, non-readline, mi tty.
+
+	Here's what I observe happening when I send multiple commands to gdb
+	using a single write, if I send gdb this:
+
+	  command_1\ncommand_2\ncommand_3
+
+	then gdb's event loop will wake up (from its select) as it sees there
+	is input available.  We call into gdb_readline_no_editing_callback,
+	where we call fgetc, glibc will do a single big read, and get back
+	just:
+
+	  command_1\n
+
+	that is, despite there being multiple lines of input available, I
+	consistently get just a single line.  From glibc a single character is
+	returned from the fgetc call, and within gdb we accumulate characters,
+	one at a time, into our own buffer.  Eventually gdb sees the '\n'
+	character, and dispatches the whole 'command_1' into gdb's command
+	handler, which processes the command and prints the result.  We then
+	return to gdb_readline_no_editing_callback, which in turn returns to
+	gdb's event loop where we re-enter the select.
+
+	Inside the select we immediately see that there is more input waiting
+	on the input stream, drop out of the select, and call back into
+	gdb_readline_no_editing_callback.  In this function we again call
+	fgetc where glibc performs another big read.  This time glibc gets:
+
+	  command_2\n
+
+	that is, we once again get just a single line, despite there being a
+	third line available.  Just like the first command we copy the whole
+	string, character by character into gdb's buffer, then handle the
+	command.  After handling the command we go to the event loop, enter,
+	and then exit the select, and call back to the function
+	gdb_readline_no_editing_callback.
+
+	In gdb_readline_no_editing_callback we again call fgetc, this time
+	glibc gets the string:
+
+	  command_3\n
+
+	like before, we copy this to gdb's buffer and handle the command, then
+	we return to the event loop.  At this point the select blocks while we
+	wait for more input to arrive.
+
+	The important bit of this is that someone, somewhere is, it appears,
+	taking care to split the incoming write into lines.
+
+	My next experiment is to try something like:
+
+	  this_is_a_very_long_command\nshort_command\n
+
+	However, I actually make 'this_is_a_very_long_command' very long, as
+	in many hundreds of characters long.  One way to do this is:
+
+	  echo xxxxxx.....xxxxx
+
+	and just adding more and more 'x' characters as needed.  What I'm
+	aiming for is to have the first command be longer than glibc's
+	internal read buffer, which, on my machine, is 1024 characters.
+
+	However, for this discussion, lets imagine that glibc's buffer is just
+	8 characters (we can create just this situation by adding a suitable
+	setbuf call into gdb_readline_no_editing_callback).
+
+	Now, if I send gdb this data:
+
+	  abcdefghij\nkl\n
+
+	The first read from glibc will get 'abcdefgh', that is a full 8
+	character buffer.  Once gdb has copied these to its buffer we call
+	fgetc again, and now glibc will get 'ij\n', that is, just like before,
+	multiple lines are split at the '\n' character.  The full command,
+	which is now in gdb's buffer can be handled 'abcdefghij', after which
+	we go (via the event loop) back to gdb_readline_no_editing_callback.
+	Now we call fgetc, and glibc will get 'kl\n', which is then handled in
+	the normal way.
+
+	So far, so good.  However, there is, apparently, one edge case where
+	the above rules don't apply.
+
+	If the '\n' character is the first character read from the kernel,
+	then the incoming lines are not split up.  So, given glibc's 8
+	character buffer, if I send gdb this:
+
+	  abcdefgh\nkl\n
+
+	that is the first command is 8 characters plus a newline, then, on the
+	first read (from within glibc) we get 'abcdefgh' in a single buffer.
+	As there's no newline gdb calls fgetc again, and glibc does another
+	large read, now we get:
+
+	  \nkl\n
+
+	which doesn't follow the above pattern - the lines are not split into
+	separate buffers!
+
+	So, gdb reads the first character from glibc using fgetc, this is the
+	newline.  Now gdb has a complete command, and so the command is
+	handled.  We then return to the event loop and enter the select.
+
+	The problem is that, as far as the kernel is concerned, there is no
+	more input pending, it's all been read into glibc's buffer, and so the
+	select doesn't return.  The second command is basically stuck in
+	glibc's buffer.
+
+	If I send another command to gdb, or even just send an empty
+	command (a lone newline) then the select returns, we call into
+	gdb_readline_no_editing_callback, and now gdb sees the second
+	command.
+
+	OK, so the above is interesting, but it doesn't explain the ESPIPE
+	error.
+
+	Well, that's a slightly different, but related issue.  The ESPIPE
+	case will _only_ show up when using new-ui to create the separate tty
+	for mi commands, and is a consequence of this commit:
+
+	  commit afe09f0b6311a4dd1a7e2dc6491550bb228734f8
+	  Date:   Thu Jul 18 17:20:04 2019 +0100
+
+	      Fix for using named pipes on Windows
+
+	Prior to this commit, the new-ui command would open the tty three
+	times, once each for stdin, stderr, and stdout.  After this commit we
+	open the tty just once and reuse the FILE object for all three roles.
+
+	Consider the problem case, where glibc has (unexpectedly) read the
+	second command into its internal buffer.  When we handle the first
+	command we usually end up having to write something to the mi output
+	stream.
+
+	After the above commit the same FILE object represents both the input
+	and output streams, so, when gdb tries to write to the FILE object,
+	glibc spots that there is input pending within the input buffer, and
+	so assumes that we have read ahead of where we should be in the input
+	file.  To correct for this glibc tries to do an lseek call to
+	reposition the file offset of the output stream prior to writing to
+	it.  However, as the output stream is a tty, and seeking is not
+	supported on a tty, this lseek call fails, this results in the ESPIPE,
+	which ultimately causes gdb to terminate.
+
+	So, now we understand why the ESPIPE triggers (which was what caused
+	the gdb crash in the original bug report), and we also understand that
+	sometime gdb will not handle the second command in a timely
+	fashion (if the first command is just the wrong length). So, what to
+	do about all this?
+
+	We could revert the commit mentioned above (and implement its
+	functionality another way).  This would certainly resolve the ESPIPE
+	issue, the buffered input would now only be on the input stream, the
+	output stream would have no buffered input, and so glibc would never
+	try to lseek, and so we'd never get the ESPIPE error.
+
+	However, this only solves one of the two problems.  We would still
+	suffer from the problem where, if the first command is just the wrong
+	length, the second command will not (immediately) get handled.
+
+	The only solution I can see to this problem is to unbuffer the input
+	stream.  If glibc is not buffering the input, but instead, we read
+	incoming data character by character from the kernel, then everything
+	will be fine.  As soon as we see the newline at the end of the first
+	command we will handle the first command.  As glibc will have no
+	buffered input it will not be tempted to lseek, so no ESPIPE error.
+	When we go have to the event loop there will be more data pending in
+	the kernel, so the select will immediately return, and the second
+	command will be processed.
+
+	I'm tempted to suggest that we should move the unbuffering of the
+	input stream out of gdb_readline_no_editing_callback and do it
+	somewhere earlier, more like when we create the input streams.
+	However, I've not done that in this commit for a couple of reasons:
+
+	  1. By keeping the unbuffering in gdb_readline_no_editing_callback
+	  I'm making the smallest possible change that fixes the bug.  Moving
+	  the unbuffering somewhere better can be done as a refactor later, if
+	  that 's felt to be important,
+
+	  2. I don't think making repeated calls to unbuffer the input will
+	  have that much performance impact.  We only make the unbuffer call
+	  once per call to gdb_readline_no_editing_callback, and, if the input
+	  stream is already unbuffered we'll return pretty quickly, so I don't
+	  see this as being massively costly,
+
+	  3. Tom is currently doing lots of gdb stream management changes and
+	  I want to minimise the chances we'll conflict.
+
+	So, this commit just changes gdb_readline_no_editing_callback to
+	always unbuffer the input stream.
+
+	The test for this issue sends two commands in a loop, with the first
+	command growing bigger each time around the loop.  I actually make the
+	first command bigger by just adding whitespace to the front, as gdb
+	still has to read the complete command (including whitespace) via
+	glibc, so this is enough to trigger the bug.
+
+	The original bug was reported when using a virtual machine, and in
+	this situation we see this in the strace output:
+
+	  read(9, "70-var-info-path-expression var1.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", 1024) = 64
+	  read(9, "\n71-var-info-path-expression var1.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n", 1024) = 67
+
+	I'm not completely sure what's going on here, but it appears that the
+	kernel on the virtual machine is delivering the input to glibc slower
+	than I see on my real hardware; glibc asks for 1024 bytes, but only
+	gets 64 bytes the first time.  In the second read we see the problem
+	case, the first character is the newline, but then the entire second
+	command is included.
+
+	If I run this exact example on my real hardware then the first command
+	would not be truncated at 64 bytes, instead, I'd expect to see the
+	newline included in the first read, with the second command split into
+	a second read.
+
+	So, for testing, I check cases where the first command is just a few
+	characters (starting at 8 character), all the way up to 2048
+	characters.  Hopefully, this should mean we hit the problem case for
+	most machine setups.
+
+	The only last question relates to commit afe09f0b6311a4d that I
+	mentioned earlier.  That commit was intended to provide support for
+	Microsoft named pipes:
+
+	  https://docs.microsoft.com/en-us/windows/win32/ipc/named-pipes
+
+	I know next to nothing about this topic beyond a brief scan of the
+	above link, but I think these windows named pipe are closer in
+	behaviour to unix sockets than to unix named fifos.
+
+	I am a little nervous that, after the above commit, we now use the
+	same FILE for in, err, and out streams.  In contrast, in a vanilla C
+	program, I would expect different FILE objects for each stream.
+
+	Still, I'm reluctant to revert the above commit (and provide the same
+	functionality a different way) without a specific bug to point at,
+	and, now that the streams are unbuffered, I expect a lot of the read
+	and write calls are going straight to the kernel with minimal glibc
+	involvement, so maybe it doesn't really matter.  Anyway, I haven't
+	touched the above patch, but it is something to keep in mind when
+	working in this area.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28711
+
+2022-02-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/disasm: combine the no printing disassembler setup code
+	We have three places in gdb where we initialise a disassembler that
+	will not print anything (used for figuring out the length of
+	instructions, or collecting other information from the disassembler).
+
+	Each of these places has its own stub function to act as a print like
+	callback, the stub function is identical in each case, and just does
+	nothing.
+
+	In this commit I create a new function to initialise a disassembler
+	that doesn't print anything, and have all three locations use this new
+	function.  There's now only one non-printing stub function.
+
+	There should be no user visible changes after this commit.
+
+2022-02-07  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>
+
+	gdb: add the 'set/show suppress-cli-notifications' command
+	GDB already has a flag to suppress printing notification events, such
+	as thread and inferior context switches, on the CLI.  This is used
+	internally when executing commands.  Make the flag available to the
+	user via a new command.  This is expected to be useful in scripts.
+
+	For instance, suppose that when Inferior 1 gets to a certain state,
+	you want to add and set up a new inferior using the commands below,
+	but you also want to have a reduced/clean output.
+
+	  define do-setup
+	    printf "Setting up Inferior 2...\n"
+	    add-inferior -exec a.out
+	    inferior 2
+	    break file.c:3
+	    run
+	    inferior 1
+	    printf "Done\n"
+	  end
+
+	Currently, GDB prints
+
+	  (gdb) do-setup
+	  Setting up Inferior 2...
+	  [New inferior 2]
+	  Added inferior 2 on connection 1 (native)
+	  [Switching to inferior 2 [<null>] (/tmp/a.out)]
+	  Breakpoint 2 at 0x1155: file file.c, line 3.
+
+	  Thread 2.1 "a.out" hit Breakpoint 2, main () at file.c:3
+	  3         return 0;
+	  [Switching to inferior 1 [process 7670] (/tmp/test)]
+	  [Switching to thread 1.1 (process 7670)]
+	  #0  main () at test.c:2
+	  2         int a = 1;
+	  Done
+
+	GDB's Python API make it possible to capture and return GDB's output,
+	but this does not work for all the streams.  In particular, CLI
+	notification events are not captured:
+
+	  (gdb) python gdb.execute("do-setup", False, True)
+	  [Switching to inferior 2 [<null>] (/tmp/a.out)]
+
+	  Thread 2.1 "a.out" hit Breakpoint 2, main () at file.c:3
+	  3         return 0;
+	  [Switching to inferior 1 [process 8263] (/tmp/test)]
+	  [Switching to thread 1.1 (process 8263)]
+	  #0  main () at test.c:2
+	  2         int a = 1;
+
+	You can use the new "set suppress-cli-notifications" command to
+	suppress the output:
+
+	  (gdb) set suppress-cli-notifications on
+	  (gdb) do-setup
+	  Setting up Inferior 2...
+	  [New inferior 2]
+	  Added inferior 2 on connection 1 (native)
+	  Breakpoint 2 at 0x1155: file file.c, line 3.
+	  Done
+
+2022-02-07  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>
+
+	gdb/cli: add a 'normal_stop' option to 'cli_suppress_notification'
+	Extend the 'cli_suppress_notification' struct with a new field,
+	'normal_stop', that can be used for checking if printing normal stop
+	events on the CLI should be suppressed.
+
+	This patch only introduces the flag.  The subsequent patch adds a user
+	command to turn the flag off/on.
+
+2022-02-07  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>
+
+	gdb/cli: convert cli_suppress_notification from int to bool
+	Convert the suppress_notification flag for the CLI from int to bool.
+
+2022-02-07  Alan Modra  <amodra@gmail.com>
+
+	Revert "elf: Remove the 1-page gap before the RELRO segment"
+	This reverts commit 2f83249c13d86065b4c7cdb198ea871017b4bba1.
+
+		PR ld/28743
+		* ldlang.c (lang_size_relro_segment_1): Revert 2022-01-10 changes.
+		* testsuite/ld-i386/pr20830.d: Likewise.
+		* testsuite/ld-s390/gotreloc_64-relro-1.dd: Likewise.
+		* testsuite/ld-x86-64/pr14207.d: Likewise.
+		* testsuite/ld-x86-64/pr18176.d: Likewise.
+		* testsuite/ld-x86-64/pr20830a-now.d: Likewise.
+		* testsuite/ld-x86-64/pr20830a.d: Likewise.
+		* testsuite/ld-x86-64/pr20830b-now.d: Likewise.
+		* testsuite/ld-x86-64/pr20830b.d: Likewise.
+		* testsuite/ld-x86-64/pr21038a-now.d: Likewise.
+		* testsuite/ld-x86-64/pr21038a.d: Likewise.
+		* testsuite/ld-x86-64/pr21038b-now.d: Likewise.
+		* testsuite/ld-x86-64/pr21038c-now.d: Likewise.
+		* testsuite/ld-x86-64/pr21038c.d: Likewise.
+
+2022-02-07  Alan Modra  <amodra@gmail.com>
+
+	Revert "ld: Rewrite lang_size_relro_segment_1"
+	This reverts commit c804c6f98d342c3d46f73d7a7ec6229d5ab1c9f3.
+
+		PR ld/28743
+		PR ld/28819
+		* ldlang.c (lang_size_relro_segment_1): Revert 2022-01-14 change.
+		* testsuite/ld-x86-64/pr28743-1.d: Likewise.
+		* testsuite/ld-x86-64/pr28743-1.s: Likewise.
+		* testsuite/ld-x86-64/x86-64.exp: Likewise.
+
+2022-02-07  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-06  Alan Modra  <amodra@gmail.com>
+
+	A more elegant pr28827-1 testcase
+	Use .irpc macros in pr28827-1.s
+
+		* testsuite/ld-powerpc/pr28827-1.s: Make the testcase more
+		elegant.  Comment.
+
+2022-02-06  Tom Tromey  <tom@tromey.com>
+
+	Merge do_val_print and common_val_print
+	The only caller of do_val_print just does a small bit of work before
+	the call.  This patch merges the two functions, and removes an
+	unnecessary local variable, making gdb a bit simpler.
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove SYMBOL_LINE macro
+	Add a getter and a setter for a symbol's line.  Remove the corresponding macro
+	and adjust all callers.
+
+	Change-Id: I229f2b8fcf938c07975f641361313a8761fad9a5
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove SYMBOL_TYPE macro
+	Add a getter and a setter for a symbol's type.  Remove the corresponding
+	macro and adjust all callers.
+
+	Change-Id: Ie1a137744c5bfe1df4d4f9ae5541c5299577c8de
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remote SYMBOL_IS_CPLUS_TEMPLATE_FUNCTION macro
+	Add a getter for a whether a symbol is a C++ template function.  Remove
+	the corresponding macro and adjust all callers.
+
+	Change-Id: I89abc2802a952b77b0e0eb73a25c2306cb8e8bcc
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove SYMBOL_INLINED macro
+	Add a getter and a setter for whether a symbol is inlined.  Remove the
+	corresponding macro and adjust all callers.
+
+	Change-Id: I934468da3b5a32dd6b161a6f252a6b1b94737279
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove SYMBOL_IS_ARGUMENT macro
+	Add a getter and a setter for whether a symbol is an argument.  Remove
+	the corresponding macro and adjust all callers.
+
+	Change-Id: I71b4f0465f3dfd2ed8b9e140bd3f7d5eb8d9ee81
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove SYMBOL_OBJFILE_OWNED macro
+	Add a getter and a setter for whether a symbol is objfile owned.  Remove
+	the corresponding macro and adjust all callers.
+
+	Change-Id: Ib7ef3718d65553ae924ca04c3fd478b0f4f3147c
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove SYMBOL_DOMAIN macro
+	Add a getter and a setter for a symbol's domain.  Remove the
+	corresponding macro and adjust all callers.
+
+	Change-Id: I54465b50ac89739c663859a726aef8cdc6e4b8f3
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove SYMBOL_CLASS macro, add getter
+	Change-Id: I83211d5a47efc0564386e5b5ea4a29c00b1fd46a
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove SYMBOL_IMPL macro, add method
+	Add a getter for a symbol's "impl".  Remove the corresponding macro and
+	adjust all callers.
+
+	Change-Id: Ibe26ed442f0f99a0f5cddafca30bd96ec7fb9fa8
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove SYMBOL_ACLASS_INDEX macro, add getter/setter
+	Add a getter and a setter for a symbol's aclass index.  Remove the
+	corresponding macro and adjust all callers.
+
+	Change-Id: Ie8c8d732624cfadb714aba5ddafa3d29409b3d39
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove SYMBOL_MATCHES_SEARCH_NAME
+	It seems like this macro is not needed at all anymore, it just wraps the
+	function of the same name with the same arguments.
+
+	Change-Id: I3c342ac8d89c27af5aee1a819dc32cc6396fd41b
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove SYMTAB_DIRNAME macro
+	Remove the macro, replace with an equivalent method.
+
+	Change-Id: I46ec36b91bb734331138eb9cd086b2db01635aed
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove SYMTAB_PSPACE macro
+	Remove the macro, replace with an equivalent method.
+
+	Change-Id: Icccc20e7e8ae03ac4dac1c7514c25a12a9a0ac69
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove SYMTAB_OBJFILE macro
+	Remove the macro, replace with an equivalent method.
+
+	Change-Id: I8f9ecd290ad28502e53c1ceca5006ba78bf042eb
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove SYMTAB_BLOCKVECTOR macro
+	Remove the macro, replace with an equivalent method.
+
+	Change-Id: Id6fe2a79c04bcd6c69ccaefb7a69bc06a476288c
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove SYMTAB_LANGUAGE macro, add getter/setter
+	Add a getter and a setter for a symtab's language.  Remove the
+	corresponding macro and adjust all callers.
+
+	Change-Id: I9f4d840b11c19f80f39bac1bce020fdd1739e11f
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove SYMTAB_LINETABLE macro, add getter/setter
+	Add a getter and a setter for a symtab's linetable.  Remove the
+	corresponding macro and adjust all callers.
+
+	Change-Id: I159183fc0ccd8e18ab937b3c2f09ef2244ec6e9c
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove SYMTAB_COMPUNIT macro, add getter/setter
+	Add a getter and a setter for a symtab's compunit_symtab.  Remove the
+	corresponding macro and adjust all callers.
+
+	For brevity, I chose the name "compunit" instead of "compunit_symtab"
+	the the field, getter and setter names.  Since we are already in symtab
+	context, the _symtab suffix seems redundant.
+
+	Change-Id: I4b9b731c96e3594f7733e75af1e3d01bc0e4fe92
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove COMPUNIT_MACRO_TABLE macro, add getter/setter
+	Add a getter and a setter for a compunit_symtab's macro table.  Remove the
+	corresponding macro and adjust all callers.
+
+	Change-Id: I00615ea72d5ac43d9a865e941cb2de0a979c173a
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove COMPUNIT_EPILOGUE_UNWIND_VALID macro, add getter/setter
+	Add a getter and a setter for a compunit_symtab's epilogue unwind valid flag.
+	Remove the corresponding macro and adjust all callers.
+
+	Change-Id: If3b68629d987767da9be7041a95d96dc34367a9a
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove COMPUNIT_LOCATIONS_VALID macro, add getter/setter
+	Add a getter and a setter for a compunit_symtab's locations valid flag.
+	Remove the corresponding macro and adjust all callers.
+
+	Change-Id: I3e3cfba926ce62993d5b61814331bb3244afad01
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove COMPUNIT_BLOCK_LINE_SECTION macro, add getter/setter
+	Add a getter and a setter for a compunit_symtab's block line section.  Remove
+	the corresponding macro and adjust all callers.
+
+	Change-Id: I3eb1a323388ad55eae8bfa45f5bc4a08dc3df455
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove COMPUNIT_BLOCKVECTOR macro, add getter/setter
+	Add a getter and a setter for a compunit_symtab's blockvector.  Remove
+	the corresponding macro and adjust all callers.
+
+	Change-Id: I99484c6619dcbbea7c5d89c72aa660316ca62f64
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove COMPUNIT_DIRNAME macro, add getter/setter
+	Add a getter and a setter for a compunit_symtab's dirname.  Remove the
+	corresponding macro and adjust all callers.
+
+	Change-Id: If2f39b295fd26822586485e04a8b8b5aa5cc9b2e
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove COMPUNIT_PRODUCER macro, add getter/setter
+	Add a getter and a setter for a compunit_symtab's producer.  Remove the
+	corresponding macro and adjust all callers.
+
+	Change-Id: Ia1d6d8a0e247a08a21af23819d71e49b37d8931b
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove COMPUNIT_DEBUGFORMAT macro, add getter/setter
+	Add a getter and a setter for a compunit_symtab's debugformat.  Remove
+	the corresponding macro and adjust all callers.
+
+	Change-Id: I1667b02d5322346f8e23abd9f8a584afbcd75975
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove COMPUNIT_FILETABS macro
+	I think that most remaining uses of COMPUNIT_FILETABS intend to get the
+	primary filetab of the compunit_symtab specifically (and not to iterate
+	over all filetabs, for example, those cases would use compunit_filetabs,
+	which has been converted to compunit_symtab::filetabs), so replace mosts
+	uses with compunit_symtab::primary_filetab.
+
+	In jit.c, function finalize_symtab, we can save the symtab object
+	returned by allocate_symtab and use it, it makes things simpler.
+
+	Change-Id: I4e51d6d4b40759de8768b61292e5e13c8eae2e38
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: move compunit_filetabs to compunit_symtab::filetabs
+	Make compunit_filetabs, used to iterate a compunit_symtab's filetabs, a
+	method of compunit_symtab.  The name filetabs conflicts with the current
+	name of the field.  Rename the field to m_filetabs, since at this point
+	nothing outside of compunit_symtab uses it, so we should treat it as
+	private (even though it's not actually private).  Rename the
+	last_filetab field to m_last_filetab as well (it's only used on
+	compunit_symtab::add_filetab).
+
+	Adjust the COMPUNIT_FILETABS macro to keep its current behavior of
+	returning the first filetab.
+
+	Change-Id: I537b553a44451c52d24b18ee1bfa47e23747cfc3
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: add compunit_symtab::set_primary_filetab method
+	Add a method to set the primary filetab of the CU.  This is currently
+	done in buildsym_compunit::end_symtab_with_blockvector.
+
+	Change-Id: I16c51a6b90a4cb4c0c5f183b0f2e12bc64b6fd74
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: add compunit_symtab::add_filetab method
+	Add a method to append a filetab/symtab to a compunit_symtab.  There is
+	a single place where this is done currently, in allocate_symtab.
+
+	Change-Id: Ie86c6e34d175728173d1cffdce44acd6cff6c31d
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: rename compunit_primary_filetab to compunit_symtab::primary_filetab
+	Make compunit_primary_filetab a method of compunit_symtab.
+
+	Change-Id: Iee3c4f7e36d579bf763c5bba146e5e10d6766768
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: remove COMPUNIT_OBJFILE macro
+	Remove the macro, update all users to use the getter directly.
+
+	Change-Id: I3f0fd6f4455d1c4ebd5da73b561eb18a979ef1f6
+
+2022-02-06  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: add getter/setter for compunit_symtab::objfile
+	Rename the field to m_objfile, and add a getter and a setter.  Update
+	all users.
+
+	Change-Id: If7e2f763ee3e70570140d9af9261b1b056253317
+
+2022-02-06  Tom Tromey  <tom@tromey.com>
+
+	Allow non-ASCII characters in Rust identifiers
+	Rust 1.53 (quite a while ago now) ungated the support for non-ASCII
+	identifiers.  This didn't work in gdb.  This is PR rust/20166.
+
+	This patch fixes the problem by allowing non-ASCII characters to be
+	considered as identifier components.  It seemed simplest to just pass
+	them through -- doing any extra checking didn't seem worthwhile.
+
+	The new test also verifies that such characters are allowed in strings
+	and character literals as well.  The latter also required a bit of
+	work in the lexer.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20166
+
+2022-02-06  Tom Tromey  <tom@tromey.com>
+
+	Fix Rust parser bug with function fields
+	In Rust, 'obj.f()' is a method call -- but '(obj.f)()' is a call of a
+	function-valued field 'f' in 'obj'.  The Rust parser in gdb currently
+	gets this wrong.  This is PR rust/24082.
+
+	The expression and Rust parser rewrites made this simple to fix --
+	simply wrapping a parenthesized expression in a new operation handles
+	it.  This patch has a slight hack because I didn't want to introduce a
+	new exp_opcode enumeration constant just for this.  IMO this doesn't
+	matter, since we should work toward removing dependencies on these
+	opcodes anyway; but let me know what you think of this.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24082
+
+2022-02-06  H.J. Lu  <hjl.tools@gmail.com>
+
+	ld: Add emultempl/emulation.em
+	Add emultempl/emulation.em to define ld_${EMULATION_NAME}_emulation so
+	that new emulation hooks can be added easily.
+
+		* emultempl/aix.em (LDEMUL_AFTER_OPEN): New.
+		(LDEMUL_SET_OUTPUT_ARCH): Likewise.
+		(LDEMUL_CHOOSE_TARGET): Likewise.
+		(LDEMUL_BEFORE_ALLOCATION): Likewise.
+		(LDEMUL_CREATE_OUTPUT_SECTION_STATEMENTS): Likewise.
+		(LDEMUL_OPEN_DYNAMIC_ARCHIVE): Likewise.
+		(LDEMUL_PARSE_ARGS): Likewise.
+		(LDEMUL_ADD_OPTIONS): Likewise.
+		(LDEMUL_HANDLE_OPTION): Likewise.
+		(LDEMUL_UNRECOGNIZED_FILE): Likewise.
+		(LDEMUL_PRINT_SYMBOL): Likewise.
+		(ld_${EMULATION_NAME}_emulation): Removed.
+		Source ${srcdir}/emultempl/emulation.em.
+		* emultempl/beos.em (gld_${EMULATION_NAME}_before_parse):
+		Renamed to ...
+		(gld${EMULATION_NAME}_before_parse): This.
+		(gld_${EMULATION_NAME}_set_symbols): Renamed to ...
+		(gld${EMULATION_NAME}_set_symbols): This.
+		(gld_${EMULATION_NAME}_after_open): Renamed to ...
+		(gld${EMULATION_NAME}_after_open): This.
+		(gld_${EMULATION_NAME}_before_allocation): Renamed to ...
+		(gld${EMULATION_NAME}_before_allocation): This.
+		(gld_${EMULATION_NAME}_get_script): Renamed to ...
+		(gld${EMULATION_NAME}_get_script): This.
+		(LDEMUL_AFTER_OPEN): New.
+		(LDEMUL_BEFORE_ALLOCATION): Likewise.
+		(LDEMUL_PLACE_ORPHAN): Likewise.
+		(LDEMUL_SET_SYMBOLS): Likewise.
+		(LDEMUL_ADD_OPTIONS): Likewise.
+		(LDEMUL_HANDLE_OPTION): Likewise.
+		(ld_${EMULATION_NAME}_emulation): Removed.
+		Source ${srcdir}/emultempl/emulation.em.
+		* emultempl/elf.em (LDEMUL_AFTER_PARSE): New.
+		(LDEMUL_AFTER_OPEN): Likewise.
+		(LDEMUL_BEFORE_PLACE_ORPHANS): Likewise.
+		(LDEMUL_AFTER_ALLOCATION): Likewise.
+		(LDEMUL_SET_OUTPUT_ARCH): Likewise.
+		(LDEMUL_BEFORE_ALLOCATION): Likewise.
+		(LDEMUL_OPEN_DYNAMIC_ARCHIVE): Likewise.
+		(LDEMUL_PLACE_ORPHAN): Likewise.
+		(LDEMUL_ADD_OPTIONS): Likewise.
+		(LDEMUL_HANDLE_OPTION): Likewise.
+		(LDEMUL_LIST_OPTIONS): Likewise.
+		(LDEMUL_UNRECOGNIZED_FILE): Likewise.
+		(ld_${EMULATION_NAME}_emulation): Removed.
+		Source ${srcdir}/emultempl/emulation.em.
+		* emultempl/emulation.em: New file.
+		* emultempl/generic.em (ld_${EMULATION_NAME}_emulation): Removed.
+		Source ${srcdir}/emultempl/emulation.em.
+		* emultempl/msp430.em (LDEMUL_AFTER_OPEN): New.
+		(LDEMUL_AFTER_ALLOCATION): Likewise.
+		(LDEMUL_PLACE_ORPHAN): Likewise.
+		(LDEMUL_FINISH): Likewise.
+		(LDEMUL_ADD_OPTIONS): Likewise.
+		(LDEMUL_HANDLE_OPTION): Likewise.
+		(LDEMUL_LIST_OPTIONS): Likewise.
+		(ld_${EMULATION_NAME}_emulation): Removed.
+		Source ${srcdir}/emultempl/emulation.em.
+		* emultempl/pe.em (gld_${EMULATION_NAME}_before_parse): Renamed
+		to ...
+		(gld${EMULATION_NAME}_before_parse): This.
+		(gld_${EMULATION_NAME}_list_options): Renamed to ...
+		(gld${EMULATION_NAME}_list_options): This.
+		(gld_${EMULATION_NAME}_set_symbols): Renamed to ...
+		(gld${EMULATION_NAME}_set_symbols): This.
+		(gld_${EMULATION_NAME}_after_parse): Renamed to ...
+		(gld${EMULATION_NAME}_after_parse): This.
+		(gld_${EMULATION_NAME}_after_open): Renamed to ...
+		(gld${EMULATION_NAME}_after_open): This.
+		(gld_${EMULATION_NAME}_before_allocation): Renamed to ...
+		(gld${EMULATION_NAME}_before_allocation): This.
+		(gld_${EMULATION_NAME}_unrecognized_file): Renamed to ...
+		(gld${EMULATION_NAME}_unrecognized_file): This.
+		(gld_${EMULATION_NAME}_recognized_file): Renamed to ...
+		(gld${EMULATION_NAME}_recognized_file): This.
+		(gld_${EMULATION_NAME}_finish): Renamed to ...
+		(gld${EMULATION_NAME}_finish): This.
+		(gld_${EMULATION_NAME}_place_orphan): Renamed to ...
+		(gld${EMULATION_NAME}_place_orphan): This.
+		(gld_${EMULATION_NAME}_open_dynamic_archive): Renamed to ...
+		(gld${EMULATION_NAME}_open_dynamic_archive): This.
+		(gld_${EMULATION_NAME}_find_potential_libraries): Renamed to ...
+		(gld${EMULATION_NAME}_find_potential_libraries): This.
+		(gld_${EMULATION_NAME}_get_script): Renamed to ...
+		(gld${EMULATION_NAME}_get_script): This.
+		(LDEMUL_AFTER_PARSE): New.
+		(LDEMUL_AFTER_OPEN): Likewise.
+		(LDEMUL_BEFORE_ALLOCATION): Likewise.
+		(LDEMUL_FINISH=): Likewise.
+		(LDEMUL_OPEN_DYNAMIC_ARCHIVE): Likewise.
+		(LDEMUL_PLACE_ORPHAN): Likewise.
+		(LDEMUL_SET_SYMBOLS): Likewise.
+		(LDEMUL_ADD_OPTIONS): Likewise.
+		(LDEMUL_HANDLE_OPTION): Likewise.
+		(LDEMUL_UNRECOGNIZED_FILE): Likewise.
+		(LDEMUL_LIST_OPTIONS): Likewise.
+		(LDEMUL_RECOGNIZED_FILE): Likewise.
+		(LDEMUL_FIND_POTENTIAL_LIBRARIES): Likewise.
+		(ld_${EMULATION_NAME}_emulation): Removed.
+		Source ${srcdir}/emultempl/emulation.em.
+		* emultempl/pep.em (gld_${EMULATION_NAME}_before_parse): Renamed
+		to ...
+		(gld${EMULATION_NAME}_before_parse): This.
+		(gld_${EMULATION_NAME}_list_options): Renamed to ...
+		(gld${EMULATION_NAME}_list_options): This.
+		(gld_${EMULATION_NAME}_set_symbols): Renamed to ...
+		(gld${EMULATION_NAME}_set_symbols): This.
+		(gld_${EMULATION_NAME}_after_parse): Renamed to ...
+		(gld${EMULATION_NAME}_after_parse): This.
+		(gld_${EMULATION_NAME}_after_open): Renamed to ...
+		(gld${EMULATION_NAME}_after_open): This.
+		(gld_${EMULATION_NAME}_before_allocation): Renamed to ...
+		(gld${EMULATION_NAME}_before_allocation): This.
+		(gld_${EMULATION_NAME}_unrecognized_file): Renamed to ...
+		(gld${EMULATION_NAME}_unrecognized_file): This.
+		(gld_${EMULATION_NAME}_recognized_file): Renamed to ...
+		(gld${EMULATION_NAME}_recognized_file): This.
+		(gld_${EMULATION_NAME}_finish): Renamed to ...
+		(gld${EMULATION_NAME}_finish): This.
+		(gld_${EMULATION_NAME}_place_orphan): Renamed to ...
+		(gld${EMULATION_NAME}_place_orphan): This.
+		(gld_${EMULATION_NAME}_open_dynamic_archive): Renamed to ...
+		(gld${EMULATION_NAME}_open_dynamic_archive): This.
+		(gld_${EMULATION_NAME}_find_potential_libraries): Renamed to ...
+		(gld${EMULATION_NAME}_find_potential_libraries): This.
+		(gld_${EMULATION_NAME}_get_script): Renamed to ...
+		(gld${EMULATION_NAME}_get_script): This.
+		(LDEMUL_AFTER_PARSE): New.
+		(LDEMUL_AFTER_OPEN): Likewise.
+		(LDEMUL_BEFORE_ALLOCATION): Likewise.
+		(LDEMUL_FINISH=): Likewise.
+		(LDEMUL_OPEN_DYNAMIC_ARCHIVE): Likewise.
+		(LDEMUL_PLACE_ORPHAN): Likewise.
+		(LDEMUL_SET_SYMBOLS): Likewise.
+		(LDEMUL_ADD_OPTIONS): Likewise.
+		(LDEMUL_HANDLE_OPTION): Likewise.
+		(LDEMUL_UNRECOGNIZED_FILE): Likewise.
+		(LDEMUL_LIST_OPTIONS): Likewise.
+		(LDEMUL_RECOGNIZED_FILE): Likewise.
+		(LDEMUL_FIND_POTENTIAL_LIBRARIES): Likewise.
+		(ld_${EMULATION_NAME}_emulation): Removed.
+		Source ${srcdir}/emultempl/emulation.em.
+		* emultempl/ticoff.em (gld_${EMULATION_NAME}_list_options):
+		Renamed to ...
+		(gld${EMULATION_NAME}_list_options): This.
+		(gld_${EMULATION_NAME}_before_parse): Renamed to ...
+		(gld_${EMULATION_NAME}_get_script): Renamed to ...
+		(gld${EMULATION_NAME}_get_script): This.
+		(LDEMUL_ADD_OPTIONS): New.
+		(LDEMUL_HANDLE_OPTION): Likewise.
+		(LDEMUL_LIST_OPTIONS): Likewise.
+		(ld_${EMULATION_NAME}_emulation): Removed.
+		Source ${srcdir}/emultempl/emulation.em.
+		* emultempl/vanilla.em (LDEMUL_BEFORE_PARSE): New.
+		(LDEMUL_SET_OUTPUT_ARCH): Likewise.
+		(LDEMUL_GET_SCRIPT): Likewise.
+		(EMULATION_NAME): Likewise.
+		(OUTPUT_FORMAT): Likewise.
+		(ld_vanilla_emulation): Removed.
+		Source ${srcdir}/emultempl/emulation.em.
+
+2022-02-06  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/doc: update docs for 'info win' and 'winheight' commands
+	This started by noticing that the docs for 'winheight' are out of
+	date, the docs currently give a specific list of possible window
+	names.  However, now that windows can be implemented in Python, it is
+	not possible to list all possible names.
+
+	I now link the user to a mechanism by which they can discover the
+	valid names for themselves at run time (by using 'info win').  That,
+	and the fact that gdb provides tab-completion of the name at the
+	command line, feels good enough.
+
+	Finally, I noticed that the docs for 'win info' don't explicitly say
+	that the name of the window is given in the output.  This could
+	probably have been inferred, but given I'm now linking to this as a
+	mechanism to find the window name, I'd prefer to mention that the name
+	can be found in the output.
+
+2022-02-06  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/tui: add window width information to 'info win' output
+	Now that we support horizontal window placement in the tui, it makes
+	sense to have 'info win' include the width, as well as the height, of
+	the currently visible windows.
+
+	That's what this commit does.  Example output is now:
+
+	  (gdb) info win
+	  Name       Lines Columns Focus
+	  src           12      40 (has focus)
+	  asm           12      41
+	  status         1      80
+	  cmd           11      80
+
+	I've added a NEWS entry, but the documentation was already suitably
+	vague, it just says that 'info win' displays the size of the visible
+	windows, so I don't think anything needs to be added there.
+
+	I've also added some tests, as far as I could find, the 'info win'
+	command was previously untested.
+
+2022-02-06  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-05  H.J. Lu  <hjl.tools@gmail.com>
+
+	x86: Skip undefined symbol when finishing DT_RELR
+	Don't abort for undefined symbol when finishing DT_RELR.  Instead, skip
+	undefined symbol.  Undefined symbol will be reported by relocate_section.
+
+		* elfxx-x86.c (elf_x86_size_or_finish_relative_reloc): Skip
+		undefined symbol in finishing phase.
+
+2022-02-05  Alan Modra  <amodra@gmail.com>
+
+	Tweak assembler invocation for pr28827-1 test
+		PR 28827
+		* testsuite/ld-powerpc/pr28827-1.d: Pass -a64 to gas.
+
+2022-02-05  Alan Modra  <amodra@gmail.com>
+
+	PR28827 testcase
+	This testcase triggers a stub sizing error with the patches applied
+	for PR28743 (commit 2f83249c13d8 and c804c6f98d34).
+
+		PR 28827
+		* testsuite/ld-powerpc/pr28827-1.s,
+		* testsuite/ld-powerpc/pr28827-1.d: New test.
+		* testsuite/ld-powerpc/powerpc.exp: Run it.
+
+2022-02-05  Alan Modra  <amodra@gmail.com>
+
+	Enable "size" as a dumpprog in ld
+	binutils/
+		* testsuite/lib/binutils-common.exp (run_dump_test): Reference
+		global SIZE and SIZEFLAGS.
+	ld/
+		* testsuite/config/default.exp: Define SIZE and SIZEFLAGS.
+
+2022-02-05  Alan Modra  <amodra@gmail.com>
+
+	Detect .eh_frame_hdr earlier for SIZEOF_HEADERS
+	Current code detects the need for PT_GNU_EH_FRAME using a field set by
+	_bfd_elf_discard_section_eh_frame_hdr, which is called fairly late in
+	the linking process.  Use the elf hash table eh_info instead, which is
+	set up earlier by size_dynamic_sections.
+
+		* elf-bfd.h (struct output_elf_obj_tdata): Delete eh_frame_hdr.
+		(elf_eh_frame_hdr): Don't define.
+		(_bfd_elf_discard_section_eh_frame_hdr): Update prototype.
+		* elf-eh-frame.c (_bfd_elf_discard_section_eh_frame_hdr): Delete
+		abfd parameter.  Don't set elf_eh_frame_hdr.
+		* elf.c (elf_eh_frame_hdr): New function.
+		(get_program_header_size): Adjust elf_eh_frame_hdr call.
+		(_bfd_elf_map_sections_to_segments): Likewise.
+
+2022-02-05  Faraz Shahbazker  <fshahbazker@wavecomp.com>
+
+	sim: mips: Add simulator support for mips32r6/mips64r6
+	2022-02-01  Ali Lown  <ali.lown@imgtec.com>
+		    Andrew Bennett  <andrew.bennett@imgtec.com>
+		    Dragan Mladjenovic  <dragan.mladjenovic@rt-rk.com>
+		    Faraz Shahbazker  <fshahbazker@wavecomp.com>
+
+	sim/common/ChangeLog:
+		* sim-bits.h (EXTEND9, EXTEND18 ,EXTEND19, EXTEND21,
+		EXTEND26): New macros.
+
+	sim/mips/ChangeLog:
+		* Makefile.in (IGEN_INCLUDE): Add mips3264r6.igen.
+		* configure: Regenerate.
+		* configure.ac: Support mipsisa32r6 and mipsisa64r6.
+		(sim_engine_run): Pick simulator model from processor specified
+		in e_flags.
+		* cp1.c (value_fpr): Handle fmt_dc32.
+		(fp_unary, fp_binary): Zero initialize locals.
+		(update_fcsr, fp_classify, fp_rint, fp_r6_cmp, inner_fmac,
+		fp_fmac, fp_min, fp_max, fp_mina, fp_maxa, fp_fmadd, fp_fmsub):
+		New functions.
+		(sim_fpu_class_mips_mapping): New.
+		* cp1.h (fcsr_ABS2008_mask, fcsr_ABS2008_shift): New define.
+		* interp.c (MIPSR6_P): New.
+		(load_word): Allow unaligned memory access for MIPSR6.
+		* micromips.igen (sc, scd): Adapt to new do_sc* helper signature.
+		* mips.igen: Add *r6 models.
+		(signal_if_cti, forbiddenslot32): New helpers.
+		(delayslot32): Use signal_if_cti.
+		(do_sc, do_scd); Add store_ll_bit parameter.
+		(sc, scd): Adapt to previous change.
+		(nal, beq, bal): New definitions for *r6.
+		(sll): Split nop and ssnop cases into ...
+		(nop, ssnop): New definitions.
+		(loadstore_ea): Use the 32-bit compatibility adressing.
+		(cache): Split logic into ...
+		(do_cache): New helper.
+		(check_fpu): Select IEEE 754-2008 mode for R6.
+		(not_word_value, unpredictable, check_mt_hilo, check_mf_hilo,
+		check_multi_hilo, check_div_hilo, check_u64, do_dmfc1b, add,
+		li, addu, and, andi, bgez, bgtz, blez, bltz, bne, break, dadd,
+		daddiu, daddu, dror, dror32, drorv, dsll, dsll32, dsllv, dsra,
+		dsra32, dsrav, dsrl, dsrl32, dsub, dsubu, j, jal, jalr,
+		jalr.hb, lb, lbu, ld, lh, lhu, lui, lw, lwu, nor, or, ori, ror,
+		rorv, sb, sd, sh, sll, sllv, slt, slti, sltiu, sltu, sra, srav,
+		srl, srlv, sub, subu, sw, sync, syscall, teq, tge, tgeu, tlt,
+		tltu, tne, xor, xori, check_fmt_p, do_load_double,
+		do_store_double, abs.FMT, add.FMT, ceil.l.FMT, ceil.w.FMT,
+		cfc1, ctc1, cvt.d.FMT, cvt.l.FMT, cvt.w.FMT, div.FMT, dfmc1,
+		dmtc1, floor.l.FMT, floor.w.FMT, ldc1, lwc1, mfc1, mov.FMT,
+		mtc1, mul.FMT, recip.FMT, round.l.FMT, round.w.FMT, rsqrt.FMT,
+		sdc1, sqrt.FMT, sub.FMT, swc1, trunc.l.FMT, trunc.w.FMT, bc0f,
+		bc0fl, bc0t, bc0tl, dmfc0, dmtc0, eret, mfc0, mtc0, cop, tlbp,
+		tlbr, tlbwi, tlbwr): Enable on *r6 models.
+		* mips3264r2.igen (dext, dextm, dextu, di, dins, dinsm, dinsu,
+		dsbh, dshd, ei, ext, mfhc1, mthc1, ins, seb, seh, synci, rdhwr,
+		wsbh): Likewise.
+		* mips3264r6.igen: New file.
+		* sim-main.h (FP_formats): Add fmt_dc32.
+		(FORBIDDEN_SLOT): New macros.
+		(simFORBIDDENSLOT, FP_R6CMP_*, FP_R6CLASS_*): New defines.
+		(fp_r6_cmp, fp_classify, fp_rint, fp_min, fp_max, fp_mina,
+		fp_maxa, fp_fmadd, fp_fmsub): New declarations.
+		(R6Compare, Classify, RoundToIntegralExact, Min, Max, MinA,
+		MaxA, FusedMultiplyAdd, FusedMultiplySub): New macros. Wrapping
+		previous declarations.
+
+	sim/testsuite/mips/ChangeLog:
+		* basic.exp: Add r6-*.s tests.
+		(run_r6_removed_test): New function.
+		(run_endian_tests): New function.
+		* hilo-hazard-3.s: Skip for mips*r6.
+		* r2-fpu.s: New test.
+		* r6-64.s: New test.
+		* r6-branch.s: New test.
+		* r6-forbidden.s: New test.
+		* r6-fpu.s: New test.
+		* r6-llsc-dp.s: New test.
+		* r6-llsc-wp.s: New test.
+		* r6-removed.csv: New test.
+		* r6-removed.s: New test.
+		* r6.s: New test.
+		* utils-r6.inc: New inc.
+
+2022-02-05  Faraz Shahbazker  <fshahbazker@wavecomp.com>
+
+	sim: Add partial support for IEEE 754-2008
+	2022-02-01  Faraz Shahbazker  <fshahbazker@wavecomp.com>
+
+	sim/common/ChangeLog:
+		* sim-fpu.c (sim_fpu_minmax_nan): New.
+		(sim_fpu_max): Add variant behaviour for IEEE 754-2008.
+		(sim_fpu_min): Likewise.
+		(sim_fpu_is_un, sim_fpu_is_or): New.
+		(sim_fpu_un, sim_fpu_or): New.
+		(sim_fpu_is_ieee754_2008, sim_fpu_is_ieee754_1985): New.
+		(sim_fpu_set_mode): New.
+		(sim_fpu_classify): New.
+		* sim-fpu.h (sim_fpu_minmax_nan): New declaration.
+		(sim_fpu_un, sim_fpu_or): New declarations.
+		(sim_fpu_is_un, sim_fpu_is_or): New declarations.
+		(sim_fpu_mode): New enum.
+		[sim_fpu_state](current_mode): New field.
+		(sim_fpu_current_mode): New define.
+		(sim_fpu_is_ieee754_2008): New declaration.
+		(sim_fpu_is_ieee754_1985): New declaration.
+		(sim_fpu_set_mode): New declaration.
+		(sim_fpu_classify): New declaration.
+
+2022-02-05  Faraz Shahbazker  <fshahbazker@wavecomp.com>
+
+	sim: Factor out NaN handling in floating point operations
+	2022-02-01  Faraz Shahbazker  <fshahbazker@wavecomp.com>
+
+	sim/common/ChangeLog:
+		* sim-fpu.c (sim_fpu_op_nan): New.
+		(sim_fpu_add): Factor out NaN operand handling with
+		a call to sim_fpu_op_nan.
+		(sim_fpu_sub, sim_fpu_mul, sim_fpu_div): Likewise.
+		(sim_fpu_rem, sim_fpu_max, sim_fpu_min): Likewise.
+		* sim-fpu.h (sim_fpu_op_nan): New declaration.
+
+2022-02-05  Faraz Shahbazker  <fshahbazker@wavecomp.com>
+
+	sim: Allow toggling of quiet NaN-bit semantics
+	IEEE754-1985 specifies the top bit of the mantissa as an indicator
+	of signalling vs. quiet NaN, but does not define the precise semantics.
+	Most architectures treat this bit as indicating quiet NaN, but legacy
+	(pre-R6) MIPS goes the other way and treats it as signalling NaN.
+
+	This used to be controlled by a macro that was only defined for MIPS.
+	This patch replaces the macro with a variable to track the current
+	semantics of the NaN bit and allows differentiation between older
+	(pre-R6) and and newer MIPS cores.
+
+	2022-02-01  Faraz Shahbazker  <fshahbazker@wavecomp.com>
+
+	sim/common/ChangeLog:
+		* sim-fpu.c (_sim_fpu): New.
+		(pack_fpu, unpack_fpu): Allow reversal of quiet NaN semantics.
+		* sim-fpu.h (sim_fpu_state): New struct.
+		(_sim_fpu): New extern.
+		(sim_fpu_quiet_nan_inverted): New define.
+
+	sim/mips/ChangeLog:
+		* cp1.h (fcsr_NAN2008_mask, fcsr_NAN2008_shift): New.
+		* mips.igen (check_fpu): Select default quiet NaN mode
+		for legacy MIPS.
+		* sim-main.h (SIM_QUIET_NAN_NEGATED): Remove.
+
+2022-02-05  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-04  H.J. Lu  <hjl.tools@gmail.com>
+
+	ld: Remove emultempl/armcoff.em
+	Remove emultempl/armcoff.em which has been unused after
+
+	commit 2ac93be706418f3b2aebeb22159a328023faed52
+	Author: Alan Modra <amodra@gmail.com>
+	Date:   Mon Apr 16 20:33:36 2018 +0930
+
+	    Remove arm-aout and arm-coff support
+
+	    This also removes arm-netbsd (not arm-netbsdelf!), arm-openbsd, and
+	    arm-riscix.  Those targets weren't on the obsolete list but they are
+	    all aout, and it doesn't make all that much sense to remove arm-aout
+	    without removing them too.
+
+		* emultempl/armcoff.em: Removed.
+
+2022-02-04  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: include jit_code_entry::symfile_addr value in names of objfiles created by jit reader API
+	This commit includes the JIT object's symfile address in the names of
+	objfiles created by JIT reader API (e.g., << JIT compiled code at
+	0x7ffd8a0c77a0 >>).  This allows one to at least differentiate one from
+	another.
+
+	The address is the one that the debugged program has put in
+	jit_code_entry::symfile_addr, and that the JIT reader's read function
+	receives.  As we can see in gdb.base/jit-reader-host.c and
+	gdb.base/jit-reader.c, that may not be the actual value of where the
+	JIT-ed code is.  But it is a value chosen by the author of the JIT
+	engine and the JIT reader, so including this value in the objfile name
+	may help them correlate the JIT objfiles created by with their logs /
+	data structures.
+
+	To access this field, we need to pass down a reference to the
+	jit_code_entry.  So make jit_dbg_reader_data a structure (instead of an
+	alias for a CORE_ADDR) that includes the address of the code entry in
+	the inferior's address space (the previous meaning of
+	jit_dbg_reader_data) plus a reference to the jit_code_entry as read into
+	GDB's address space.  And while at it, pass down the gdbarch, so that we
+	don't have to call target_gdbarch.
+
+	Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
+	Change-Id: Ib26c4d1bd8de503d651aff89ad2e500cb312afa5
+
+2022-02-04  Tom Tromey  <tromey@adacore.com>
+
+	Improve Ada unchecked union type printing
+	Currently, "ptype" of an Ada unchecked union may show a
+	compiler-generated wrapper structure in its output.  It's more
+	Ada-like to elide this structure, which is what this patch implements.
+	It turned out to be simplest to reuse a part of print_variant_clauses
+	for this.
+
+	As this is Ada-specific, and Joel already reviewed it internally, I am
+	going to check it in.
+
+2022-02-04  Tom Tromey  <tromey@adacore.com>
+
+	Remove host_hex_value
+	I noticed that host_hex_value is redundant, because gdbsupport already
+	has fromhex.  This patch removes the former in favor of the latter.
+
+	Regression tested on x86-64 Fedora 34.
+
+2022-02-04  Andi Kleen  <andi@firstfloor.org>
+
+	Support symbol+offset lookup in addr2line
+	The Linux kernel usually ouputs symbol+offset instead of plain code
+	addresses these days, to avoid leaking ASLR secrets and to handle
+	dynamically loaded modules.
+
+	Converting those with addr2line is somewhat involved: it requires
+	looking up the symbol first using nm and then manually compute the
+	offset, and then pass it to addr2line.
+
+	This patch implements the necessary steps directly in addr2line,
+	by looking up the symbol (with demangling if needed) and computing
+	the offset.
+
+	It's possible that a symbol is ambigious with a hex number. In this
+	case it uses the symbol lookup if the string contains a +. When it isn't
+	ambigious the + is optional.
+
+2022-02-04  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-03  Cary Coutant  <ccoutant@gmail.com>
+
+	Rename EM_56800V4 to EM_56800EF.
+	include/elf:
+		* common.h: Rename EM_56800V4 to EM_56800EF.
+
+2022-02-03  H.J. Lu  <hjl.tools@gmail.com>
+
+	x86: Update X86_64_GOT_TYPE_P to cover more GOT relocations
+	Add R_X86_64_GOT32, R_X86_64_GOT64, R_X86_64_GOTPCREL64 and
+	R_X86_64_GOTPLT64 to X86_64_GOT_TYPE_P to cover more GOT relocations.
+
+		PR ld/28858
+		* elfxx-x86.h (X86_64_GOT_TYPE_P): Add R_X86_64_GOT32,
+		R_X86_64_GOT64, R_X86_64_GOTPCREL64 and R_X86_64_GOTPLT64.
+
+2022-02-03  Cary Coutant  <ccoutant@gmail.com>
+
+	Add new e_machine values.
+	include/elf:
+		* common.h: Add EM_U16_U8CORE, EM_TACHYUM, EM_56800V4.
+
+2022-02-03  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>
+
+	testsuite: fix failure in gdb.threads/killed-outside.exp
+	Starting with commit
+
+	  commit 1da5d0e664e362857153af8682321a89ebafb7f6
+	  Date:   Tue Jan 4 08:02:24 2022 -0700
+
+	    Change how Python architecture and language are handled
+
+	we see a failure in gdb.threads/killed-outside.exp:
+
+	  ...
+	  Executing on target: kill -9 16622    (timeout = 300)
+	  builtin_spawn -ignore SIGHUP kill -9 16622
+	  continue
+	  Continuing.
+	  Couldn't get registers: No such process.
+	  (gdb) [Thread 0x7ffff77c2700 (LWP 16626) exited]
+
+	  Program terminated with signal SIGKILL, Killed.
+	  The program no longer exists.
+	  FAIL: gdb.threads/killed-outside.exp: prompt after first continue (timeout)
+
+	This is not a regression but a failure due to a change in GDB's
+	output.  Prior to the aforementioned commit, GDB has been printing the
+	"Couldn't get registers: No such process." message twice.  The second
+	one came from
+
+	  (top-gdb) bt
+	  #0  amd64_linux_nat_target::fetch_registers (this=0x555557f31440 <the_amd64_linux_nat_target>, regcache=0x555558805ce0, regnum=16) at /gdb-up/gdb/amd64-linux-nat.c:225
+	  #1  0x000055555640ac5f in target_ops::fetch_registers (this=0x555557d636d0 <the_thread_db_target>, arg0=0x555558805ce0, arg1=16) at /gdb-up/gdb/target-delegates.c:502
+	  #2  0x000055555641a647 in target_fetch_registers (regcache=0x555558805ce0, regno=16) at /gdb-up/gdb/target.c:3945
+	  #3  0x0000555556278e68 in regcache::raw_update (this=0x555558805ce0, regnum=16) at /gdb-up/gdb/regcache.c:587
+	  #4  0x0000555556278f14 in readable_regcache::raw_read (this=0x555558805ce0, regnum=16, buf=0x555558881950 "") at /gdb-up/gdb/regcache.c:601
+	  #5  0x00005555562792aa in readable_regcache::cooked_read (this=0x555558805ce0, regnum=16, buf=0x555558881950 "") at /gdb-up/gdb/regcache.c:690
+	  #6  0x000055555627965e in readable_regcache::cooked_read_value (this=0x555558805ce0, regnum=16) at /gdb-up/gdb/regcache.c:748
+	  #7  0x0000555556352a37 in sentinel_frame_prev_register (this_frame=0x555558181090, this_prologue_cache=0x5555581810a8, regnum=16) at /gdb-up/gdb/sentinel-frame.c:53
+	  #8  0x0000555555fa4773 in frame_unwind_register_value (next_frame=0x555558181090, regnum=16) at /gdb-up/gdb/frame.c:1235
+	  #9  0x0000555555fa420d in frame_register_unwind (next_frame=0x555558181090, regnum=16, optimizedp=0x7fffffffd570, unavailablep=0x7fffffffd574, lvalp=0x7fffffffd57c, addrp=0x7fffffffd580,
+	      realnump=0x7fffffffd578, bufferp=0x7fffffffd5b0 "") at /gdb-up/gdb/frame.c:1143
+	  #10 0x0000555555fa455f in frame_unwind_register (next_frame=0x555558181090, regnum=16, buf=0x7fffffffd5b0 "") at /gdb-up/gdb/frame.c:1199
+	  #11 0x00005555560178e2 in i386_unwind_pc (gdbarch=0x5555587c4a70, next_frame=0x555558181090) at /gdb-up/gdb/i386-tdep.c:1972
+	  #12 0x0000555555cd2b9d in gdbarch_unwind_pc (gdbarch=0x5555587c4a70, next_frame=0x555558181090) at /gdb-up/gdb/gdbarch.c:3007
+	  #13 0x0000555555fa3a5b in frame_unwind_pc (this_frame=0x555558181090) at /gdb-up/gdb/frame.c:948
+	  #14 0x0000555555fa7621 in get_frame_pc (frame=0x555558181160) at /gdb-up/gdb/frame.c:2572
+	  #15 0x0000555555fa7706 in get_frame_address_in_block (this_frame=0x555558181160) at /gdb-up/gdb/frame.c:2602
+	  #16 0x0000555555fa77d0 in get_frame_address_in_block_if_available (this_frame=0x555558181160, pc=0x7fffffffd708) at /gdb-up/gdb/frame.c:2665
+	  #17 0x0000555555fa5f8d in select_frame (fi=0x555558181160) at /gdb-up/gdb/frame.c:1890
+	  #18 0x0000555555fa5bab in lookup_selected_frame (a_frame_id=..., frame_level=-1) at /gdb-up/gdb/frame.c:1720
+	  #19 0x0000555555fa5e47 in get_selected_frame (message=0x0) at /gdb-up/gdb/frame.c:1810
+	  #20 0x0000555555cc9c6e in get_current_arch () at /gdb-up/gdb/arch-utils.c:848
+	  #21 0x000055555625b239 in gdbpy_before_prompt_hook (extlang=0x555557451f20 <extension_language_python>, current_gdb_prompt=0x555557f4d890 <top_prompt+16> "(gdb) ")
+	      at /gdb-up/gdb/python/python.c:1063
+	  #22 0x0000555555f7cfbb in ext_lang_before_prompt (current_gdb_prompt=0x555557f4d890 <top_prompt+16> "(gdb) ") at /gdb-up/gdb/extension.c:922
+	  #23 0x0000555555f7d442 in std::_Function_handler<void (char const*), void (*)(char const*)>::_M_invoke(std::_Any_data const&, char const*&&) (__functor=...,
+	      __args#0=@0x7fffffffd900: 0x555557f4d890 <top_prompt+16> "(gdb) ") at /usr/include/c++/7/bits/std_function.h:316
+	  #24 0x0000555555f752dd in std::function<void (char const*)>::operator()(char const*) const (this=0x55555817d838, __args#0=0x555557f4d890 <top_prompt+16> "(gdb) ")
+	      at /usr/include/c++/7/bits/std_function.h:706
+	  #25 0x0000555555f75100 in gdb::observers::observable<char const*>::notify (this=0x555557f49060 <gdb::observers::before_prompt>, args#0=0x555557f4d890 <top_prompt+16> "(gdb) ")
+	      at /gdb-up/gdb/../gdbsupport/observable.h:150
+	  #26 0x0000555555f736dc in top_level_prompt () at /gdb-up/gdb/event-top.c:444
+	  #27 0x0000555555f735ba in display_gdb_prompt (new_prompt=0x0) at /gdb-up/gdb/event-top.c:411
+	  #28 0x00005555564611a7 in tui_on_command_error () at /gdb-up/gdb/tui/tui-interp.c:205
+	  #29 0x0000555555c2173f in std::_Function_handler<void (), void (*)()>::_M_invoke(std::_Any_data const&) (__functor=...) at /usr/include/c++/7/bits/std_function.h:316
+	  #30 0x0000555555e10c20 in std::function<void ()>::operator()() const (this=0x5555580f9028) at /usr/include/c++/7/bits/std_function.h:706
+	  #31 0x0000555555e10973 in gdb::observers::observable<>::notify() const (this=0x555557f48d20 <gdb::observers::command_error>) at /gdb-up/gdb/../gdbsupport/observable.h:150
+	  #32 0x00005555560e9b3f in start_event_loop () at /gdb-up/gdb/main.c:438
+	  #33 0x00005555560e9bcc in captured_command_loop () at /gdb-up/gdb/main.c:481
+	  #34 0x00005555560eb616 in captured_main (data=0x7fffffffddd0) at /gdb-up/gdb/main.c:1348
+	  #35 0x00005555560eb67c in gdb_main (args=0x7fffffffddd0) at /gdb-up/gdb/main.c:1363
+	  #36 0x0000555555c1b6b3 in main (argc=12, argv=0x7fffffffded8) at /gdb-up/gdb/gdb.c:32
+
+	Commit 1da5d0e664 eliminated the call to 'get_current_arch'
+	in 'gdbpy_before_prompt_hook'.  Hence, the second instance of
+	"Couldn't get registers: No such process." does not appear anymore.
+
+	Fix the failure by updating the regular expression in the test.
+
+2022-02-03  Alan Modra  <amodra@gmail.com>
+
+	PowerPC64 treatment of absolute symbols
+	Supporting -static-pie on PowerPC64 requires the linker to properly
+	treat SHN_ABS symbols for cases like glibc's _nl_current_LC_CTYPE_used
+	absolute symbol.  I've been slow to fix the linker on powerpc because
+	there is some chance that this will break some shared libraries or
+	PIEs.
+
+	bfd/
+		* elf64-ppc.c (ppc64_elf_check_relocs): Consolidate local sym
+		handling code.  Don't count dyn relocs against non-dynamic
+		absolute symbols.
+		(dec_dynrel_count): Adjust to suit.
+		(ppc64_elf_edit_toc): Don't remove entries for absolute symbols
+		when pic.
+		(allocate_got): Don't allocate space for got relocs against
+		non-dynamic absolute syms.
+		(ppc64_elf_layout_multitoc): Likewise.
+		(got_and_plt_relr): Likewise.
+		(ppc64_elf_size_dynamic_sections): Likewise for local got.
+		(got_and_plt_relr_for_local_syms): Likewise.
+		(ppc64_elf_size_stubs): Don't allocate space for relr either.
+		(ppc64_elf_relocate_section): Don't write relocs against non-dynamic
+		absolute symbols.  Don't optimise got and toc code sequences
+		loading absolute symbol entries.
+	ld/
+		* testsuite/ld-powerpc/abs-reloc.s,
+		* testsuite/ld-powerpc/abs-static.d,
+		* testsuite/ld-powerpc/abs-static.r,
+		* testsuite/ld-powerpc/abs-pie.d,
+		* testsuite/ld-powerpc/abs-pie.r,
+		* testsuite/ld-powerpc/abs-shared.d,
+		* testsuite/ld-powerpc/abs-shared.r,
+		* testsuite/ld-powerpc/abs-pie-relr.d,
+		* testsuite/ld-powerpc/abs-pie-relr.r,
+		* testsuite/ld-powerpc/abs-shared-relr.d,
+		* testsuite/ld-powerpc/abs-shared-relr.r: New tests.
+		* testsuite/ld-powerpc/powerpc.exp: Run them.
+
+2022-02-03  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-02  Nick Clifton  <nickc@redhat.com>
+
+	Stop the BFD library complaining about compressed dwarf debug string sections being too big.
+		PR 28834
+		* dwarf2.c (read_section): Change the heuristic that checks for
+		overlarge dwarf debug info sections.
+
+2022-02-02  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: fix formatting for help set/show extended-prompt
+	The formatting of the help text for 'help set extended-prompt' and
+	'help show extended-prompt' is a little off.
+
+	Here's the offending snippet:
+
+	    Substitutions are applied to VALUE to compute the real prompt.
+
+	    The currently defined substitutions are:
+	      \[	Begins a sequence of non-printing characters.
+	  \\	A backslash.
+	  \]	Ends a sequence of non-printing characters.
+	  \e	The ESC character.
+
+	Notice that the line for '\[' is indented more that the others.
+
+	Turns out this is due to how we build this help text, something which
+	is done in Python.  We extended a classes __doc__ string with some
+	dynamically generated text.
+
+	The classes doc string looks like this:
+
+	    """Set the extended prompt.
+
+	    Usage: set extended-prompt VALUE
+
+	    Substitutions are applied to VALUE to compute the real prompt.
+
+	    The currently defined substitutions are:
+	    """
+
+	Notice the closing """ are in a line of their own, and include some
+	white space just before.  It's this extra white space that's causing
+	the problem.
+
+	Fix the formatting issue by moving the """ to the end of the previous
+	line.  I then add the extra newline in at the point where the doc
+	string is merged with the dynamically generated text.
+
+	Now everything lines up correctly.
+
+2022-02-02  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: test to check one aspect of the linespec parsing code
+	While working on the fix for PR cli/28665 (see previous couple of
+	commits), I was playing with making a change in the linespec parsing
+	code.  Specifically, I was thinking about whether the spec_string for
+	LINESPEC_LOCATION locations should ever be nullptr.
+
+	I made a change to prevent the spec_string from ever being nullptr,
+	tested gdb, and saw no regressions.
+
+	However, as part of this work I was reviewing how the breakpoint code
+	handles this case (spec_string being nullptr), and spotted that in
+	parse_breakpoint_sals the nullptr case is specifically handled, so
+	changing this should have caused a regression.  But I didn't see one.
+
+	So, this commit adds a comment in location.c mentioning that the
+	nullptr case is (a) not an oversight, and (b) is required.  Then I add
+	a new test to gdb.base/break.exp that ensures a change in this area
+	will cause a regression.
+
+	This test passes on current gdb, but with my modified (and broken)
+	gdb, the test would fail.
+
+2022-02-02  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: handle calls to edit command passing only a linespec condition
+	While working on the previous commit to fix PR cli/28665, I noticed
+	that the 'edit' command would suffer from the same problem.  That is,
+	something like:
+
+	  (gdb) edit task 123
+
+	would cause GDB to break.  For a full explanation of what's going on
+	here, see the commit message for the previous commit.
+
+	As with the previous commit, this issue can be prevented by detecting,
+	and throwing, a junk at the end of the line error earlier, before
+	calling decode_line_1.
+
+	So, that's what this commit does.  I've also added some tests for this
+	issue.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28665
+
+2022-02-02  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: handle calls to list command passing only a linespec condition
+	In PR cli/28665, it was reported that GDB would crash when given a
+	command like:
+
+	  (gdb) list task 123
+
+	The problem here is that in cli/cli-cmd.c:list_command, the string
+	'task 123' is passed to string_to_event_location in find a location
+	specification.  However, this location parsing understands about
+	breakpoint conditions, and so, will stop parsing when it sees
+	something that looks like a condition, in this case, the 'task 123'
+	looks like a breakpoint condition.
+
+	As a result, the location we get back from string_to_event_location
+	has no actual location specification attached to it.  The actual call
+	path is:
+
+	  list_command
+	    string_to_event_location
+	      string_to_event_location_basic
+	        new_linespec_location
+
+	In new_linespec_location we call linespec_lex_to_end, which looks at
+	'task 123' and decides that there's nothing there that describes a
+	location.  As such, in new_linespec_location, the spec_string field of
+	the location is left as nullptr.
+
+	Back in list_command we then call decode_line_1, which calls
+	event_location_to_sals, which calls parse_linespec, which takes the
+	spec_string we found earlier, and tries to converts this into a list
+	of sals.
+
+	However, parse_linespec is not intended to be passed a nullptr, for
+	example, calling is_ada_operator will try to access through the
+	nullptr, causing undefined behaviour.  But there are other cases
+	within parse_linespec which don't expect to see a nullptr.
+
+	When looking at how to fix this issue, I first considered having
+	linespec_lex_to_end detect the problem.  That function understands
+	when the first thing in the linespec is a condition keyword, and so,
+	could throw an error saying something like: "no linespec before
+	condition keyword", however, this is not going to work, at least, not
+	without additional changes to GDB, it is valid to place a breakpoint
+	like:
+
+	  (gdb) break task 123
+
+	This will place a breakpoint at the current location with the
+	condition 'task 123', and changing linespec_lex_to_end breaks this
+	behaviour.
+
+	So, next, I considered what would happen if I added a condition to an
+	otherwise valid list command, this is what I see:
+
+	  (gdb) list file.c:1 task 123
+	  Junk at end of line specification.
+	  (gdb)
+
+	So, then I wondered, could we just pull the "Junk" detection forward,
+	so that we throw the error earlier, before we call decode_line_1?
+
+	It turns out that yes we can.  Well, sort of.
+
+	It is simpler, I think, to add a separate check into the list_command
+	function, after calling string_to_event_location, but before calling
+	decode_line_1.  We know when we call string_to_event_location that the
+	string in question is not empty, so, after calling
+	string_to_event_location, if non of the string has been consumed, then
+	the content of the string must be junk - it clearly doesn't look like
+	a location specification.
+
+	I've reused the same "Junk at end of line specification." error for
+	consistency, and added a few tests to cover this issue.
+
+	While the first version of this patch was on the mailing list, a
+	second bug PR gdb/28797 was raised.  This was for a very similar
+	issue, but this time the problem command was:
+
+	  (gdb) list ,,
+
+	Here the list command understands about the first comma, list can have
+	two arguments separated by a comma, and the first argument can be
+	missing.  So we end up trying to parse the second command "," as a
+	linespec.
+
+	However, in linespec_lex_to_end, we will stop parsing a linespec at a
+	comma, so, in the above case we end up with an empty linespec (between
+	the two commas), and, like above, this results in the spec_string
+	being nullptr.
+
+	As with the previous case, I've resolved this issue by adding an extra
+	check for junk at the end of the line - after parsing (or failing to
+	parse) the nothing between the two commas, we still have the "," left
+	at the end of the list command line - when we see this we can throw
+	the same "junk at the end of the line" error, and all is good.
+
+	I've added tests for this case too.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28665
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28797
+
+2022-02-02  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: move linespec test into gdb.linespec/ directory
+	The gdb.base/linespecs.exp test should really live in the gdb.linespec
+	directory, so lets move it there.
+
+	As we already have gdb.linespec/linespec.exp, I've renamed the test to
+	gdb.linespec/errors.exp, as this better reflects what the test is
+	actually checking.
+
+	Finally, the test script doesn't have its own source file, it was
+	reusing a random other source file, gdb.base/memattr.c.  Now the tests
+	script is in gdb.linespec/, I've updated the test to use a different
+	source file from that directory.
+
+2022-02-02  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: add empty string check in parse_linespec
+	If parse_linespec (linespec.c) is passed ARG as an empty string then
+	we end up calling `strchr (linespec_quote_characters, '\0')`, which
+	will return a pointer to the '\0' at the end of
+	linespec_quote_characters.  This then results in GDB calling
+	skip_quote_char with `ARG + 1`, which is undefined behaviour (as ARG
+	only contained a single character, the '\0').
+
+	Fix this by checking for the first character of ARG being '\0' before
+	the call to strchr.
+
+	I have additionally added an assertion that ARG can't itself be
+	nullptr, as calling is_ada_operator with nullptr can end up calling
+	'startswith' on the nullptr, which is undefined behaviour.
+
+	Finally, I moved the declaration of TOKEN into the body of
+	parse_linespec, to where TOKEN is defined.
+
+	This patch came about while I was working on fixes for PR cli/28665
+	and PR gdb/28797.  The actual fixes for these two issues will be in a
+	later commit in this series, but, with this patch in place, both of
+	the above bugs would hit the new assertion rather than accessing
+	invalid memory and crashing.  The '\0' check is not currently ever
+	hit, but just makes the code a little safer.
+
+	Because this patch only changes the nature of the failure for the
+	above two bugs, there's no tests here.  A later commit will fix the
+	above two issues, at which point I'll add some tests.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28665
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28797
+
+2022-02-02  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: update the comment on string_to_event_location
+	The comment on string_to_event_location is (I believe) out of date.
+	This commit fixes the two issues I see:
+
+	  1. This function can't return NULL any more.  The implementation
+	  calls string_to_explicit_location which can return NULL, but if this
+	  is the case we then call string_to_event_location_basic, which I
+	  don't believe can ever return NULL.
+
+	  2. I've removed the mention that the returned string is malloc'd,
+	  though this is true, now that we return a managed pointer, I believe
+	  the source of the memory allocation is irrelevant, and so, shouldn't
+	  be discussed in the header comment.
+
+	There should be no user visible changes after this commit.
+
+2022-02-02  Nick Clifton  <nickc@redhat.com>
+
+	Updated French translation for the ld/ and gold/ sub-directories
+
+2022-02-02  Stafford Horne  <shorne@gmail.com>
+
+	or1k: Avoid R_OR1K_GOT16 signed overflow by using special howto
+	Previously when fixing PR 21464 we masked out upper bits of the
+	relocation value in order to avoid overflow complaints when acceptable.
+	It turns out this does not work when the relocation value ends up being
+	signed.
+
+	To fix this this patch introduces a special howto with
+	complain_on_overflow set to complain_overflow_dont.  This is used in
+	place of the normal R_OR1K_GOT16 howto when we detect R_OR1K_GOT_AHI16
+	relocations.
+
+	bfd/ChangeLog:
+
+		PR 28735
+		* elf32-or1k.c (or1k_elf_got16_no_overflow_howto): Define.
+		(or1k_elf_relocate_section): Use new howto instead of trying to
+		mask out relocation bits.
+
+2022-02-02  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-02-01  Tom Tromey  <tromey@adacore.com>
+
+	Fix flex rule in gdb
+	Currently, if flex fails, it will leave the resulting .c file in the
+	tree.  This will cause a cascade of errors, and requires the manual
+	deletion of the .c file in order to recreate the problem.
+
+	It's better for the rule to fail such that the .c file is not updated.
+	This way, 'make' will fail the same way every time -- which is much
+	handier for debugging syntax errors.
+
+	This fix just updates the Makefile rule to follow the way that the
+	"yacc" rule already works.
+
+2022-02-01  Markus Metzger  <markus.t.metzger@intel.com>
+
+	gdb, btrace: improve error messages
+	When trying to use 'record btrace' on a system that does not support it,
+	the error message isn't as clear as it could be.  See
+	https://sourceware.org/pipermail/gdb/2022-January/049870.html.
+
+	Improve the error message in a few cases.
+
+	Reported-by: Simon Sobisch  <simonsobisch@gnu.org>
+
+2022-02-01  Jan Vrany  <jan.vrany@labware.com>
+
+	gdb/python: fix gdb.Objfile.__repr__ () for dynamically compiled code
+	While experimenting with JIT reader API I realized that calling repr ()
+	on objfile created by JIT reader crashes GDB.
+
+	The problem was that objfpy_repr () called objfile_filename () which
+	returned NULL, causing PyString_FromFormat () to crash.
+
+	This commit fixes this problem by using objfile_name () instead of
+	objfile_filename (). This also makes consistent with the value of gdb.Objfile.filename variable.
+
+2022-02-01  Samuel Thibault  <samuel.thibault@gnu.org>
+
+	hurd: Fix RPC prototypes
+	The last updates of MIG introduced qualifying strings and arrays with
+	const as appropriate.  We thus have to update the protypes in gdb too.
+
+	Change-Id: I3f72aac1dfa6e58d1394d5776b822d7c8f2409df
+
+2022-02-01  Samuel Thibault  <samuel.thibault@gnu.org>
+
+	hurd: Fix RPC link names
+	The RPC stub code expects to be calling a C function, not a C++
+	function.
+
+	Change-Id: Idd7549fc118f2addc7fb4975667a011cacacc03f
+
+2022-02-01  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-31  H.J. Lu  <hjl.tools@gmail.com>
+
+	elf: Check symbol version without any symbols
+	VER_FLG_WEAK doesn't indicate that all symbol references of the symbol
+	version have STB_WEAK.  VER_FLG_WEAK indicates a weak symbol version
+	definition with no symbols associated with it.  It is used to verify
+	the existence of a particular implementation without any symbol references
+	to the weak symbol version.
+
+		PR ld/24718
+		* testsuite/ld-elf/pr24718-1.d: New file.
+		* testsuite/ld-elf/pr24718-1.s: Likewise.
+		* testsuite/ld-elf/pr24718-1.t: Likewise.
+
+2022-01-31  H.J. Lu  <hjl.tools@gmail.com>
+
+	Load debug section only when dumping debug sections
+	Don't load debug sections if we aren't dumping any debug sections.
+
+		PR binutils/28843
+		* objdump.c (dump_any_debugging): New.
+		(load_debug_section): Return false if dump_any_debugging isn't
+		set.
+		(main): Set dump_any_debugging when dumping any debug sections.
+		* readelf (dump_any_debugging): New.
+		(parse_args): Set dump_any_debugging when dumping any debug
+		sections.
+		(load_debug_section): Return false if dump_any_debugging isn't
+		set.
+
+2022-01-31  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: fix some clang-tidy readability-misleading-indentation warnings
+	I have warnings like these showing in my editor all the time, so I
+	thought I'd run clang-tidy with this diagnostic on all the files (that I
+	can compile) and fix them.
+
+	There is still one warning, in utils.c, but that's because some code
+	is mixed up with preprocessor macros (#ifdef TUI), so I think there no
+	good solution there.
+
+	Change-Id: I345175fc7dd865318f0fbe61ac026c88c3b6a96b
+
+2022-01-31  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	gdb, testsuite, fortran: adapt info symbol expected output for intel compilers
+	Info symbol is expected to print the symbol table name of a symbol, since
+	symbol lookup happens via the minimal symbol table.  This name
+	corresponds to the linkage name in the full symbol table.
+
+	For gfortran (and maybe others) these names currently have the form
+	XXXX.NUMBER where XXXX is the symbol name and NUMBER a compiler
+	generated appendix for mangling.
+	An example taken from the modified nested-funcs-2.exp would be
+
+	~~~~
+	$ objdump -t ./outputs/gdb.fortran/nested-funcs-2/nested-funcs-2 | grep \
+	increment
+	00000000000014ab l  F .text  0000000000000095  increment.3883
+	000000000000141c l  F .text  000000000000008f  increment_program_global.3881
+	~~~~
+
+	This mangled name gets recognized by the Ada demangler/decoder and decoded as
+	Ada to XXXX (setting the symbol language to Ada).  This leads to output
+	of XXXX over XXXX.NUMBER for info symbol on gfortran symbols.
+
+	For ifort and ifx the generated linkage names have the form
+	SCOPEA_SCOPEB_XXXX_ which are not recognized by the Ada decoder (or any
+	other demangler for that matter) and thus printed as is.
+	The respective objdump in the above case looks like
+
+	~~~~
+	$ objdump -t ./outputs/gdb.fortran/nested-funcs-2/nested-funcs-2 | grep \
+	increment
+	0000000000403a44 l  F .text  0000000000000074  contains_keyword_IP_increment_
+	0000000000403ab8 l  F .text  0000000000000070
+	contains_keyword_IP_increment_program_global_
+	~~~~
+
+	In the unmodified testcase this results in 'fails' when ran with the intel
+	compilers:
+
+	~~~~
+	>> make check RUNTESTFLAGS="gdb.fortran/nested-funcs-2.exp \
+	GDBFLAGS='$GDBFLAGS' CC_FOR_TARGET='icpc' F90_FOR_TARGET='ifort'"
+
+	...
+
+	                === gdb Summary ===
+
+	\# of expected passes            80
+	\# of unexpected failures        14
+	~~~~
+
+	Note that there is no Fortran mangling standard.  We keep the gfortran
+	behavior as is and modify the test to reflect ifx and ifort mangled
+	names which fixes above fails.
+
+2022-01-31  Nick Clifton  <nickc@redhat.com>
+
+	Import patch from mainline GCC to fix an infinite recusion in the Rust demangler.
+		PR 98886
+		PR 99935
+		* rust-demangle.c (struct rust_demangler): Add a recursion
+		counter.
+		(demangle_path): Increment/decrement the recursion counter upon
+		entry and exit.  Fail if the counter exceeds a fixed limit.
+		(demangle_type): Likewise.
+		(rust_demangle_callback): Initialise the recursion counter,
+		disabling if requested by the option flags.
+
+2022-01-31  Alan Modra  <amodra@gmail.com>
+
+	Re: PR28827, assertion building LLVM 9 on powerpc64le-linux-gnu
+	In trying to find a testcase for PR28827, I managed to hit a linker
+	error in bfd_set_section_contents with a .branch_lt input section
+	being too large for the output .branch_lt.
+
+	bfd/
+		PR 28827
+		* elf64-ppc.c (ppc64_elf_size_stubs): Set section size to
+		maxsize past STUB_SHRINK_ITER before laying out.  Remove now
+		unnecessary conditional setting of maxsize at start of loop.
+	ld/
+		* testsuite/ld-powerpc/pr28827-2.d,
+		* testsuite/ld-powerpc/pr28827-2.lnk,
+		* testsuite/ld-powerpc/pr28827-2.s: New test.
+		* testsuite/ld-powerpc/powerpc.exp: Run it.
+
+2022-01-31  Tom Tromey  <tom@tromey.com>
+
+	Remove unused variables in fbsd-tdep.c files
+	i386-fbsd-tdep.c and amd64-fbsd-tdep.c failed to build on my x86-64
+	Fedora 34 machine, using the system gcc, after a recent patch.  These
+	two files now have unused variables, which provokes a warning in this
+	configuration.
+
+	I'm checking in this patch to remove the unused variables.
+
+2022-01-31  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-30  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-29  Alan Modra  <amodra@gmail.com>
+
+	Re: PR28827, assertion building LLVM 9 on powerpc64le-linux-gnu
+	The previous patch wasn't quite correct.  The size and padding depends
+	on offset used in the current iteration, and if we're fudging the
+	offset past STUB_SHRINK_ITER then we'd better use that offset.  We
+	can't have plt_stub_pad using stub_sec->size as the offset.
+
+		PR 28827
+		* elf64-ppc.c (plt_stub_pad): Add stub_off param.
+		(ppc_size_one_stub): Set up stub_offset to value used in this
+		iteration before sizing the stub.  Adjust plt_stub_pad calls.
+
+2022-01-29  Alan Modra  <amodra@gmail.com>
+
+	objcopy --only-keep-debug
+	From: Peilin Ye <peilin.ye@bytedance.com>
+	objcopy's --only-keep-debug option has been broken for ELF files since
+	commit 8c803a2dd7d3.
+
+	  1. binutils/objcopy.c:setup_section() marks non-debug sections as
+	     SHT_NOBITS, then calls bfd_copy_private_section_data();
+	  2. If ISEC and OSEC share the same section flags,
+	     bfd/elf.c:_bfd_elf_init_private_section_data() restores OSEC's
+	     section type back to ISEC's section type, effectively undoing
+	     "make_nobits".
+
+		* objcopy.c (setup_section): Act on make_nobits after calling
+		bfd_copy_private_section_data.
+
+2022-01-29  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-28  John Baldwin  <jhb@FreeBSD.org>
+
+	gdb: fix ppc-sysv-tdep.c build on 32-bit platforms
+	The previous code triggered the following error on an i386 host:
+
+	/git/gdb/gdb/ppc-sysv-tdep.c:1764:34: error: non-constant-expression cannot be narrowed from type 'ULONGEST' (aka 'unsigned long long') to 'size_t' (aka 'unsigned int') in initializer list [-Wc++11-narrowing]
+	              unscaled.read ({writebuf, TYPE_LENGTH (valtype)},
+	                                        ^~~~~~~~~~~~~~~~~~~~~
+	/git/gdb/gdb/gdbtypes.h:2043:31: note: expanded from macro 'TYPE_LENGTH'
+	                              ^~~~~~~~~~~~~~~~~~
+	/git/gdb/gdb/ppc-sysv-tdep.c:1764:34: note: insert an explicit cast to silence this issue
+	              unscaled.read ({writebuf, TYPE_LENGTH (valtype)},
+	                                        ^~~~~~~~~~~~~~~~~~~~~
+	                                        static_cast<size_t>( )
+	/git/gdb/gdb/gdbtypes.h:2043:31: note: expanded from macro 'TYPE_LENGTH'
+	                              ^~~~~~~~~~~~~~~~~~
+	1 error generated.
+
+	Fix this by using gdb::make_array_view.
+
+2022-01-28  John Baldwin  <jhb@FreeBSD.org>
+
+	FreeBSD x86 nat: Use register maps for GP register sets.
+	Rather than using the x86-specific register offset tables, use
+	register maps to describe the layout of the general purpose registers
+	fetched via PT_GETREGS.  The sole user-visible difference is that
+	FreeBSD/amd64 will now report additional segment registers ($ds, $es,
+	$fs, and $gs) for both 32-bit and 64-bit processes.
+
+	As part of these changes, the FreeBSD x86 native targets no longer use
+	amd64-bsd-nat.c or i386-bsd-nat.c.  Remove FreeBSD-specific register
+	handling (for $fs_base, $gs_base, and XSAVE state) from these files.
+	Similarly, remove the global x86bsd_xsave_len from x86-bsd-nat.c.  The
+	FreeBSD x86 native targets use a static xsave_len instead.
+
+	While here, rework the probing of PT_GETXMMREGS on FreeBSD/i386.
+	Probe the ptrace op once in the target read_description method and
+	cache the result for the future similar to the way the status of XSAVE
+	support is probed in the read_description method.  In addition, return
+	the proper xcr0 mask (X87-only) for old kernels or systems without
+	either XSAVE or XMM support.
+
+2022-01-28  John Baldwin  <jhb@FreeBSD.org>
+
+	fbsd-nat: Return a bool from fetch_register_set and store_register_set.
+	Change these helper functions to return true if they did any work.
+
+2022-01-28  John Baldwin  <jhb@FreeBSD.org>
+
+	FreeBSD x86: Use tramp-frame for signal frames.
+	Use a register map to describe the registers in mcontext_t as part of
+	the signal frame as is done on several other FreeBSD arches.  This
+	permits fetching the fsbase and gsbase register values from the signal
+	frame for both amd64 and i386 and permits fetching additional segment
+	registers stored as 16-bit values on amd64.
+
+	While signal frames on FreeBSD do contain floating point/XSAVE state,
+	these unwinders do not attempt to supply those registers.  The
+	existing x86 signal frame uwinders do not support these registers, and
+	the only existing functions which handle FSAVE/FXSAVE/XSAVE state all
+	work with regcaches.  In the future these unwinders could create a
+	tempory regcache, collect floating point registers, and then supply
+	values out of the regcache into the trad-frame.
+
+2022-01-28  John Baldwin  <jhb@FreeBSD.org>
+
+	Use register maps for gp regsets on FreeBSD/x86 core dumps.
+	In particular, this permits reporting the value of the $ds, $es, $fs,
+	and $gs segment registers from amd64 core dumps since they are stored
+	as 16-bit values rather than the 32-bit size assumed by i386_gregset.
+
+2022-01-28  John Baldwin  <jhb@FreeBSD.org>
+
+	regcache: Zero-extend small registers described by a register map.
+	When registers are supplied via regcache_supply_register from a
+	register block described by a register map, registers may be stored in
+	slots smaller than GDB's native register size (e.g. x86 segment
+	registers are 16 bits, but the GDB registers for those are 32-bits).
+	regcache_collect_regset is careful to zero-extend slots larger than a
+	register size, but regcache_supply_regset just used
+	regcache::raw_supply_part and did not initialize the upper bytes of a
+	register value.
+
+	trad_frame_set_reg_regmap assumes these semantics (zero-extending
+	short registers).  Upcoming patches also require these semantics for
+	handling x86 segment register values stored in 16-bit slots on
+	FreeBSD.  Note that architecturally x86 segment registers are 16 bits,
+	but the x86 gdb architectures treat these registers as 32 bits.
+
+2022-01-28  John Baldwin  <jhb@FreeBSD.org>
+
+	FreeBSD x86: Remove fallback for detecting signal trampolines by address.
+	A few FreeBSD releases did not include the page holding the signal
+	code in core dumps.  As a workaround, a sysctl was used to fetch the
+	default location of the signal code instead.  The youngest affected
+	FreeBSD release is 10.1 released in November 2014 and EOLed in
+	December 2016.  The fallback only works for native processes and would
+	require a separate unwinder once the FreeBSD arches are converted to
+	use tramp_frame for signal frames.
+
+	Remove support for pre-5.0 FreeBSD/i386 signal trampolines.
+	The last relevant release (FreeBSD 4.11) was released in January of
+	2005.
+
+	Remove vestigal FreeBSD/i386 3.x support.
+	This was orphaned when a.out support was removed as the FreeBSD/i386
+	ELF support always used the register layouts from 4.0+.
+
+2022-01-28  Bruno Larsen  <blarsen@redhat.com>
+
+	Add Bruno Larsen to gdb/MAINTAINERS
+
+2022-01-28  Enze Li  <lienze2010@hotmail.com>
+
+	gdb/build: Fix Wpessimizing-move in clang build
+	When building with clang, I run into an error:
+
+	...
+	tui/tui-disasm.c:138:25: error: moving a temporary object prevents copy
+	elision [-Werror,-Wpessimizing-move]
+	      tal.addr_string = std::move (gdb_dis_out.release ());
+	                        ^
+	tui/tui-disasm.c:138:25: note: remove std::move call here
+	      tal.addr_string = std::move (gdb_dis_out.release ());
+	                        ^~~~~~~~~~~                      ~
+	...
+
+	The error above is caused by the recent commit 5d10a2041eb8 ("gdb: add
+	string_file::release method").
+
+	Fix this by removing std::move.
+
+	Build on x86_64-linux with clang 13.0.0.
+
+2022-01-28  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	Add top-level .editorconfig file
+	Add a .editorconfig [1] file.  This helps configure editors
+	automatically with the right whitespace settings.  It will help me,
+	since I need to juggle with different whitespace settings for different
+	projects.   But I think it can also help newcomers get things right from
+	the start.
+
+	Some editors have native support for reading these files, while others
+	require a plug-in [2].  And if you don't want to use it, then this file
+	doesn't change anything to your life.
+
+	I added rules for the kinds of files I edit most often, but more can be
+	added later.  I assumed that the rules were the same for GDB and the
+	other projects, but if that's not the case, we can always put
+	.editorconfig files in project subdirectories to override settings.
+
+	[1] https://editorconfig.org/
+	[2] https://editorconfig.org/#download
+
+	Change-Id: Ifda136d13877fafcf0d137fec8501f6a34e1367b
+
+2022-01-28  Nick Clifton  <nickc@redhat.com>
+
+	Updated French translation for the gas sub-directory.
+
+2022-01-28  Alan Modra  <amodra@gmail.com>
+
+	Set __ehdr_start rel_from_abs earlier
+	This is just a tidy, making the __ehdr_start symbol flag tweaks all in
+	one place.
+
+		* ldelf.c (ldelf_before_allocation): Don't set rel_from_abs
+		for __ehdr_start.
+		* ldlang.c (lang_symbol_tweaks): Set it here instead.
+
+2022-01-28  Alan Modra  <amodra@gmail.com>
+
+	PowerPC64 handling of @tocbase
+		* elf64-ppc.c (ppc64_elf_relocate_section): Warn if the symbol
+		on R_PPC64_TOC isn't local.
+
+2022-01-28  Alan Modra  <amodra@gmail.com>
+
+	Update PowerPC64 symtocbase test
+	Using a symbol other than .TOC. with @tocbase is an extension to the
+	ABI.  It is never valid to use a symbol without a definition in the
+	binary, and symbols on these expressions cannot be overridden.  Make
+	this explicit by using ".hidden" in the testcase.
+
+		* testsuite/ld-powerpc/symtocbase-1.s: Align data.  Make function
+		entry symbol hidden.
+		* testsuite/ld-powerpc/symtocbase-2.s: Likewise.
+		* testsuite/ld-powerpc/symtocbase.d: Adjust expected output.
+
+2022-01-28  Alan Modra  <amodra@gmail.com>
+
+	PR28827, assertion building LLVM 9 on powerpc64le-linux-gnu
+	The assertion is this one in ppc_build_one_stub
+	  BFD_ASSERT (stub_entry->stub_offset >= stub_entry->group->stub_sec->size);
+	It is checking that a stub doesn't overwrite the tail of a previous
+	stub, so not something trivial.
+
+	Normally, stub sizing iterates until no stubs are added, detected by
+	no change in stub section size.  Iteration also continues if no stubs
+	are added but one or more stubs increases in size, which also can be
+	detected by a change in stub section size.  But there is a
+	pathological case where stub section sizing decreases one iteration
+	then increases the next.  To handle that situation, stub sizing also
+	stops at more than STUB_SHRINK_ITER (20) iterations when calculated
+	stub section size is smaller.  The previous larger size is kept for
+	the actual layout (so that building the stubs, which behaves like
+	another iteration of stub sizing, will see the stub section sizes
+	shrink).  The problem with that stopping condition is that it assumes
+	that stub sizing is only affected by addresses external to the stub
+	sections, which isn't always true.
+
+	This patch fixes that by also keeping larger individual stub_offset
+	addresses past STUB_SHRINK_ITER.  It also catches a further
+	pathological case where one stub shrinks and another expands in such a
+	way that no stub section size change is seen.
+
+		PR 28827
+		* elf64-ppc.c (struct ppc_link_hash_table): Add stub_changed.
+		(STUB_SHRINK_ITER): Move earlier in file.
+		(ppc_size_one_stub): Detect any change in stub_offset.  Keep
+		larger one if past STUB_SHRINK_ITER.
+		(ppc64_elf_size_stubs): Iterate on stub_changed too.
+
+2022-01-28  Alan Modra  <amodra@gmail.com>
+
+	PR28826 x86_64 ld segfaults building xen
+	Fallout from commit e86fc4a5bc37
+
+		PR 28826
+		* coffgen.c (coff_write_alien_symbol): Init dummy to zeros.
+
+2022-01-28  Alan Modra  <amodra@gmail.com>
+
+	PR28753, buffer overflow in read_section_stabs_debugging_info
+		PR 28753
+		* rddbg.c (read_section_stabs_debugging_info): Don't read past
+		end of section when concatentating stab strings.
+
+2022-01-28  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-27  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: work around negative DW_AT_data_member_location GCC 11 bug
+	g++ 11.1.0 has a bug where it will emit a negative
+	DW_AT_data_member_location in some cases:
+
+	    $ cat test.cpp
+	    #include <memory>
+
+	    int
+	    main()
+	    {
+	      std::unique_ptr<int> ptr;
+	    }
+	    $ g++ -g test.cpp
+	    $ llvm-dwarfdump -F a.out
+	    ...
+	    0x00000964:       DW_TAG_member
+	                        DW_AT_name [DW_FORM_strp]   ("_M_head_impl")
+	                        DW_AT_decl_file [DW_FORM_data1]     ("/usr/include/c++/11.1.0/tuple")
+	                        DW_AT_decl_line [DW_FORM_data1]     (125)
+	                        DW_AT_decl_column [DW_FORM_data1]   (0x27)
+	                        DW_AT_type [DW_FORM_ref4]   (0x0000067a "default_delete<int>")
+	                        DW_AT_data_member_location [DW_FORM_sdata]  (-1)
+	    ...
+
+	This leads to a GDB crash (when built with ASan, otherwise probably
+	garbage results), since it tries to read just before (to the left, in
+	ASan speak) of the value's buffer:
+
+	    ==888645==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000c52af at pc 0x7f711b239f4b bp 0x7fff356bd470 sp 0x7fff356bcc18
+	    READ of size 1 at 0x6020000c52af thread T0
+	        #0 0x7f711b239f4a in __interceptor_memcpy /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827
+	        #1 0x555c4977efa1 in value_contents_copy_raw /home/simark/src/binutils-gdb/gdb/value.c:1347
+	        #2 0x555c497909cd in value_primitive_field(value*, long, int, type*) /home/simark/src/binutils-gdb/gdb/value.c:3126
+	        #3 0x555c478f2eaa in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:333
+	        #4 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
+	        #5 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
+	        #6 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
+	        #7 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
+	        #8 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
+	        #9 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
+	        #10 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
+	        #11 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
+	        #12 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
+	        #13 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
+	        #14 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151
+	        #15 0x555c478f2fcb in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335
+	        #16 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
+	        #17 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
+	        #18 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
+	        #19 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
+	        #20 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
+	        #21 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
+	        #22 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151
+	        #23 0x555c478f2fcb in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335
+	        #24 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
+	        #25 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
+	        #26 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
+	        #27 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
+	        #28 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151
+	        #29 0x555c4760f04c in c_value_print(value*, ui_file*, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:587
+	        #30 0x555c483ff954 in language_defn::value_print(value*, ui_file*, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:614
+	        #31 0x555c49759f61 in value_print(value*, ui_file*, value_print_options const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1189
+	        #32 0x555c48950f70 in print_formatted /home/simark/src/binutils-gdb/gdb/printcmd.c:337
+	        #33 0x555c48958eda in print_value(value*, value_print_options const&) /home/simark/src/binutils-gdb/gdb/printcmd.c:1258
+	        #34 0x555c48959891 in print_command_1 /home/simark/src/binutils-gdb/gdb/printcmd.c:1367
+	        #35 0x555c4895a3df in print_command /home/simark/src/binutils-gdb/gdb/printcmd.c:1458
+	        #36 0x555c4767f974 in do_simple_func /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:97
+	        #37 0x555c47692e25 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2475
+	        #38 0x555c4936107e in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:670
+	        #39 0x555c485f1bff in catch_command_errors /home/simark/src/binutils-gdb/gdb/main.c:523
+	        #40 0x555c485f249c in execute_cmdargs /home/simark/src/binutils-gdb/gdb/main.c:618
+	        #41 0x555c485f6677 in captured_main_1 /home/simark/src/binutils-gdb/gdb/main.c:1317
+	        #42 0x555c485f6c83 in captured_main /home/simark/src/binutils-gdb/gdb/main.c:1338
+	        #43 0x555c485f6d65 in gdb_main(captured_main_args*) /home/simark/src/binutils-gdb/gdb/main.c:1363
+	        #44 0x555c46e41ba8 in main /home/simark/src/binutils-gdb/gdb/gdb.c:32
+	        #45 0x7f71198bcb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
+	        #46 0x555c46e4197d in _start (/home/simark/build/binutils-gdb-one-target/gdb/gdb+0x77f197d)
+
+	    0x6020000c52af is located 1 bytes to the left of 8-byte region [0x6020000c52b0,0x6020000c52b8)
+	    allocated by thread T0 here:
+	        #0 0x7f711b2b7459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
+	        #1 0x555c470acdc9 in xcalloc /home/simark/src/binutils-gdb/gdb/alloc.c:100
+	        #2 0x555c49b775cd in xzalloc(unsigned long) /home/simark/src/binutils-gdb/gdbsupport/common-utils.cc:29
+	        #3 0x555c4977bdeb in allocate_value_contents /home/simark/src/binutils-gdb/gdb/value.c:1029
+	        #4 0x555c4977be25 in allocate_value(type*) /home/simark/src/binutils-gdb/gdb/value.c:1040
+	        #5 0x555c4979030d in value_primitive_field(value*, long, int, type*) /home/simark/src/binutils-gdb/gdb/value.c:3092
+	        #6 0x555c478f6280 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:501
+	        #7 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
+	        #8 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
+	        #9 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
+	        #10 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
+	        #11 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
+	        #12 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
+	        #13 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
+	        #14 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
+	        #15 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
+	        #16 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151
+	        #17 0x555c478f2fcb in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335
+	        #18 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
+	        #19 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
+	        #20 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
+	        #21 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
+	        #22 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
+	        #23 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
+	        #24 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151
+	        #25 0x555c478f2fcb in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335
+	        #26 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
+	        #27 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
+	        #28 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
+	        #29 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
+
+	Since there are some binaries with this in the wild, I think it would be
+	useful for GDB to work around this.  I did the obvious simple thing, if
+	the DW_AT_data_member_location's value is -1, replace it with 0.  I
+	added a producer check to only apply this fixup for GCC 11.  The idea is
+	that if some other compiler ever uses a DW_AT_data_member_location value
+	of -1 by mistake, we don't know (before analyzing the bug at least) if
+	they did mean 0 or some other value.  So I wouldn't want to apply the
+	fixup in that case.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28063
+	Change-Id: Ieef3459b0b9bbce8bdad838ba83b4b64e7269d42
+
+2022-01-27  Kevin Buettner  <kevinb@redhat.com>
+
+	Fix GDB internal error by using text (instead of data) section offset
+	Fedora Rawhide is now using gcc-12.0.  As part of updating to the
+	gcc-12.0 package set, Rawhide is also now using a version of libgcc_s
+	which lacks a .data section.  This causes gdb to fail in the following
+	fashion while debugging a program (such as gdb) which uses libgcc_s:
+
+	    (top-gdb) run
+	    Starting program: rawhide-master/bld/gdb/gdb
+	    ...
+	    objfiles.h:467: internal-error: sect_index_data not initialized
+	    A problem internal to GDB has been detected,
+	    further debugging may prove unreliable.
+	    ...
+
+	I snipped the backtrace from the above output.  Instead, here's a
+	portion of a backtrace obtained using GDB's backtrace command.
+	(Obviously, in order to obtain it, I used a GDB which has been patched
+	with this commit.)
+
+	    #0  internal_error (
+		file=0xc6a508 "gdb/objfiles.h", line=467,
+		fmt=0xc6a4e8 "sect_index_data not initialized")
+		at gdbsupport/errors.cc:51
+	    #1  0x00000000005f9651 in objfile::data_section_offset (this=0x4fa48f0)
+		at gdb/objfiles.h:467
+	    #2  0x000000000097c5f8 in relocate_address (address=0x17244, objfile=0x4fa48f0)
+		at gdb/stap-probe.c:1333
+	    #3  0x000000000097c630 in stap_probe::get_relocated_address (this=0xa1a17a0,
+		objfile=0x4fa48f0)
+		at gdb/stap-probe.c:1341
+	    #4  0x00000000004d7025 in create_exception_master_breakpoint_probe (
+		objfile=0x4fa48f0)
+		at gdb/breakpoint.c:3505
+	    #5  0x00000000004d7426 in create_exception_master_breakpoint ()
+		at gdb/breakpoint.c:3575
+	    #6  0x00000000004efcc1 in breakpoint_re_set ()
+		at gdb/breakpoint.c:13407
+	    #7  0x0000000000956998 in solib_add (pattern=0x0, from_tty=0, readsyms=1)
+		at gdb/solib.c:1001
+	    #8  0x00000000009576a8 in handle_solib_event ()
+		at gdb/solib.c:1269
+	    ...
+
+	The function 'relocate_address' in gdb/stap-probe.c attempts to do
+	its "relocation" by using objfile->data_section_offset().  That
+	method, data_section_offset() is defined as follows in objfiles.h:
+
+	  CORE_ADDR data_section_offset () const
+	  {
+	    return section_offsets[SECT_OFF_DATA (this)];
+	  }
+
+	The internal error occurs when the SECT_OFF_DATA macro finds that the
+	'sect_index_data' field is -1:
+
+	    #define SECT_OFF_DATA(objfile) \
+		 ((objfile->sect_index_data == -1) \
+		  ? (internal_error (__FILE__, __LINE__, \
+				     _("sect_index_data not initialized")), -1)	\
+		  : objfile->sect_index_data)
+
+	relocate_address() is obtaining the section offset in order to compute
+	a relocated address.  For some ABIs, such as the System V ABI, the
+	section offsets will all be the same.  So for those ABIs, it doesn't
+	matter which offset is used.  However, other ABIs, such as the FDPIC
+	ABI, will have different offsets for the various sections.  Thus, for
+	those ABIs, it is vital that this and other relocation code use the
+	correct offset.
+
+	In stap_probe::get_relocated_address, the address to which to add the
+	offset (thus forming the relocated address) is obtained via
+	this->get_address (); get_address is a getter for m_address in
+	probe.h.  It's documented/defined as follows (also in probe.h):
+
+	  /* The address where the probe is inserted, relative to
+	     SECT_OFF_TEXT.  */
+	  CORE_ADDR m_address;
+
+	(Thanks to Tom Tromey for this observation.)
+
+	So, based on this, the current use of data_section_offset /
+	SECT_OFF_DATA is wrong.  This relocation code should have been using
+	text_section_offset / SECT_OFF_TEXT all along.  That being the
+	case, I've adjusted the stap-probe.c relocation code accordingly.
+
+	Searching the sources turned up one other use of data_section_offset,
+	in gdb/dtrace-probe.c, so I've updated that code as well.  The same
+	reasoning presented above applies to this case too.
+
+	Summary:
+
+		* gdb/dtrace-probe.c (dtrace_probe::get_relocated_address):
+		Use method text_section_offset instead of data_section_offset.
+		* gdb/stap-probe.c (relocate_address): Likewise.
+
+2022-01-27  Markus Metzger  <markus.t.metzger@intel.com>
+
+	gdb, remote, btrace: move switch_to_thread call right before xfer call
+	In remote_target::remote_btrace_maybe_reopen, we switch to the currently
+	iterated thread in order to set inferior_ptid for a subsequent xfer.
+
+	Move the switch_to_thread call directly before the target_read_stralloc
+	call to clarify why we need to switch threads.
+
+2022-01-27  Markus Metzger  <markus.t.metzger@intel.com>
+
+	gdb, gdbserver: update thread identifier in enable_btrace target method
+	The enable_btrace target method takes a ptid_t to identify the thread on
+	which tracing shall be enabled.
+
+	Change this to thread_info * to avoid translating back and forth between
+	the two.  This will be used in a subsequent patch.
+
+2022-01-27  Markus Metzger  <markus.t.metzger@intel.com>
+
+	gdb, btrace: switch threads in remote_btrace_maybe_reopen()
+	In remote_btrace_maybe_reopen() we iterate over threads and use
+	set_general_thread() to set the thread from which to transfer the btrace
+	configuration.
+
+	This sets the remote general thread but does not affect inferior_ptid.  On
+	the xfer request later on, remote_target::xfer_partial() again sets the
+	remote general thread to inferior_ptid, overwriting what
+	remote_btrace_maybe_reopen() had done.
+
+	In one case, this led to inferior_ptid being null_ptid when we tried to
+	enable tracing on a newly created thread inside a newly created process
+	during attach.
+
+	This, in turn, led to find_inferior_pid() asserting when we iterated over
+	threads in record_btrace_is_replaying(), which was called from
+	record_btrace_target::xfer_partial() when reading the btrace configuration
+	of the new thread to check whether it was already being recorded.
+
+	The bug was exposed by
+
+	    0618ae41497 gdb: optimize all_matching_threads_iterator
+
+	and found by
+
+	    FAIL: gdb.btrace/enable-new-thread.exp: ... (GDB internal error)
+
+	Use switch_to_thread() in remote_btrace_maybe_reopen().
+
+2022-01-27  Markus Metzger  <markus.t.metzger@intel.com>
+
+	gdb, btrace: rename record_btrace_enable_warn()
+	We use record_btrace_enable_warn() as the new-thread observer callback.
+	It is not used in other contexts.
+
+	Rename it to record_btrace_on_new_thread() to make its role more clear.
+
+2022-01-27  Nick Clifton  <nickc@redhat.com>
+
+	Updated Swedish translation for the binutils subdirectory
+
+2022-01-27  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-26  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/python: handle non utf-8 characters when source highlighting
+	This commit adds support for source files that contain non utf-8
+	characters when performing source styling using the Python pygments
+	package.  This does not change the behaviour of GDB when the GNU
+	Source Highlight library is used.
+
+	For the following problem description, assume that either GDB is built
+	without GNU Source Highlight support, of that this has been disabled
+	using 'maintenance set gnu-source-highlight enabled off'.
+
+	The initial problem reported was that a source file containing non
+	utf-8 characters would cause GDB to print a Python exception, and then
+	display the source without styling, e.g.:
+
+	  Python Exception <class 'UnicodeDecodeError'>: 'utf-8' codec can't decode byte 0xc0 in position 142: invalid start byte
+	  /* Source code here, without styling...  */
+
+	Further, as the user steps through different source files, each time
+	the problematic source file was evicted from the source cache, and
+	then later reloaded, the exception would be printed again.
+
+	Finally, this problem is only present when using Python 3, this issue
+	is not present for Python 2.
+
+	What makes this especially frustrating is that GDB can clearly print
+	the source file contents, they're right there...  If we disable
+	styling completely, or make use of the GNU Source Highlight library,
+	then everything is fine.  So why is there an error when we try to
+	apply styling using Python?
+
+	The problem is the use of PyString_FromString (which is an alias for
+	PyUnicode_FromString in Python 3), this function converts a C string
+	into a either a Unicode object (Py3) or a str object (Py2).  For
+	Python 2 there is no unicode encoding performed during this function
+	call, but for Python 3 the input is assumed to be a uft-8 encoding
+	string for the purpose of the conversion.  And here of course, is the
+	problem, if the source file contains non utf-8 characters, then it
+	should not be treated as utf-8, but that's what we do, and that's why
+	we get an error.
+
+	My first thought when looking at this was to spot when the
+	PyString_FromString call failed with a UnicodeDecodeError and silently
+	ignore the error.  This would mean that GDB would print the source
+	without styling, but would also avoid the annoying exception message.
+
+	However, I also make use of `pygmentize`, a command line wrapper
+	around the Python pygments module, which I use to apply syntax
+	highlighting in the output of `less`.  And this command line wrapper
+	is quite happy to syntax highlight my source file that contains non
+	utf-8 characters, so it feels like the problem should be solvable.
+
+	It turns out that inside the pygments module there is already support
+	for guessing the encoding of the incoming file content, if the
+	incoming content is not already a Unicode string.  This is what
+	happens for Python 2 where the incoming content is of `str` type.
+
+	We could try and make GDB smarter when it comes to converting C
+	strings into Python Unicode objects; this would probably require us to
+	just try a couple of different encoding schemes rather than just
+	giving up after utf-8.
+
+	However, I figure, why bother?  The pygments module already does this
+	for us, and the colorize API is not part of the documented external
+	API of GDB.  So, why not just change the colorize API, instead of the
+	content being a Unicode string (for Python 3), lets just make the
+	content be a bytes object.  The pygments module can then take
+	responsibility for guessing the encoding.
+
+	So, currently, the colorize API receives a unicode object, and returns
+	a unicode object.  I propose that the colorize API receive a bytes
+	object, and return a bytes object.
+
+2022-01-26  Tom Tromey  <tom@tromey.com>
+
+	Remove global wrap_here function
+	This removes the global wrap_here function, so that future calls
+	cannot be introduced.  Instead, all callers must use the method on the
+	appropriate ui_file.
+
+	This temporarily moves the implementation of this method to utils.c.
+	This will change once the remaining patches to untangle the pager have
+	been written.
+
+2022-01-26  Tom Tromey  <tom@tromey.com>
+
+	Always call the wrap_here method
+	This changes all existing calls to wrap_here to call the method on the
+	appropriate ui_file instead.  The choice of ui_file is determined by
+	context.
+
+2022-01-26  Tom Tromey  <tom@tromey.com>
+
+	Add ui_file::wrap_here
+	Right now, wrap_here is a global function.  In the long run, we'd like
+	output streams to be relatively self-contained objects, and having a
+	global function like this is counter to that goal.  Also, existing
+	code freely mixes writes to some parameterized stream with calls to
+	wrap_here -- but wrap_here only really affects gdb_stdout, so this is
+	also incoherent.
+
+	This step is a patch toward making wrap_here more sane.  It adds a
+	wrap_here method to ui_file and changes ui_out implementations to use
+	it.
+
+2022-01-26  Tom Tromey  <tom@tromey.com>
+
+	Convert wrap_here to use integer parameter
+	I think it only really makes sense to call wrap_here with an argument
+	consisting solely of spaces.  Given this, it seemed better to me that
+	the argument be an int, rather than a string.  This patch is the
+	result.  Much of it was written by a script.
+
+2022-01-26  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/python: improve the auto help text for gdb.Parameter
+	This commit attempts to improve the help text that is generated for
+	gdb.Parameter objects when the user fails to provide their own
+	documentation.
+
+	Documentation for a gdb.Parameter is currently pulled from two
+	sources: the class documentation string, and the set_doc/show_doc
+	class attributes.  Thus, a fully documented parameter might look like
+	this:
+
+	  class Param_All (gdb.Parameter):
+	     """This is the class documentation string."""
+
+	     show_doc = "Show the state of this parameter"
+	     set_doc = "Set the state of this parameter"
+
+	     def get_set_string (self):
+	        val = "on"
+	        if (self.value == False):
+	           val = "off"
+	        return "Test Parameter has been set to " + val
+
+	     def __init__ (self, name):
+	        super (Param_All, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN)
+	        self._value = True
+
+	  Param_All ('param-all')
+
+	Then in GDB we see this:
+
+	  (gdb) help set param-all
+	  Set the state of this parameter
+	  This is the class documentation string.
+
+	Which is fine.  But, if the user skips both of the documentation parts
+	like this:
+
+	  class Param_None (gdb.Parameter):
+
+	     def get_set_string (self):
+	        val = "on"
+	        if (self.value == False):
+	           val = "off"
+	        return "Test Parameter has been set to " + val
+
+	     def __init__ (self, name):
+	        super (Param_None, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN)
+	        self._value = True
+
+	  Param_None ('param-none')
+
+	Now in GDB we see this:
+
+	  (gdb) help set param-none
+	  This command is not documented.
+	  This command is not documented.
+
+	That's not great, the duplicated text looks a bit weird.  If we drop
+	different parts we get different results.  Here's what we get if the
+	user drops the set_doc and show_doc attributes:
+
+	  (gdb) help set param-doc
+	  This command is not documented.
+	  This is the class documentation string.
+
+	That kind of sucks, we say it's undocumented, then proceed to print
+	the documentation.  Finally, if we drop the class documentation but
+	keep the set_doc and show_doc:
+
+	  (gdb) help set param-set-show
+	  Set the state of this parameter
+	  This command is not documented.
+
+	That seems OK.
+
+	So, I think there's room for improvement.
+
+	With this patch, for the four cases above we now see this:
+
+	  # All values provided by the user, no change in this case:
+	  (gdb) help set param-all
+	  Set the state of this parameter
+	  This is the class documentation string.
+
+	  # Nothing provided by the user, the first string is now different:
+	  (gdb) help set param-none
+	  Set the current value of 'param-none'.
+	  This command is not documented.
+
+	  # Only the class documentation is provided, the first string is
+	  # changed as in the previous case:
+	  (gdb) help set param-doc
+	  Set the current value of 'param-doc'.
+	  This is the class documentation string.
+
+	  # Only the set_doc and show_doc are provided, this case is unchanged
+	  # from before the patch:
+	  (gdb) help set param-set-show
+	  Set the state of this parameter
+	  This command is not documented.
+
+	The one place where this change might be considered a negative is when
+	dealing with prefix commands.  If we create a prefix command but don't
+	supply the set_doc / show_doc strings, then this is what we saw before
+	my patch:
+
+	  (gdb) python Param_None ('print param-none')
+	  (gdb) help set print
+	  set print, set pr, set p
+	  Generic command for setting how things print.
+
+	  List of set print subcommands:
+
+	  ... snip ...
+	  set print param-none -- This command is not documented.
+	  ... snip ...
+
+	And after my patch:
+
+	  (gdb) python Param_None ('print param-none')
+	  (gdb) help set print
+	  set print, set pr, set p
+	  Generic command for setting how things print.
+
+	  List of set print subcommands:
+
+	  ... snip ...
+	  set print param-none -- Set the current value of 'print param-none'.
+	  ... snip ...
+
+	This seems slightly less helpful than before, but I don't think its
+	terrible.
+
+	Additionally, I've changed what we print when the get_show_string
+	method is not provided in Python.
+
+	Back when gdb.Parameter was first added to GDB, we didn't provide a
+	show function when registering the internal command object within
+	GDB.  As a result, GDB would make use of its "magic" mangling of the
+	show_doc string to create a sentence that would display the current
+	value (see deprecated_show_value_hack in cli/cli-setshow.c).
+
+	However, when we added support for the get_show_string method to
+	gdb.Parameter, there was an attempt to maintain backward compatibility
+	by displaying the show_doc string with the current value appended, see
+	get_show_value in py-param.c.  Unfortunately, this isn't anywhere
+	close to what deprecated_show_value_hack does, and the results are
+	pretty poor, for example, this is GDB before my patch:
+
+	  (gdb) show param-none
+	  This command is not documented. off
+
+	I think we can all agree that this is pretty bad.
+
+	After my patch, we how show this:
+
+	  (gdb) show param-none
+	  The current value of 'param-none' is "off".
+
+	Which at least is a real sentence, even if it's not very informative.
+
+	This patch does change the way that the Python API behaves slightly,
+	but only in the cases when the user has missed providing GDB with some
+	information.  In most cases I think the new behaviour is a lot better,
+	there's the one case (noted above) which is a bit iffy, but I think is
+	still OK.
+
+	I've updated the existing gdb.python/py-parameter.exp test to cover
+	the modified behaviour.
+
+	Finally, I've updated the documentation to (I hope) make it clearer
+	how the various bits of help text come together.
+
+2022-01-26  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/python: add gdb.history_count function
+	Add a new function gdb.history_count to the Python api, this function
+	returns an integer, the number of items in GDB's value history.
+
+	This is useful if you want to pull items from the history by their
+	absolute number, for example, if you wanted to show a complete history
+	list.  Previously we could figure out how many items are in the
+	history list by trying to fetch the items, and then catching the
+	exception when the item is not available, but having this function
+	seems nicer.
+
+2022-01-26  Tom Tromey  <tromey@adacore.com>
+
+	Remove unused declaration
+	This removes an unused declaration from top.h.  This type is not
+	defined anywhere.
+
+2022-01-26  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: convert maintenance target-async and target-non-stop settings to callbacks
+	This simplifies things a bit, as we don't need two variables and think
+	about reverting target_async_permitted_1 and target_non_stop_enabled_1
+	values if we can't change the setting.
+
+	Change-Id: I36acab045dacf02ae1988486cfdb27c1dff309f6
+
+2022-01-26  Keith Seitz  <keiths@redhat.com>
+
+	Reference array of structs instead of first member during memcpy
+	aarch64-tdep.c defines the following macro:
+
+	#define MEM_ALLOC(MEMS, LENGTH, RECORD_BUF) \
+	        do  \
+	          { \
+	            unsigned int mem_len = LENGTH; \
+	            if (mem_len) \
+	              { \
+	                MEMS =  XNEWVEC (struct aarch64_mem_r, mem_len);  \
+	                memcpy(&MEMS->len, &RECORD_BUF[0], \
+	                       sizeof(struct aarch64_mem_r) * LENGTH); \
+	              } \
+	          } \
+	          while (0)
+
+	This is simlpy allocating a new array and copying it. However, for
+	the destination address, it is actually copying into the first member
+	of the first element of the array (`&MEMS->len"). This elicits a
+	warning with GCC 12:
+
+	../../binutils-gdb/gdb/aarch64-tdep.c: In function ‘int aarch64_process_record(gdbarch*, regcache*, CORE_ADDR)’:
+	../../binutils-gdb/gdb/aarch64-tdep.c:3711:23: error: writing 16 bytes into a region of size 8 [-Werror=stringop-overflow=]
+	 3711 |                 memcpy(&MEMS->len, &RECORD_BUF[0], \
+	      |                       ^
+	../../binutils-gdb/gdb/aarch64-tdep.c:4394:3: note: in expansion of macro ‘MEM_ALLOC’
+	 4394 |   MEM_ALLOC (aarch64_insn_r->aarch64_mems, aarch64_insn_r->mem_rec_count,
+	      |   ^~~~~~~~~
+	../../binutils-gdb/gdb/aarch64-tdep.c:3721:12: note: destination object ‘aarch64_mem_r::len’ of size 8
+	 3721 |   uint64_t len;    /* Record length.  */
+	      |            ^~~
+
+	The simple fix is to reference the array, `MEMS' as the destination of the copy.
+
+	Tested by rebuilding.
+
+
+	# Please enter the commit message for your changes. Lines starting
+	# with '#' will be kept; you may remove them yourself if you want to.
+	# An empty message aborts the commit.
+	#
+	# Date:      Tue Jan 25 08:28:32 2022 -0800
+	#
+	# On branch master
+	# Your branch is ahead of 'origin/master' by 1 commit.
+	#   (use "git push" to publish your local commits)
+	#
+	# Changes to be committed:
+	#	modified:   aarch64-tdep.c
+	#
+
+2022-01-26  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: add string_file::release method
+	A common pattern for string_file is to want to move out the internal
+	string buffer, because it is the result of the computation that we want
+	to return.  It is the reason why string_file::string returns a non-const
+	reference, as explained in the comment.  I think it would make sense to
+	have a dedicated method for that instead and make string_file::string
+	return a const reference.
+
+	This allows removing the explicit std::move in the typical case.  Note
+	that compile_program::compute was missing a move, meaning that the
+	resulting string was copied.  With the new version, it's not possible to
+	forget to move.
+
+	Change-Id: Ieaefa35b73daa7930b2f3a26988b6e3b4121bb79
+
+2022-01-26  Tom Tromey  <tromey@adacore.com>
+
+	Add a way to temporarily set a gdb parameter from Python
+	It's sometimes useful to temporarily set some gdb parameter from
+	Python.  Now that the 'endian' crash is fixed, and now that the
+	current language is no longer captured by the Python layer, it seems
+	reasonable to add a helper function for this situation.
+
+	This adds a new gdb.with_parameter function.  This creates a context
+	manager which temporarily sets some parameter to a specified value.
+	The old value is restored when the context is exited.  This is most
+	useful with the Python "with" statement:
+
+	   with gdb.with_parameter('language', 'ada'):
+	      ... do Ada stuff
+
+	This also adds a simple function to set a parameter,
+	gdb.set_parameter, as suggested by Andrew.
+
+	This is PR python/10790.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=10790
+
+2022-01-26  Tom Tromey  <tromey@adacore.com>
+
+	Fix another crash with gdb parameters in Python
+	While looking into the language-capturing issue, I found another way
+	to crash gdb using parameters from Python:
+
+	(gdb) python print(gdb.parameter('endian'))
+
+	(This is related to PR python/12188, though this patch isn't going to
+	fix what that bug is really about.)
+
+	The problem here is that the global variable that underlies the
+	"endian" parameter is initialized to NULL.  However, that's not a
+	valid value for an "enum" set/show parameter.
+
+	My understanding is that, in gdb, an "enum" parameter's underlying
+	variable must have a value that is "==" (not just strcmp-equal) to one
+	of the values coming from the enum array.  This invariant is relied on
+	in various places.
+
+	I started this patch by fixing the problem with "endian".  Then I
+	added some assertions to add_setshow_enum_cmd to try to catch other
+	problems of the same type.
+
+	This patch fixes all the problems that I found.  I also looked at all
+	the calls to add_setshow_enum_cmd to ensure that they were all
+	included in the gdb I tested.  I think they are: there are no calls in
+	nat-* files, or in remote-sim.c; and I was trying a build with all
+	targets, Python, and Guile enabled.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12188
+
+2022-01-26  Tom Tromey  <tromey@adacore.com>
+
+	Change how Python architecture and language are handled
+	Currently, gdb's Python layer captures the current architecture and
+	language when "entering" Python code.  This has some undesirable
+	effects, and so this series changes how this is handled.
+
+	First, there is code like this:
+
+	  gdbpy_enter enter_py (python_gdbarch, python_language);
+
+	This is incorrect, because both of these are NULL when not otherwise
+	assigned.  This can cause crashes in some cases -- I've added one to
+	the test suite.  (Note that this crasher is just an example, other
+	ones along the same lines are possible.)
+
+	Second, when the language is captured in this way, it means that
+	Python code cannot affect the current language for its own purposes.
+	It's reasonable to want to write code like this:
+
+	    gdb.execute('set language mumble')
+	    ... stuff using the current language
+	    gdb.execute('set language previous-value')
+
+	However, this won't actually work, because the language is captured on
+	entry.  I've added a test to show this as well.
+
+	This patch changes gdb to try to avoid capturing the current values.
+	The Python concept of the current gdbarch is only set in those few
+	cases where a non-default value is computed or needed; and the
+	language is not captured at all -- instead, in the cases where it's
+	required, the current language is temporarily changed.
+
+2022-01-26  H.J. Lu  <hjl.tools@gmail.com>
+
+	bfd: Make bfd.stamp depend on source bfd.texi
+	Make bfd.stamp depend on source bfd.texi to avoid regenerating
+	doc/bfd.info for each make run.
+
+		PR binutils/28807
+		* Makefile.in: Regenerate.
+		* doc/local.mk (%D%/bfd.stamp): Depend on $(srcdir)/%D%/bfd.texi.
+
+2022-01-26  H.J. Lu  <hjl.tools@gmail.com>
+
+	ld: Rewrite lang_size_relro_segment_1
+	1. Compute the desired PT_GNU_RELRO segment base and find the maximum
+	section alignment of sections starting from the PT_GNU_RELRO segment.
+	2. Find the first preceding load section.
+	3. Don't add the 1-page gap between the first preceding load section and
+	the relro segment if the maximum page size >= the maximum section
+	alignment.  Align the PT_GNU_RELRO segment first.  Subtract the maximum
+	page size if therer is still a 1-page gap.
+
+		PR ld/28743
+		PR ld/28819
+		* ldlang.c (lang_size_relro_segment_1): Rewrite.
+		* testsuite/ld-x86-64/pr28743-1.d: New file.
+		* testsuite/ld-x86-64/pr28743-1.s: Likewise.
+		* testsuite/ld-x86-64/x86-64.exp: Run pr28743-1.
+
+2022-01-26  Lancelot SIX  <lancelot.six@amd.com>
+
+	gdb/testsuite: Ensure constant test name in gdb.base/break-interp.exp
+	When running the testsuite, I have lines similar to the following in the
+	gdb.sum file:
+
+	~~~
+	PASS: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: first backtrace: p /x 0x7f283d2f0fd1
+	...
+	PASS: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: binprelink=NO: binsepdebug=NO: binpie=NO: INNER: first backtrace: p /x 0x7f00de0317a5
+	...
+	~~~
+
+	The address part of the command might change between execution of the
+	test, which adds noise to a diff between two .sum files.
+
+	This patch changes to test name to "p /x $pc" in order to have constant
+	test name.
+
+	Tested on x86_64-Linux.
+
+	Change-Id: I973c1237a084dd6d424276443cbf0920533c9a21
+
+2022-01-26  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-25  Tom Tromey  <tom@tromey.com>
+
+	Always print the "host libthread-db" message to stdout
+	linux-thread-db.c has a bit of unusual code that unconditionally
+	prints a message, but decides whether to print to gdb_stdout or
+	gdb_stdlog based on a debug flag.  It seems better to me to simply
+	always print this; and this is the only spot in gdb where we
+	conditionally pass gdb_stdout to one of the f*_unfiltered functions.
+
+2022-01-25  Tom Tromey  <tom@tromey.com>
+
+	Reduce explicit use of gdb_stdout
+	In an earlier version of the pager rewrite series, it was important to
+	audit unfiltered output calls to see which were truly necessary.
+
+	This is no longer necessary, but it still seems like a decent cleanup
+	to change calls to avoid explicitly passing gdb_stdout.  That is,
+	rather than using something like fprintf_unfiltered with gdb_stdout,
+	the code ought to use plain printf_unfiltered instead.
+
+	This patch makes this change.  I went ahead and converted all the
+	_filtered calls I could find, as well, for the same clarity.
+
+2022-01-25  Tom Tromey  <tom@tromey.com>
+
+	Sent timing stats to gdb_stdlog
+	This changes the time / space / symtab per-command statistics code to
+	send its output to gdb_stdlog rather than gdb_stdout.  This seems
+	slightly more correct to me.
+
+	Send some error output to gdb_stderr
+	This changes some code to send some error messages to gdb_stderr
+	rather than gdb_stdout.
+
+2022-01-25  Klaus Ziegler  <klausz@haus-gisela.de>
+
+	Fix a probem building the binutils on SPARC/amd64
+		PR 28816
+		* elf/common.h (AT_SUN_HWCAP): Make definition conditional.
+
+2022-01-25  H.J. Lu  <hjl.tools@gmail.com>
+
+	bfd: Regenerate Makefile.in
+		* Makefile.in: Regenerate.
+
+2022-01-25  Mike Frysinger  <vapier@gentoo.org>
+
+	gold: drop old cygnus install hack
+	The gold subdir doesn't actually have a manual, so this hack doesn't
+	do anything.  Plus the automake cygnus option was removed years ago
+	by Simon in d0ac1c44885daf68f631befa37e ("Bump to autoconf 2.69 and
+	automake 1.15.1").  So delete it here.
+
+	gas: drop old cygnus install hack
+	This was needed when gas was using the automake cygnus option, but
+	this was removed years ago by Simon in d0ac1c44885daf68f631befa37e
+	("Bump to autoconf 2.69 and automake 1.15.1").  So delete it here.
+	The info pages are already & still installed by default w/out it.
+
+2022-01-25  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-24  H.J. Lu  <hjl.tools@gmail.com>
+
+	bfd: Update doc/local.mk
+		PR binutils/28807
+		* Makefile.in: Regenerate.
+		* doc/local.mk (AM_MAKEINFOFLAGS): Add -I "$(srcdir)/%D%" -I %D%.
+		(TEXI2DVI): New.
+		(%D%/bfd.texi): Removed.
+		(doc/bfd/index.html): Remove -I$(srcdir).  Replace bfd.texi with
+		%D%/bfd.texi.
+
+2022-01-24  Roland McGrath  <mcgrathr@google.com>
+
+	bfd/doc: Fix racy build failure from missing mkdir
+	bfd/
+		* doc/local.mk (%D%/bfdver.texi): Add mkdir command.
+
+2022-01-24  Martin Sebor  <msebor@redhat.com>
+
+	Fix a proble building the libiberty library with gcc-12.
+		PR 28779
+		* regex.c: Suppress -Wuse-after-free.
+
+2022-01-24  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/doc: improve description for Window.click on Python TUI windows
+	The description of the Window.click method doesn't mention where the
+	coordinates are anchored (it's the top left corner).
+
+	This minor tweak just mentions this point.
+
+2022-01-24  Nick Clifton  <nickc@redhat.com>
+
+	Update Bulgarian, French, Romaniam and Ukranian translation for some of the sub-directories
+
+2022-01-24  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-23  Tom Tromey  <tom@tromey.com>
+
+	Simplify some Rust expression-evaluation code
+	A few Rust operations do a bit of work in their 'evaluate' functions
+	and then call another function -- but are also the only caller.  This
+	patch simplifies this code by removing the extra layer.
+
+	Tested on x86-64 Fedora 34.  I'm checking this in.
+
+2022-01-23  H.J. Lu  <hjl.tools@gmail.com>
+
+	bfd: Partially revert commit 0e3839bde6f
+	Partially revert
+
+	commit 0e3839bde6f93e1e3eefce815be3636e3d81054d
+	Author: H.J. Lu <hjl.tools@gmail.com>
+	Date:   Sun Jan 23 07:29:27 2022 -0800
+
+	    bfd: Properly install library and header files
+
+		PR binutils/28807
+		* Makefile.am: Revert bfdlib_LTLIBRARIES and bfdinclude_HEADERS
+		changes.
+		* Makefile.in: Regenerate.
+
+2022-01-23  H.J. Lu  <hjl.tools@gmail.com>
+
+	bfd: Properly install library and header files
+	Rename bfdlib_LTLIBRARIES and bfdinclude_HEADERS to lib_LTLIBRARIES and
+	include_HEADERS to fix the missing installed library and header files in
+	bfd caused by
+
+	commit bd32be01c997f686ab0b53f0640eaa0aeb61fbd3
+	Author: Mike Frysinger <vapier@gentoo.org>
+	Date:   Fri Dec 3 00:23:20 2021 -0500
+
+	    bfd: merge doc subdir up a level
+
+		PR binutils/28807
+		* Makefile.am (bfdlib_LTLIBRARIES): Renamed to ...
+		(lib_LTLIBRARIES): This.
+		(bfdinclude_HEADERS): Renamed to ...
+		(include_HEADERS): This.
+		* Makefile.in: Regenerate.
+		* doc/local.mk (install): Removed.
+
+2022-01-23  H.J. Lu  <hjl.tools@gmail.com>
+
+	Regenerate Makefile.in files with automake 1.15.1
+	Regenerate Makefile.in files with the unmodified automake 1.15.1 to
+	remove
+
+	runstatedir = @runstatedir@
+
+	bfd/
+
+		* Makefile.in: Regenerate.
+
+	binutils/
+
+		* Makefile.in: Regenerate.
+
+	gas/
+
+		* Makefile.in: Regenerate.
+
+	gold/
+
+		* Makefile.in: Regenerate.
+		* testsuite/Makefile.in: Likewise.
+
+	gprof/
+
+		* Makefile.in: Regenerate.
+
+	ld/
+
+		* Makefile.in: Regenerate.
+
+	opcodes/
+
+		* Makefile.in: Regenerate.
+
+2022-01-23  H.J. Lu  <hjl.tools@gmail.com>
+
+	Regenerate configure files with autoconf 2.69
+	Regenerate configure files with the unmodified autoconf 2.69 to remove
+
+	  --runstatedir=DIR       modifiable per-process data [LOCALSTATEDIR/run]
+
+	bfd/
+
+		* configure: Regenerate.
+
+	binutils/
+
+		* configure: Regenerate.
+
+	gas/
+
+		* configure: Regenerate.
+
+	gold/
+
+		* configure: Regenerate.
+
+	gprof/
+
+		* configure: Regenerate.
+
+	ld/
+
+		* configure: Regenerate.
+
+	opcodes/
+
+		* configure: Regenerate.
+
+2022-01-23  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-22  Mike Frysinger  <vapier@gentoo.org>
+
+	bfd: merge doc subdir up a level
+	This avoids a recursive make into the doc subdir and speeds up the
+	build slightly.  It also allows for more parallelism.
+
+	bfd: rename core.texi to corefile.texi
+	This is a generated file name from a correspondingly named C file.
+	Rename it to avoid unique build rules since there's no difference
+	to the generated manual.
+
+	bfd: replace doc header generation with pattern rules
+	This unifies boilerplate rules for most files with pattern rules.
+
+2022-01-22  Martin Storsj?  <martin@martin.st>
+
+	Allow inferring tmp_prefix from the dll name from a def file.
+
+2022-01-22  Alexander von Gluck IV  <kallisti5@unixzen.com>
+
+	Adjust default page sizes for haiku arm.
+		* configure.tgt (arm-haiku): Fix typo.
+		* emulparams/armelf_haiku.su (MAXPAGESIZE): Use the default value.
+		(COMMONPAGESIZE): Likewise.
+
+2022-01-22  Nick Clifton  <nickc@redhat.com>
+
+	Update release makeing script with new release numbers
+
+	Change version number to 2.38.50 and regenerate files
+
+	Add markers for 2.38 branch
+
+2022-01-22  Lifang Xia  <lifang_xia@linux.alibaba.com>
+
+	RISC-V: create new frag after alignment.
+	PR 28793:
+
+	The alignment may be removed in linker. We need to create new frag after
+	alignment to prevent the assembler from computing static offsets.
+
+	gas/
+		* config/tc-riscv.c (riscv_frag_align_code): Create new frag.
+
+2022-01-22  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-21  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: include gdbsupport/buildargv.h in ser-mingw.c
+	Fixes:
+
+	      CXX    ser-mingw.o
+	    /home/simark/src/binutils-gdb/gdb/ser-mingw.c: In function ‘int pipe_windows_open(serial*, const char*)’:
+	    /home/simark/src/binutils-gdb/gdb/ser-mingw.c:870:3: error: ‘gdb_argv’ was not declared in this scope
+	      870 |   gdb_argv argv (name);
+	          |   ^~~~~~~~
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28802
+	Change-Id: I7f3e8ec5f9ca8582d587545fdf6b69901259f199
+
+2022-01-21  Nick Clifton  <nickc@redhat.com>
+
+	Updated Serbian translation for the ld sub-directory
+
+2022-01-21  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/doc: fill in two missing @r
+	I noticed two places in the docs where we appear to be missing @r.
+	makeinfo seems to do the correct things despite these being
+	missing (at least, I couldn't see any difference in the pdf or info
+	output), but it doesn't hurt to have the @r in place.
+
+2022-01-21  Mike Frysinger  <vapier@gentoo.org>
+
+	drop old unused stamp-h.in file
+	This was needed by ancient versions of automake, but that hasn't been
+	the case since at least automake-1.5, so punt this from the tree.
+
+2022-01-21  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdbsupport/gdb_regex.cc: replace defs.h include with common-defs.h
+	This was forgotten when gdb_regex was moved from gdb to gdbsupport.
+
+	Change-Id: I73b446f71861cabbf7afdb7408ef9d59fa64b804
+
+2022-01-21  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-20  Tom Tromey  <tromey@adacore.com>
+
+	Avoid bad breakpoints with --gc-sections
+	We found a case where --gc-sections can cause gdb to set an invalid
+	breakpoint.  In the included test case, gdb will set a breakpoint with
+	two locations, one of which is 0x0.
+
+	The code in lnp_state_machine::check_line_address is intended to
+	filter out this sort of problem, but in this case, the entire CU is
+	empty, causing unrelocated_lowpc==0x0 -- which circumvents the check.
+
+	It seems to me that if a CU is empty like this, then it is ok to
+	simply ignore the line table, as there won't be any locations anyway.
+
+2022-01-20  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-19  Maciej W. Rozycki  <macro@embecosm.com>
+
+	Add `set print array-indexes' tests for C/C++ arrays
+	Add `set print array-indexes' tests for C/C++ arrays, complementing one
+	for Fortran arrays.
+
+2022-01-19  Maciej W. Rozycki  <macro@embecosm.com>
+
+	Respect `set print array-indexes' with Fortran arrays
+	Add `set print array-indexes' handling for Fortran arrays.  Currently
+	the setting is ignored and indices are never shown.
+
+	Keep track of the most recent index handled so that any outstanding
+	repeated elements printed when the limit set by `set print elements' is
+	hit have the correct index shown.
+
+	Output now looks like:
+
+	(gdb) set print array-indexes on
+	(gdb) print array_1d
+	$1 = ((-2) = 1, (-1) = 1, (0) = 1, (1) = 1, (2) = 1)
+	(gdb) set print repeats 4
+	(gdb) set print elements 12
+	(gdb) print array_2d
+	$2 = ((-2) = ((-2) = 2, <repeats 5 times>) (-1) = ((-2) = 2, <repeats 5 times>) (0) = ((-2) = 2, (-1) = 2, ...) ...)
+	(gdb)
+
+	for a 5-element vector and a 5 by 5 array filled with the value of 2.
+
+2022-01-19  Maciej W. Rozycki  <macro@embecosm.com>
+
+	Add `set print repeats' tests for C/C++ arrays
+	Add `set print repeats' tests for C/C++ arrays, complementing one for
+	Fortran arrays and covering the different interpretation of the `set
+	print elements' setting in particular where the per-dimension count of
+	the elements handled is matched against the trigger rather than the
+	total element count as with Fortran arrays.
+
+2022-01-19  Maciej W. Rozycki  <macro@embecosm.com>
+
+	Respect `set print repeats' with Fortran arrays
+	Implement `set print repeats' handling for Fortran arrays.  Currently
+	the setting is ignored and always treated as if no limit was set.
+
+	Unlike the generic array walker implemented decades ago the Fortran one
+	is a proper C++ class.  Rather than trying to mimic the old walker then,
+	which turned out a bit of a challenge where interacting with the `set
+	print elements' setting, write it entirely from scratch, by adding an
+	extra specialization handler method for processing dimensions other than
+	the innermost one and letting the specialization class call the `walk_1'
+	method from the handler as it sees fit.  This way repeats can be tracked
+	and the next inner dimension recursed into as a need arises only, or
+	unconditionally in the base class.
+
+	Keep track of the dimension number being handled in the class rather as
+	a parameter to the walker so that it does not have to be passed across
+	by the specialization class.
+
+	Use per-dimension element count tracking, needed to terminate processing
+	early when the limit set by `set print elements' is hit.  This requires
+	extra care too where the limit triggers exactly where another element
+	that is a subarray begins.  In that case rather than recursing we need
+	to terminate processing or lone `(...)' would be printed.  Additionally
+	if the skipped element is the last one in the current dimension we need
+	to print `...' by hand, because `continue_walking' won't print it at the
+	upper level, because it can see the last element has already been taken
+	care of.
+
+	Preserve the existing semantics of `set print elements' where the total
+	count of the elements handled is matched against the trigger level which
+	is unlike with the C/C++ array printer where the per-dimension element
+	count is used instead.
+
+	Output now looks like:
+
+	(gdb) set print repeats 4
+	(gdb) print array_2d
+	$1 = ((2, <repeats 5 times>) <repeats 5 times>)
+	(gdb) set print elements 12
+	(gdb) print array_2d
+	$2 = ((2, <repeats 5 times>) (2, <repeats 5 times>) (2, 2, ...) ...)
+	(gdb)
+
+	for a 5 by 5 array filled with the value of 2.
+
+	Amend existing test cases accordingly that rely on the current incorrect
+	behavior and explicitly request that there be no limit for printing
+	repeated elements there.
+
+	Add suitable test cases as well covering sliced arrays in particular.
+
+	Co-Authored-By: Andrew Burgess <andrew.burgess@embecosm.com>
+
+2022-01-19  John Baldwin  <jhb@FreeBSD.org>
+
+	fbsd-nat: Add include for gdb_argv.
+
+2022-01-19  Alan Modra  <amodra@gmail.com>
+
+	PowerPC64 DT_RELR ELFv1
+	More fun with R_PPC64_NONE found in .opd.  Fixed by the
+	allocate_dynrelocs and ppc64_elf_size_dynamic_sections changes, and
+	since we are doing ifunc, opd and SYMBOL_REFERENCES_LOCAL tests later,
+	don't duplicate that work in check_relocs.
+
+		* elf64-ppc.c (ppc64_elf_check_relocs): Remove opd and ifunc
+		conditions for rel_count.
+		(dec_dynrel_count): Likewise.
+		(allocate_dynrelocs): Test for opd and ifunc when allocating
+		relative relocs.
+		(ppc64_elf_size_dynamic_sections): Likewise.
+
+2022-01-19  Alan Modra  <amodra@gmail.com>
+
+	PowerPC64 DT_RELR local PLT
+	Similarly to the local GOT case.
+
+		* elf64-ppc.c (ppc64_elf_size_dynamic_sections): Don't allocate
+		space for PLT relocs against local syms when enable_dt_relr.
+
+2022-01-19  Alan Modra  <amodra@gmail.com>
+
+	PowerPC64 DT_RELR local GOT
+	Fixes another case where we end up with superfluous R_PPC64_NONE.
+
+		* elf64-ppc.c (ppc64_elf_size_dynamic_sections): Don't allocate
+		space for GOT relocs against non-TLS local syms when enable_dt_relr.
+		(ppc64_elf_layout_multitoc): Likewise.
+
+2022-01-19  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-18  Alan Modra  <amodra@gmail.com>
+
+	Re: PowerPC64 DT_RELR
+	HJ: "There are 238 R_PPC64_NONEs in libc.so.6 alone."
+	Indeed, let's make them go away.  I had the SYMBOL_REFERENCES_LOCAL
+	test in the wrong place.  check_relocs is too early to know whether a
+	symbol is dynamic in a shared library.  Lots of glibc symbols are made
+	local by version script, but that doesn't happen until
+	size_dynamic_sections.
+
+		* elf64-ppc.c (ppc64_elf_check_relocs): Don't count relative relocs
+		here depending on SYMBOL_REFERENCES_LOCAL.
+		(dec_dynrel_count): Likewise.
+		(allocate_dynrelocs): Do so here instead.
+
+2022-01-18  Tom Tromey  <tom@tromey.com>
+
+	Fix the remote-sim.c build
+	My earlier patch to move gdb_argv broke the remote-sim.c build.  This
+	patch fixes the bug.  I'm checking it in.
+
+2022-01-18  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdbserver: introduce remote_debug_printf
+	Add remote_debug_printf, and use it for all debug messages controlled by
+	remote_debug.
+
+	Change remote_debug to be a bool, which is trivial in this case.
+
+	Change-Id: I90de13cb892faec3830047b571661822b126d6e8
+
+2022-01-18  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdbserver: introduce threads_debug_printf, THREADS_SCOPED_DEBUG_ENTER_EXIT
+	Add the threads_debug_printf and THREADS_SCOPED_DEBUG_ENTER_EXIT, which
+	use the logging infrastructure from gdbsupport/common-debug.h.  Replace
+	all debug_print uses that are predicated by debug_threads with
+	threads_dethreads_debug_printf.  Replace uses of the debug_enter and
+	debug_exit macros with THREADS_SCOPED_DEBUG_ENTER_EXIT, which serves
+	essentially the same purpose, but allows showing what comes between the
+	enter and the exit in an indented form.
+
+	Note that "threads" debug is currently used for a bit of everything in
+	GDBserver, not only threads related stuff.  It should ideally be cleaned
+	up and separated logically as is done in GDB, but that's out of the
+	scope of this patch.
+
+	Change-Id: I2d4546464462cb4c16f7f1168c5cec5a89f2289a
+
+2022-01-18  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdbserver: turn debug_threads into a boolean
+	debug_threads is always used as a boolean.  Except in ax.cc and
+	tracepoint.cc.  These files have their own macros that use
+	debug_threads, and have a concept of verbosity level.  But they both
+	have a single level, so it's just a boolean in the end.
+
+	Remove this concept of level.  If we ever want to re-introduce it, I
+	think it will be better implemented in a more common location.
+
+	Change debug_threads to bool and adjust some users that were treating it
+	as an int.
+
+	Change-Id: I137f596eaf763a08c977dd74417969cedfee9ecf
+
+2022-01-18  Tom Tromey  <tom@tromey.com>
+
+	Simplify Ada catchpoints
+	All the Ada catchpoints use the same breakpoint_ops contents, because
+	the catchpoint itself records its kind.  This patch simplifies the
+	code by removing the redundant ops structures.
+
+	Move "catch exec" to a new file
+	The "catch exec" code is reasonably self-contained, and so this patch
+	moves it out of breakpoint.c (the second largest source file in gdb)
+	and into a new file, break-catch-exec.c.
+
+	Move "catch fork" to a new file
+	The "catch fork" code is reasonably self-contained, and so this patch
+	moves it out of breakpoint.c (the second largest source file in gdb)
+	and into a new file, break-catch-fork.c.
+
+	Unify "catch fork" and "catch vfork"
+	I noticed that "catch fork" and "catch vfork" are nearly identical.
+	This patch simplifies the code by unifying these two cases.
+
+	Move gdb_regex to gdbsupport
+	This moves the gdb_regex convenience class to gdbsupport.
+
+	Introduce gdb-hashtab module in gdbsupport
+	gdb has some extensions and helpers for working with the libiberty
+	hash table.  This patch consolidates these and moves them to
+	gdbsupport.
+
+	Move gdb obstack code to gdbsupport
+	This moves the gdb-specific obstack code -- both extensions like
+	obconcat and obstack_strdup, and things like auto_obstack -- to
+	gdbsupport.
+
+	Move gdb_argv to gdbsupport
+	This moves the gdb_argv class to a new header in gdbsupport.
+
+	Simplify event_location_probe
+	event_location_probe currently stores two strings, but really only
+	needs one.  This patch simplifies it and removes some unnecessary
+	copies as well.
+
+	Use std::string in event_location
+	This changes event_location to use std::string, removing some manual
+	memory management, and an unnecessary string copy.
+
+	Split event_location into subclasses
+	event_location uses the old C-style discriminated union approach.
+	However, it's better to use subclassing, as this makes the code
+	clearer and removes some chances for error.  This also enables future
+	cleanups to avoid manual memory management and copies.
+
+	Remove EL_* macros from location.c
+	This patch removes the old-style EL_* macros from location.c.  This
+	cleans up the code by itself, IMO, but also enables further cleanups
+	in subsequent patches.
+
+	Boolify explicit_to_string_internal
+	This changes explicit_to_string_internal to use 'bool' rather than
+	'int'.
+
+	Remove a use of xfree in location.c
+	This small cleanup removes a use of xfree from location.c, by
+	switching to unique_xmalloc_ptr.  One function is only used in
+	location.c, so it is made static.  And, another function is changed to
+	avoid a copy.
+
+2022-01-18  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: use ptid_t::to_string instead of target_pid_to_str in debug statements
+	Same idea as 0fab79556484 ("gdb: use ptid_t::to_string in infrun debug
+	messages"), but throughout GDB.
+
+	Change-Id: I62ba36eaef29935316d7187b9b13d7b88491acc1
+
+2022-01-18  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: preserve `|` in connection details string
+	Consider this GDB session:
+
+	  $ gdb -q
+	  (gdb) target remote  | gdbserver - ~/tmp/hello.x
+	  Remote debugging using | gdbserver - ~/tmp/hello.x
+	  ... snip ...
+	  (gdb) info connections
+	    Num  What                              Description
+	  * 1    remote gdbserver - ~/tmp/hello.x  Remote target using gdb-specific protocol
+	  (gdb) python conn = gdb.selected_inferior().connection
+	  (gdb) python print(conn.details)
+	  gdbserver - ~/tmp/hello.x
+	  (gdb)
+
+	I think there are two things wrong here, first in the "What" column of
+	the 'info connections' output, I think the text should be:
+
+	  remote | gdbserver - ~/tmp/hello.x
+
+	to correctly show the user how the connection was established.  And in
+	a similar fashion, I think that the `details` string of the
+	gdb.TargetConnection object should be:
+
+	  | gdbserver - ~/tmp/hello.x
+
+	This commit makes this change.  Currently the '|' is detected and
+	removed in gdb/serial.c.  The string passed to the pipe_ops
+	structure (from gdb/ser-pipe.c), doesn't then, contain the `|`, this
+	is instead implied by the fact that it is a pipes based implementation
+	of the serial_ops interface.
+
+	After this commit we still detect the `|` in gdb/serial.c, but we now
+	store the full string (including the `|`) in the serial::name member
+	variable.
+
+	For pipe based serial connections, this name is only used for
+	displaying the two fields I mention above, and in pipe_open (from
+	gdb/ser-pipe.c), and in pipe_open, we now know to skip over the `|`.
+
+	The benefit I see from this change is that GDB's output now more
+	accurately reflects the commands used to start a target, thus making
+	it easier for a user to understand what is going on.
+
+2022-01-18  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: testsuite: print explicit test result for gdb.base/dfp-test.exp
+	In the current code, if decimal floating point is not supported for
+	this target, there is no binary file dfp-test, and also there is no
+	test result after execute the following commands:
+
+	  $ make check-gdb TESTS="gdb.base/dfp-test.exp"
+	  $ grep error gdb/testsuite/gdb.log
+	  /home/loongson/gdb.git/gdb/testsuite/gdb.base/dfp-test.c:39:1: error: decimal floating point not supported for this target
+	  [...]
+	  $ cat gdb/testsuite/gdb.sum
+	  [...]
+	  Running target unix
+	  Running /home/loongson/gdb.git/gdb/testsuite/gdb.base/dfp-test.exp ...
+
+			  === gdb Summary ===
+	  [...]
+
+	With this patch:
+
+	  $ make check-gdb TESTS="gdb.base/dfp-test.exp"
+	  $ cat gdb/testsuite/gdb.sum
+	  [...]
+	  Running target unix
+	  Running /home/loongson/gdb.git/gdb/testsuite/gdb.base/dfp-test.exp ...
+	  UNSUPPORTED: gdb.base/dfp-test.exp: decimal floating point not supported for this target.
+
+			  === gdb Summary ===
+
+	  # of unsupported tests		1
+	  [...]
+
+2022-01-18  Simon Marchi  <simon.marchi@efficios.com>
+
+	bfd/elf64-ppc.c: fix clang -Wbitwise-instead-of-logical warning in ppc64_elf_check_init_fini
+	I see this error with clang-14:
+
+	      CC       elf64-ppc.lo
+	    /home/smarchi/src/binutils-gdb/bfd/elf64-ppc.c:13131:11: error: use of bitwise '&' with boolean operands [-Werror,-Wbitwise-instead-of-logical]
+	      return (check_pasted_section (info, ".init")
+	             ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+	Fix by replacing & with &&.  But given that the check_pasted_section
+	function has side-effects and we want to make sure both calls are made,
+	assign to temporary variables before evaluating the `&&`.
+
+	Change-Id: I849e1b2401bea5f4d8ef3ab9af99ba9e3ef42490
+
+2022-01-18  Alan Modra  <amodra@gmail.com>
+
+	PR28029, debuginfod tests
+	binutils/NEWS says of the change in --process-links semantics:
+	  If other debug section display options are also enabled (eg
+	  --debug-dump=info) then the contents of matching sections in both the main
+	  file and the separate debuginfo file *will* be displayed.  This is because in
+	  most cases the debug section will only be present in one of the files.
+
+	Implying that debug info is dumped without --process-links.  Indeed
+	that appears to be the case for readelf.  This does the same for
+	objdump.
+
+		PR 28029
+		* objdump.c (dump_bfd): Do not exit early when !is_mainfile
+		&& !processlinks, instead just exclude non-debug output.
+		(dump_dwarf): Add is_mainfile parameter and pass to
+		dump_dwarf_section.
+		(dump_dwarf_section): Only display debug sections when
+		!is_mainfile and !process_links.
+
+2022-01-18  Alan Modra  <amodra@gmail.com>
+
+	Check thin archive element file size against archive header
+	Makes it a little less likely for someone to break their thin archives.
+
+		* archive.c (_bfd_get_elt_at_filepos): Check thin archive
+		element file size.
+
+2022-01-18  Alan Modra  <amodra@gmail.com>
+
+	lang_size_relro_segment tidy
+	This function has seen too many minimal change style edits.
+	No functional changes in this patch.
+
+		* ldlang.c (lang_size_relro_segment): Tidy.
+
+2022-01-18  Alan Modra  <amodra@gmail.com>
+
+	PowerPC64 DT_RELR
+	PowerPC64 takes a more traditional approach to DT_RELR than x86.  Count
+	relative relocs in check_relocs, allocate space for them and output in
+	the usual places but not doing so when enable_dt_relr.  DT_RELR is
+	sized in the existing ppc stub relaxation machinery, run via the
+	linker's ldemul_after_allocation hook.  DT_RELR is output in the same
+	function that writes ppc stubs, run via ldemul_finish.
+
+	This support should be considered experimental.
+
+	bfd/
+		* elf64-ppc.c (struct ppc_local_dyn_relocs): Renamed from
+		ppc_dyn_relocs.  Add rel_count field.  Update uses.
+		(struct ppc_dyn_relocs): New.  Replace all uses of elf_dyn_relocs.
+		(struct ppc_link_hash_table): Add relr_alloc, relr_count and
+		relr_addr.
+		(ppc64_elf_copy_indirect_symbol): Merge rel_count.
+		(ppc64_elf_check_relocs): Init rel_count for global and local syms.
+		(dec_dynrel_count): Change r_info param to reloc pointer.  Update
+		all callers.  Handle decrementing rel_count.
+		(allocate_got): Don't allocate space for relative relocs when
+		enable_dt_relr.
+		(allocate_dynrelocs): Likewise.
+		(ppc64_elf_size_dynamic_sections): Likewise.  Handle srelrdyn.
+		(ppc_build_one_stub): Don't emit relative relocs on .branch_lt.
+		(compare_relr_address, append_relr_off): New functions.
+		(got_and_plt_relr_for_local_syms, got_and_plt_relr): Likewise.
+		(ppc64_elf_size_stubs): Size .relr.syn.
+		(ppc64_elf_build_stubs): Emit .relr.dyn.
+		(build_global_entry_stubs_and_plt): Don't output relative relocs
+		when enable_dt_relr.
+		(write_plt_relocs_for_local_syms): Likewise.
+		(ppc64_elf_relocate_section): Likewise.
+	binutils/
+		* testsuite/lib/binutils-common.exp (supports_dt_relr): Add
+		powerpc64.
+	ld/
+		* emulparams/elf64ppc.sh: Source dt-relr.sh.
+		* testsuite/ld-elf/dt-relr-2b.d: Adjust for powerpc.
+		* testsuite/ld-elf/dt-relr-2c.d: Likewise.
+		* testsuite/ld-elf/dt-relr-2d.d: Likewise.
+		* testsuite/ld-elf/dt-relr-2e.d: Likewise.
+
+2022-01-18  Alan Modra  <amodra@gmail.com>
+
+	tweak __ehdr_start visibility and flags for check_relocs
+	bfd/
+		* elf-bfd.h (UNDEFWEAK_NO_DYNAMIC_RELOC): Test linker_def.
+	ld/
+		* ldelf.c (ldelf_before_allocation): Don't force __ehdr_start
+		local and hidden here..
+		* ldlang.c (lang_symbol_tweaks): ..do so here instead and set
+		def_regular and linker_def for check_relocs.  New function
+		extracted from lang_process.
+
+2022-01-18  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-17  Nick Clifton  <nickc@redhat.com>
+
+	Update the config.guess and config.sub files from the master repository and regenerate files.
+
+2022-01-17  Sergey Belyashov  <sergey.belyashov@gmail.com>
+
+	Fix Z80 assembly failure.
+		PR 28762
+		* app.c (do_scrub_chars): Correct handling when the symbol is not 'af'.
+
+2022-01-17  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/infrun: rename variable and move to more specific scope
+	Move the "started" variable to the scope it's needed, and rename it to
+	"step_over_started".
+
+	Change-Id: I56f3384dbd328f55198063bb855edda10f1492a3
+
+2022-01-17  Jan Beulich  <jbeulich@suse.com>
+
+	x86: adjust struct instr_info field types
+	Now that this lives on the stack, let's have it be a little less
+	wasteful in terms of space. Switch boolean fields to "bool" (also when
+	this doesn't change their size) and also limit the widths of "rex",
+	"rex_used", "op_ad", and "op_index". Do a little bit of re-ordering as
+	well to limit the number of padding holes.
+
+	x86: drop index16 field
+	There's a single use on a generally infrequently taken code path. Put
+	the necessary conditional there instead.
+
+	x86: drop most Intel syntax register name arrays
+	By making use of, in particular, oappend_maybe_intel() there's no need
+	for this redundant set of static data.
+
+	x86: fold variables in memory operand index handling
+	There's no real need for the pseudo-boolean "haveindex" or for separate
+	32-bit / 64-bit index pointers. Fold them into a single "indexes" and
+	set that uniformly to AT&T names, compensating by emitting the register
+	name via oappend_maybe_intel().
+
+	x86: constify disassembler static data
+	Now that the code is intended to be largely thread-safe, we'd better not
+	have any writable static objects.
+
+2022-01-17  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-16  Joel Brobecker  <brobecker@adacore.com>
+
+	gdb/copyright.py: Do not update gdbsupport/Makefile.in
+	This file is generated, so we should not modify it (any modification
+	we make is going to be undone at the next re-generation anyway).
+
+2022-01-16  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-15  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-14  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb.dlang/demangle.exp: update expected output for _D8demangle4testFnZv
+	Since commit ce2d3708bc8b ("Synchronize binutils libiberty sources with
+	gcc version."), I see this failure:
+
+	    demangle _D8demangle4testFnZv^M
+	    demangle.test(typeof(null))^M
+	    (gdb) FAIL: gdb.dlang/demangle.exp: _D8demangle4testFnZv
+
+	The commit imported the commit 0e32a5aa8bc9 ("libiberty: Add support for
+	D `typeof(*null)' types") from the gcc repository.  That commit includes
+	an update to libiberty/testsuite/d-demangle-expected, which updates a
+	test for the exact same mangled name:
+
+	     _D8demangle4testFnZv
+	    -demangle.test(none)
+	    +demangle.test(typeof(null))
+
+	I don't know anything about D, but give that the change was made by Iain
+	Buclaw, the D language maintainer, I trust him on that.
+
+	Fix our test by updating the expected output in the same way.
+
+	Note: it's not really useful to have all these D demangling tests in the
+	GDB testsuite, since there are demangling tests in libiberty.  We should
+	consider removing them, but we first need to make sure that everything
+	that is covered in gdb/testsuite/gdb.dlang/demangle.exp is also covered
+	in libiberty/testsuite/d-demangle-expected.
+
+	Change-Id: If2b290ea8367b8e1e0b90b20d4a6e0bee517952d
+
+2022-01-14  Nils-Christian Kempke  <nils-christian.kempke@intel.com>
+
+	gdb/testsuite: enable __INTEL_LLVM_COMPILER preprocessor in get_compiler_info
+	Intel Next Gen compiler defines preprocessor __INTEL_LLVM_COMPILER and provides
+	version info in __clang_version__ e.g. value: 12.0.0 (icx 2020.10.0.1113).
+
+	gdb/testsuite/ChangeLog:
+	2020-12-07  Abdul Basit Ijaz  <abdul.b.ijaz@intel.com>
+
+		* lib/compiler.c: Add Intel next gen compiler pre-processor check.
+		* lib/compiler.cc: Ditto.
+		* lib/fortran.exp (fortran_main): Check Intel next gen compiler in
+		test_compiler_info.
+
+2022-01-14  Alan Modra  <amodra@gmail.com>
+
+	PR28751 mbind2a / mbind2b regressions on powerpc*-linux
+	include/
+		* bfdlink.h (struct bfd_link_info): Add commonpagesize_is_set.
+	ld/
+		PR 28751
+		* emultempl/elf.em (handle_option): Set commonpagesize_is_set.
+		* ldelf.c (ldelf_after_parse): Don't error when only one of
+		-z max-page-size or -z common-page-size is given, correct the
+		other value to make it sane.
+		* testsuite/ld-elf/elf.exp (mbind2a, mbind2b): Do not pass
+		-z max-page-size.
+
+2022-01-14  Jan Beulich  <jbeulich@suse.com>
+
+	x86: drop ymmxmm_mode
+	This enumerator is not used by any table entry.
+
+	x86: share yet more VEX table entries with EVEX decoding
+	On top of prior similar work more opportunities have appeared in the
+	meantime. Note that this also happens to address the prior lack of
+	decoding of EVEX.L'L for VMOV{L,H}P{S,D} and VMOV{LH,HL}PS.
+
+	x86: consistently use scalar_mode for AVX512-FP16 scalar insns
+	For some reason the original AVFX512F insns were not taken as a basis
+	here, causing unnecessary divergence. While not an active issue, it is
+	still relevant to note that OP_XMM() has special treatment of e.g.
+	scalar_mode (marking broadcast as invalid). Such would better be
+	consistent for all sufficiently similar insns.
+
+	x86: record further wrong uses of EVEX.b
+	For one EVEX.W set does not imply EVEX.b is uniformly valid. Reject it
+	for modes which occur for insns allowing for EVEX.W to be set (noticed
+	with VMOV{H,L}PD and VMOVDDUP, and only in AT&T mode, but not checked
+	whether further insns would also have been impacted; I expect e.g.
+	VCMPSD would have had the same issue). And then the present concept of
+	broadcast makes no sense at all when the memory operand of an insn is
+	the destination.
+
+2022-01-14  Jan Beulich  <jbeulich@suse.com>
+
+	x86: reduce AVX512 FP set of insns decoded through vex_w_table[]
+	Like for AVX512-FP16, there's not that many FP insns where going through
+	this table is easier / cheaper than using suitable macros. Utilize %XS
+	and %XD more to eliminate a fair number of table entries.
+
+	While doing this I noticed a few anomalies. Where lines get touched /
+	moved anyway, these are being addressed right here:
+	- vmovshdup used EXx for its 2nd operand, thus displaying seemingly
+	  valid broadcast when EVEX.b is set with a memory operand; use
+	  EXEvexXNoBcst instead just like vmovsldup already does
+	- vmovlhps used EXx for its 3rd operand, when all sibling entries use
+	  EXq; switch to EXq there for consistency (the two differ only for
+	  memory operands)
+
+2022-01-14  Jan Beulich  <jbeulich@suse.com>
+
+	x86: reduce AVX512-FP16 set of insns decoded through vex_w_table[]
+	Like already indicated during review of the original submission, there's
+	really only very few insns where going through this table is easier /
+	cheaper than using suitable macros. Utilize %XH more and introduce
+	similar %XS and %XD (which subsequently can be used for further table
+	size reduction).
+
+	While there also switch to using oappend() in 'XH' macro processing.
+
+2022-01-14  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-13  H.J. Lu  <hjl.tools@gmail.com>
+
+	ld: Disable DT_RELR in some -z relro tests
+	Disable DT_RELR in the following -z relro tests which don't expect
+	DT_RELR in linker outputs.
+
+		* testsuite/ld-i386/pr20830.d: Pass $NO_DT_RELR_LDFLAGS to ld.
+		* testsuite/ld-x86-64/pr20830a-now.d: Likewise.
+		* testsuite/ld-x86-64/pr20830a.d: Likewise.
+		* testsuite/ld-x86-64/pr20830b-now.d: Likewise.
+		* testsuite/ld-x86-64/pr20830b.d: Likewise.
+		* testsuite/ld-x86-64/pr21038a-now.d: Likewise.
+		* testsuite/ld-x86-64/pr21038a.d: Likewise.
+		* testsuite/ld-x86-64/pr21038b-now.d: Likewise.
+		* testsuite/ld-x86-64/pr21038c-now.d: Likewise.
+		* testsuite/ld-x86-64/pr21038c.d: Likewise.
+
+2022-01-13  H.J. Lu  <hjl.tools@gmail.com>
+
+	Reapply libiberty: Pass --plugin to AR and RANLIB
+	Reapply the patch to detect GCC LTO plugin used for libiberty build to
+	support LTO build in libiberty.
+
+		* Makefile.in (AR): Add @AR_PLUGIN_OPTION@
+		(RANLIB): Add @RANLIB_PLUGIN_OPTION@.
+		(configure_deps): Depend on ../config/gcc-plugin.m4.
+		* aclocal.m4: Include ../config/gcc-plugin.m4.
+		* configure.ac: AC_SUBST AR_PLUGIN_OPTION and
+		RANLIB_PLUGIN_OPTION.
+		* configure: Regenerate.
+
+2022-01-13  H.J. Lu  <hjl.tools@gmail.com>
+
+	elf: Remove the 1-page gap before the RELRO segment
+	The existing RELRO scheme may leave a 1-page gap before the RELRO segment
+	and align the end of the RELRO segment to the page size:
+
+	  [18] .eh_frame    PROGBITS    408fa0 008fa0 005e80 00   A  0   0  8
+	  [19] .init_array  INIT_ARRAY  410de0 00fde0 000008 08  WA  0   0  8
+	  [20] .fini_array  FINI_ARRAY  410de8 00fde8 000008 08  WA  0   0  8
+	  [21] .dynamic     DYNAMIC     410df0 00fdf0 000200 10  WA  7   0  8
+	  [22] .got         PROGBITS    410ff0 00fff0 000010 08  WA  0   0  8
+	  [23] .got.plt     PROGBITS    411000 010000 000048 08  WA  0   0  8
+
+	Instead, we can remove the 1-page gap if the maximum page size >= the
+	maximum section alignment:
+
+	  [18] .eh_frame    PROGBITS    408fa0 008fa0 005e80 00   A  0   0  8
+	  [19] .init_array  INIT_ARRAY  40fde0 00fde0 000008 08  WA  0   0  8
+	  [20] .fini_array  FINI_ARRAY  40fde8 00fde8 000008 08  WA  0   0  8
+	  [21] .dynamic     DYNAMIC     40fdf0 00fdf0 000200 10  WA  7   0  8
+	  [22] .got         PROGBITS    40fff0 00fff0 000010 08  WA  0   0  8
+	  [23] .got.plt     PROGBITS    410000 010000 000048 08  WA  0   0  8
+
+	Because the end of the RELRO segment is always aligned to the page size
+	and may not be moved, the RELRO segment size may be increased:
+
+	  [ 3] .dynstr      STRTAB      000148 000148 000001 00   A  0   0  1
+	  [ 4] .eh_frame    PROGBITS    000150 000150 000000 00   A  0   0  8
+	  [ 5] .init_array  INIT_ARRAY  200150 000150 000010 08  WA  0   0  1
+	  [ 6] .fini_array  FINI_ARRAY  200160 000160 000010 08  WA  0   0  1
+	  [ 7] .jcr         PROGBITS    200170 000170 000008 00  WA  0   0  1
+	  [ 8] .data.rel.ro PROGBITS    200180 000180 000020 00  WA  0   0 16
+	  [ 9] .dynamic     DYNAMIC     2001a0 0001a0 0001c0 10  WA  3   0  8
+	  [10] .got         PROGBITS    200360 000360 0002a8 00  WA  0   0  8
+	  [11] .bss         NOBITS      201000 000608 000840 00  WA  0   0  1
+
+	vs the old section layout:
+
+	  [ 3] .dynstr      STRTAB      000148 000148 000001 00   A  0   0  1
+	  [ 4] .eh_frame    PROGBITS    000150 000150 000000 00   A  0   0  8
+	  [ 5] .init_array  INIT_ARRAY  200b48 000b48 000010 08  WA  0   0  1
+	  [ 6] .fini_array  FINI_ARRAY  200b58 000b58 000010 08  WA  0   0  1
+	  [ 7] .jcr         PROGBITS    200b68 000b68 000008 00  WA  0   0  1
+	  [ 8] .data.rel.ro PROGBITS    200b70 000b70 000020 00  WA  0   0 16
+	  [ 9] .dynamic     DYNAMIC     200b90 000b90 0001c0 10  WA  3   0  8
+	  [10] .got         PROGBITS    200d50 000d50 0002a8 00  WA  0   0  8
+	  [11] .bss         NOBITS      201000 000ff8 000840 00  WA  0   0  1
+
+	But there is no 1-page gap.
+
+		PR ld/28743
+		* ldlang.c (lang_size_relro_segment_1): Remove the 1-page gap
+		before the RELRO segment if the maximum page size >= the maximum
+		section alignment.
+		* testsuite/ld-i386/pr20830.d: Adjusted.
+		* testsuite/ld-s390/gotreloc_64-relro-1.dd: Likewise.
+		* testsuite/ld-x86-64/pr14207.d: Likewise.
+		* testsuite/ld-x86-64/pr18176.d: Likewise.
+		* testsuite/ld-x86-64/pr20830a-now.d: Likewise.
+		* testsuite/ld-x86-64/pr20830a.d: Likewise.
+		* testsuite/ld-x86-64/pr20830b-now.d: Likewise.
+		* testsuite/ld-x86-64/pr20830b.d: Likewise.
+		* testsuite/ld-x86-64/pr21038a-now.d: Likewise.
+		* testsuite/ld-x86-64/pr21038a.d: Likewise.
+		* testsuite/ld-x86-64/pr21038b-now.d: Likewise.
+		* testsuite/ld-x86-64/pr21038c-now.d: Likewise.
+		* testsuite/ld-x86-64/pr21038c.d: Likewise.
+
+2022-01-13  Nick Clifton  <nickc@redhat.com>
+
+	Synchronize binutils libiberty sources with gcc version.
+	+2021-12-30  Lancelot SIX  <lsix@lancelotsix.com>
+	+
+	+	* cp-demangle.c (d_clone_suffix): Support digits in clone tag
+	+	names.
+	+	* testsuite/demangle-expected: Check demangling of clone symbols
+	+	with digits in name.
+	+
+	+2021-12-16  H.J. Lu  <hjl.tools@gmail.com>
+	+
+	+	Revert:
+	+	2021-12-16  H.J. Lu  <hjl.tools@gmail.com>
+	+
+	+	* Makefile.in (AR): Add @AR_PLUGIN_OPTION@
+	+	(RANLIB): Add @RANLIB_PLUGIN_OPTION@.
+	+	(configure_deps): Depend on ../config/gcc-plugin.m4.
+	+	* configure.ac: AC_SUBST AR_PLUGIN_OPTION and
+	+	RANLIB_PLUGIN_OPTION.
+	+	* aclocal.m4: Regenerated.
+	+	* configure: Likewise.
+	+
+	+2021-12-15  H.J. Lu  <hjl.tools@gmail.com>
+	+
+	+	* Makefile.in (AR): Add @AR_PLUGIN_OPTION@
+	+	(RANLIB): Add @RANLIB_PLUGIN_OPTION@.
+	+	(configure_deps): Depend on ../config/gcc-plugin.m4.
+	+	* configure.ac: AC_SUBST AR_PLUGIN_OPTION and
+	+	RANLIB_PLUGIN_OPTION.
+	+	* aclocal.m4: Regenerated.
+	+	* configure: Likewise.
+	+
+	+2021-11-29  Eric Gallager  <egallager@gcc.gnu.org>
+	+
+	+	PR other/103021
+	+	* Makefile.in: Use ETAGS variable in TAGS target.
+	+	* configure: Regenerate.
+	+	* configure.ac: Allow ETAGS variable to be overridden.
+	+
+	+2021-11-29  Andrew Pinski  <apinski@marvell.com>
+	+
+	+	* make-temp-file.c (try_dir): Check to see if the dir
+	+	is actually a directory.
+	+
+	+2021-10-22  Eric Gallager  <egallager@gcc.gnu.org>
+	+
+	+	PR other/102663
+	+	* Makefile.in: Allow dvi-formatted documentation
+	+	to be installed.
+	+
+	+2021-10-17  Lu?s Ferreira  <contact@lsferreira.net>
+	+
+	+	PR d/102618
+	+	* d-demangle.c (dlang_parse_qualified): Handle anonymous
+	+	symbols correctly.
+	+	* testsuite/d-demangle-expected: New tests to cover anonymous
+	+	symbols.
+	+
+	+2021-10-14  Lu?s Ferreira  <contact@lsferreira.net>
+	+
+	+	* testsuite/d-demangle-expected: Add test case for function literals.
+	+
+	+2021-10-14  Lu?s Ferreira  <contact@lsferreira.net>
+	+
+	+	* testsuite/d-demangle-expected: Add test cases for simple special
+	+	mangles.
+	+
+	+2021-10-12  Lu?s Ferreira  <contact@lsferreira.net>
+	+
+	+	* d-demangle.c (dlang_parse_qualified): Remove redudant parenthesis
+	+	around lhs and rhs of assignments.
+	+
+	+2021-10-01  Lu?s Ferreira  <contact@lsferreira.net>
+	+
+	+	* testsuite/d-demangle-expected: Add missing format for new test
+	+
+	+2021-09-23  Lu?s Ferreira  <contact@lsferreira.net>
+	+
+	+	* d-demangle.c (dlang_Type): Validate MANGLED is nonnull.
+	+	* testsuite/d-demangle-expected: New test.
+	+
+	+2021-09-23  Lu?s Ferreira  <contact@lsferreira.net>
+	+
+	+	* d-demangle.c (dlang_symbol_backref): Ensure strlen of
+	+	string is less than length computed by dlang_number.
+	+
+	+2021-09-01  Iain Sandoe  <iain@sandoe.co.uk>
+
+	 	* configure: Regenerate.
+	+	* configure.ac: Do not search for sbrk on Darwin.
+	+	* xmalloc.c: Do not declare sbrk unless it has been found
+	+	by configure.
+	+
+	+2021-08-29  Iain Buclaw  <ibuclaw@gdcproject.org>
+	+
+	+	* d-demangle.c (dlang_identifier): Skip over fake parent manglings.
+	+	* testsuite/d-demangle-expected: Add tests.
+	+
+	+2021-08-29  Iain Buclaw  <ibuclaw@gdcproject.org>
+	+
+	+	* d-demangle.c (dlang_parse_arrayliteral): Add 'info' parameter.
+	+	(dlang_parse_assocarray): Likewise.
+	+	(dlang_parse_structlit): Likewise.
+	+	(dlang_value): Likewise.  Handle function literal symbols.
+	+	(dlang_template_args): Pass 'info' to dlang_value.
+	+	* testsuite/d-demangle-expected: Add new test.
+	+
+	+2021-08-29  Iain Buclaw  <ibuclaw@gdcproject.org>
+	+
+	+	* d-demangle.c (dlang_attributes): Handle typeof(*null).
+	+	(dlang_type): Likewise.  Demangle 'n' as typeof(null).
+	+	* testsuite/d-demangle-expected: Update tests.
+	+
+	+2021-08-23  Iain Sandoe  <iain@sandoe.co.uk>
+	+
+	+	* simple-object-mach-o.c (simple_object_mach_o_write_segment):
+	+	Cast the first argument to set_32 as needed.
+
+	-2021-07-03  Nick Clifton  <nickc@redhat.com>
+	+2021-08-18  Iain Sandoe  <iain@sandoe.co.uk>
+
+	+	* simple-object-mach-o.c (simple_object_mach_o_write_segment):
+	+	Arrange to swap the LTO index tables where needed.
+	 # Please enter the commit message for your changes. Lines starting
+
+2022-01-13  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: don't use -Wmissing-prototypes with g++
+	This commit aims to not make use of -Wmissing-prototypes when
+	compiling with g++.
+
+	Use of -Wmissing-prototypes was added with this commit:
+
+	  commit a0761e34f054767de6d6389929d27e9015fb299b
+	  Date:   Wed Mar 11 15:15:12 2020 -0400
+
+	      gdb: enable -Wmissing-prototypes warning
+
+	Because clang can provide helpful warnings with this flag.
+	Unfortunately, g++ doesn't accept this flag, and will give this
+	warning:
+
+	  cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++
+
+	In theory the fact that this flag is not supported should be detected
+	by the configure check in gdbsupport/warning.m4, but for users of
+	ccache, this check doesn't work due to a long standing ccache issue:
+
+	  https://github.com/ccache/ccache/issues/738
+
+	The ccache problem is that -W... options are reordered on the command
+	line, and so -Wmissing-prototypes is seen before -Werror.  Usually
+	this doesn't matter, but the above warning (about the flag not being
+	valid) is issued before the -Werror flag is processed, and so is not
+	fatal.
+
+	There have been two previous attempts to fix this that I'm aware of.
+	The first is:
+
+	  https://sourceware.org/pipermail/gdb-patches/2021-September/182148.html
+
+	In this attempt, instead of just relying on a compile to check if a
+	flag is valid, the proposal was to both compile and link.  As linking
+	doesn't go through ccache, we don't suffer from the argument
+	reordering problem, and the link phase will correctly fail when using
+	-Wmissing-prototypes with g++.  The configure script will then disable
+	the use of this flag.
+
+	This approach was rejected, and the suggestion was to only add the
+	-Wmissing-prototypes flag if we are compiling with gcc.
+
+	The second attempt, attempts this approach, and can be found here:
+
+	  https://sourceware.org/pipermail/gdb-patches/2021-November/183076.html
+
+	This attempt only adds the -Wmissing-prototypes flag is the value of
+	GCC is not 'yes'.  This feels like it is doing the right thing,
+	unfortunately, the GCC flag is really a 'is gcc like' flag, not a
+	strict, is gcc check.  As such, GCC is set to 'yes' for clang, which
+	would mean the flag was not included for clang or gcc.  The entire
+	point of the original commit was to add this flag for clang, so
+	clearly the second attempt is not sufficient either.
+
+	In this new attempt I have added gdbsupport/compiler-type.m4, this
+	file defines AM_GDB_COMPILER_TYPE.  This macro sets the variable
+	GDB_COMPILER_TYPE to either 'gcc', 'clang', or 'unknown'.  In future
+	the list of values might be extended to cover other compilers, if this
+	is ever useful.
+
+	I've then modified gdbsupport/warning.m4 to only add the problematic
+	-Wmissing-prototypes flag if GDB_COMPILER_TYPE is not 'gcc'.
+
+	I've tested this with both gcc and clang and see the expected results,
+	gcc no longer attempts to use the -Wmissing-prototypes flag, while
+	clang continues to use it.
+
+	When compiling using ccache, I am no longer seeing the warning.
+
+2022-01-13  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: add some extra debug information to attach_command
+	While working on another patch I wanted to add some extra debug
+	information to the attach_command function.  This required me to add a
+	new function to convert the thread_info::state variable to a string.
+
+	The new debug might be useful to others, and the state to string
+	function might be useful in other locations, so I thought I'd merge
+	it.
+
+2022-01-13  Alan Modra  <amodra@gmail.com>
+
+	Re: gas: add visibility support using GNU syntax on XCOFF
+	tc-ppc.c: In function 'ppc_comm':
+	tc-ppc.c:4560:40: error: 'visibility' may be used uninitialized in this function [-Werror=maybe-uninitialized]
+
+	With that fixed we hit lots of segfaults in the ld testsuite.
+
+		PR 22085
+	bfd/
+		* xcofflink.c (xcoff_link_input_bfd): Don't segfault on NULL
+		sym_hash.
+	gas/
+		* config/tc-ppc.c (ppc_comm): Init visibility.
+
+2022-01-13  Alan Modra  <amodra@gmail.com>
+
+	dt-relr.exp --no-as-needed
+	Otherwise the very simple test may not be linked with libc.so at all,
+	and thus correctly have no version reference added.  Causing failure
+	of the dt-relr-glibc-1b.so test.
+
+		* testsuite/ld-elf/dt-relr.exp: Link with --no-as-needed.
+
+2022-01-13  Alan Modra  <amodra@gmail.com>
+
+	Correct .relr.dyn nocombreloc script
+		* scripttempl/elf.sc (.relr.dyn): Don't depend on $COMBRELOC.
+
+2022-01-13  Alan Modra  <amodra@gmail.com>
+
+	testsuite supports_dt_relr
+	Tidy, and fix "FAIL: Build dt-relr-glibc-1b.so" on all non-x86
+	linux targets.
+
+	binutils/
+		* binutils-common.exp (supports_dt_relr): New proc.
+	ld/
+		* testsuite/config/default.exp (DT_RELR_LDFLAGS, NO_DT_RELR_LDFLAGS),
+		(DT_RELR_CC_LDFLAGS, NO_DT_RELR_CC_LDFLAGS): Use supports_dt_relr.
+		* testsuite/ld-elf/dt-relr.exp: Don't run unless supports_dt_relr.
+		* testsuite/ld-elf/dt-relr-1a.d: Likewise.
+		* testsuite/ld-elf/dt-relr-1b.d: Likewise.
+		* testsuite/ld-elf/dt-relr-1c.d: Likewise.
+		* testsuite/ld-elf/dt-relr-2a.d: Likewise.
+		* testsuite/ld-elf/dt-relr-2b.d: Likewise.
+		* testsuite/ld-elf/dt-relr-2c.d: Likewise.
+		* testsuite/ld-elf/dt-relr-2d.d: Likewise.
+		* testsuite/ld-elf/dt-relr-2e.d: Likewise.
+		* testsuite/ld-elf/dt-relr-2f.d: Likewise.
+		* testsuite/ld-elf/dt-relr-2g.d: Likewise.
+		* testsuite/ld-elf/dt-relr-2h.d: Likewise.
+		* testsuite/ld-elf/dt-relr-3a.d: Likewise.
+		* testsuite/ld-elf/dt-relr-3b.d: Likewise.
+
+2022-01-13  Alan Modra  <amodra@gmail.com>
+
+	Don't use C++ comments in assembly
+	It might seem to work, but only if '/' is a start of comment char.
+
+		* testsuite/ld-elf/dt-relr-1.s: Use # for comment.
+		* testsuite/ld-elf/dt-relr-2.s: Likewise.
+		* testsuite/ld-elf/dt-relr-3.s: Likewise.
+
+2022-01-13  Alan Modra  <amodra@gmail.com>
+
+	Move DT_RELR tag setting to elflink.c
+	This makes the code setting DT_RELR tags generally available.  Many
+	targets will be able to use the defaults.  Those that can't should set
+	up sh_entsize for .relr.dyn output section before reaching the dynamic
+	tag code in bfd_elf_final_link.
+
+		* elflink.c (bfd_elf_final_link): Set up DT_RELR tags and sh_entsize.
+		* elfxx-x86.c (_bfd_x86_elf_finish_dynamic_sections): Don't do any
+		of that here.
+
+2022-01-13  Alan Modra  <amodra@gmail.com>
+
+	Re: Set SEC_ELF_REVERSE_COPY earlier
+	Let's not rely on .init/.fini having relocs for the size sanity check.
+	This is mainly to squash reports of "my fuzzed object made ld hang".
+
+2022-01-13  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: testsuite: make string[] type as char in gdb.base/charset.c
+	This reverts the commit ff656e2e1cb1 ("gdb: testsuite: fix failed
+	testcases in gdb.base/charset.exp").
+
+	The original test code has no problem. On an architecture where
+	char is signed, then both 'A' and ebcdic_us_string[7] will yield
+	-63, which makes the equality true. On an architecture where char
+	is unsigned, then both 'A' and ebcdic_us_string[7] will yield 193,
+	which also makes the equality true.
+
+	The test cases only failed on LoongArch. The default type of char
+	is signed char on LoongArch, like x86-64. But when use gdb print
+	command on LoongArch, the default type of char is unsigned char,
+	this is wrong, I will look into it later, sorry for that.
+
+	On LoongArch:
+
+	  $ cat test_char.c
+	  #include <stdio.h>
+
+	  int main()
+	  {
+	          char c1 = 193;
+	          unsigned char c2 = 193;
+
+	          printf("%d\n", c1);
+	          printf("%d\n", c1 == c2);
+
+	          return 0;
+	  }
+	  $ gcc test_char.c -o test_char
+	  $ ./test_char
+	  -63
+	  0
+
+	  (gdb) set target-charset EBCDIC-US
+	  (gdb) print 'A'
+	  $1 = 193 'A'
+	  (gdb) print /c 'A'
+	  $2 = 193 'A'
+	  (gdb) print /u 'A'
+	  $3 = 193
+	  (gdb) print /d 'A'
+	  $4 = -63
+	  (gdb) print /x 'A'
+	  $5 = 0xc1
+
+2022-01-13  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-12  Carl Love  <cel@us.ibm.com>
+
+	gdb Power 9 add test for HW watchpoint support.
+	The Power 9 processor revision 2.2 has HW watchpoint support disabled due
+	to a HW bug.  The support is fixed in Power 9 processor revision 2.3.  This
+	patch add a test to lib/gdb.exp for Power to determine if the processor
+	supports HW watchpoints or not.  If the Power processor doesn't support HW
+	watchpoints the proceedure skip_hw_watchpoint_tests will return 1 to
+	disable the various HW watchpoint tests.
+
+	The patch has been tested on Power 9, processor revesions 2.2 and 2.3.  The
+	patch has also been tested on Power 10.  No regression test failures were
+	found.
+
+2022-01-12  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/python: add gdb.host_charset function
+	We already have gdb.target_charset and gdb.target_wide_charset.  This
+	commit adds gdb.host_charset along the same lines.
+
+2022-01-12  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>
+
+	gdb/testsuite: fix gdb.python/py-events.exp for finding process id
+	When executed with --target_board=native-extended-gdbserver, the
+	gdb.python/py-events.exp test errors out with
+
+	  ERROR: tcl error sourcing /path/to/gdb/testsuite/gdb.python/py-events.exp.
+	  ERROR: can't read "process_id": no such variable
+	      while executing
+	  "lappend expected "ptid: \\($process_id, $process_id, 0\\)" "address: $addr""
+	      (file "/path/to/gdb/testsuite/gdb.python/py-events.exp" line 103)
+	      invoked from within
+	  "source /path/to/gdb/testsuite/gdb.python/py-events.exp"
+	      ("uplevel" body line 1)
+	      invoked from within
+	  "uplevel #0 source /path/to/gdb/testsuite/gdb.python/py-events.exp"
+	      invoked from within
+	  "catch "uplevel #0 source $test_file_name""
+
+	There are multiple problems around this:
+
+	1. The process_id variable is not initialized to a default value.
+
+	2. The test attempts to find the PID of the current thread, but the
+	   regexp that it uses is not tailored for the output printed by the
+	   remote target.
+
+	3. The test uses "info threads" to find the current thread PID.
+	   Using the "thread" command instead is simpler.
+
+	Fix these problems.
+
+2022-01-12  Tom Tromey  <tromey@adacore.com>
+
+	Don't mention "serial" in target remote description
+	PR remote/9177 points out that "info files" mentions "serial" a couple
+	of times:
+
+	    Remote serial target in gdb-specific protocol:
+	    Debugging a target over a serial line.
+
+	However, often the remote target isn't really a serial connection.
+
+	It seems to me that this text could be a bit clearer; and furthermore
+	since "info files" prints the target's long description,
+	remote_target::files_info doesn't really add much and can simply be
+	removed.
+
+	Regression tested on x86-64 Fedora 34.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=9177
+
+2022-01-12  H.J. Lu  <hjl.tools@gmail.com>
+
+	ld: Add glibc dependency for DT_RELR
+	When DT_RELR is enabled, to avoid random run-time crash with older glibc
+	binaries without DT_RELR support, add a GLIBC_ABI_DT_RELR symbol version,
+	which is provided by glibc with DT_RELR support, dependency on the shared
+	C library if it provides a GLIBC_2.XX symbol version.
+
+	bfd/
+
+		* elflink.c (elf_link_add_dt_relr_dependency): New function.
+		(bfd_elf_size_dynamic_sections): Call
+		elf_link_add_dt_relr_dependency if DT_RELR is enabled.
+
+	ld/
+
+		* ld.texi: Mention GLIBC_ABI_DT_RELR in -z pack-relative-relocs
+		entry.
+		* testsuite/ld-elf/dt-relr-glibc-1.c: New file.
+		* testsuite/ld-elf/dt-relr-glibc-1a.rd: Likewise.
+		* testsuite/ld-elf/dt-relr-glibc-1b.rd: Likewise.
+		* testsuite/ld-elf/dt-relr.exp: Likewise.
+
+2022-01-12  H.J. Lu  <hjl.tools@gmail.com>
+
+	ld: Add simple DT_RELR tests
+		* testsuite/ld-elf/dt-relr-1.s: New file.
+		* testsuite/ld-elf/dt-relr-1a.d: Likewise.
+		* testsuite/ld-elf/dt-relr-1b.d: Likewise.
+		* testsuite/ld-elf/dt-relr-1c.d: Likewise.
+		* testsuite/ld-elf/dt-relr-2.s: Likewise.
+		* testsuite/ld-elf/dt-relr-2a.d: Likewise.
+		* testsuite/ld-elf/dt-relr-2b.d: Likewise.
+		* testsuite/ld-elf/dt-relr-2c.d: Likewise.
+		* testsuite/ld-elf/dt-relr-2d.d: Likewise.
+		* testsuite/ld-elf/dt-relr-2e.d: Likewise.
+		* testsuite/ld-elf/dt-relr-2f.d: Likewise.
+		* testsuite/ld-elf/dt-relr-2g.d: Likewise.
+		* testsuite/ld-elf/dt-relr-2h.d: Likewise.
+		* testsuite/ld-elf/dt-relr-3.s: Likewise.
+		* testsuite/ld-elf/dt-relr-3a.d: Likewise.
+		* testsuite/ld-elf/dt-relr-3b.d: Likewise.
+		* testsuite/ld-i386/dt-relr-1.s: Likewise.
+		* testsuite/ld-i386/dt-relr-1a.d: Likewise.
+		* testsuite/ld-i386/dt-relr-1b.d: Likewise.
+		* testsuite/ld-x86-64/dt-relr-1a-x32.d: Likewise.
+		* testsuite/ld-x86-64/dt-relr-1a.d: Likewise.
+		* testsuite/ld-x86-64/dt-relr-1b-x32.d: Likewise.
+		* testsuite/ld-x86-64/dt-relr-1b.d: Likewise.
+		* testsuite/ld-x86-64/dt-relr-1.s: Likewise.
+		* testsuite/ld-i386/i386.exp: Run dt-relr-1a and dt-relr-1b.
+		* testsuite/ld-x86-64/x86-64.exp: Run dt-relr-1a, dt-relr-1a-x32
+		dt-relr-1b and dt-relr-1b-x32.
+
+2022-01-12  H.J. Lu  <hjl.tools@gmail.com>
+
+	x86: Add DT_RELR support
+	DT_RELR is implemented with linker relaxation:
+
+	1. During linker relaxation, we scan input relocations with the same
+	logic in relocate_section to determine if a relative relocation should
+	be generated and save the relative relocation candidate information for
+	sizing the DT_RELR section later after all symbols addresses can be
+	determined.  For these relative relocations which can't be placed in
+	the DT_RELR section, they will be placed in the rela.dyn/rel.dyn
+	section.
+	2. When DT_RELR is enabled, _bfd_elf_map_sections_to_segments calls a
+	backend function to size the DT_RELR section which will compute the
+	DT_RELR section size and tell ldelf_map_segments to layout sections
+	again when the DT_RELR section size has been increased.
+	3. After regular symbol processing is finished, bfd_elf_final_link calls
+	a backend function to finish the DT_RELR section.
+
+		* elf32-i386.c (elf_i386_relocate_section): Don't generate
+		relative relocation when DT_RELR is enabled.
+		(elf_i386_finish_dynamic_symbol): Likewise.
+		* elf64-x86-64.c (elf_x86_64_relocate_section): Don't generate
+		relative relocation when DT_RELR is enabled.
+		(elf_x86_64_finish_dynamic_symbol): Likewise.
+		* elfxx-x86.c (_bfd_x86_elf_link_hash_table_create): Initialize
+		relative_r_type, relative_r_name, elf_append_reloc,
+		elf_write_addend and elf_write_addend_in_got.
+		(elf_x86_relative_reloc_record_add): New function.
+		(_bfd_x86_elf_link_relax_section): Likewise.
+		(elf64_dt_relr_bitmap_add): Likewise.
+		(elf32_dt_relr_bitmap_add): Likewise.
+		(_bfd_elf32_write_addend): Likewise.
+		(_bfd_elf64_write_addend): Likewise.
+		(elf_x86_size_or_finish_relative_reloc): Likewise.
+		(elf_x86_compute_dl_relr_bitmap): Likewise.
+		(elf_x86_write_dl_relr_bitmap): Likewise.
+		(elf_x86_relative_reloc_compare ): Likewise.
+		(_bfd_elf_x86_size_relative_relocs): Likewise.
+		(_bfd_elf_x86_finish_relative_relocs): Likewise.
+		(_bfd_x86_elf_size_dynamic_sections): Skip the .relr.dyn section.
+		(_bfd_x86_elf_finish_dynamic_sections): Convert 3 spare dynamic
+		tags to DT_RELR, DT_RELRSZ and for compact relative relocation.
+		* elfxx-x86.h (X86_64_GOT_TYPE_P): New.
+		(I386_GOT_TYPE_P): Likewise.
+		(X86_GOT_TYPE_P): Likewise.
+		(X86_64_RELATIVE_RELOC_TYPE_P): Likewise.
+		(I386_RELATIVE_RELOC_TYPE_P): Likewise.
+		(X86_RELATIVE_RELOC_TYPE_P): Likewise.
+		(X86_LOCAL_GOT_RELATIVE_RELOC_P): Likewise.
+		(I386_PCREL_TYPE_P): Likewise.
+		(X86_64_PCREL_TYPE_P): Likewise.
+		(X86_64_NEED_DYNAMIC_RELOC_TYPE_P): Rewrite.
+		(I386_NEED_DYNAMIC_RELOC_TYPE_P): Likewise.
+		(GENERATE_DYNAMIC_RELOCATION_P): Also check rel_from_abs.
+		(elf_x86_link_hash_entry): Add got_relative_reloc_done.
+		(elf_x86_relative_reloc_record): New.
+		(elf_x86_relative_reloc_data): Likewise.
+		(elf_dt_relr_bitmap): Likewise.
+		(elf_x86_link_hash_table): Add dt_relr_bitmap, relative_reloc,
+		unaligned_relative_reloc, relative_r_type, relative_r_name,
+		elf_append_reloc, elf_write_addend, elf_write_addend_in_got and
+		relative_reloc_done.
+		(elf_x86_relative_reloc_done): New.
+		(relative_reloc_packed): Likewise.
+		(_bfd_x86_elf_link_relax_section): Likewise.
+		(_bfd_elf_x86_size_relative_relocs): Likewise.
+		(_bfd_elf_x86_finish_relative_relocs): Likewise.
+		(_bfd_elf32_write_addend): Likewise.
+		(_bfd_elf64_write_addend): Likewise.
+		(bfd_elf32_bfd_relax_section): Likewise.
+		(bfd_elf64_bfd_relax_section): Likewise.
+		(elf_backend_size_relative_relocs): Likewise.
+		(elf_backend_finish_relative_relocs): Likewise.
+		(elf_x86_allocate_local_got_info): Also allocate
+		relative_reloc_done.
+
+2022-01-12  H.J. Lu  <hjl.tools@gmail.com>
+
+	elf: Support DT_RELR in linker tests
+	Allow eabling and disabling DT_RELR in linker tests.  Disable DT_RELR in
+	linker tests which don't expect DT_RELR in linker outputs.
+
+	binutils/
+
+		* testsuite/lib/binutils-common.exp (run_dump_test): Make
+		DT_RELR_LDFLAGS and NO_DT_RELR_LDFLAGS global.
+
+	ld/
+
+		* testsuite/config/default.exp (DT_RELR_LDFLAGS): New.
+		(DT_RELR_CC_LDFLAGS): Likewise.
+		(NO_DT_RELR_LDFLAGS): Likewise.
+		(NO_DT_RELR_CC_LDFLAGS): Likewise.
+		* testsuite/ld-elf/shared.exp: Pass $NO_DT_RELR_LDFLAGS to
+		linker for some tests.
+		* testsuite/ld-i386/export-class.exp: Likewise.
+		* testsuite/ld-i386/i386.exp: Likewise.
+		* testsuite/ld-i386/ibt-plt-2a.d: Pass $NO_DT_RELR_LDFLAGS to
+		linker.
+		* testsuite/ld-i386/ibt-plt-3a.d: Likewise.
+		* testsuite/ld-i386/ibt-plt-3c.d: Likewise.
+		* testsuite/ld-i386/pr26869.d: Likewise.
+		* testsuite/ld-i386/report-reloc-1.d: Likewise.
+		* testsuite/ld-ifunc/ifunc-2-i386-now.d: Likewise.
+		* testsuite/ld-ifunc/ifunc-2-local-i386-now.d: Likewise.
+		* testsuite/ld-ifunc/ifunc-2-local-x86-64-now.d: Likewise.
+		* testsuite/ld-ifunc/ifunc-2-x86-64-now.d: Likewise.
+		* testsuite/ld-ifunc/pr17154-x86-64.d: Likewise.
+		* testsuite/ld-x86-64/bnd-branch-1-now.d: Likewise.
+		* testsuite/ld-x86-64/bnd-ifunc-1-now.d: Likewise.
+		* testsuite/ld-x86-64/bnd-ifunc-2-now.d: Likewise.
+		* testsuite/ld-x86-64/bnd-ifunc-2.d: Likewise.
+		* testsuite/ld-x86-64/bnd-plt-1-now.d: Likewise.
+		* testsuite/ld-x86-64/bnd-plt-1.d: Likewise.
+		* testsuite/ld-x86-64/ibt-plt-2a-x32.d: Likewise.
+		* testsuite/ld-x86-64/ibt-plt-2a.d: Likewise.
+		* testsuite/ld-x86-64/ibt-plt-3a-x32.d: Likewise.
+		* testsuite/ld-x86-64/ibt-plt-3a.d: Likewise.
+		* testsuite/ld-x86-64/ilp32-4.d: Likewise.
+		* testsuite/ld-x86-64/load1c.d: Likewise.
+		* testsuite/ld-x86-64/load1d.d: Likewise.
+		* testsuite/ld-x86-64/pr13082-2b.d: Likewise.
+		* testsuite/ld-x86-64/pr14207.d: Likewise.
+		* testsuite/ld-x86-64/pr18176.d: Likewise.
+		* testsuite/ld-x86-64/pr19162.d: Likewise.
+		* testsuite/ld-x86-64/pr19636-2d.d: Likewise.
+		* testsuite/ld-x86-64/pr19636-2l.d: Likewise.
+		* testsuite/ld-x86-64/pr20253-1d.d: Likewise.
+		* testsuite/ld-x86-64/pr20253-1f.d: Likewise.
+		* testsuite/ld-x86-64/pr20253-1j.d: Likewise.
+		* testsuite/ld-x86-64/pr20253-1l.d: Likewise.
+		* testsuite/ld-x86-64/report-reloc-1-x32.d: Likewise.
+		* testsuite/ld-x86-64/report-reloc-1.d: Likewise.
+		* testsuite/ld-x86-64/export-class.exp (x86_64_export_class_test):
+		Pass $NO_DT_RELR_LDFLAGS to linker.
+		* testsuite/ld-x86-64/x86-64.exp: Pass $NO_DT_RELR_LDFLAGS to
+		linker for some tests.
+
+2022-01-12  H.J. Lu  <hjl.tools@gmail.com>
+
+	elf: Add size_relative_relocs and finish_relative_relocs
+	On some targets, the DT_RELR section size can be computed only after all
+	symbols addresses can be determined.  Set the preliminary DT_RELR section
+	size before mapping sections to segments and set the final DT_RELR section
+	size after regular symbol processing is done.
+
+		* elf-bfd.h (elf_backend_data): Add size_relative_relocs and
+		finish_relative_relocs.
+		* elf.c (_bfd_elf_map_sections_to_segments): Call
+		size_relative_relocs if DT_RELR is enabled.
+		* elflink.c (bfd_elf_final_link): Call finish_relative_relocs
+		after regular symbol processing is finished if DT_RELR is enabled.
+		* elfxx-target.h (elf_backend_size_relative_relocs): New.
+		(elf_backend_finish_relative_relocs): Likewise.
+		(elfNN_bed): Add elf_backend_size_relative_relocs and
+		elf_backend_finish_relative_relocs.
+
+2022-01-12  H.J. Lu  <hjl.tools@gmail.com>
+
+	ld: Initial DT_RELR support
+	Add a -z pack-relative-relocs option to enable DT_RELR and create a
+	relr.dyn section for DT_RELR.  DT_RELR is implemented with the linker
+	relaxation infrastructure, but it doesn't require the --relax option
+	enabled.  -z pack-relative-relocs implies -z combreloc.  -z nocombreloc
+	implies -z nopack-relative-relocs.
+
+	-z pack-relative-relocs is chosen over the similar option in lld,
+	--pack-dyn-relocs=relr, to implement a glibc binary lockout mechanism
+	with a special glibc version symbol, to avoid random crashes of DT_RELR
+	binaries with the existing glibc binaries.
+
+	bfd/
+
+		* elf-bfd.h (elf_link_hash_table): Add srelrdyn.
+		* elflink.c (_bfd_elf_link_create_dynamic_sections): Create a
+		.relr.dyn section for DT_RELR.
+
+	include/
+
+		* bfdlink.h (bfd_link_info): Add enable_dt_relr.
+
+	ld/
+
+		* News: Mention -z pack-relative-relocs and
+		-z nopack-relative-relocs.
+		* ld.texi: Document -z pack-relative-relocs and
+		-z nopack-relative-relocs.
+		* ldelf.c (ldelf_after_parse): Disable DT_RELR if not building
+		PIE nor shared library.  Add 3 spare dynamic tags for DT_RELR,
+		DT_RELRSZ and DT_RELRENT.
+		* ldlang.c (lang_relax_sections): Also enable relaxation if
+		DT_RELR is enabled.
+		* emulparams/elf32_x86_64.sh: Source dt-relr.sh.
+		* emulparams/elf_i386.sh: Likewise.
+		* emulparams/elf_x86_64.sh: Likewise.
+		* emulparams/dt-relr.sh: New file.
+		* scripttempl/elf.sc: Support .relr.dyn.
+
+2022-01-12  H.J. Lu  <hjl.tools@gmail.com>
+
+	elf: Pass need_layout to _bfd_elf_map_sections_to_segments
+	On some targets, the DT_RELR section size can be computed only after all
+	symbols addresses can be determined.  Update ldelf_map_segments to pass
+	need_layout to _bfd_elf_map_sections_to_segments which will size DT_RELR
+	section and set need_layout to true if the DT_RELR section size is changed.
+
+	bfd/
+
+		* elf-bfd.h (_bfd_elf_map_sections_to_segments): Add a bool
+		pointer argument.
+		* elf.c (_bfd_elf_map_sections_to_segments): Add a bool pointer
+		argument to indicate if section layout needs update.
+		(assign_file_positions_for_load_sections): Pass NULL to
+		_bfd_elf_map_sections_to_segments.
+		* elflink.c (_bfd_elf_strip_zero_sized_dynamic_sections): Pass
+		NULL to _bfd_elf_map_sections_to_segments.
+
+	ld/
+
+		* ldelfgen.c (ldelf_map_segments): Pass &need_layout to
+		_bfd_elf_map_sections_to_segments.
+
+2022-01-12  H.J. Lu  <hjl.tools@gmail.com>
+
+	elf: Add .relr.dyn to special_sections_r
+		* elf.c (special_sections_r): Add .relr.dyn.
+
+2022-01-12  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: add 'maint set/show gnu-source-highlight enabled' command
+	In a later commit I want to address an issue with the Python pygments
+	based code styling solution.  As this approach is only used when the
+	GNU Source Highlight library is not available, testing bugs in this
+	area can be annoying, as it requires GDB to be rebuilt with use of GNU
+	Source Highlight disabled.
+
+	This commit adds a pair of new maintenance commands:
+
+	  maintenance set gnu-source-highlight enabled on|off
+	  maintenance show gnu-source-highlight enabled
+
+	these commands can be used to disable use of the GNU Source Highlight
+	library, allowing me, in a later commit, to easily test bugs that
+	would otherwise be masked by GNU Source Highlight being used.
+
+	I made this a maintenance command, rather than a general purpose
+	command, as it didn't seem like this was something a general user
+	would need to adjust.  We can always convert the maintenance command
+	to a general command later if needed.
+
+	There's no test for this here, but this feature will be used in a
+	later commit.
+
+2022-01-12  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: erase items from the source_cache::m_offset_cache
+	The source_cache class has two member variables m_source_map, which
+	stores the file contents, and m_offset_cache, which stores offsets
+	into the file contents.
+
+	As source files are read the contents of the file, as well as the
+	offset data, are stored in the cache using these two member variables.
+
+	Whenever GDB needs either the files contents, or the offset data,
+	source_cache::ensure is called.  This function looks for the file in
+	m_source_map, and if it's found then this implies the file is also in
+	m_offset_cache, and we're done.
+
+	If the file is not in m_source_map then GDB calls
+	source_cache::get_plain_source_lines to open the file and read its
+	contents.  ::get_plain_source_lines also calculates the offset data,
+	which is then inserted into m_offset_cache.
+
+	Back in ::ensure, the file contents are added into m_source_map.  And
+	finally, if m_source_map contains more than MAX_ENTRIES, an entry is
+	removed from m_source_map.
+
+	The problem is entries are not removed from m_offset_cache at the same
+	time.
+
+	This means that if a program contains enough source files, GDB will
+	hold at most MAX_ENTRIES cached source file contents, but can contain
+	offsets data for every source file.
+
+	Now, the offsets data is going to be smaller than the cached file
+	contents, so maybe there's no harm here.  But, when we reload the file
+	contents we always recalculate the offsets data.  And, when we
+	::get_line_charpos asking for offset data we still call ::ensure which
+	will ends up loading and caching the file contents.
+
+	So, given the current code does the work of reloading the offset data
+	anyway, we may as well save memory by capping m_offset_cache to
+	MAX_ENTRIES just like we do m_source_map.
+
+	That's what this commit does.
+
+	There should be no user visible changes after this commit, except for
+	ever so slightly lower memory usage in some cases.
+
+2022-01-12  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: new 'maint flush source-cache' command
+	This commit adds a new 'maint flush source-cache' command, this
+	flushes the cache of source file contents.
+
+	After flushing GDB is forced to reread source files the next time any
+	source lines are to be displayed.
+
+	I've added a test for this new feature.  The test is a little weird,
+	in that it modifies a source file after compilation, and makes use of
+	the cache flush so that the changes show up when listing the source
+	file.  I'm not sure when such a situation would ever crop up in real
+	life, but maybe we can imagine such cases.
+
+	In reality, this command is useful for testing the syntax highlighting
+	within GDB, we can adjust the syntax highlighting settings, flush the
+	cache, and then get the file contents re-highlighted using the new
+	settings.
+
+2022-01-12  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: rename lin-lwp to linux-nat in set/show debug
+	Rename 'set debug lin-lwp' to 'set debug linux-nat' and 'show debug
+	lin-lwp' to 'show debug linux-nat'.
+
+	I've updated the documentation and help text to match, as well as
+	making it clear that the debug that is coming out relates to all
+	aspects of Linux native inferior support, not just the LWP aspect of
+	it.
+
+	The boundary between general "native" target debug, and the lwp
+	specific part of that debug was always a little blurry, but the actual
+	debug variable inside GDB is debug_linux_nat, and the print routine
+	linux_nat_debug_printf, is used throughout the linux-nat.c file, not
+	just for lwp related debug, so the new name seems to make more sense.
+
+2022-01-12  Clément Chigot  <clement.chigot@atos.net>
+
+	ld: add hidden and internal visibility support for XCOFF
+	This patch adds a primary support for hidden and internal visibility in
+	GNU linker for XCOFF format.
+	The protected visibility isn't yet supported.
+
+	PR 22085
+
+	bfd/ChangeLog:
+
+		* xcofflink.c (xcoff_dynamic_definition_p): Add hidden
+		  and internal visibility support.
+		(xcoff_link_add_symbols): Likewise.
+		(xcoff_auto_export_p): Likewise.
+		(bfd_xcoff_export_symbol): Likewise.
+		(xcoff_link_input_bfd): Likewise.
+
+	ld/ChangeLog:
+
+		* testsuite/ld-vsb/main.c: Adapt for XCOFF.
+		* testsuite/ld-vsb/sh1.c: Likewse.
+		* testsuite/ld-vsb/vsb.exp: Likewise.
+		* testsuite/ld-vsb/visibility-1-xcoff-32.d: New test.
+		* testsuite/ld-vsb/visibility-1-xcoff-64.d: New test.
+		* testsuite/ld-vsb/visibility-2-xcoff-32.d: New test.
+		* testsuite/ld-vsb/visibility-2-xcoff-64.d: New test.
+		* testsuite/ld-vsb/xcoffvsb.dat: New test.
+
+2022-01-12  Clément Chigot  <clement.chigot@atos.net>
+
+	ld/testsuite: prepare ld-elfvsb to support XCOFF
+	A following patch will add visibility support in ld for XCOFF. Thus,
+	ld-elfvsb is renamed ld-vsb and a suffix is added to files targeting only
+	ELF format.
+
+	ld/ChangeLog:
+
+		* testsuite/ld-elfvsb: rename as ld-vsb.
+		* testsuite/ld-elfvsb/hidden0.d: move to ld-vsb and rename with
+		  suffix -elf.d.
+		* testsuite/ld-elfvsb/hidden1.d: Likewise.
+		* testsuite/ld-elfvsb/hidden2.d: Likewise.
+		* testsuite/ld-elfvsb/internal0.d: Likewise.
+		* testsuite/ld-elfvsb/internal1.d: Likewise.
+		* testsuite/ld-elfvsb/protected0.d: Likewise.
+		* testsuite/ld-elfvsb/protected1.d: Likewise.
+
+2022-01-12  Clément Chigot  <clement.chigot@atos.net>
+
+	gas: add visibility support using GNU syntax on XCOFF
+	In order to ease port of GNU assembly code and especially ld testsuite,
+	this patch allows XCOFF to accept the usual GNU syntax for visibility.
+
+	PR 22085
+
+	gas/ChangeLog:
+
+		* config/tc-ppc.c (ppc_GNU_visibility): New function.
+		* testsuite/gas/ppc/aix.exp: Add new tests.
+		* testsuite/gas/ppc/xcoff-visibility-2-32.d: New test.
+		* testsuite/gas/ppc/xcoff-visibility-2-64.d: New test.
+		* testsuite/gas/ppc/xcoff-visibility-2.s: New test.
+
+2022-01-12  Clément Chigot  <clement.chigot@atos.net>
+
+	gas: add visibility support for XCOFF
+	XCOFF assembly defines the visibility using an additional argument
+	on several pseudo-ops: .globl, .weak, .extern and .comm.
+	This implies that .globl and .weak syntax is different than the
+	usual GNU syntax. But we want to provide compatibility with AIX
+	assembler, especially because GCC is generating the visibility
+	using this XCOFF syntax.
+
+	PR 22085
+
+	bfd/ChangeLog:
+
+	        * coffcode.h (coff_write_object_contents): Change XCOFF header
+	        vstamp field to 2.
+	        * coffgen.c (coff_print_symbol): Increase the size for n_type.
+
+	gas/ChangeLog:
+
+	        * config/tc-ppc.c (ppc_xcoff_get_visibility): New function.
+	        (ppc_globl): New function.
+	        (ppc_weak): New function.
+	        (ppc_comm): Add visibility field support.
+	        (ppc_extern): Likewise.
+	        * testsuite/gas/all/cofftag.d: Adjust to new n_type size
+	        providing by objdump.
+	        * testsuite/gas/ppc/test1xcoff32.d: Likewise.
+	        * testsuite/gas/ppc/aix.exp: Add new tests.
+	        * testsuite/gas/ppc/xcoff-visibility-1-32.d: New test.
+	        * testsuite/gas/ppc/xcoff-visibility-1-64.d: New test.
+	        * testsuite/gas/ppc/xcoff-visibility-1.s: New test.
+
+	include/ChangeLog:
+
+	        * coff/internal.h (SYM_V_INTERNAL, SYM_V_HIDDEN,
+	        SYM_V_PROTECTED, SYM_V_EXPORTED, SYM_V_MASK): New defines.
+	        * coff/xcoff.h (struct xcoff_link_hash_entry): Add visibility
+	        field.
+
+	ld/ChangeLog:
+
+	        * testsuite/ld-pe/pr19803.d: Adjust to new n_type size
+	        providing by objdump.
+
+2022-01-12  Hans-Peter Nilsson  <hp@axis.com>
+
+	objdump, readelf: Emit "CU:" format only when wide output is requested
+	As pre-approved by Alan in
+	https://sourceware.org/pipermail/binutils/2021-September/118019.html
+	and I believe people have run into getting testsuite failures for
+	test-environments with "long" directory names, at least once more
+	since that time.  Enough.  I grepped the gas, binutils and ld
+	testsuites for "CU:" to catch target-specific occurrences, but I
+	noticed none.  I chose to remove "CU:" on the objdump tests instead of
+	changing options to get the wide format, so as to keep the name of the
+	test consistent with actual options; but added it to the readelf
+	options for the gas test as I believe the "CU:" format is preferable.
+
+	Tested for cris-elf and native x86_64-pc-linux-gnu.
+
+	binutils:
+		* dwarf.c (display_debug_lines_decoded): Don't check the
+		string length of the directory, instead emit the "CU: dir/name"
+		format only if wide output is requested.
+		* testsuite/binutils-all/dw5.W, testsuite/binutils-all/objdump.WL:
+		Adjust accordingly.
+
+	gas:
+		* testsuite/gas/elf/dwarf-5-loc0.d: Add -W to readelf options.
+
+2022-01-12  Alan Modra  <amodra@gmail.com>
+
+	Set SEC_ELF_REVERSE_COPY earlier
+	For the sake of DT_RELR.
+
+	bfd/
+		* elflink.c (elf_link_input_bfd): Don't set SEC_ELF_REVERSE_COPY
+		here.  Move sanity checks to reverse copying code.
+	ld/
+		* ldlang.c (lang_add_section): Set SEC_ELF_REVERSE_COPY for
+		.ctors/.dtors in .init_array/.fini_array.
+
+2022-01-12  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: testsuite: fix wrong comment in gdb.base/charset.c
+	In gdb/testsuite/gdb.base/charset.c, use "IBM1047" instead of "EBCDIC"
+	to fix the wrong comment.
+
+2022-01-12  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: testsuite: fix failed testcases in gdb.base/charset.exp
+	In gdb/testsuite/gdb.base/charset.c, the last argument is greater than 127
+	when call fill_run() in EBCDIC-US and IBM1047, but the type of string[] is
+	char, this will change the value due to sign extension.
+
+	For example, ebcdic_us_string[7] will be -63 instead of the original 193 in
+	EBCDIC-US.
+
+	Make the type of string[] as unsigned char to fix the following six failed
+	testcases:
+
+	  $ grep FAIL gdb/testsuite/gdb.sum
+	  FAIL: gdb.base/charset.exp: check value of parsed character literal in EBCDIC-US
+	  FAIL: gdb.base/charset.exp: check value of parsed string literal in EBCDIC-US
+	  FAIL: gdb.base/charset.exp: check value of escape that doesn't exist in EBCDIC-US
+	  FAIL: gdb.base/charset.exp: check value of parsed character literal in IBM1047
+	  FAIL: gdb.base/charset.exp: check value of parsed string literal in IBM1047
+	  FAIL: gdb.base/charset.exp: check value of escape that doesn't exist in IBM1047
+
+2022-01-12  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-11  Fangrui Song  <maskray@google.com>
+
+	ar: Add --thin for creating thin archives
+	In many ar implementations (FreeBSD, elfutils, etc), -T has the X/Open
+	System Interface specified semantics. Therefore -T for thin archives is
+	not recommended for portability. -T is deprecated without diagnostics.
+
+	    PR binutils/28759
+	    * ar.c (long_options): Add --thin.
+	    (usage) Add --thin. Deprecate -T without diagnostics.
+	    * doc/binutils.texi: Add doc.
+	    * NEWS: Mention --thin.
+	    * binutils/testsuite/binutils-all/ar.exp: Add tests.
+
+2022-01-11  Martin Storsj  <martin@martin.st>
+
+	Fix multiple problems with DLL generation.
+	ld	* pe-dll.c (make_head): Prefix the symbol name with the dll name.
+		(make_tail, make_one, make_singleton_name_thunk): Likewise.
+		(make_import_fixup_entry, make_runtime_pseudo_reloc): Likewise.
+		(pe_create_runtime_relocator_reference): Likewise.
+		(pe_dll_generate_implib): Set dll_symname_len.
+		(pe_process_import_defs): Likewise.
+
+	binutils
+		* dlltool.c (main): If a prefix has not been provided, attempt to
+		use a deterministic one based upon the dll name.
+
+2022-01-11  Jan Beulich  <jbeulich@suse.com>
+
+	gas/doc: mention quoted symbol names
+
+2022-01-11  Andrew Burgess  <aburgess@redhat.com>
+
+	gdbsupport: regenerate Makefile.in
+	I had cause to regenerate gdbsupport/Makefile.in, and noticed some
+	unexpected changes in the copyright header dates.
+
+	I suspect that this was caused by the end of year date range update
+	process.
+
+	The Makefile.in contains two date ranges.  The first range appears to
+	be the date range for the version of automake being used, that is the
+	range runs up to 2017 only, when automake 1.15.1 was released.
+
+	The second date range in Makefile.in represents the date range for the
+	generated file, and so, now runs up to 2022.
+
+	Anyway, this is the result of running autoreconf (using automake
+	1.15.1) in the gdbsupport directory.
+
+2022-01-11  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-10  Clément Chigot  <clement.chigot@atos.net>
+
+	XCOFF: add support for TLS relocations on hidden symbols
+	This patch adds support for TLS relocation targeting C_HIDEXT symbols.
+	In gas, TLS relocations, except R_TLSM and R_TLMSL, must keep the value
+	of their target symbol.
+	In ld, it simply ensures that internal TLS symbols are added to the
+	linker hash table for xcoff_reloc_type_tls.
+
+	It also improves the tests made by both.
+
+	bfd/ChangeLog:
+
+		* coff-rs6000.c (xcoff_howto_table): Fix name of R_TLSML.
+		(xcoff_reloc_type_tls): Replace the error when h is NULL by
+		an assert.
+		(xcoff_complain_overflow_unsigned_func): Adjust comments.
+		* coff64-rs6000.c (xcoff64_howto_table): Fix name of R_TLSML.
+		* xcofflink.c (xcoff_link_add_symbols_to_hash_table): New
+		function.
+		(xcoff_link_add_symbols): Add C_HIDEXT TLS symbols to the linker
+		hash table.
+
+	gas/ChangeLog:
+
+		* config/tc-ppc.c (md_apply_fix): Enable support for TLS
+		relocation over internal symbols.
+		* testsuite/gas/ppc/aix.exp: Replace xcoff-tlms by xcoff-tls.
+		* testsuite/gas/ppc/xcoff-tlsm-32.d: Removed.
+		* testsuite/gas/ppc/xcoff-tlsm-64.d: Removed.
+		* testsuite/gas/ppc/xcoff-tlsm.s: Removed.
+		* testsuite/gas/ppc/xcoff-tls-32.d: New test.
+		* testsuite/gas/ppc/xcoff-tls-64.d: New test.
+		* testsuite/gas/ppc/xcoff-tls.s: New test.
+
+	ld/ChangeLog:
+
+		* testsuite/ld-powerpc/aix52.exp: Improve aix-tls-reloc test.
+		* testsuite/ld-powerpc/aix-tls-reloc.s: Likewise.
+		* testsuite/ld-powerpc/aix-tls-reloc-32.d: Removed.
+		* testsuite/ld-powerpc/aix-tls-reloc-64.d: Removed.
+		* testsuite/ld-powerpc/aix-tls-reloc-32.dd: New test.
+		* testsuite/ld-powerpc/aix-tls-reloc-32.dt: New test.
+		* testsuite/ld-powerpc/aix-tls-reloc-64.dd: New test.
+		* testsuite/ld-powerpc/aix-tls-reloc-64.dt: New test.
+
+2022-01-10  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: add Tiezhu Yang to MAINTAINERS
+
+2022-01-10  Tom Tromey  <tom@tromey.com>
+
+	Reduce use of unfiltered output in Darwin code
+	The Darwin code uses unfiltered output liberally.  This patch changes
+	this code to send some output to gdb_stdlog (in some cases via the use
+	of debug_prefixed_printf_cond_nofunc), or to gdb_stderr, or to simply
+	switch to filtered output.
+
+	Note that I didn't switch inferior_debug to use
+	debug_prefixed_printf_cond_nofunc, because that would affect the
+	output by removing the information about the inferior.  I wasn't sure
+	if this was important or not, so I left it in.
+
+	v2 of this patch uses warning rather than prints to gdb_stderr, and
+	removes some trailing whitespace.
+
+	I can't compile this patch, so it's "best effort".
+
+2022-01-10  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-09  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-08  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/hurd: handle inferiors exiting
+	While testing on GNU/Hurd (i386) I noticed that GDB crashes when an
+	inferior exits, with this error:
+
+	  inferior.c:293: internal-error: inferior* find_inferior_pid(process_stratum_target*, int): Assertion `pid != 0' failed.
+
+	The problem appears to be in gnu_nat_target::wait.
+
+	We always set inferior_ptid to null_ptid before calling target_wait,
+	this has been the case since the multi-target changes were made to GDB
+	in commit:
+
+	  commit 5b6d1e4fa4fc6827c7b3f0e99ff120dfa14d65d2
+	  Date:   Fri Jan 10 20:06:08 2020 +0000
+
+	      Multi-target support
+
+	With follow up changes in commit:
+
+	  commit 24ed6739b699f329c2c45aedee5f8c7d2f54e493
+	  Date:   Thu Jan 30 14:35:40 2020 +0000
+
+	      gdb/remote: Restore support for 'S' stop reply packet
+
+	Unfortunately, the GNU/Hurd target is still relying on the value of
+	inferior_ptid in the case where an inferior exits - we return the
+	value of inferior_ptid as the pid of the process that exited.  This
+	was fine in the single target world, where inferior_ptid identified
+	the one running inferior, but this is no longer good enough.
+
+	Instead, we should return a ptid containing the pid of the process
+	that exited, as obtained from the wait event, and this is what this
+	commit does.
+
+	I've not run the full testsuite on GNU/Hurd as there appear to be lots
+	of other issues with this target that makes running the full testsuite
+	very painful, but I think this looks like a small easy improvement.
+
+2022-01-08  Tom Tromey  <tom@tromey.com>
+
+	Add explicit check for nullptr to target_announce_attach
+	Lancelot pointed out that target_announce_attach was missing an
+	explicit check against nullptr.  This patch adds it.
+
+2022-01-08  Hannes Domani  <ssbssa@yahoo.de>
+
+	Add _sigsys info to siginfo struct
+	This patch adds information about _sigsys structure from newer
+	kernels, so that $_siginfo decoding can show information about
+	_sigsys, making it easier for developers to debug seccomp failures.
+	Requested in PR gdb/24283.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24283
+
+2022-01-08  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	gdb: testsuite: show print array-indexes after set in arrayidx.exp
+	Add "show print array-indexes" testcases after set print array-indexes
+	to off or on.
+
+	Without this patch:
+
+	    PASS: gdb.base/arrayidx.exp: set print array-indexes to off
+	    PASS: gdb.base/arrayidx.exp: print array with array-indexes off
+	    PASS: gdb.base/arrayidx.exp: set print array-indexes to on
+	    PASS: gdb.base/arrayidx.exp: print array with array-indexes on
+
+	With this patch:
+
+	    PASS: gdb.base/arrayidx.exp: set print array-indexes to off
+	    PASS: gdb.base/arrayidx.exp: show print array-indexes is off
+	    PASS: gdb.base/arrayidx.exp: print array with array-indexes off
+	    PASS: gdb.base/arrayidx.exp: set print array-indexes to on
+	    PASS: gdb.base/arrayidx.exp: show print array-indexes is on
+	    PASS: gdb.base/arrayidx.exp: print array with array-indexes on
+
+2022-01-08  H.J. Lu  <hjl.tools@gmail.com>
+
+	ld: Extract _bfd_elf_link_iterate_on_relocs
+	DT_RELR encodes consecutive R_*_RELATIVE relocations in GOT (the global
+	offset table) and data sections in a compact format:
+
+	https://groups.google.com/g/generic-abi/c/bX460iggiKg
+
+	On some targets, R_*_RELATIVE relocations are counted and the GOT offsets
+	are allocated when setting the dynamic section sizes after seeing all
+	relocations.  R_*_RELATIVE relocations are generated while relocating
+	sections after section layout has been finalized.
+
+	To prepare for DT_RELR implementation on these targets, extract
+	_bfd_elf_link_iterate_on_relocs from _bfd_elf_link_check_relocs so
+	that a backend can scan relocations in elf_backend_always_size_sections
+
+	For x86 targets, the old check_relocs is renamed to scan_relocs and a
+	new check_relocs is added to chek input sections and create dynamic
+	relocation sections so that they will be mapped to output sections.
+	scan_relocs is now called from elf_backend_always_size_sections.
+
+	Since relocations are scanned after __start, __stop, .startof. and
+	.sizeof. symbols have been finalized on x86, __[start|stop]_SECNAME for
+	--gc-sections -z start-stop-gc are now zero when all SECNAME sections
+	been garbage collected.  This is no need for elf_x86_start_stop_gc_p.
+
+	bfd/
+
+		* elf-bfd.h (_bfd_elf_link_iterate_on_relocs): New.
+		* elf32-i386.c (elf_i386_convert_load_reloc): Don't call
+		elf_x86_start_stop_gc_p.
+		(elf_i386_check_relocs): Renamed to ...
+		(elf_i386_scan_relocs): This.  Don't call
+		_bfd_elf_make_dynamic_reloc_section.
+		(elf_i386_always_size_sections): New.
+		(elf_backend_check_relocs): Removed.
+		(elf_backend_always_size_sections): New.
+		* elf64-x86-64.c (elf_x86_64_convert_load_reloc): Don't call
+		elf_x86_start_stop_gc_p.
+		(elf_x86_64_check_relocs): Renamed to ...
+		(elf_x86_64_scan_relocs): This.  Don't call
+		_bfd_elf_make_dynamic_reloc_section.
+		(elf_x86_64_always_size_sections): New.
+		(elf_backend_check_relocs): Removed.
+		(elf_backend_always_size_sections): New.
+		* elflink.c (elf_link_check_or_scan_relocs):
+		New.  Extracted from _bfd_elf_link_check_relocs.
+		(_bfd_elf_link_check_relocs): Call elf_link_check_or_scan_relocs.
+		* elfxx-x86.c (_bfd_x86_elf_check_relocs): New.
+		* elfxx-x86.h (X86_64_NEED_DYNAMIC_RELOC_TYPE_P): New.
+		(I386_NEED_DYNAMIC_RELOC_TYPE_P): Likewise.
+		(X86_NEED_DYNAMIC_RELOC_TYPE_P): Likewise.
+		(_bfd_x86_elf_check_relocs): Likewise.
+		(elf_backend_check_relocs): Likewise.
+		(elf_backend_always_size_sections): Removed.
+		(elf_x86_start_stop_gc_p): Likewise.
+
+	ld/
+
+		* testsuite/ld-i386/pr27491-1a.d: Updated.
+		* testsuite/ld-x86-64/pr27491-1a.d: Likewise.
+
+2022-01-08  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.mi/mi-catch-load.exp
+	When I run the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.mi/mi-catch-load.exp ...
+	    DUPLICATE: gdb.mi/mi-catch-load.exp: breakpoint at main
+	    DUPLICATE: gdb.mi/mi-catch-load.exp: mi runto main
+
+	Fix by grouping the various phases in with_test_prefix blocks.  Since
+	the tests now have a prefix, remove the manually written prefixes in
+	testnames.
+
+	Also change some messages with the pattern "(timeout) $testname" into
+	"$estname (timeout)" since tools will handle this as $testname[1] (which
+	is what we want in this particular scenario).
+
+	Tested on x86_64-linux.
+
+	[1] https://sourceware.org/gdb/wiki/GDBTestcaseCookbook#Do_not_use_.22tail_parentheses.22_on_test_messages
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.threads/staticthreads.ex
+	When running the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.threads/staticthreads.exp ...
+	    DUPLICATE: gdb.threads/staticthreads.exp: couldn't compile staticthreads.c: unrecognized error
+
+	Fix by using foreach_with_prefix instead of foreach when preparing the
+	test case.
+
+	Testeed on x86_64-linux both in a setup where the test fails to prepare
+	and in a setup where the test fails to setup.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.mi/mi-language.exp
+	When running the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.mi/mi-language.exp ...
+	    DUPLICATE: gdb.mi/mi-language.exp: set lang ada
+
+	This is due to an erroneous explicit test name.  This explicit test name
+	also happens to be useless (at least it would have been if it was
+	correct) since it only repeats the command, so just remove the explicit
+	test name and let the command be used as default test name.  Also remove
+	explicit test name at another location in the file since it also just
+	repeat the command.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.mi/mi-nonstop-exit.exp
+	When running the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.mi/mi-nonstop-exit.exp ...
+	    DUPLICATE: gdb.mi/mi-nonstop-exit.exp: breakpoint at main
+	    DUPLICATE: gdb.mi/mi-nonstop-exit.exp: mi runto main
+
+	This test runs the same sequence of operations twice.  Refactor the code
+	by running both of those sequences within a foreach_with_prefix block to
+	ensure that the commands have unique test names.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.mi/mi-nonstop.exp
+	When running the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.mi/mi-nonstop.exp ...
+	    DUPLICATE: gdb.mi/mi-nonstop.exp: check varobj, w1, 1
+	    DUPLICATE: gdb.mi/mi-nonstop.exp: stacktrace of stopped thread
+
+	Fix by adjusting the problematic test names.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.mi/mi-nsthrexec.exp
+	When running the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.mi/mi-nsthrexec.exp ...
+	    DUPLICATE: gdb.mi/mi-nsthrexec.exp: breakpoint at main
+
+	Fix by adjusting the duplicated test name.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.base/watchpoints.exp
+	When running the testsuite, I have:
+
+	    Running ../gdb/testsuite/gdb.base/watchpoints.exp ...
+	    DUPLICATE: gdb.base/watchpoints.exp: watchpoint hit, first time
+
+	Fix by adjusting the test names where appropriate.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.base/nested-subp2.exp
+	When running the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.base/nested-subp2.exp ...
+	    DUPLICATE: gdb.base/nested-subp2.exp: continue to the STOP marker
+	    DUPLICATE: gdb.base/nested-subp2.exp: print c
+	    DUPLICATE: gdb.base/nested-subp2.exp: print count
+
+	Fix by using with_test_prefix to differentiate the test that are
+	performed at different points during the execution of the debuggee.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.base/call-signal-resume.exp
+	When running the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.base/call-signal-resume.exp ...
+	    DUPLICATE: gdb.base/call-signal-resume.exp: dummy stack frame number
+	    DUPLICATE: gdb.base/call-signal-resume.exp: set confirm off
+	    DUPLICATE: gdb.base/call-signal-resume.exp: return
+
+	This is due to the fact that a pattern was probably copy/pasted to
+	re-use the logic while not adjusting the test names to avoid the
+	duplication.
+
+	Fix by removing the redundant tests ('set confirm off' only needs to be
+	used once) and adjusting the test names where appropriate.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.base/pointers.exp
+	When I run the testsuite, I have :
+
+	    Running .../gdb/testsuite/gdb.base/pointers.exp ...
+	    DUPLICATE: gdb.base/pointers.exp: pointer assignment
+
+	Fix by placing the sections with duplication in with_test_prefix blocks.
+	This removes the duplication and gives a better organization the file.
+
+	Tested on x86_64-linux.
+	Co-Authored-By: Pedro Alves <pedro@palves.net>
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.base/unload.exp
+	When running the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.base/unload.exp ...
+	    DUPLICATE: gdb.base/unload.exp: continuing to unloaded libfile
+
+	Fix by adjusting the test name.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.base/define-prefix.exp
+	When running the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.base/define-prefix.exp ...
+	    DUPLICATE: gdb.base/define-prefix.exp: define user command: ghi-prefix-cmd
+
+	Fix by adjusting test names.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.base/funcargs.exp
+	When running the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.base/funcargs.exp ...
+	    DUPLICATE: gdb.base/funcargs.exp: run to call2a
+
+	Fix by using proc_with_prefix instead on plain proc to create logical
+	function blocks.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.base/shlib-call.exp
+	When I run the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.base/shlib-call.exp ...
+	    DUPLICATE: gdb.base/shlib-call.exp: print g
+	    DUPLICATE: gdb.base/shlib-call.exp: set print sevenbit-strings
+	    DUPLICATE: gdb.base/shlib-call.exp: set print address off
+	    DUPLICATE: gdb.base/shlib-call.exp: set width 0
+	    DUPLICATE: gdb.base/shlib-call.exp: continue until exit
+
+	Fix by adjusting the test names when required, and by removing
+	un-necessary commands.
+
+	While at it, do some cleanup:
+	- Replace an explicit GDB restart sequence with a call to clean_restart.
+	- Remove trailing whitespaces.
+	- Use $gdb_test_name in gdb_test_multiple.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.base/set-cfd.exp
+	When running the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.base/set-cwd.exp ...
+	    DUPLICATE: gdb.base/set-cwd.exp: test_cwd_reset: continue to breakpoint: break-here
+
+	Fix by moving the tests after the 'runto_main' within the same
+	with_test_prefix scope.
+
+	While at it, I fix some indentation issues.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.base/exprs.exp
+	When running the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.base/exprs.exp ...
+	    DUPLICATE: gdb.base/exprs.exp: \$[0-9]* = red (setup)
+
+	Fix by using with_test_prefix where appropriate.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.base/readline.exp
+	When running the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.base/readline.exp ...
+	    DUPLICATE: gdb.base/readline.exp: Simple operate-and-get-next - final prompt
+
+	Fix by adjusting the prefix given to the second 'simple' call to
+	operate_and_get_next.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.base/pretty-array.exp
+	When I run the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.base/pretty-array.exp ...
+	    DUPLICATE: gdb.base/pretty-array.exp: print nums
+	    DUPLICATE: gdb.base/pretty-array.exp: print nums
+
+	Fix by giving a name to the test cases.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.base/ui-redirect.exp
+	When running the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.base/ui-redirect.exp ...
+	    DUPLICATE: gdb.base/ui-redirect.exp: redirect while already logging: set logging redirect off
+
+	Fix by moving the first 'set logging redirect off' to the end of the
+	previous [with_test_prefix] test block. The statement's purpose is to
+	clean the on flag set in this previous block, so moving it there makes
+	sense and does not change the sequence of commands in the test file.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb: completion-support.exp: improve leading whitespace support
+	There is a expect support library in the source tree designed to help
+	developers test the auto-completion capabilities of GDB.
+
+	One of the functions is test_gdb_complete_unique_re.  It is used
+	(usually indirectly via test_gdb_complete_unique) to test that a given
+	input line is completed as a given output line.  The test checks for two
+	ways to do the completion: using tab-completion, or using the
+	'complete' command.  To do this, calls to two dedicated functions are
+	performed.  If we omit few details, we can consider that a call to
+
+	    test_gdb_complete_unique $input $expected
+
+	is equivalent to the two following calls:
+
+	    test_gdb_complete_tab_unique $input $expected
+	    test_gdb_complete_cmd_unique $input $expected
+
+	When using the tab-completion, everything works as expected, but some
+	care must be taken when using the 'complete' command if the given input
+	has leading whitespaces.  In such situation, the output of the
+	'complete' command will drop the leading whitespaces.
+
+	The current approach is that in such situation, the input and expected
+	outputs are right trimmed (i.e. all leading whitespaces are removed)
+	when performing the command completion check.
+
+	This means that the following call:
+
+	    test_gdb_complete_unique "   $input" "   $expected"
+
+	is almost equivalent to (again, omitting few details and arguments):
+
+	    test_gdb_complete_tab_unique "   $input" "   $expected"
+	    test_gdb_complete_cmd_unique "$input" "$expected"
+
+	This approach comes with a problem that we encounter when running the
+	tests in complete-empty.exp.  When doing so, we have:
+
+	    Running .../gdb/testsuite/gdb.base/complete-empty.exp ...
+	    DUPLICATE: gdb.base/complete-empty.exp: empty-input-line: cmd complete ""
+
+	This is because the test file does something like:
+
+	    test_gdb_complete_unique "" "!" " " 1
+	    test_gdb_complete_unique "   " "   !" " " 1¬
+
+	which, if we do the substitution introduced above is equivalent to:
+
+	    test_gdb_complete_tab_unique "" "!"
+	    test_gdb_complete_cmd_unique "" "!"
+	    test_gdb_complete_tab_unique "   " "   !"
+	    test_gdb_complete_cmd_unique "" "!"
+
+	We see that the lines 2 and 4 are now the same, and for this reason the
+	testing framework complains about DUPLICATE test names.
+
+	To fix that, this commit proposes that instead of left trimming both
+	input and expected outputs, only the expected output is trimmed.
+
+	Care must be taken in the case the completion gives more possibilities
+	than allowed by the max-completions setting.  In this case, the input
+	will be repeated in the output in its left trimmed version.  This commit
+	also ensures that this is taken care of.
+
+	With this commit, the gdb.base/complete-empty.exp still passes all its
+	tests but does not report the DUPLICATE anymore.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.base/subst.exp
+	When I run the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.base/subst.ex ...
+	    DUPLICATE: gdb.base/subst.exp: unset substitute-path from, no rule entered yet
+
+	Fix by adjusting the problematic test name.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Pedro Alves  <pedro@palves.net>
+
+	gdb/testsuite: Remove duplicates from gdb.base/dfp-exprs.exp
+	When I run the testsuite, I have:
+
+	    Running ../gdb/testsuite/gdb.base/dfp-exprs.exp ...
+	    DUPLICATE: gdb.base/dfp-exprs.exp: p 1.2dl < 1.3df
+
+	Replace hand-written tests checking various comparison operators between
+	various decimal floating point types with a loop to programmatically
+	generate all the combinations.  This removes the need to eyeball for all
+	suffixes, which lead to the original duplication.
+
+	Also add a lot more combinations, testing all comparison operators
+	comprehensively.  The result is 262 unique tests vs 104 before this
+	patch.
+
+	Tested on x86_86-linux.
+
+	Change-Id: Id215a3d610aa8e032bf06ee160b5e3aed4a92d1e
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.base/ptype.exp
+	When running the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.base/ptype.exp ...
+	    DUPLICATE: gdb.base/ptype.exp: ptype the_highest
+	    DUPLICATE: gdb.base/ptype.exp: list intfoo
+	    DUPLICATE: gdb.base/ptype.exp: list charfoo
+
+	Fix by adjusting the offending test names.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.base/dfp-test.exp
+	When running the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.base/dfp-test.exp ...
+	    DUPLICATE: gdb.base/dfp-test.exp: 1.23E is an invalid number
+	    DUPLICATE: gdb.base/dfp-test.exp: 1.23E45A is an invalid number
+	    DUPLICATE: gdb.base/dfp-test.exp: 1.23E is an invalid number
+	    DUPLICATE: gdb.base/dfp-test.exp: 1.23E45A is an invalid number
+
+	Fix by using proc_with_prefix where appropriate.
+
+	Tested on x86_64-linux.
+	Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.base/del.exp
+	When running the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.base/del.exp ...
+	    DUPLICATE: gdb.base/del.exp: info break after removing break on main
+
+	Refactor slightly this test to run the various configurations under
+	foreach_with_prefix so each variant is automatically prefixed, ensuring
+	that the forgotten custom test name cannot happen.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.base/solib-display.exp
+	When running the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.base/solib-display.exp ...
+	    DUPLICATE: gdb.base/solib-display.exp: NO: break 25
+	    DUPLICATE: gdb.base/solib-display.exp: NO: continue
+	    DUPLICATE: gdb.base/solib-display.exp: IN: break 25
+	    DUPLICATE: gdb.base/solib-display.exp: IN: continue
+	    DUPLICATE: gdb.base/solib-display.exp: SEP: break 25
+	    DUPLICATE: gdb.base/solib-display.exp: SEP: continue
+
+	The 'break 25' appears because the test inserts two breakpoints at the
+	same location.  Fix this by only inserting the breakpoint once.
+
+	Fix the 'continue' DUPLICATE by giving a phony name to the second
+	continue: 'continue two'.
+
+	While at it, this commit also removes a trailing space.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.base/decl-before-def.exp
+	When running the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.base/decl-before-def.exp ...
+	    DUPLICATE: gdb.base/decl-before-def.exp: p a
+
+	Fix by giving explicit names to the two tests that use the same command.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.base/pending.exp
+	When running the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.base/pending.exp ...
+	    DUPLICATE: gdb.base/pending.exp: disable other breakpoints
+
+	Fix by adjusting the test names.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.base/checkpoint.exp
+	When running the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.base/checkpoint.exp ...
+	    DUPLICATE: gdb.base/checkpoint.exp: verify lines 5 two
+	    DUPLICATE: gdb.base/checkpoint.exp: restart 0 one
+
+	This patch fixes the various erroneous incorrect test names.
+
+	While at it, this patch also remove some trailing white spaces across
+	the file.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.base/pie-fork.exp
+	When running the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.base/pie-fork.exp ...
+	    DUPLICATE: gdb.base/pie-fork.exp: test_no_detach_on_fork: continue
+
+	Fix by giving explicit names to the 'continue' commands that cause the
+	duplicate message.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.base/realname-expand.exp
+	When running the testsuite, I have:
+
+	    Running .../gdb/testsuite/gdb.base/realname-expand.exp ...
+	    DUPLICATE: gdb.base/realname-expand.exp: set basenames-may-differ on
+
+	This is due to the fact that the test restarts GDB twice and each time
+	sets the basenames-may-differ setting.  This patch proposes to fix this
+	by not restarting GDB so the setting is maintained.  It just clears the
+	breakpoints between the two tests and updates the breakpoints number as
+	required.
+
+	This patch also perform some minor refactorings to improve visibility.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.base/interp.exp
+	When running the testsuite I have:
+
+	    Running .../gdb/testsuite/gdb.base/interp.exp ...
+	    DUPLICATE: gdb.base/interp.exp: interpreter-exec mi "-var-update *"
+
+	This is due to the fact that multiple successive instances of
+	gdb_test_multiple use 'pass $cmd', but one of them forgets to reset $cmd
+	to a new test name.
+
+	Fix by using 'pass $gdb_test_name', given that the gdb_test_name is set
+	by gdb_test_multiple.
+
+	While fixing this, this patch refactors all occurrences of the following
+	pattern:
+
+	    set cmd foo
+	    gdb_test_multiple $cmd $cmd {
+	        -re ... {
+	            pass $cmd
+	        }
+	    }
+
+	into
+
+	    gdb_test_multiple foo "" {
+	        -re ... {
+	            pass $gdb_test_name
+	         }
+	    }
+
+	This makes this test file coherent in its use of $gdb_test_name.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.base/miscexprs.exp
+	When running the testsuite I see:
+
+	    Running .../gdb/testsuite/gdb.base/miscexprs.exp ...
+	    DUPLICATE: gdb.base/miscexprs.exp: print value of !ibig.i[100]
+	    DUPLICATE: gdb.base/miscexprs.exp: print value of !ibig.i[100]
+
+	This is due to an explicit test name repeated across multiple tests.
+	The actual test explicit names do not add much over the command from
+	wich default test names are derived.
+
+	Fix by removing the explicit test names across the file where they do
+	not add value.  While at doing some cleaning, also use $gdb_test_name in
+	the various uses of gdb_test_multiple.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates from gdb.base/stack-checking.exp
+	When running the testsuite I have:
+
+	    Running .../gdb/testsuite/gdb.base/stack-checking.exp ...
+	    DUPLICATE: gdb.base/stack-checking.exp: bt
+	    DUPLICATE: gdb.base/stack-checking.exp: bt
+
+	Fix by using with_test_prefix.
+
+	Tested on x86_64-linux.
+
+2022-01-07  Philipp Tomsich  <philipp.tomsich@vrull.eu>
+
+	RISC-V: update docs to reflect privileged spec v1.9 has been dropped
+	After commit d8af286fffa ("RISC-V: Drop the privileged spec v1.9
+	support.") has removed support for privileged spec v1.9, this removes
+	it from the documentation.
+
+	References: d8af286fffa ("RISC-V: Drop the privileged spec v1.9 support.")
+
+	gas/ChangeLog:
+
+		* configure: Regenerate.
+		* configure.ac: Remove reference to priv spec 1.9.
+		* po/fr.po: Same.
+		* po/ru.po: Same.
+		* po/uk.po: Same.
+
+2022-01-07  Philipp Tomsich  <philipp.tomsich@vrull.eu>
+
+	RISC-V: update docs for -mpriv-spec/--with-priv-spec for 1.12
+	While support for the privileged spec was added in a63375ac337
+	("RISC-V: Hypervisor ext: support Privileged Spec 1.12"), the
+	documentation has not been updated.  Add 1.12 to the relevant
+	documentation.
+
+	References: a63375ac337 ("RISC-V: Hypervisor ext: support Privileged Spec 1.12")
+
+	gas/ChangeLog:
+
+		* config/tc-riscv.c: Add 1.12 to the usage message.
+		* configure: Regenerate.
+		* configure.ac: Add 1.12 to the help/usage message.
+		* po/fr.po: Same.
+		* po/ru.po: Same.
+		* po/uk.po: Same.
+
+2022-01-07  Tom Tromey  <tromey@adacore.com>
+
+	Do not use CC_HAS_LONG_LONG
+	ax.cc checks CC_HAS_LONG_LONG, but nothing defines this.  However,
+	PRINTF_HAS_LONG_LONG is checked in configure.  This patch removes the
+	former and keeps the latter.  This is PR remote/14976 (filed by me in
+	2012, lol).
+
+	I'm checking this in.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14976
+
+2022-01-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/doc: shorten some source lines, and prevent some line breaks
+	Building on the previous commit, this makes use of a trailing @ to
+	split long @deffn lines in the guile.texi source file.  This splitting
+	doesn't change how the document is laid out by texinfo.
+
+	I have also wrapped keyword and argument name pairs in @w{...} to
+	prevent line breaks appearing between the two.  I've currently only
+	done this for the longer @deffn lines, where a line break is
+	possible.  This makes the @deffn lines much nicer to read in the
+	generated pdf.
+
+2022-01-07  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/doc: Remove (...) around guile procedure names in @deffn lines
+	Most guile procedures in the guile.texi file are defined like:
+
+	  @deffn {Scheme Procedure} name arg1 arg2 arg3
+
+	But there are two places where we do this:
+
+	  @deffn {Scheme Procedure} (name arg1 arg2 arg3)
+
+	Notice the added (...).  Though this does represent how a procedure
+	call is written in scheme, it's not the normal style throughout the
+	manual.  I also checked the 'info guile' info page to see how they
+	wrote there declarations, and they use the first style too.
+
+	The second style also has the drawback that index entries are added as
+	'(name', and so they are grouped in the '(' section of the index,
+	which is not very user friendly.
+
+	In this commit I've changed the definitions of make-command and
+	make-parameter to use the first style.
+
+	The procedure declaration lines can get pretty long with all of the
+	arguments, and this was true for both of the procedures I am changing
+	in this commit.  I have made use of a trailing '@' to split the deffn
+	lines, and keep them under 80 characters in the texi source.  This
+	makes no difference to how the final document looks.
+
+	Finally, our current style for keyword arguments, appears to be:
+
+	  [#:keyword-name argument-name]
+
+	I don't really understand the reason for this, 'info guile' just seems
+	to use:
+
+	  [#:keyword-name]
+
+	which seems just as good to me.  But I don't propose to change
+	that just now.  What I do notice though, is that sometimes, texinfo
+	will place a line break between the keyword-name and the
+	argument-name, for example, the pdf of make-command is:
+
+	  make-command name [#:invoke invoke] [#:command-class
+	    command-class] [#:completer-class completer] [#:prefix? prefix] [#:doc
+	    doc-string]
+
+	Notice the line break after '#:command-class' and after '#:doc',
+	neither of which are ideal.  And so, for the two commands I am
+	changing in this commit, I have made use of @w{...} to prevent line
+	breaks between the keyword-name and the argument-name.  Now the pdf
+	looks like this:
+
+	  make-command name [#:invoke invoke]
+	    [#:command-class command-class] [#:completer-class completer]
+	    [#:prefix? prefix] [#:doc doc-string]
+
+	Which seems much better.  I'll probably update the other deffn lines
+	at some point.
+
+2022-01-07  Pavel Mayorov  <pmayorov@cloudlinux.com>
+
+	Revert previous delta to debug.c.  Replace with patch to reject indirect types that point to indirect types.
+		PR 28718
+		* dwarf.c: Revert previous delta.
+		(debug_get_real_type): Reject indirect types that point to
+		indirect types.
+		(debug_get_type_name, debug_get_type_size, debug_write_type):
+		Likewise.
+
+2022-01-07  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: Updated the default ISA spec to 20191213.
+	Update the default ISA spec from 2.2 to 20191213 will change the default
+	version of i from 2.0 to 2.1.  Since zicsr and zifencei are separated
+	from i 2.1, users need to add them in the architecture string if they need
+	fence.i and csr instructions.  Besides, we also allow old ISA spec can
+	recognize zicsr and zifencei, but we won't output them since they are
+	already included in the i extension when i's version is less than 2.1.
+
+	bfd/
+		* elfxx-riscv.c (riscv_parse_add_subset): Allow old ISA spec can
+		recognize zicsr and zifencei.
+	gas/
+		* config/tc-riscv.c (DEFAULT_RISCV_ISA_SPEC): Updated to 20191213.
+		* testsuite/gas/riscv/csr-version-1p10.d: Added zicsr to -march since
+		the default version of i is 2.1.
+		* testsuite/gas/riscv/csr-version-1p11.d: Likewise.
+		* testsuite/gas/riscv/csr-version-1p12.d: Likewise.
+		* testsuite/gas/riscv/csr-version-1p9p1.d: Likewise.
+		* testsuite/gas/riscv/option-arch-03.d: Updated i's version to 2.1.
+		* testsuite/gas/riscv/option-arch-03.s: Likewise.
+	ld/
+		* testsuite/ld-riscv-elf/call-relax.d: Added zicsr to -march since
+		the default version of i is 2.1.
+		* testsuite/ld-riscv-elf/attr-merge-arch-01.d: Updated i's version to 2.1.
+		* testsuite/ld-riscv-elf/attr-merge-arch-01a.s: Likewise.
+		* testsuite/ld-riscv-elf/attr-merge-arch-01b.: Likewise.
+		* testsuite/ld-riscv-elf/attr-merge-arch-02.d: Likewise.
+		* testsuite/ld-riscv-elf/attr-merge-arch-02a.s: Likewise.
+		* testsuite/ld-riscv-elf/attr-merge-arch-02b.s: Likewise.
+		* testsuite/ld-riscv-elf/attr-merge-arch-03.d: Likewise.
+		* testsuite/ld-riscv-elf/attr-merge-arch-03a.s: Likewise.
+		* testsuite/ld-riscv-elf/attr-merge-arch-03b.s: Likewise.
+		* testsuite/ld-riscv-elf/attr-merge-arch-failed-02.d: Added zifencei
+		into Tag_RISCV_arch since it is added implied when i's version is
+		larger than 2.1.
+
+2022-01-07  Alan Modra  <amodra@gmail.com>
+
+	Move elf_backend_always_size_sections earlier
+		* elflink.c (bfd_elf_size_dynamic_sections): Move plt/got init
+		earlier and call elf_backend_always_size_sections at the start
+		of this function.
+
+2022-01-07  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-06  H.J. Lu  <hjl.tools@gmail.com>
+
+	ldelfgen.c: Add missing newlines when calling einfo
+		* ldelfgen.c (ldelf_map_segments): Add the missing newline to
+		einfo.
+
+2022-01-06  Nick Clifton  <nickc@redhat.com>
+
+	Fix a stack exhaustion bug parsing malicious STABS format debug information.
+		PR 28718
+		* debug.c (debug_write_type): Allow for malicious recursion via
+		indirect debug types.
+
+2022-01-06  Richard Sandiford  <richard.sandiford@arm.com>
+
+	aarch64: Add support for new SME instructions
+	This patch adds support for three new SME instructions: ADDSPL,
+	ADDSVL and RDSVL.  They behave like ADDPL, ADDVL and RDVL, but read
+	the streaming vector length instead of the current vector length.
+
+	opcodes/
+		* aarch64-tbl.h (aarch64_opcode_table): Add ADDSPL, ADDSVL and RDSVL.
+		* aarch64-dis-2.c: Regenerate.
+
+	gas/
+		* testsuite/gas/aarch64/sme.s, testsuite/gas/aarch64/sme.d: Add tests
+		for ADDSPL, ADDSVL and RDSVL.
+
+2022-01-06  Tom Tromey  <tom@tromey.com>
+
+	Use target_announce_detach in more targets
+	target_announce_detach was added in commit 0f48b757 ("Factor out
+	"Detaching from program" message printing").  There, Pedro wrote:
+
+	    (For now, I left the couple targets that print this a bit differently
+	    alone.  Maybe this could be further pulled out into infcmd.c.  If we
+	    did that, and those targets want to continue printing differently,
+	    this new function could be converted to a target method.)
+
+	It seems to me that the differences aren't very big, and in some cases
+	other targets handled the output a bit more nicely.  In particular,
+	some targets will print a different message when exec_file==NULL,
+	rather than printing the same output with an empty string as
+	exec_file.
+
+	This patch incorporates the nicer output into target_announce_detach,
+	then changes the remaining ports to use this function.
+
+2022-01-06  Tom Tromey  <tom@tromey.com>
+
+	Introduce target_announce_attach
+	This introduces target_announce_attach, by analog with
+	target_announce_detach.  Then it converts existing targets to use
+	this, rather than emitting their own output by hand.
+
+2022-01-06  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: make use add_setshow_prefix_cmd in gnu-nat.c
+	In gnu-nat.c we currently implement some set/show prefix commands
+	"manually", that is, we call add_prefix_cmd, and assign a set and show
+	function to each prefix command.
+
+	These set/show functions print an error indicating that the user
+	didn't type a complete command.
+
+	If we instead switch to using add_setshow_prefix_cmd then we can
+	delete the set/show functions, GDB provides some default functions,
+	which give a nice help style summary that lists all of the available
+	sub-commands, along with a one line summary of what each does.
+
+	Though this clearly changes the existing behaviour, I think this
+	change is acceptable as the new behaviour is more inline with other
+	set/show prefix commands, and the new behaviour is more informative.
+
+	This change will conflict with Tom's change here:
+
+	  https://sourceware.org/pipermail/gdb-patches/2022-January/184724.html
+
+	Where Tom changes the set/show functions that I delete.  My suggestion
+	is that the set/show functions still be deleted even after Tom's
+	patch (or instead of Tom's patch).
+
+	For testing I've build GDB on GNU/Hurd, and manually tested these
+	functions.  I did a grep over the testsuite, and don't believe the
+	existing error messages are being checked for in any tests.
+
+2022-01-06  Tom Tromey  <tom@tromey.com>
+
+	Use warning in windows-nat error messages
+	A warning in windows-nat.c can be converted to use the warning
+	function.  As a side effect, this arranges for the output to be sent
+	to gdb_stderr.
+
+2022-01-06  Tom Tromey  <tom@tromey.com>
+
+	Clean up some dead code in windows-tdep.c
+	windows-tdep.c checks the result of xmalloc, which isn't necessary.  I
+	initially removed this dead check, but then went a bit further and
+	modified the code so that some "goto"s and explicit memory management
+	could be removed.  Then, I added a couple of missing bounds checks.
+
+	I believe this also fixes a possible bug with a missing 0-termination
+	of a string.  I am not certain, but that is why I think the existing
+	code allocates a buffer that is 1 byte too long -- but then it fails
+	to set this byte to 0.
+
+2022-01-06  Tom Tromey  <tromey@adacore.com>
+
+	Avoid crash in language_info
+	language_info calls:
+
+	  show_language_command (NULL, 1, NULL, NULL);
+
+	... "knowing" that show_language_command does not use its ui_file
+	parameter.  However, this was changed in commit 7514a661
+	("Consistently Use ui_file parameter to show callbacks").
+
+	This patch changes language_info to pass a ui_file.
+
+	It took a while to write the test -- this function is only called when
+	'verbose' is on and when switching the "expected" language in auto
+	mode.
+
+2022-01-06  Tom Tromey  <tromey@adacore.com>
+
+	Fix some failures in langs.exp
+	langs.exp currently has some fails for me because the stack trace
+	includes full paths to the source files.
+
+	    FAIL: gdb.base/langs.exp: up to foo in langs.exp
+	    FAIL: gdb.base/langs.exp: up to cppsub_ in langs.exp
+	    FAIL: gdb.base/langs.exp: up to fsub in langs.exp
+
+	This fixes the failures by making the filename regexps a bit more lax.
+
+2022-01-06  Jan Beulich  <jbeulich@suse.com>
+
+	x86: drop NoAVX insn attribute
+	To avoid issues like that addressed by 6e3e5c9e4181 ("x86: extend SSE
+	check to PCLMULQDQ, AES, and GFNI insns"), base the check on opcode
+	attributes and operand types.
+
+	x86: drop NoAVX from POPCNT
+	With the introduction of CpuPOPCNT the NoAVX attribute has become
+	meaningless for POPCNT.
+
+	x86: drop some "comm" template parameters
+	As already indicated in a remark when introducing these templates, the
+	"commutative" attribute is ignored for legacy encoding templates. Hence
+	it is possible to shorten a number of templates by specifying C directly
+	rather than through a template parameter. I think this helps readability
+	a bit.
+
+	x86: templatize FMA insn templates
+	The operand ordering portion of the mnemonics repeats, causing a flurry
+	of almost identical templates. Abstract this out.
+
+	x86-64: restrict PC32 -> PLT32 conversion
+	Neither non-64-bit code nor uses with a non-zero offset from a symbol
+	should be converted to PLT32, as an eventual PLT entry would not express
+	what was requested.
+
+2022-01-06  Lancelot SIX  <lancelot.six@amd.com>
+
+	gdb: Fix copyright year in gdb/testsuite/gdb.base/inferior-clone.exp
+	I just realized that I forgot to update the year before pushing the
+	patch that created this file.  Since it landed after the global
+	copyright year update have been done, this file’s copyright year is
+	updated.
+
+	This patch fixes that.
+
+	Change-Id: I280f7d86e02d38425f7afdcf19a1c3500d51c23f
+
+2022-01-06  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: ppc: migrate to standard uintXX_t types
+	Drop the sim-specific unsignedXX types and move to the standard uintXX_t
+	types that C11 provides.
+
+	sim: common: migrate to standard uintXX_t types
+	Drop the sim-specific unsignedXX types and move to the standard uintXX_t
+	types that C11 provides.
+
+	sim: igen: migrate to standard uintXX_t types
+	Move off the custom local 64-bit types and to the standard uintXX_t
+	types that C11 provides.
+
+	sim: mips: migrate to standard uintXX_t types
+	Move off the sim-specific unsignedXX types and to the standard uintXX_t
+	types that C11 provides.
+
+	sim: cris: migrate to standard uintXX_t types
+	Move off the sim-specific unsignedXX types and to the standard uintXX_t
+	types that C11 provides.
+
+	sim: iq2000: migrate to standard uintXX_t types
+	Move off the sim-specific unsignedXX types and to the standard uintXX_t
+	types that C11 provides.
+
+	sim: synacor: migrate to standard uintXX_t types
+	Move off the sim-specific unsignedXX types and to the standard uintXX_t
+	types that C11 provides.
+
+	sim: msp430: migrate to standard uintXX_t types
+	Move off the sim-specific unsignedXX types and to the standard uintXX_t
+	types that C11 provides.
+
+	sim: riscv: migrate to standard uintXX_t types
+	Move off the sim-specific unsignedXX types and to the standard uintXX_t
+	types that C11 provides.
+
+	sim: bfin: migrate to standard uintXX_t types
+	Move off the sim-specific unsignedXX types and to the standard uintXX_t
+	types that C11 provides.
+
+	sim: testsuite: migrate to standard uintXX_t types
+	This old code setup its own uintXX types, but since we require C11
+	now, we can assume the standard uintXX_t types exist and use them.
+
+	sim: erc32: migrate to standard uintXX_t types
+	This old port setup its own uintXX types, but since we require C11
+	now, we can assume the standard uintXX_t types exist and use them.
+
+	sim: mn10300: migrate to standard uintXX_t types
+	This old port setup its own uintXX types, but since we require C11
+	now, we can assume the standard uintXX_t types exist and use them.
+
+	sim: v850: migrate to standard uintXX_t types
+	This old port setup its own uintXX types, but since we require C11
+	now, we can assume the standard uintXX_t types exist and use them.
+
+2022-01-06  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: m68hc11: migrate to standard uintXX_t types
+	This old port setup its own uintXX types, but since we require C11
+	now, we can assume the standard uintXX_t types exist and use them.
+
+	Also migrate off the sim-specific unsignedXX types.
+
+2022-01-06  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: d10v: migrate to standard uintXX_t types
+	This old port setup its own uintXX types, but since we require C11
+	now, we can assume the standard uintXX_t types exist and use them.
+
+	Also migrate off the sim-specific unsignedXX types.
+
+2022-01-06  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: cr16: migrate to standard uintXX_t types
+	This old port setup its own uintXX types, but since we require C11
+	now, we can assume the standard uintXX_t types exist and use them.
+
+	Also migrate off the sim-specific unsignedXX types.
+
+2022-01-06  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-05  H.J. Lu  <hjl.tools@gmail.com>
+
+	x86: Add elf_x86_allocate_local_got_info
+	Add elf_x86_allocate_local_got_info to allocate x86 GOT info for local
+	symbols.
+
+		* elf32-i386.c (elf_i386_check_relocs): Call
+		elf_x86_allocate_local_got_info.
+		* elf64-x86-64.c (elf_x86_64_check_relocs): Likewise.
+		* elfxx-x86.h (elf_x86_allocate_local_got_info): New.
+
+2022-01-05  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+	opcodes: Make i386-dis.c thread-safe
+	Improve thread safety in print_insn_i386_att, print_insn_i386_intel and
+	print_insn_i386 by removing the use of static variables.
+
+	Tested on x86_64-pc-linux-gnu.
+
+	2022-01-04 Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+		* i386-dis.c: Make print_insn_i386_att, print_insn_i386_intel
+		and print_insn_i386 thread-safe
+
+2022-01-05  H.J. Lu  <hjl.tools@gmail.com>
+
+	doc: Replace =frame-interp with =frames-interp
+	The actual objdump and readelf option name is =frames-interp, not
+	=frames-interp.
+
+		PR binutils/28747
+		* doc/debug.options.texi: Replace =frame-interp with
+		=frames-interp.
+
+2022-01-05  Tom Tromey  <tromey@adacore.com>
+
+	Change riscv_return_value to use RETURN_VALUE_ABI_PRESERVES_ADDRESS
+	Internally, AdaCore has a test that is equivalent to (really a direct
+	translation of) gdb.base/gnu_vector.exp.  On 32-bit RISC-V, the
+	"return" part of this test fails.
+
+	Joel tracked this down to riscv_return_value returning
+	RETURN_VALUE_ABI_RETURNS_ADDRESS.  Using
+	RETURN_VALUE_ABI_PRESERVES_ADDRESS is more correct here, and fixes the
+	bug.
+
+	I tested this for both 32- and 64-bit RISC-V using the AdaCore
+	internal test suite, and Andrew Burgess tested it using
+	gnu_vector.exp.
+
+2022-01-05  Tom Tromey  <tom@tromey.com>
+
+	Filtered output cleanup in expression dumping
+	Most of the expression-dumping code uses filtered output, but a few
+	functions did not.  This patch cleans up these instance.
+
+	Note that this won't cause any behavior change, because the only calls
+	to dump_prefix_expression pass in gdb_stdlog.  However, in the long
+	run it's easier to audit the code if the number of uses of _unfiltered
+	is reduced.
+
+2022-01-05  Tom Tromey  <tom@tromey.com>
+
+	Use filtered output in terminal_info implementations
+	This changes one terminal_info implementation, and
+	default_terminal_info, to use filtered output.  Other implementations
+	of this method already use filtered output.
+
+	I can't compile go32-nat.c, so this is a 'best effort' patch.
+
+2022-01-05  Tom Tromey  <tom@tromey.com>
+
+	Use filtered output in gnu-nat.c commands
+	gnu-nat.c has a number of ordinary commands that should use filtered
+	output.  In a few cases, I changed the output to use gdb_stderr as
+	well.  I can't compile this file, so this patch is split out as a
+	"best effort".
+
+	Use filtered output in *-tdep commands
+	Various targets introduce their own commands, which then use
+	unfiltered output.  It's better to use filtered output by default, so
+	this patch fixes the instances I found.
+
+	Use filtered output in btrace-related commands
+	This changes btrace.c and record-btrace.c to use filtered output in
+	the commands implemented there.
+
+	Use filtered output in some dumping commands
+	There are several commands that may optionally send their output to a
+	file -- they take an optional filename argument and open a file.  This
+	patch changes these commands to use filtered output.  The rationale
+	here is that, when printing to gdb_stdout, filtering is appropriate --
+	it is, and should be, the default for all commands.  And, when writing
+	to a file, paging will not happen anyway (it only happens when the
+	stream==gdb_stdout), so using the _filtered form will not change
+	anything.
+
+	Use filtered output in kill command
+	This changes the kill command to use filtered output.  I split this
+	one into its own patch because, out of an abundance of caution, I
+	changed the function to call bfd_cache_close_all a bit earlier, in
+	case pagination caused an exception.
+
+2022-01-05  Tom Tromey  <tom@tromey.com>
+
+	Use filtered output in ordinary commands
+	Many otherwise ordinary commands choose to use unfiltered output
+	rather than filtered.  I don't think there's any reason for this, so
+	this changes many such commands to use filtered output instead.
+
+	Note that complete_command is not touched due to a comment there
+	explaining why unfiltered output is believed to be used.
+
+2022-01-05  Tom Tromey  <tom@tromey.com>
+
+	Use filtered output in language_info
+	Change language_info to use filtered output.  This is ok because the
+	sole caller uses filtered output elsewhere, and because this function
+	calls show_language_command, which also uses filtered output.
+
+	Use filtered output in files_info implementations
+	This changes the implementations of the target files_info method to
+	use filtered output.  This makes sense because the sole caller of this
+	method is an ordinary command (info_program_command).  This patch
+	changes this command to use filtered output as well.
+
+	Use filtered output in target-descriptions.c
+	target-descriptions.c uses unfiltered output.  However, if you happen
+	to invoke this command interactively, it's probably better for it to
+	use filtering.  For non-interactive use, this doesn't matter.
+
+	Use filtered output for gdbarch dump
+	This changes gdbarch dumping to use filtered output.  This seems a bit
+	better to me, both on the principle that this is an ordinary command,
+	and because the output can be voluminous, so it may be nice to stop in
+	the middle.
+
+2022-01-05  Tom Tromey  <tom@tromey.com>
+
+	Implement putstr and putstrn in ui_file
+	In my tour of the ui_file subsystem, I found that fputstr and fputstrn
+	can be simplified.  The _filtered forms are never used (and IMO
+	unlikely to ever be used) and so can be removed.  And, the interface
+	can be simplified by removing a callback function and moving the
+	implementation directly to ui_file.
+
+	A new self-test is included.  Previously, I think nothing was testing
+	this code.
+
+	Regression tested on x86-64 Fedora 34.
+
+2022-01-05  Tom Tromey  <tromey@adacore.com>
+
+	Change how versioned symbols are recorded
+	A change to BFD caused a gdb regression when using the Ada "catch
+	exception" feature.  The bug is visible when a shared library throws
+	an exception that is caught in the main executable.
+
+	This was discussed here:
+
+	https://sourceware.org/pipermail/binutils/2021-July/117538.html
+
+	This patch implements Alan's proposed fix, namely to use VERSYM_HIDDEN
+	rather than the name when deciding to install a version-less symbol.
+
+	The internal test case is identical to the catch_ex_std.exp that is
+	in-tree, so I haven't added a new test.  I could not make that one
+	fail on x86-64 Linux, though.  It's possible that maybe I'd have to
+	update the system linker first, but I didn't want to try that.
+
+	Regression tested on x86-64 Fedora 32.
+
+2022-01-05  Hannes Domani  <ssbssa@yahoo.de>
+
+	Fix inferior_thread attribute in new_thread event
+	Commit 72ee03ff58 fixed a use-after-move bug in add_thread_object, but
+	it changed the inferior_thread attribute to contain the inferior instead
+	of the actual thread.
+	This now uses the thread_obj in its new location instead.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28429
+
+2022-01-05  Tom Tromey  <tom@tromey.com>
+
+	Simplify execute_control_commands_to_string
+	execute_control_commands_to_string can be rewritten in terms of
+	execute_fn_to_string, which consolidates some knowledge about which
+	streams to redirect.
+
+	Regression tested on x86-64 Fedora 34.
+
+2022-01-05  Tom Tromey  <tromey@adacore.com>
+
+	Do not print anything when self-backtrace unavailable
+	Right now, gdb's self-backtrace feature will still print something
+	when a backtrace is unavailable:
+
+	   sig_write (_("----- Backtrace -----\n"));
+	[...]
+	     sig_write (_("Backtrace unavailable\n"));
+	    sig_write ("---------------------\n");
+
+	However, if GDB_PRINT_INTERNAL_BACKTRACE is undefined, it seems better
+	to me to print nothing at all.
+
+	This patch implements this change.  It also makes a couple of other
+	small changes in this same module: it adds a header guard to
+	bt-utils.h, and it protects the definitions of
+	gdb_internal_backtrace_1 with a check of GDB_PRINT_INTERNAL_BACKTRACE.
+
+2022-01-05  Tom Tromey  <tromey@adacore.com>
+
+	Fix pager regression
+	The patch to fix paging with redirection caused a regression in the
+	internal AdaCore test suite.  The problem occurs when running an MI
+	command from the CLI using interpreter-exec, when paging is enabled.
+	This scenario isn't covered by the current test suite, so this patch
+	includes a new test.
+
+	The problem is that, in this situation, MI does:
+
+	  fputs_unfiltered (strcmp (context->command, "target-select") == 0
+			     ? "^connected" : "^done", mi->raw_stdout);
+
+	Here raw_stdout is a stdio_file wrapping stdout, so the pager thinks
+	that it is ok to buffer the output.  However, in this setup, it isn't
+	ok, and flushing the wrap buffer doesn't really work properly.  Also,
+	MI next does:
+
+	  mi_out_put (uiout, mi->raw_stdout);
+
+	... but this uses ui_file::write, which also doesn't flush the wrap
+	buffer.
+
+	I think all this will be fixed by the pager rewrite series I'm working
+	on.  However, in the meantime, adding the old gdb_stdout check back to
+	the pager fixes this problem.
+
+	Regression tested on x86-64 Fedora 34.
+
+2022-01-05  H.J. Lu  <hjl.tools@gmail.com>
+
+	elf: Set p_align to the minimum page size if possible
+	Currently, on 32-bit and 64-bit ARM, it seems that ld generates p_align
+	values of 0x10000 even if no section alignment is greater than 0x1000.
+	The issue is more general and probably affects other targets with multiple
+	page sizes.
+
+	While file layout absolutely must take 64K page size into account, that
+	does not have to be reflected in the p_align value.  If running on a 64K
+	kernel, the file will be loaded at a 64K page boundary by necessity. On
+	a 4K kernel, 64K alignment is not needed.
+
+	The glibc loader has been fixed to honor p_align:
+
+	https://sourceware.org/bugzilla/show_bug.cgi?id=28676
+
+	similar to kernel:
+
+	commit ce81bb256a224259ab686742a6284930cbe4f1fa
+	Author: Chris Kennelly <ckennelly@google.com>
+	Date:   Thu Oct 15 20:12:32 2020 -0700
+
+	    fs/binfmt_elf: use PT_LOAD p_align values for suitable start address
+
+	This means that on 4K kernels, we will start to do extra work for 64K
+	p_align, but this pointless for pretty much all binaries (whose section
+	alignment rarely exceeds 16).
+
+	The minimum page size is used, instead of the maximum section alignment
+	due to this glibc bug:
+
+	https://sourceware.org/bugzilla/show_bug.cgi?id=28688
+
+	It has been fixed in glibc 2.35.  But linker output must work on existing
+	glibc binaries.
+
+	1. Set p_align to the minimum page size while laying out segments aligning
+	to the maximum page size or section alignment.  The run-time loader can
+	align segments to the minimum page size or above, depending on system page
+	size.
+	2. If -z max-page-size=NNN is used, p_align will be set to the maximum
+	page size or the largest section alignment.
+	3. If a section requires alignment higher than the minimum page size,
+	don't set p_align to the minimum page size.
+	4. If a section requires alignment higher than the maximum page size,
+	set p_align to the section alignment.
+	5. For objcopy, when the minimum page size != the maximum page size,
+	p_align may be set to the minimum page size while segments are aligned
+	to the maximum page size.  In this case, the input p_align will be
+	ignored and the maximum page size will be used to align the ouput
+	segments.
+	6. Update linker to disallow the common page size > the maximum page size.
+	7. Update linker to avoid the common page size > the maximum page size.
+	8. Adjust pru_irq_map-1.d to expect p_align == sh_addralign:
+
+	Section Headers:
+	  [Nr] Name   Type            Addr     Off    Size   ES Flg Lk Inf Al
+	  [ 0]        NULL            00000000 000000 000000 00      0   0  0
+	  [ 1] .text  PROGBITS        20000000 00007c 000004 00  AX  0   0  4
+	...
+	Program Headers:
+	  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
+	  LOAD           0x000074 0x00000000 0x00000000 0x00008 0x00008 RW  0x1
+	  LOAD           0x00007c 0x20000000 0x20000000 0x00004 0x00004 R E 0x4
+
+	vs.
+
+	Section Headers:
+	  [Nr] Name   Type            Addr     Off    Size   ES Flg Lk Inf Al
+	  [ 0]        NULL            00000000 000000 000000 00      0   0  0
+	  [ 1] .text  PROGBITS        20000000 00007c 000004 00  AX  0   0  4
+	...
+	Program Headers:
+	  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
+	  LOAD           0x000074 0x00000000 0x00000000 0x00008 0x00008 RW  0x1
+	  LOAD           0x00007c 0x20000000 0x20000000 0x00004 0x00004 R E 0x1
+
+	To enable this linker optimization, the backend should define ELF_P_ALIGN
+	to ELF_MINPAGESIZE.
+
+	bfd/
+
+		PR ld/28689
+		PR ld/28695
+		* elf-bfd.h (elf_backend_data): Add p_align.
+		* elf.c (assign_file_positions_for_load_sections): Set p_align
+		to the default p_align value while laying out segments aligning
+		to maximum page size or section alignment.
+		(elf_is_p_align_valid): New function.
+		(copy_elf_program_header): Call elf_is_p_align_valid to determine
+		if p_align is valid.
+		* elfxx-target.h (ELF_P_ALIGN): New.  Default to 0.
+		(elfNN_bed): Add ELF_P_ALIGN.
+		* elfxx-x86.h (ELF_P_ALIGN): New.  Set to ELF_MINPAGESIZE.
+
+	include/
+
+		PR ld/28689
+		PR ld/28695
+		* bfdlink.h (bfd_link_info): Add maxpagesize_is_set.
+
+	ld/
+
+		PR ld/28689
+		PR ld/28695
+		* emultempl/elf.em (gld${EMULATION_NAME}_handle_option): Set
+		link_info.maxpagesize_is_set for -z max-page-size=NNN.
+		* ldelf.c (ldelf_after_parse): Disallow link_info.commonpagesize
+		> link_info.maxpagesize.
+		* testsuite/ld-elf/elf.exp: Pass -z max-page-size=0x4000 to
+		linker to build mbind2a and mbind2b.
+		* testsuite/ld-elf/header.d: Add -z common-page-size=0x100.
+		* testsuite/ld-elf/linux-x86.exp: Add PR ld/28689 tests.
+		* testsuite/ld-elf/p_align-1.c: New file.
+		* testsuite/ld-elf/page-size-1.d: New test.
+		* testsuite/ld-elf/pr26936.d: Add -z common-page-size=0x1000.
+		* testsuite/ld-elf/seg.d: Likewise.
+		* testsuite/ld-scripts/rgn-at5.d: Likewise.
+		* testsuite/ld-pru/pru_irq_map-1.d: Append 1 to name.  Adjust
+		expected PT_LOAD segment alignment.
+		* testsuite/ld-pru/pru_irq_map-2.d: Append 2 to name.
+		* testsuite/ld-scripts/pr23571.d: Add -z max-page-size=0x1000.
+
+2022-01-05  Alan Modra  <amodra@gmail.com>
+
+	Adjust quoted-sym-names test
+	Some targets restrict symbol addresses in .text to instruction
+	boundaries.
+
+		* testsuite/gas/all/quoted-sym-names.s: Define syms in .data.
+		* testsuite/gas/all/quoted-sym-names.d: Adjust to suit.
+
+2022-01-05  Alan Modra  <amodra@gmail.com>
+
+	infinite recursion detected in gold testcase
+	gold/testsuite/icf_test.cc:32:5: error: infinite recursion detected [-Werror=infinite-recursion]
+	   32 | int kept_func()
+	      |     ^~~~~~~~~
+
+		* testsuite/icf_test.cc: Avoid infinite recursion error.
+
+2022-01-05  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-04  H.J. Lu  <hjl.tools@gmail.com>
+
+	ld/x86: Update -z report-relative-reloc
+	Use 0x%v, instead of bfd_sprintf_vma, to report relative relocations.
+	Change linker relative relocations report from
+
+	tmpdir/dump: R_X86_64_IRELATIVE (offset: 0x0000000000002000, info: 0x0000000000000025, addend: 0x0000000000001007) against 'ifunc' for section '.data.rel.ro.local' in tmpdir/report-reloc-1.o
+
+	to
+
+	tmpdir/dump: R_X86_64_IRELATIVE (offset: 0x2000, info: 0x25, addend: 0x1007) against 'ifunc' for section '.data.rel.ro.local' in tmpdir/report-reloc-1.o
+
+	bfd/
+
+		* elfxx-x86.c (_bfd_x86_elf_link_report_relative_reloc): Use
+		0x%v instead of bfd_sprintf_vma.
+
+	ld/
+
+		* testsuite/ld-i386/report-reloc-1.l: Updated.
+		* testsuite/ld-x86-64/report-reloc-1.l: Likewise.
+
+2022-01-04  H.J. Lu  <hjl.tools@gmail.com>
+
+	ld: Improve thin archive member error message
+	Improve thin archive member error message with:
+
+	ld: libbar.a(bar.o): error opening thin archive member: No such file or directory
+
+	instead of
+
+	ld: libbar.a: error adding symbols: No such file or directory
+
+		PR ld/28722
+		* archive.c (_bfd_get_elt_at_filepos): Add a pointer argument
+		for struct bfd_link_info.  Call linker callback when failing to
+		open thin archive member.
+		(_bfd_generic_get_elt_at_index): Pass NULL to
+		_bfd_get_elt_at_filepos.
+		(bfd_generic_openr_next_archived_file): Likewise.
+		* coff-alpha.c (alpha_ecoff_get_elt_at_filepos): Add a pointer
+		argument for struct bfd_link_info and pass it to
+		_bfd_get_elt_at_filepos.
+		(alpha_ecoff_openr_next_archived_file): Pass NULL to
+		_bfd_get_elt_at_filepos.
+		(alpha_ecoff_get_elt_at_index): Likewise.
+		* coff-rs6000.c (_bfd_xcoff_openr_next_archived_file): Likewise.
+		* ecoff.c (ecoff_link_add_archive_symbols): Pass info to
+		backend->get_elt_at_filepos.
+		* elflink.c (elf_link_is_defined_archive_symbol): info to
+		_bfd_get_elt_at_filepos.
+		* libbfd-in.h (_bfd_get_elt_at_filepos): Add a pointer argument
+		for struct bfd_link_info.
+		* libbfd.h: Regenerate.
+		* libecoff.h (ecoff_backend_data): Add a pointer argument for
+		struct bfd_link_info to get_elt_at_filepos.
+		* linker.c (_bfd_generic_link_add_archive_symbols): Pass info to
+		_bfd_get_elt_at_filepos.
+
+2022-01-04  Lancelot SIX  <lancelot.six@amd.com>
+
+	gdb/testsuite: fix inferior-clone.exp for native-extended-gdbserver
+	003aae076207dbf32f98ba846158fc32669ef85f (gdb: Copy inferior properties
+	in clone-inferior) introduced a testcase that fails when testing with
+	the native-extended-gdbserver board:
+
+	    Running ../gdb/testsuite/gdb.base/inferior-clone.exp ...
+	    FAIL: gdb.base/inferior-clone.exp: inferior 2: clone-inferior
+	    FAIL: gdb.base/inferior-clone.exp: inferior 3: clone-inferior
+
+	The error is as follows:
+
+	    clone-inferior
+	    [New inferior 2]
+	    Added inferior 2 on connection 1 (extended-remote localhost:2346)
+	    (gdb) FAIL: gdb.base/inferior-clone.exp: inferior 2: clone-inferior
+
+	This fails because the testcase only expect the 'Added inferior 2' part
+	of the message.  The 'on connection 1 [...]' part is unexpected.
+
+	Fix by adjusting the testcase to a account for the possible trailing
+	part of the message.
+
+	Tested on x86_64-linux with native-extende-gdbserver and unix boards.
+
+	Change-Id: Ie3d6f04c9ffe9cab1fbda8ddf4935ee09b858c7a
+
+2022-01-04  Nick Clifton  <nickc@redhat.com>
+
+	Add ATTRIBUTE_UNUSED to load_build_id_debug_file()'s main_filename parameter.
+
+2022-01-04  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: don't pass nullptr to sigwait
+	I tried building GDB on GNU/Hurd, and ran into this warning:
+
+	  gdbsupport/scoped_ignore_signal.h:78:16: error: null argument where non-null required (argument 2) [-Werror=nonnull]
+
+	This is because in this commit:
+
+	  commit 99624310dd82542c389c89c2e55d8cae36bb74e1
+	  Date:   Sun Jun 27 15:13:14 2021 -0400
+
+	      gdb: fall back on sigpending + sigwait if sigtimedwait is not available
+
+	A call to sigwait was introduced that passes nullptr as the second
+	argument, this call is only reached if sigtimedwait is not supported.
+
+	The original patch was written for macOS, I assume on that target
+	passing nullptr as the second argument is fine.
+
+	On my GNU/Linux box, the man-page for sigwait doesn't mention that
+	nullptr is allowed for the second argument, so my assumption would be
+	that nullptr is not OK, and, if I change the '#ifdef
+	HAVE_SIGTIMEDWAIT' introduced by the above patch to '#if 0', and
+	rebuild on GNU/Linux, I see the same warning that I see on GNU/Hurd.
+
+	I propose that we stop passing nullptr as the second argument to
+	sigwait, and instead pass a valid int pointer.  The value returned in
+	the int can then be used in an assert.
+
+	For testing, I (locally) made the change to the #ifdef I mentioned
+	above, compiled GDB, and ran the usual tests, this meant I was using
+	sigwait instead on sigtimedwait on GNU/Linux, I saw no regressions.
+
+2022-01-04  Nick Clifton  <nickc@redhat.com>
+
+	Remove a spurious debugging message.
+		PR 28716
+		* dwarf.c (load_build_id_debug_file): Remove spurious printf.
+
+2022-01-04  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/build] Fix build breaker in gdb/cli/cli-logging.c
+	Fix build breaker in gdb/cli/cli-logging.c:
+	...
+	gdb/cli/cli-logging.c: In function \
+	  ‘void show_logging_enabled(ui_file*, int, cmd_list_element*, const char*)’:
+	gdb/gdbsupport/gdb_locale.h:28:28: error: cannot convert ‘char*’ to ‘ui_file*’
+	   28 | # define _(String) gettext (String)
+	      |                    ~~~~~~~~^~~~~~~~
+	      |                            |
+	      |                            char*
+	gdb/cli/cli-logging.c:202:25: note: in expansion of macro ‘_’
+	  202 |     fprintf_unfiltered (_("on: Logging is enabled.\n"));
+	      |                         ^
+	...
+
+	Build and tested on x86_64-linux.
+
+	Fixes: 45aec4e5ed8 ("[gdb/cli] Improve show logging output")
+
+2022-01-04  Jan Beulich  <jbeulich@suse.com>
+
+	x86/Intel: correct VFPCLASSP{S,D} handling when displacement is present
+	fits_in_disp8() can be called before ambiguous operands get resolved
+	or rejected (in process_suffix()), which requires that i.memshift be
+	non-negative to avoid an internal error. This case wasn't covered by
+	6c0946d0d28d ("x86: correct VFPCLASSP{S,D} operand size handling").
+
+2022-01-04  Jan Beulich  <jbeulich@suse.com>
+
+	gas: rework handling of backslashes in quoted symbol names
+	Strange effects can result from the present handling, e.g.:
+
+	.if 1
+	"backslash\\":
+	.endif
+
+	yields first (correctly) "missing closing `"'" but then also "invalid
+	character '\' in mnemonic" and further "end of file inside conditional".
+	Symbols names ending in \ are in principle not expressable with that
+	scheme.
+
+	Instead of recording whether a backslash was seen, inspect the
+	subsequent character right away. Only accept \\ (meaning a single
+	backslash in the resulting symbol name) and \" (meaning an embedded
+	double quote in the resulting symbol name) for now, warning about any
+	other combination.
+
+	While perhaps not necessary immediately, also permit concatenated
+	strings to form a symbol name. This may become useful if going forward
+	we would want to support \<octal> or \x<hex> sequences, where closing
+	and re-opening quotes can be useful to delimit such sequences.
+
+	The ELF "Multibyte symbol names" test gets switched away from using
+	.set, as that would now also mean excluding nios2 and pru. By using
+	.equiv instead, even the existing #notarget can be dropped. (For h8300
+	the .section directive additionally needs attributes specified, to avoid
+	a target specific warning.)
+
+2022-01-04  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-03  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/cli] Improve show logging output
+	Before commit 3b6acaee895 "Update more calls to add_prefix_cmd" we had the
+	following output for "show logging":
+	...
+	$ gdb -q -batch -ex "set trace-commands on" \
+	    -ex "set logging off" \
+	    -ex "show logging" \
+	    -ex "set logging on" \
+	    -ex "show logging"
+	+set logging off
+	+show logging
+	Future logs will be written to gdb.txt.
+	Logs will be appended to the log file.
+	Output will be logged and displayed.
+	Debug output will be logged and displayed.
+	+set logging on
+	+show logging
+	Currently logging to "gdb.txt".
+	Logs will be appended to the log file.
+	Output will be logged and displayed.
+	Debug output will be logged and displayed.
+	...
+
+	After that commit we have instead:
+	...
+	+set logging off
+	+show logging
+	debugredirect:  The logging output mode is off.
+	file:  The current logfile is "gdb.txt".
+	overwrite:  Whether logging overwrites or appends to the log file is off.
+	redirect:  The logging output mode is off.
+	+set logging on
+	+show logging
+	debugredirect:  The logging output mode is off.
+	file:  The current logfile is "gdb.txt".
+	overwrite:  Whether logging overwrites or appends to the log file is off.
+	redirect:  The logging output mode is off.
+	...
+	which gives less clear output for some subcommands.
+
+	OTOH, it's explicit about whether boolean values are on or off.
+
+	The new text seems to have been chosen to match the set/show help texts:
+	...
+	(gdb) help show logging
+	Show logging options.
+
+	List of show logging subcommands:
+
+	show logging debugredirect -- Show the logging debug output mode.
+	show logging file -- Show the current logfile.
+	show logging overwrite -- \
+	  Show whether logging overwrites or appends to the log file.
+	show logging redirect -- Show the logging output mode.
+	...
+
+	Make the show logging messages more clear, while still keep the boolean
+	values explicit, such that we have:
+	...
+	$ ./gdb.sh -q -batch -ex "show logging"
+	logging debugredirect:  off: \
+	  Debug output will go to both the screen and the log file.
+	logging enabled:  off: Logging is disabled.
+	logging file:  The current logfile is "gdb.txt".
+	logging overwrite:  off: Logging appends to the log file.
+	logging redirect:  off: Output will go to both the screen and the log file.
+	...
+
+	Tested on x86_64-linux.
+
+2022-01-03  Tom Tromey  <tromey@adacore.com>
+
+	Fix use of 'printf' in gdbtypes.c
+	An earlier patch of mine, commit 64b7cc50 ("Remove
+	gdb_print_host_address") inadvertently changed a function in
+	gdbtypes.c to use printf rather than printf_filtered.  This patch
+	fixes the problem.
+
+	Fix regression in page-logging.exp
+	Simon and Tom pointed out that page-logging.exp failed on their
+	machines.  Tom tracked this down to the "width" setting.  Since
+	there's no need in the test to change the width, it seems simplest to
+	remove the setting.  I confirmed that the test still fails if the fix
+	is backed out, ensuring that the test is still testing what it
+	purports to.
+
+	Small indentation fix in eval.c
+	I noticed that the AdaCore tree had a small divergence in eval.c -- it
+	had a fix for an indentation problem in binop_promote.  I'm checking
+	in this small fix as obvious.
+
+2022-01-03  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Handle for loop initial decl with gcc 4.8.5
+	When running test-case gdb.threads/schedlock-thread-exit.exp on a system with
+	system compiler gcc 4.8.5, I run into:
+	...
+	src/gdb/testsuite/gdb.threads/schedlock-thread-exit.c:33:3: error: \
+	  'for' loop initial declarations are only allowed in C99 mode
+	...
+
+	Fix this by:
+	- using -std=c99, or
+	- using -std=gnu99, in case that's required, or
+	- in the case of the jit test-cases, rewriting the for loops.
+
+	Tested on x86_64-linux, both with gcc 4.8.5 and gcc 7.5.0.
+
+2022-01-03  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-02  Tom Tromey  <tom@tromey.com>
+
+	Update copying.awk for _initialize declaration patch
+	Commit 6c265988 ("gdb: add back declarations for _initialize
+	functions") modified copying.c, but not copying.awk.  This patch
+	updates copying.awk to backport the appropriate fix.  This way, if
+	copying.awk is run again, it will create the correct output.
+
+	I'm checking this in as obvious.
+
+2022-01-02  Tom Tromey  <tom@tromey.com>
+
+	Use filtered output in print_i387_ext
+	print_i387_ext mostly uses filtered output, but one call in the middle
+	of the function uses the _unfiltered form.  This patch fixes this
+	call.  I'm checking this in as obvious.
+
+2022-01-02  Alan Modra  <amodra@gmail.com>
+
+	Update year range in copyright notice of binutils files
+	The result of running etc/update-copyright.py --this-year, fixing all
+	the files whose mode is changed by the script, plus a build with
+	--enable-maintainer-mode --enable-cgen-maint=yes, then checking
+	out */po/*.pot which we don't update frequently.
+
+	The copy of cgen was with commit d1dd5fcc38ead reverted as that commit
+	breaks building of bfp opcodes files.
+
+2022-01-02  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2022-01-01  Mike Frysinger  <vapier@gentoo.org>
+
+	gdb: copyright: fix a few comment typos
+
+	sim: ppc: drop natural types
+	These are almost entirely unused.  For the very few places using them,
+	replace with explicit signed types.  This matches what was done in the
+	common sim code.
+
+	sim: mips: clean up bad style/whitespace
+	This doesn't fix all the problems, but grabs a bunch of the more
+	obvious ones.
+
+	sim: tweak copyright lines for gnulib update-copyright
+	The regex it uses does not like so many leading spaces which causes
+	it to think the files lack copyright.  Trim them down so the script
+	can find & update them accordingly.
+
+	gdb: update sim mips testsuite copyright exemption
+	The sim testsuite was reorganized last year, so update the path.
+
+2022-01-01  Mike Frysinger  <vapier@gentoo.org>
+
+	unify 64-bit bfd checks
+	Move the 64-bit bfd logic out of bfd/configure.ac and into bfd64.m4
+	under config so it can be shared between all the other subdirs.
+
+	This replaces want64 with enable_64_bit_bfd which was already being
+	declared, but not used directly.
+
+2022-01-01  Joel Brobecker  <brobecker@adacore.com>
+
+	Update Copyright year in gdb/testsuite/gdb.arch/powerpc-power10.exp
+	This commit updates the copyright year range in the script
+	gdb/testsuite/gdb.arch/powerpc-power10.exp. The update was
+	performed by running gdb/copyright.py again, to make sure
+	that the copyright year range will be automatically updated
+	in years forward.
+
+2022-01-01  Joel Brobecker  <brobecker@adacore.com>
+
+	Fix copyright header in gdb/testsuite/gdb.arch/powerpc-power10.exp
+	The copyright year and holder line is slight malformed, missing
+	a space after a comma, and this is sufficient for gdb's
+	copyright.py script to miss this file during its automated
+	copyright year update.
+
+	This commit fixes this.
+
+2022-01-01  Joel Brobecker  <brobecker@adacore.com>
+
+	gdb/copyright.py: Add update-netbsd.sh to MULTIPLE_COPYRIGHT_HEADERS
+	Add gdb/syscalls/update-netbsd.sh to the reminder printed
+	at the end of the execution listing all the files where
+	a manual update of the copyright header is needed. This
+	scripts contains some inline code which includes a copyright
+	header.
+
+	Manual copyright year update of various GDB files
+	This commit updates the copyright year in some files where
+	we have a copyright year outside of the copyright year,
+	and thus are not included in gdb's copyright.py script.
+
+2022-01-01  Joel Brobecker  <brobecker@adacore.com>
+
+	Automatic Copyright Year update after running gdb/copyright.py
+	This commit brings all the changes made by running gdb/copyright.py
+	as per GDB's Start of New Year Procedure.
+
+	For the avoidance of doubt, all changes in this commits were
+	performed by the script.
+
+2022-01-01  Joel Brobecker  <brobecker@adacore.com>
+
+	Update Copyright Year in gdb, gdbserver and gdbreplay version output
+	This commit changes the copyright year printed by gdb, gdbserver
+	and gdbreplay when printing the tool's version.
+
+2022-01-01  Alan Modra  <amodra@gmail.com>
+
+	ubsan: next_char_of_string signed integer overflow
+	Squash another totally useless fuzz report that I should have ignored.
+
+		* read.c (next_char_of_string): Avoid integer overflow.
+
+2022-01-01  Alan Modra  <amodra@gmail.com>
+
+	ubsan: bfd_mach_o_build_commands shift exponent 64 is too large
+		* mach-o.c (bfd_mach_o_read_section_32): Limit alignment further.
+		(bfd_mach_o_read_section_64): Likewise.
+
+2022-01-01  Alan Modra  <amodra@gmail.com>
+
+	ubsan: signed integer multiply overflow
+	9223371018427387904 * 2 cannot be represented in type 'long', yes, but
+	we don't care.
+
+		* expr.c (expr): Avoid signed overflow.
+
+2022-01-01  Alan Modra  <amodra@gmail.com>
+
+	asan: Null-dereference in _bfd_xcoff_copy_private_bfd_data
+	sec->output_section will be NULL when objcopy removes sections.
+
+		* coff-rs6000.c (_bfd_xcoff_copy_private_bfd_data): Protect against
+		objcopy removing sections.
+
+2022-01-01  Alan Modra  <amodra@gmail.com>
+
+	ubsan: integer overflow in section filepos subtraction
+		* elf.c (assign_file_positions_for_non_load_sections): Avoid
+		signed integer overflow.
+
+2022-01-01  Alan Modra  <amodra@gmail.com>
+
+	Remove unnecessary ELF_MINPAGESIZE defines
+	The idea of this patch is to make it easy to see which targets (just
+	sparc) have ELF_MINPAGESIZE != ELF_COMMONPAGESIZE.
+
+		* elf32-arm.c (ELF_MINPAGESIZE): Don't define.
+		* elf32-metag.c: Likewise.
+		* elfnn-aarch64.c: Likewise.
+		* elf64-x86-64.c: Likewise.  Also don't redefine a bunch of other
+		macros for l1om elf64-target.h use that are unchanged from default.
+
+2022-01-01  H.J. Lu  <hjl.tools@gmail.com>
+
+	ld-x86-64: Pass options to linker with "-Wl,"
+		* testsuite/ld-x86-64/x86-64.exp: Pass options to linker with
+		"-Wl,".
+
+2022-01-01  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-31  Tom Tromey  <tom@tromey.com>
+
+	Do not call reinitialize_more_filter from avr_io_reg_read_command
+	avr_io_reg_read_command is an ordinary gdb command, and so should not
+	be calling reinitialize_more_filter.  This patch removes it.  I'm
+	checking this in as obvious.  Tested by rebuilding.
+
+2021-12-31  H.J. Lu  <hjl.tools@gmail.com>
+
+	x86: Define check_relocs_failed in elfxx-x86.h
+		* elf32-i386.c (check_relocs_failed): Moved to ...
+		* elfxx-x86.h (check_relocs_failed): Here.  New.
+		* elf64-x86-64.c (check_relocs_failed): Removed.
+
+	Define X86_PCREL_TYPE_P/X86_SIZE_TYPE_P in elfxx-x86.h
+		* elf32-i386.c: Don't include "elf/i386.h".
+		(X86_PCREL_TYPE_P): Removed.
+		(X86_SIZE_TYPE_P): Likewise.
+		(elf_i386_check_relocs): Pass false to NEED_DYNAMIC_RELOCATION_P.
+		(elf_i386_relocate_section): Pass false to
+		GENERATE_DYNAMIC_RELOCATION_P and COPY_INPUT_RELOC_P.
+		* elf64-x86-64.c: Don't include "elf/x86-64.h".
+		(X86_PCREL_TYPE_P): Removed.
+		(X86_SIZE_TYPE_P): Likewise.
+		(elf_x86_64_check_relocs): Pass true to NEED_DYNAMIC_RELOCATION_P
+		and X86_PCREL_TYPE_P.
+		(elf_x86_64_relocate_section): Pass true to X86_PCREL_TYPE_P,
+		X86_SIZE_TYPE_P, GENERATE_DYNAMIC_RELOCATION_P and
+		COPY_INPUT_RELOC_P.
+		* elfxx-x86.c: Don't include "elf/i386.h" nor "elf/x86-64.h".
+		* elfxx-x86.h (X86_64_PCREL_TYPE_P): New.
+		(I386_PCREL_TYPE_P): Likewise.
+		(X86_PCREL_TYPE_P): Likewise.
+		(X86_64_SIZE_TYPE_P): Likewise.
+		(I386_SIZE_TYPE_P): Likewise.
+		(X86_SIZE_TYPE_P): Likewise.
+		(NEED_DYNAMIC_RELOCATION_P): Add IS_X86_64 and pass it to
+		X86_PCREL_TYPE_P.
+		(COPY_INPUT_RELOC_P): Likewise.
+		(GENERATE_DYNAMIC_RELOCATION_P): Add IS_X86_64, pass it to
+		X86_PCREL_TYPE_P and X86_SIZE_TYPE_P.
+
+2021-12-31  Tamar Christina  <tamar.christina@arm.com>
+
+	ld: fix coff PE SEH
+	COFF_WITH_pex64 and COFF_WITH_peAArch64 can't be true at the same time.
+	That means that two conditionals that control the sorting of the .pdata section
+	became a falsum.
+
+	The testsuite doesn't catch this because the linker does the sorting and to link
+	you require library support from the unwinder so we can't test from binutils in
+	isolation.
+
+	bfd/ChangeLog:
+
+	2021-12-31  Tamar Christina  <tamar.christina@arm.com>
+
+		PR ld/28682
+		* peXXigen.c: Fix conditional.
+
+2021-12-31  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-30  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-29  Tom Tromey  <tom@tromey.com>
+
+	Use filtered output in show callbacks
+	"show" command callbacks, like most ordinary gdb commands, should use
+	filtered output.  I found a few that did not, so this patch changes
+	them to use the filtered form.
+
+2021-12-29  Tom Tromey  <tom@tromey.com>
+
+	Consistently Use ui_file parameter to show callbacks
+	I happened to notice that one "show" callback was printing to
+	gdb_stdout rather than to the passed-in ui_file parameter.  I went
+	through all such callbacks and fixed them to consistently use the
+	ui_file.
+
+	Regression tested on x86-64 Fedora 34.
+
+2021-12-29  Tom Tromey  <tom@tromey.com>
+
+	Use gdb_stdlog for MI debugging
+	When MI debugging is enabled, the logging output should be sent to
+	gdb_stdlog.  This is part of PR gdb/7233.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233
+
+2021-12-29  Tom Tromey  <tom@tromey.com>
+
+	Use debug_prefixed_printf_cond_nofunc in index-cache
+	This changes index-cache.c to use debug_prefixed_printf_cond_nofunc.
+	As a side effect, logs are now written to gdb_stdlog.  This is part of
+	PR gdb/7233.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233
+
+2021-12-29  Tom Tromey  <tom@tromey.com>
+
+	Send minsym logging to gdb_stdlog
+	This changes minsyms.c to send logging output to gdb_stdlog.  This is
+	part of PR gdb/7233.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233
+
+2021-12-29  Tom Tromey  <tom@tromey.com>
+
+	Use gdb_stdlog for separate debug file logging
+	This changes the separate debug file logging code (spread across two
+	files) to use gdb_stdlog for its output.  This is part of PR gdb/7233.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233
+
+2021-12-29  Tom Tromey  <tom@tromey.com>
+
+	Use debug_prefixed_printf_cond_nofunc in machoread
+	This changes machoread.c to use debug_prefixed_printf_cond_nofunc.  As
+	a side effect, the logs are now written to gdb_stdlog.  This is part
+	of PR gdb/7233.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233
+
+2021-12-29  Tom Tromey  <tom@tromey.com>
+
+	Use debug_prefixed_printf_cond_nofunc in microblaze.c
+	This changes microblaze.c to use the standard logging macro.  As a
+	side effect, logs will now go to gdb_stdlog.  This is part of PR gdb/7233.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233
+
+2021-12-29  Tom Tromey  <tom@tromey.com>
+
+	Send debugging data to gdb_stdlog in mips-linux-nat.c
+	This changes mips-linux-nat.c to send some logging output to
+	gdb_stdlog, rather than stdout.  This is part of PR gdb/7233.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233
+
+2021-12-29  Tom Tromey  <tom@tromey.com>
+
+	Send arch-utils error messages to gdb_stderr
+	This changes arch-utils.c to send some error messages to gdb_stderr.
+	This is part of PR gdb/7233.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233
+
+2021-12-29  Tom Tromey  <tom@tromey.com>
+
+	Use correct stream for process record output
+	The process record code often emits unfiltered output.  In some cases,
+	this output ought to go to gdb_stderr (but see below).  In other
+	cases, the output is guarded by a logging variable and so ought to go
+	to gdb_stdlog.  This patch makes these changes.
+
+	Note that in many cases, the output to stderr is followed by a
+	"return -1", which is how process record indicates an error.  It seems
+	to me that calling error here would be preferable, because, in many
+	cases, that's all the caller does when it sees a -1.  However, I
+	haven't made this change.
+
+	This is part of PR gdb/7233.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233
+
+2021-12-29  Tom Tromey  <tom@tromey.com>
+
+	Send jit.c errors to gdb_stderr
+	jit.c writes some error messages to gdb_stdout, but using gdb_stderr
+	is better.  This is part of PR gdb/7233.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233
+
+2021-12-29  Tom Tromey  <tom@tromey.com>
+
+	Fix logging redirection bug with pager
+	I noticed yesterday that if gdb output is redirected to a file, the
+	pager will still be active.  This is irritating, because the output
+	isn't actually visible -- just the pager prompt.  Looking in bugzilla,
+	I found that this had been filed 17 years ago, as PR cli/8798.
+
+	This patch fixes the bug.  It changes the pagination code to query the
+	particular ui-file to see if paging is allowable.  The ui-file
+	implementations are changed so that only the stdout implementation and
+	a tee (where one sub-file is stdout) can page.
+
+	Regression tested on x86-64 Fedora 34.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=8798
+
+2021-12-29  Tom Tromey  <tom@tromey.com>
+
+	Remove unusual use of core_addr_eq and core_addr_hash
+	gdbtypes.h uses core_addr_eq and core_addr_hash in a weird way: taking
+	the address of a member and then passing this (as a void*) to these
+	functions.
+
+	It seems better to simply inline the ordinary code here.  CORE_ADDR is
+	a scalar so it can be directly compared, and the identity hash
+	function seems safe to assume as well.
+
+	After this, core_addr_eq and core_addr_hash are unused, so this patch
+	removes them.
+
+2021-12-29  Lancelot SIX  <lancelot.six@amd.com>
+
+	gdb: Copy inferior properties in clone-inferior
+	This commit ensures that the following settings are cloned from one
+	inferior to the new one when processing the clone-inferior command:
+	  - inferior-tty
+	  - environment variables
+	  - cwd
+	  - args
+
+	Some of those parameters can be passed as command line arguments to GDB
+	(-args and -tty), so one could expect the clone-inferior to respect
+	those flags.  The following debugging session illustrates that:
+
+	    gdb -nx -quiet -batch \
+	         -ex "show args" \
+	         -ex "show inferior-tty" \
+	         -ex "clone-inferior" \
+	         -ex "inferior 2" \
+	         -ex "show args" \
+	         -ex "show inferior-tty" \
+	         -tty=/some/tty \
+	         -args echo foo bar
+	    Argument list to give program being debugged when it is started is "foo bar".
+	    Terminal for future runs of program being debugged is "/some/tty".
+	    [New inferior 2]
+	    Added inferior 2.
+	    [Switching to inferior 2 [<null>] (/bin/echo)]
+	    Argument list to give program being debugged when it is started is "".
+	    Terminal for future runs of program being debugged is "".
+
+	The other properties this commit copies on clone (i.e. CWD and the
+	environment variables) are included since they are related (in the sense
+	that they influence the runtime behavior of the program) even if they
+	cannot be directly set using command line switches.
+
+	There is a chance that this patch changes existing user workflow.  I
+	think that this change is mostly harmless.  If users want to start a new
+	inferior based on an existing one, they probably already propagate those
+	settings to the new inferior in some way.
+
+	Tested on x86_64-linux.
+
+	Change-Id: I3b1f28b662f246228b37bb24c2ea1481567b363d
+
+2021-12-29  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-28  H.J. Lu  <hjl.tools@gmail.com>
+
+	elf32-i386: Fix a typo in GOT comments
+	Entry offsets in the global offset table are multiples of 4, not 8.
+
+		* elf32-i386.c (elf_i386_relocate_section): Fix a typo in GOT
+		comments.
+
+2021-12-28  H.J. Lu  <hjl.tools@gmail.com>
+
+	bfd: Don't check non-thin archive member file size
+	There is no need to check member file size for thin archive member.
+
+		* bfdio.c (bfd_bread): Don't check non-thin archive member file
+		size.
+
+2021-12-28  Alan Modra  <amodra@gmail.com>
+
+	gas reloc sorting
+	In some cases, eg. riscv_pre_output_hook, gas generates out-of-order
+	relocations.  Various places in the linker assume relocs are sorted
+	by increasing r_offset, which is normally the case.  Provide
+	GAS_SORT_RELOCS to handle unsorted relocs.
+
+	bfd/
+		PR 28709
+		* elf32-nds32.c (nds32_insertion_sort): Make static.
+		* elf32-nds32.h (nds32_insertion_sort): Delete declaration.
+	gas/
+		PR 28709
+		* write.c (write_relocs): Implement reloc sorting by r_offset
+		when GAS_SORT_RELOCS.
+		* config/tc-nds32.c (compar_relent, nds32_set_section_relocs): Delete.
+		* config/tc-nds32.h (nds32_set_section_relocs): Don't declare.
+		(SET_SECTION_RELOCS): Don't define.
+		(GAS_SORT_RELOCS): Define.
+		* config/tc-riscv.h (GAS_SORT_RELOCS): Define.
+
+2021-12-28  jiawei  <jiawei@iscas.ac.cn>
+
+	ld: Fix testcase errors due to -shared not support.
+	Reviewed-by: Jim Wilson <jim.wilson.gcc@gmail.com>
+
+	ld/ChangeLog:
+
+	        * testsuite/ld-ctf/ctf.exp: Add shared lib check.
+	        * testsuite/ld-plugin/lto.exp: Add lto shared check.
+
+2021-12-28  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-27  H.J. Lu  <hjl.tools@gmail.com>
+
+	elf: Update comments for check_relocs in elf_backend_data
+	Since
+
+	commit 5c3261b0e834647cf9eb555320e20871b7854f98
+	Author: H.J. Lu <hjl.tools@gmail.com>
+	Date:   Mon Oct 16 03:49:54 2017 -0700
+
+	    ELF: Call check_relocs after opening all inputs
+
+	check_relocs is called after opening all inputs.
+
+		* elf-bfd.h (elf_backend_data::check_relocs): Update comments.
+
+2021-12-27  H.J. Lu  <hjl.tools@gmail.com>
+
+	ld: Remove emultempl/linux.em
+	Remove emultempl/linux.em whose last usage was removed by
+
+	commit c65c21e1ffd1e02d9970a4bca0b7e384788a50f0
+	Author: Alan Modra <amodra@gmail.com>
+	Date:   Mon Apr 16 22:14:01 2018 +0930
+
+	    various i386-aout and i386-coff target removal
+
+	    Also tidies some other aout leftovers in binutils-common.exp.
+
+2021-12-27  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-26  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-25  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-24  Tom Tromey  <tom@tromey.com>
+
+	Remove gdb_print_host_address
+	gdb_print_host_address is just a simple wrapper around
+	fprintf_filtered.  However, it is readily replaced in all callers by a
+	combination of %s and call to host_address_to_string.  This also
+	simplifies the code, so I think it's worthwhile to remove this
+	function.
+
+	Regression tested on x86-64 Fedora 64.
+
+2021-12-24  Tom Tromey  <tom@tromey.com>
+
+	Move gdb_bfd_errmsg to gdb_bfd.c
+	gdb_bfd.c contains most of gdb's BFD-related utility functions.
+	However, gdb_bfd_errmsg is in utils.c.  It seemed better to me to move
+	this out of util.[ch] and into the BFD-related file instead.
+
+	Tested by rebuilding.
+
+2021-12-24  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: Rewrite the csr testcases.
+	Maskray (Fangrui Song) had suggested me before that we should combine
+	multiple testcases into one file as possible as we can.  So that we can
+	more easily understand what these test cases are testing, and easier to
+	maintain.  Therefore, this patch rewrites all csr testcases, to make them
+	more clean.
+
+	gas/
+		* testsuite/gas/riscv/csr-fail-nonexistent.d: Renamed from
+		priv-reg-fail-nonexistent testcase.
+		* testsuite/gas/riscv/csr-fail-nonexistent.: Likewise.
+		* testsuite/gas/riscv/csr-fail-nonexistent.s: Likewise.
+		* testsuite/gas/riscv/csr-insns-pseudo-noalias.d: Renamed from
+		priv-reg-pseudo testcase.
+		* testsuite/gas/riscv/csr-insns-pseudo.d: Likewise.
+		* testsuite/gas/riscv/csr-insns-pseudo.s: Likewise.
+		* testsuite/gas/riscv/csr-insns-read-only.d: Renamed from
+		priv-reg-fail-read-only-02 testcase.
+		* testsuite/gas/riscv/csr-insns-read-only.l: Likewise.
+		* testsuite/gas/riscv/csr-insns-read-only.s: Likewise.
+		* testsuite/gas/riscv/h-ext-32.d: Moved hypervisor csrs to csr.s.
+		* testsuite/gas/riscv/h-ext-32.s: Likewise.
+		* testsuite/gas/riscv/h-ext-64.d: Likewise.
+		* testsuite/gas/riscv/h-ext-64.s: Likewise.
+		* testsuite/gas/riscv/csr.s: Renamed from priv-reg.s, and then
+		added the hypervisor csrs.
+		* testsuite/gas/riscv/csr-version-1p9p1.d: The csr testcase when
+		the privileged spec is 1.9.1.  Also tested all invalid csr warnings
+		when -mcsr-check is enabled.
+		* testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
+		* testsuite/gas/riscv/csr-version-1p10.d: Likewise, but the
+		privileged spec is 1.10..
+		* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
+		* testsuite/gas/riscv/csr-version-1p11.d: Likewise, but the
+		privileged spec is 1.11.
+		* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
+		* testsuite/gas/riscv/csr-version-1p12.d: Likewise, but the
+		privileged spec is 1.12.
+		* testsuite/gas/riscv/csr-version-1p12.l: Likewise.
+		* testsuite/gas/riscv/priv-reg*: Removed or Renamed.
+
+2021-12-24  Vineet Gupta  <vineetg@rivosinc.com>
+
+	RISC-V: Hypervisor ext: support Privileged Spec 1.12
+	This is the Hypervisor Extension 1.0
+
+	 - Hypervisor Memory-Management Instructions
+	   HFENCE.VVMA, HFENCE.GVMA,
+
+	 - Hypervisor Virtual Machine Load and Store Instructions
+	   HLV.B, HLV.BU,          HSV.B,
+	   HLV.H, HLV.HU, HLVX.HU, HSB.H,
+	   HLV.W, HLV.WU, HLVX.WU, HSV.W,
+	   HLV.D,                  HSV.D
+
+	 - Hypervisor CSRs (some new, some address changed)
+	   hstatus, hedeleg, hideleg, hie, hcounteren, hgeie, htval, hip, hvip,
+	   htinst, hgeip, henvcfg, henvcfgh, hgatp, hcontext, htimedelta, htimedeltah,
+	   vsstatus, vsie, vstvec, vsscratch, vsepc, vscause, vstval, vsip, vsatp,
+
+	Note that following were added already as part of svinval extension
+	support:
+	   HINVAL.GVMA, HINVAL.VVMA
+
+	Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
+	Reviewed-by: Nelson Chu <nelson.chu@sifive.com>
+
+	bfd/
+		* cpu-riscv.c (riscv_priv_specs): Added entry for 1.12.
+		* cpu-riscv.h (enum riscv_spec_class): Added PRIV_SPEC_CLASS_1P12.
+	gas/
+		* config/tc-riscv.c (abort_version): Updated comment.
+		(validate_riscv_insn): Annotate switch-break.
+		* testsuite/gas/riscv/h-ext-32.d: New testcase for hypervisor.
+		* testsuite/gas/riscv/h-ext-32.s: Likewise.
+		* testsuite/gas/riscv/h-ext-64.d: Likewise.
+		* testsuite/gas/riscv/h-ext-64.s: Likewise.
+	include/
+		* opcode/riscv-opc.h: Added encodings for hypervisor csrs and
+		instrcutions.
+	opcodes/
+		* riscv-opc.c (riscv_opcodes): Added hypervisor instrcutions.
+
+2021-12-24  Vineet Gupta  <vineetg@rivosinc.com>
+
+	RISC-V: Hypervisor ext: drop Privileged Spec 1.9.1 implementation/tests
+	This makes way for a clean 1.12 based Hypervisor Ext support.
+
+	There are no known implementors of 1.9.1 H-ext. (Per Jim, kendryte k210
+	is based on priv spec 1.9.1, but it seems unlikely that they implemented
+	H-ext).
+
+	Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
+	Reviewed-by: Nelson Chu <nelson.chu@sifive.com>
+
+	gas/
+		* testsuite/gas/riscv/csr-dw-regnums.d: Drop the hypervisor csrs
+		defined in the privileged spec 1.9.1.
+		* testsuite/gas/riscv/csr-dw-regnums.s: Likewise.
+		* testsuite/gas/riscv/priv-reg-fail-read-only-01.s: Likewise.
+		* testsuite/gas/riscv/priv-reg-fail-version-1p10.l: Likewise.
+		* testsuite/gas/riscv/priv-reg-fail-version-1p11.l: Likewise.
+		* testsuite/gas/riscv/priv-reg-version-1p10.d: Likewise.
+		* testsuite/gas/riscv/priv-reg-version-1p11.d: Likewise.
+		* testsuite/gas/riscv/priv-reg-version-1p9p1.d: Likewise.
+		* testsuite/gas/riscv/priv-reg.s: Likewise.
+	include/
+		* opcode/riscv-opc.h: Drop the hypervisor csrs defined in the
+		privileged spec 1.9.1.
+
+2021-12-24  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-23  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: resolve some duplicate testnames in gdb.mi
+	Set of fixes to resolve some duplicate test names in the gdb.mi/
+	directory.  There should be no real test changes after this set of
+	fixes, they are all either:
+
+	  - Adding with_test_prefix type constructs to make test names unique,
+	    or
+
+	  - Changing the test name to be more descriptive, or better reflect
+	    the test being run.
+
+2021-12-23  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb/remote: handle attach when stop packet lacks thread-id
+	Bug PR gdb/28405 reports a regression when using attach with an
+	extended-remote target.  In this case the target is not including a
+	thread-id in the stop packet it sends back after the attach.
+
+	The regression was introduced with this commit:
+
+	  commit 8f66807b98f7634c43149ea62e454ea8f877691d
+	  Date:   Wed Jan 13 20:26:58 2021 -0500
+
+	      gdb: better handling of 'S' packets
+
+	The problem is that when GDB processes the stop packet, it sees that
+	there is no thread-id and so has to "guess" which thread the stop
+	should apply to.
+
+	In this case the target only has one thread, so really, there's no
+	guessing needed, but GDB still runs through the same process, this
+	shouldn't cause us any problems.
+
+	However, after the above commit, GDB now expects itself to be more
+	internally consistent, specifically, only a thread that GDB thinks is
+	resumed, can be a candidate for having stopped.
+
+	It turns out that, when GDB attaches to a process through an
+	extended-remote target, the threads of the process being attached too,
+	are not, initially, marked as resumed.
+
+	And so, when GDB tries to figure out which thread the stop might apply
+	too, it finds no threads in the processes marked resumed, and so an
+	assert triggers.
+
+	In extended_remote_target::attach we create a new thread with a call
+	to add_thread_silent, rather than remote_target::remote_add_thread,
+	the reason is that calling the latter will result in a call to
+	'add_thread' rather than 'add_thread_silent'.  However,
+	remote_target::remote_add_thread includes additional
+	actions (i.e. calling remote_thread_info::set_resumed and set_running)
+	which are missing from extended_remote_target::attach.  These missing
+	calls are what would serve to mark the new thread as resumed.
+
+	In this commit I propose that we add an extra parameter to
+	remote_target::remote_add_thread.  This new parameter will force the
+	new thread to be added with a call to add_thread_silent.  We can now
+	call remote_add_thread from the ::attach method, the extra
+	actions (listed above) will now be performed, and the thread will be
+	left in the correct state.
+
+	Additionally, in PR gdb/28405, a segfault is reported.  This segfault
+	triggers when 'set debug remote 1' is used before trying to reproduce
+	the original assertion failure.  The cause of this is in
+	remote_target::select_thread_for_ambiguous_stop_reply, where we do
+	this:
+
+	  remote_debug_printf ("first resumed thread is %s",
+			       pid_to_str (first_resumed_thread->ptid).c_str ());
+	  remote_debug_printf ("is this guess ambiguous? = %d", ambiguous);
+
+	  gdb_assert (first_resumed_thread != nullptr);
+
+	Notice that when debug printing is on we dereference
+	first_resumed_thread before we assert that the pointer is not
+	nullptr.  This is the cause of the segfault, and is resolved by moving
+	the assert before the debug printing code.
+
+	I've extended an existing test, ext-attach.exp, so that the original
+	test is run multiple times; we run in the original mode, as normal,
+	but also, we now run with different packets disabled in gdbserver.  In
+	particular, disabling Tthread would trigger the assertion as it was
+	reported in the original bug.  I also run the test in all-stop and
+	non-stop modes now for extra coverage, we also run the tests with
+	target-async enabled, and disabled.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28405
+
+2021-12-23  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: on x86-64 non-trivial C++ objects are returned in memory
+	Fixes PR gdb/28681.  It was observed that after using the `finish`
+	command an incorrect value was displayed in some cases.  Specifically,
+	this behaviour was observed on an x86-64 target.
+
+	Consider this test program:
+
+	  struct A
+	  {
+	    int i;
+
+	    A ()
+	    { this->i = 0; }
+	    A (const A& a)
+	    { this->i = a.i; }
+	  };
+
+	  A
+	  func (int i)
+	  {
+	    A a;
+	    a.i = i;
+	    return a;
+	  }
+
+	  int
+	  main ()
+	  {
+	    A a = func (3);
+	    return a.i;
+	  }
+
+	And this GDB session:
+
+	  $ gdb -q ex.x
+	  Reading symbols from ex.x...
+	  (gdb) b func
+	  Breakpoint 1 at 0x401115: file ex.cc, line 14.
+	  (gdb) r
+	  Starting program: /home/andrew/tmp/ex.x
+
+	  Breakpoint 1, func (i=3) at ex.cc:14
+	  14	  A a;
+	  (gdb) finish
+	  Run till exit from #0  func (i=3) at ex.cc:14
+	  main () at ex.cc:23
+	  23	  return a.i;
+	  Value returned is $1 = {
+	    i = -19044
+	  }
+	  (gdb) p a
+	  $2 = {
+	    i = 3
+	  }
+	  (gdb)
+
+	Notice how after the `finish` the contents of $1 are junk, but, when I
+	immediately ask for the value of `a`, I get back the correct value.
+
+	The problem here is that after the finish command GDB calls the
+	function amd64_return_value to figure out where the return value can
+	be found (on x86-64 targets anyway).
+
+	This function makes the wrong choice for the struct A in our case, as
+	sizeof(A) <= 8, then amd64_return_value decides that A will be
+	returned in a register.  GDB then reads the return value register an
+	interprets the contents as an instance of A.
+
+	Unfortunately, A is not trivially copyable (due to its copy
+	constructor), and the sys-v specification for argument and return
+	value passing, says that any non-trivial C++ object should have space
+	allocated for it by the caller, and the address of this space is
+	passed to the callee as a hidden first argument.  The callee should
+	then return the address of this space as the return value.
+
+	And so, the register that GDB is treating as containing an instance of
+	A, actually contains the address of an instance of A (in this case on
+	the stack), this is why GDB shows the incorrect result.
+
+	The call stack within GDB for where we actually go wrong is this:
+
+	  amd64_return_value
+	    amd64_classify
+	      amd64_classify_aggregate
+
+	And it is in amd64_classify_aggregate that we should be classifying
+	the type as AMD64_MEMORY, instead of as AMD64_INTEGER as we currently
+	do (via a call to amd64_classify_aggregate_field).
+
+	At the top of amd64_classify_aggregate we already have this logic:
+
+	  if (TYPE_LENGTH (type) > 16 || amd64_has_unaligned_fields (type))
+	    {
+	      theclass[0] = theclass[1] = AMD64_MEMORY;
+	      return;
+	    }
+
+	Which handles some easy cases where we know a struct will be placed
+	into memory, that is (a) the struct is more than 16-bytes in size,
+	or (b) the struct has any unaligned fields.
+
+	All we need then, is to add a check here to see if the struct is
+	trivially copyable.  If it is not then we know the struct will be
+	passed in memory.
+
+	I originally structured the code like this:
+
+	  if (TYPE_LENGTH (type) > 16
+	      || amd64_has_unaligned_fields (type)
+	      || !language_pass_by_reference (type).trivially_copyable)
+	    {
+	      theclass[0] = theclass[1] = AMD64_MEMORY;
+	      return;
+	    }
+
+	This solved the example from the bug, and my small example above.  So
+	then I started adding some more extensive tests to the GDB testsuite,
+	and I ran into a problem.  I hit this error:
+
+	  gdbtypes.h:676: internal-error: loc_bitpos: Assertion `m_loc_kind == FIELD_LOC_KIND_BITPOS' failed.
+
+	This problem is triggered from:
+
+	  amd64_classify_aggregate
+	    amd64_has_unaligned_fields
+	      field::loc_bitpos
+
+	Inside the unaligned field check we try to get the bit position of
+	each field.  Unfortunately, in some cases the field location is not
+	FIELD_LOC_KIND_BITPOS, but is FIELD_LOC_KIND_DWARF_BLOCK.
+
+	An example that shows this bug is:
+
+	  struct B
+	  {
+	    short j;
+	  };
+
+	  struct A : virtual public B
+	  {
+	    short i;
+
+	    A ()
+	    { this->i = 0; }
+	    A (const A& a)
+	    { this->i = a.i; }
+	  };
+
+	  A
+	  func (int i)
+	  {
+	    A a;
+	    a.i = i;
+	    return a;
+	  }
+
+	  int
+	  main ()
+	  {
+	    A a = func (3);
+	    return a.i;
+	  }
+
+	It is the virtual base class, B, that causes the problem.  The base
+	class is represented, within GDB, as a field within A.  However, the
+	location type for this field is a DWARF_BLOCK.
+
+	I spent a little time trying to figure out how to convert the
+	DWARF_BLOCK to a BITPOS, however, I realised that, in this case at
+	least, conversion is not needed.
+
+	The C++ standard says that a class is not trivially copyable if it has
+	any virtual base classes.  And so, in this case, even if I could
+	figure out the BITPOS for the virtual base class fields, I know for
+	sure that I would immediately fail the trivially_copyable check.  So,
+	lets just reorder the checks in amd64_classify_aggregate to:
+
+	  if (TYPE_LENGTH (type) > 16
+	      || !language_pass_by_reference (type).trivially_copyable
+	      || amd64_has_unaligned_fields (type))
+	    {
+	      theclass[0] = theclass[1] = AMD64_MEMORY;
+	      return;
+	    }
+
+	Now, if we have a class with virtual bases we will fail quicker, and
+	avoid the unaligned fields check completely.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28681
+
+2021-12-23  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: make use of SCOPE_EXIT to manage thread executing state
+	While working on another patch relating to how GDB manages threads
+	executing and resumed state, I spotted the following code in
+	record-btrace.c:
+
+	  executing = tp->executing ();
+	  set_executing (proc_target, inferior_ptid, false);
+
+	  id = null_frame_id;
+	  try
+	    {
+	      id = get_frame_id (get_current_frame ());
+	    }
+	  catch (const gdb_exception &except)
+	    {
+	      /* Restore the previous execution state.  */
+	      set_executing (proc_target, inferior_ptid, executing);
+
+	      throw;
+	    }
+
+	  /* Restore the previous execution state.  */
+	  set_executing (proc_target, inferior_ptid, executing);
+
+	  return id;
+
+	I notice that we only catch the exception so we can call
+	set_executing, and this is the same call to set_executing that we need
+	to perform in the non-exception return path.
+
+	This would be much cleaner if we could use SCOPE_EXIT to avoid the
+	try/catch, so lets do that.
+
+	While cleaning this up, I also applied a similar patch to
+	record-full.c, though there's no try/catch in that case, but using
+	SCOPE_EXIT makes the code safe if, in the future, we do start throwing
+	exceptions.
+
+	There should be no user visible changes after this commit.
+
+2021-12-23  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-22  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/doc: add some index entries relating to mi-async setting
+	I noticed that the mi-async setting was not referenced from the index
+	in any way, this commit tries to rectify that a bit.
+
+	The @cindex lines I think are not controversial, these same index
+	entries are used elsewhere in the manual for async related topics (see
+	@node Background Execution).
+
+	The only bit that might be controversial is that I've added a @kindex
+	entry for 'set mi-async' when the command is documented as '-gdb-set
+	mi-async' (with a similar difference for the show/-gdb-show).
+
+	My reasoning here is that nothing else is indexed under -gdb-set or
+	-gdb-show, and as -gdb-set/-gdb-show are just the MI equivalent for
+	set/show anything that is documented under set/show can be adjusted
+	using -gdb-set/-gdbshow, and so, I've tried to keep the index
+	consistent for mi-async.
+
+2021-12-22  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: convert 'set debug lin-lwp' to a boolean command
+	Convert the 'set debug lin-lwp' command to a boolean.  Adds a new
+	LINUX_NAT_SCOPED_DEBUG_ENTER_EXIT macro, and makes use of it in one
+	place (linux_nat_target::stop).
+
+	The manual entry for 'set debug lin-lwp' is already vague about
+	exactly what arguments this command takes, and the description talks
+	about turning debug on and off, so I don't think there's any updates
+	required there.
+
+	I have updated the doc strings shown when the users enters 'help show
+	debug lin-lwp' or 'help show debug lin-lwp'.  The old title lines used
+	to talk about the 'GNU/Linux lwp module', but this debug flag is now
+	used for any native linux target debug, so we now talk about
+	'GNU/Linux native target'.  The body string for this setting has been
+	changed from 'Enables printf debugging output.' to 'When on, print
+	debug messages relating to the GNU/Linux native target.', the old
+	value looks like a cut&paste error to me.
+
+2021-12-22  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: add threads debugging switch
+	Add new commands:
+
+	  set debug threads on|off
+	  show debug threads
+
+	Prints additional debug information relating to thread creation and
+	deletion.
+
+	GDB already announces when threads are created of course.... most of
+	the time, but sometimes threads are added silently, in which case this
+	debug message is the only mechanism to see the thread being added.
+	Also, though GDB does announce when a thread exits, it doesn't
+	announce when the thread object is deleted, I've added a debug message
+	for that.
+
+	Additionally, having message printed through the debug system will
+	cause the messages to be nested to an appropriate depth when other
+	debug sub-systems are turned on (especially things like `infrun` and
+	`lin-lwp`).
+
+2021-12-22  jiawei  <jiawei@iscas.ac.cn>
+
+	RISC-V: Update Scalar Crypto testcases.
+	Add opcodes in testcases to make sure every instruction generate
+	right opcode after disassemble.
+
+	gas/ChangeLog:
+
+	        * testsuite/gas/riscv/k-ext-64.d: Add opcode detect.
+	        * testsuite/gas/riscv/k-ext.d: Ditto.
+	        * testsuite/gas/riscv/zbkb-32.d: Ditto.
+	        * testsuite/gas/riscv/zbkb-64.d: Ditto.
+	        * testsuite/gas/riscv/zbkc-32.d: Ditto.
+	        * testsuite/gas/riscv/zbkc-64.d: Ditto.
+	        * testsuite/gas/riscv/zbkx-32.d: Ditto.
+	        * testsuite/gas/riscv/zbkx-64.d: Ditto.
+	        * testsuite/gas/riscv/zknd-32.d: Ditto.
+	        * testsuite/gas/riscv/zknd-64.d: Ditto.
+	        * testsuite/gas/riscv/zkne-32.d: Ditto.
+	        * testsuite/gas/riscv/zkne-64.d: Ditto.
+	        * testsuite/gas/riscv/zknh-32.d: Ditto.
+	        * testsuite/gas/riscv/zknh-64.d: Ditto.
+	        * testsuite/gas/riscv/zksed-32.d: Ditto.
+	        * testsuite/gas/riscv/zksed-64.d: Ditto.
+	        * testsuite/gas/riscv/zksh-32.d: Ditto.
+	        * testsuite/gas/riscv/zksh-64.d: Ditto.
+
+2021-12-22  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdbarch-components.py: change empty "params" tuples to empty lists
+	During review, it was suggested to change the "params" parameter from a
+	tuple to a list, for esthetic reasons.  The empty ones are still tuples
+	though, they should probably be changed to be empty lists, for
+	consistency.  It does not change anything in the script result.
+
+	Change-Id: If13c6c527aa167a5ee5b45740e5f1bda1e9517e4
+
+2021-12-22  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-21  Luis Machado  <luis.machado@linaro.org>
+
+	[AArch64] Fix typo in error messages
+	Fix mispelling of PROT_ME to PROT_MTE in the error messages.
+
+2021-12-21  Joel Sherrill  <joel@rtems.org>
+
+	Obsolete m32c-rtems and m32r-rtems
+	2020-12-20  Joel Sherrill <joel@rtems.org>
+
+	bfd/
+		* config.bfd (m32c-*-rtems*): Remove target.
+
+	ld/
+		* configure.tgt (m32c-*-rtems*): Remove target.
+		* configure.tgt (m32r-*-rtems*): Remove target.
+
+2021-12-21  Jan Beulich  <jbeulich@suse.com>
+
+	x86: -mfence-as-lock-add=yes doesn't work for 16-bit mode
+	Rather than trying to fix this (which would require making an assumption
+	on the upper half of %esp being zero), simply issue an error. While at
+	it, since the generated code is in conflict with -momit-lock-prefix=yes,
+	issue an error in that case as well.
+
+	gas/ELF: avoid below-base ref in obj_elf_parse_section_letters()
+	We would better be prepared for 'm' being the first character of the
+	incoming string.
+
+2021-12-21  Alan Modra  <amodra@gmail.com>
+
+	Typo fixes in binutils doc
+		* doc/binutils.texi: Fix typos.
+
+2021-12-21  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-20  Tom Tromey  <tom@tromey.com>
+
+	Remove print_spaces
+	This removes the print_spaces helper function, in favor of using the
+	"*%s" idiom that's already used in many places in gdb.  One spot (in
+	symmisc.c) is changed to use print_spaces_filtered, because the rest
+	of that function is using filtered output.  (This highlights one way
+	that the printf idiom is better -- this error is harder to make when
+	using that.)
+
+	Regression tested on x86-64 Fedora 34.
+
+2021-12-20  Tom Tromey  <tom@tromey.com>
+
+	Remove puts_debug
+	I noticed that puts_debug isn't used in the tree.  git log tells me
+	that the last use was removed in 2015:
+
+	    commit 40e0b27177e747600d3ec186458fe0e482a1cf77
+	    Author: Pedro Alves <palves@redhat.com>
+	    Date:   Mon Aug 24 15:40:26 2015 +0100
+
+		Delete the remaining ROM monitor targets
+
+	... and this commit mentions that the code being removed here probably
+	hadn't worked for 6 years prior to that.
+
+	Based on this, I'm removing puts_debug.  I don't think it's useful.
+	Tested by rebuilding.
+
+2021-12-20  Tom Tromey  <tom@tromey.com>
+
+	Make n_spaces return a const char *
+	n_spaces keeps the spaces in a static buffer.  If a caller overwrites
+	these, it may give an incorrect result to a subsequent caller.  So,
+	make the return type const to help avoid this outcome.
+
+2021-12-20  Enze Li  <lienze2010@hotmail.com>
+
+	Add Enze Li to gdb/MAINTAINERS
+
+2021-12-20  Joel Brobecker  <brobecker@adacore.com>
+
+	gdb/ada-exp.y: Reformat comment to follow GDB's coding standards
+	This commit reformats a comment in gdb/ada-exp.y to avoid
+	the leading '*' at the beginning of each line of the comment.
+
+	gdb/ada-lang.h: Reformat comment to follow coding standards
+	This commit reformats a comment in gdb/ada-lang.h to avoid
+	the leading '*' at the beginning of each line of the comment.
+
+2021-12-20  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-19  Alan Modra  <amodra@gmail.com>
+
+	Obsolete m32c-rtems
+
+	readelf: avoid a possible divide by zero
+		* readelf.c (process_section_headers): Check SHT_RELR entsize.
+
+2021-12-19  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-18  Enze Li  <lienze2010@hotmail.com>
+
+	gdb: add "exit" command as an alias for "quit"
+	This command adds the "exit" command as an alias for the "quit"
+	command, as requested in PR gdb/28406.
+
+	The documentation is also updated to mention this new command.
+
+	Tested on x86_64-linux.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28406
+
+2021-12-18  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: add assert in remote_target::wait relating to async being off
+	While working on another patch I ended up in a situation where I had
+	async mode disabled (with 'maint set target-async off'), but the async
+	event token got marked anyway.
+
+	In this situation GDB was continually calling into
+	remote_target::wait, however, the async token would never become
+	unmarked as the unmarking is guarded by target_is_async_p.
+
+	We could just unconditionally unmark the token, but that would feel
+	like just ignoring a bug, so, instead, lets assert that if
+	!target_is_async_p, then the async token should not be marked.
+
+	This assertion would have caught my earlier mistake.
+
+	There should be no user visible changes with this commit.
+
+2021-12-18  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/remote: some fixes for 'maint set target-async off'
+	While working on another patch relating to remote targets, I wanted to
+	test with 'maint set target-async off' in place.  Unfortunately I ran
+	into some problems.  This commit is an attempt to fix one of the
+	issues I hit.
+
+	In my particular case I was actually running with:
+
+	  maint set target-async off
+	  maint set target-non-stop off
+
+	that is, we're telling GDB to force the targets to operate in
+	non-async mode, and in all-stop mode.  Here's my GDB session showing
+	the problem:
+
+	  (gdb) maintenance set target-async off
+	  (gdb) maintenance set target-non-stop off
+	  (gdb) target extended-remote :54321
+	  Remote debugging using :54321
+	  (gdb) attach 2365960
+	  Attaching to process 2365960
+	  No unwaited-for children left.
+	  (gdb)
+
+	Notice the 'No unwaited-for children left.' error, this is the
+	problem.  There's no reason why GDB should not be able to attach to
+	the process.
+
+	The problem is this:
+
+	  1. The user runs 'attach PID' and this sends GDB into attach_command
+	  in infcmd.c.  From here we call the ::attach method on the attach
+	  target, which will be the extended_remote_target.
+
+	  2. In extended_remote_target::attach, we attach to the remote target
+	  and get the first reply (which is a stop packet).  We put off
+	  processing the stop packet until the end of ::attach.  We setup the
+	  inferior and thread to represent the process we attached to, and
+	  download the target description.  Finally, we process the initial
+	  stop packet.
+
+	  If '!target_is_non_stop_p ()' and '!target_can_async_p ()', which is
+	  the case for us given the maintenance commands we used, we cache the
+	  stop packet within the remote_state::buf for later processing.
+
+	  3. Back in attach_command, if 'target_is_non_stop_p ()' then we
+	  request that the target stops.  This will either process any cached
+	  stop replies, or request that the target stops, and process the stop
+	  replies.  However, this code is not what we use due to non-stop mode
+	  being disabled.  So, we skip to the next step which is to call
+	  validate_exec_file.
+
+	  4. Calling validate_exec_file can cause packets to be sent to the
+	  remote target, and replies received, the first path I hit is the
+	  call to target_pid_to_exec_file, which calls
+	  remote_target::pid_to_exec_file, which can then try to read the
+	  executable from the remote.  Sending an receiving packets will make
+	  use of the remote_state::buf object.
+
+	  5. The attempt to attach continues, but the damage is already done...
+
+	So, the problem is that, in step #2 we cache a stop reply in the
+	remote_state::buf, and then in step #4 we reuse the remote_state::buf
+	object, discarding any cached stop reply.  As a result, the initial
+	stop, which is sent when GDB first attaches to the target, is lost.
+
+	This problem can clearly be seen, I feel, by looking at the
+	remote_state::cached_wait_status flag.  This flag tells GDB if there
+	is a wait status cached in remote_state::buf.  However, in
+	remote_target::putpkt_binary and remote_target::getpkt_or_notif_sane_1
+	this flag is just set back to 0, doing this immediately discards any
+	cached data.
+
+	I don't know if this scheme ever made sense,  looking at commit
+	2d717e4f8a54, where the cached_wait_status flag was added, it appears
+	that there was nothing between where the stop was cached, and where
+	the stop was consumed, so, I suspect, there never was a situation
+	where we ended up in putpkt_binary or getpkt_or_notif_sane_1 and
+	needed to clear to the flag, maybe the clearing was added "just in
+	case".  Whatever the history, I claim that this clearing this flag is
+	no longer a good idea.
+
+	So, my first step toward fixing this issue was to replace the two
+	instances of 'rs->cached_wait_status = 0;' in ::putpkt_binary and
+	::getpkt_or_notif_sane_1 with 'gdb_assert (rs->cached_wait_status ==
+	0);', this, at least would show me when GDB was doing something
+	dangerous, and indeed, this assert is now hit in my test case above.
+
+	I did play with using some kind of scoped restore to backup, and
+	restore the remote_state::buf object in all the places within remote.c
+	that I was hitting where the ::buf was being corrupted.  The first
+	problem with this is that, where the ::cached_wait_status flag is
+	reset is _not_ where ::buf is corrupted.  For the ::putpkt_binary
+	case, by the time we get to the method the buffer has already been
+	corrupted in many cases, so we end up needing to add the scoped
+	save/restore within the callers, which means we need the save/restore
+	in _lots_ of places.
+
+	Plus, using this save/restore model feels like the wrong solution.  I
+	don't think that it's obvious that the buffer might be holding cached
+	data, and I think it would be too easy for new corruptions of the
+	buffer to be introduced, which could easily go unnoticed for a long
+	time.
+
+	So, I really wanted a solution that didn't require us to cache data in
+	the ::buf object.
+
+	Luckily, I think we already have such a solution in place, the
+	remote_state::stop_reply_queue, it seems like this does exactly the
+	same task, just in a slightly different way.  With the
+	::stop_reply_queue, the stop packets are processed upon receipt and
+	the stop_reply object is added to the queue.  With the ::buf cache
+	solution, the unprocessed stop reply is cached in the ::buf, and
+	processed later.
+
+	So, finally, in this commit, I propose to remove the
+	remote_state::cached_wait_status flag and to stop using the ::buf to
+	cache stop replies.  Instead, stop replies will now always be stored
+	in the ::stop_reply_queue.
+
+	There are two places where we use the ::buf to hold a cached stop
+	reply, the first is in the ::attach method, and the second is in
+	remote_target::start_remote, however, the second of these cases is far
+	less problematic, as after caching the stop reply in ::buf we call the
+	global start_remote function, which does very little work before
+	calling normal_stop, which processes the cached stop reply.  However,
+	my plan is to switch both users over to using ::stop_reply_queue so
+	that the old (unsafe) ::cached_wait_status mechanism can be completely
+	removed.
+
+	The next problem is that the ::stop_reply_queue is currently only used
+	for async-mode, and so, in remote_target::push_stop_reply, where we
+	push stop_reply objects into the ::stop_reply_queue, we currently also
+	mark the async event token.  I've modified this so we only mark the
+	async event token if 'target_is_async_p ()' - note, _is_, not _can_
+	here. The ::push_stop_reply method is called in places where async
+	mode has been temporarily disabled, but, when async mode is switched
+	back on (see remote_target::async) we will mark the event token if
+	there are events in the queue.
+
+	Another change of interest is in remote_target::remote_interrupt_as.
+	Previously this code checked ::cached_wait_status, but didn't check
+	for events in the ::stop_reply_queue.  Now that ::cached_wait_status
+	has been removed we now check the queue length instead, which should
+	have the same result.
+
+	Finally, in remote_target::wait_as, I've tried to merge the processing
+	of the ::stop_reply_queue with how we used to handle the
+	::cached_wait_status flag.
+
+	Currently, when processing the ::stop_reply_queue we call
+	process_stop_reply and immediately return.  However, when handling
+	::cached_wait_status we run through the whole of ::wait_as, and return
+	at the end of the function.
+
+	If we consider a standard stop packet, the two differences I see are:
+
+	  1. Resetting of the remote_state::waiting_for_stop_reply, flag; this
+	  is not currently done when processing a stop from the
+	  ::stop_reply_queue.
+
+	  2. The final return value has the possibility of being adjusted at
+	  the end of ::wait_as, as well as there being calls to
+	  record_currthread, non of which are done if we process a stop from
+	  the ::stop_reply_queue.
+
+	After discussion on the mailing list:
+
+	  https://sourceware.org/pipermail/gdb-patches/2021-December/184535.html
+
+	it was suggested that, when an event is pushed into the
+	::stop_reply_queue, the ::waiting_for_stop_reply flag is never going
+	to be set.  As a result, we don't need to worry about the first
+	difference.  I have however, added a gdb_assert to validate the
+	assumption that the flag is never going to be set.  If in future the
+	situation ever changes, then we should find out pretty quickly.
+
+	As for the second difference, I have resolved this by having all stop
+	packets taken from the ::stop_reply_queue, pass through the return
+	value adjustment code at the end of ::wait_as.
+
+	An example of a test that reveals the benefits of this commit is:
+
+	  make check-gdb \
+	    RUNTESTFLAGS="--target_board=native-extended-gdbserver \
+	                  GDBFLAGS='-ex maint\ set\ target-async\ off \
+	                            -ex maint\ set\ target-non-stop\ off' \
+	                  gdb.base/attach.exp"
+
+	For testing I've been running test on x86-64/GNU Linux, and run with
+	target boards unix, native-gdbserver, and native-extended-gdbserver.
+	For each board I've run with the default GDBFLAGS, as well as with:
+
+	  GDBFLAGS='-ex maint\ set\ target-async\ off \
+	            -ex maint\ set\ target-non-stop\ off' \
+
+	Though running with the above GDBFLAGS is clearly a lot more unstable
+	both before and after my patch, I'm not seeing any consistent new
+	failures with my patch, except, with the native-extended-gdbserver
+	board, where I am seeing new failures, but only because more tests are
+	now running.  For that configuration alone I see the number of
+	unresolved go down by 49, the number of passes goes up by 446, and the
+	number of failures also increases by 144.  All of the failures are new
+	tests as far as I can tell.
+
+2021-12-18  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>
+
+	x86: Terminate mnemonicendp in swap_operand()
+	Tested on x86_64-pc-linux-gnu.
+
+	opcodes/ChangeLog:
+	2021-12-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+		* i386-dis.c (swap_operand): Terminate mnemonicendp.
+
+	gas/ChangeLog:
+	2021-12-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
+
+		* testsuite/gas/i386/opts-intel.d: Updated expected disassembly.
+		* testsuite/gas/i386/opts.d: Likewise.
+		* testsuite/gas/i386/sse2avx-opts-intel.d: Likewise.
+		* testsuite/gas/i386/sse2avx-opts.d: Likewise.
+		* testsuite/gas/i386/x86-64-opts-intel.d: Likewise.
+		* testsuite/gas/i386/x86-64-opts.d: Likewise.
+		* testsuite/gas/i386/x86-64-sse2avx-opts-intel.d: Likewise.
+		* testsuite/gas/i386/x86-64-sse2avx-opts.d: Likewise.
+
+2021-12-18  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-17  Tom Tromey  <tom@tromey.com>
+
+	Document gdbarch-components.py
+	This adds a comment to document how to update gdbarch.
+
+	Remove gdbarch.sh
+	This patch runs gdbarch.py and removes gdbarch.sh.
+
+2021-12-17  Simon Marchi  <simon.marchi@efficios.com>
+
+	Add new gdbarch generator
+	The new gdbarch generator is a Python program.  It reads the
+	"components.py" that was created in the previous patch, and generates
+	gdbarch.c and gdbarch-gen.h.
+
+	This is a relatively straightforward translation of the existing .sh
+	code.  It doesn't try very hard to be idiomatic Python or to be
+	especially smart.
+
+	It is, however, incredibly faster:
+
+	    $ time ./gdbarch.sh
+
+	    real	0m8.197s
+	    user	0m5.779s
+	    sys	0m3.384s
+
+	    $ time ./gdbarch.py
+
+	    real	0m0.065s
+	    user	0m0.053s
+	    sys	0m0.011s
+
+	Co-Authored-By: Tom Tromey <tom@tromey.com>
+
+2021-12-17  Tom Tromey  <tom@tromey.com>
+
+	Generate new gdbarch-components.py from gdbarch.sh
+	The new gdbarch.sh approach will be to edit a Python file, rather than
+	adding a line to a certain part of gdbarch.sh.  We use the existing sh
+	code, though, to generate the first draft of this .py file.
+
+	Documentation on the format will come in a subsequent patch.
+
+	Note that some info (like "staticdefault") in the current code is
+	actually unused, and so is ignored by this new generator.
+
+2021-12-17  Tom Tromey  <tom@tromey.com>
+
+	Do not sort the fields in gdbarch_dump
+	This changes gdbarch.sh so that it no longer sorts the fields in
+	gdbarch_dump.  This sorting isn't done anywhere else by gdbarch.sh,
+	and this simplifies the new generator a little bit.
+
+	Do not generate gdbarch.h
+	Now that gdbarch.h has been split, we no longer need the generator
+	code in gdbarch.sh, so remove it.
+
+2021-12-17  Tom Tromey  <tom@tromey.com>
+
+	Split gdbarch.h into two files
+	This patch splits gdbarch.h into two files -- gdbarch.h now is
+	editable and hand-maintained, and the new gdbarch-gen.h file is the
+	only thing generated by gdbarch.sh.  This lets us avoid maintaining
+	boilerplate in the gdbarch.sh file.
+
+	Note that gdbarch.sh still generates gdbarch.h after this patch.  This
+	makes it easier to re-run when rebasing.  This code is removed in a
+	subsequent patch.
+
+2021-12-17  Tom Tromey  <tom@tromey.com>
+
+	Move ordinary gdbarch code to arch-utils
+	While I think it makes sense to generate gdbarch.c, at the same time I
+	think it is better for ordinary code to be editable in a C file -- not
+	as a hunk of C code embedded in the generator.
+
+	This patch moves this sort of code out of gdbarch.sh and gdbarch.c and
+	into arch-utils.c, then has arch-utils.c include gdbarch.c.
+
+2021-12-17  Maciej W. Rozycki  <macro@embecosm.com>
+
+	Avoid redundant operations in `fortran_array_walker'
+	Move inner dimension's element type determination outside the respective
+	loops in `fortran_array_walker'.  The operation is exactly the same with
+	each iteration, so there is no point in redoing it for each element and
+	while a smart compiler might be able to move it outside the loop it is
+	regardless a bad coding style.  No functional change.
+
+	Initialize `m_ndimensions' in the member initializer list
+	Following our coding convention initialize the `m_ndimensions' member in
+	the member initializer list rather than in the body of the constructor
+	of the `fortran_array_walker' class.  No functional change.
+
+2021-12-17  Lancelot SIX  <lancelot.six@amd.com>
+	    Pedro Alves  <pedro@palves.net>
+
+	gdb/tui: install SIGWINCH only when connected to a TTY
+	PR26056 reports that when GDB is connected to non-TTY stdin/stdout, it
+	crashes when it receives a SIGWINCH signal.
+
+	This can be reproduced as follows:
+
+	    $ gdb/gdb -nx -batch -ex 'run' --args sleep 60 </dev/null 2>&1 | cat
+
+	    # from another terminal:
+	    $ kill -WINCH %(pidof gdb)
+
+	When doing so, the process crashes in a call to rl_resize_terminal:
+
+	    void
+	    rl_resize_terminal (void)
+	    {
+	      _rl_get_screen_size (fileno (rl_instream), 1);
+	      ...
+	    }
+
+	The problem is that at this point rl_instream has the value NULL.
+
+	The rl_instream variable is supposed to be initialized during a call to
+	readline_initialize_everything, which in a normal startup sequence is
+	called under this call chain:
+
+	    tui_interp::init
+	      tui_ensure_readline_initialized
+	        rl_initialize
+	          readline_initialize_everything
+
+	In tui_interp::init, we have the following sequence:
+
+	    tui_initialize_io ();
+	    tui_initialize_win ();                // <- Installs SIGWINCH
+	    if (gdb_stdout->isatty ())
+	      tui_ensure_readline_initialized (); // <- Initializes rl_instream
+
+	This function unconditionally installs the SIGWINCH signal handler (this
+	is done by tui_initialize_win), and then if gdb_stdout is a TTY it
+	initializes readline.  Therefore, if stdout is not a TTY, SIGWINCH is
+	installed but readline is not initialized.  In such situation
+	rl_instream stays NULL, and when GDB receives a SIGWINCH it calls its
+	handler and in fine tries to access rl_instream leading to the crash.
+
+	This patch proposes to fix this issue by installing the SIGWINCH signal
+	handler only if GDB is connected to a TTY.  Given that this
+	initialization it the only task of tui_initialize_win, this patch moves
+	tui_initialize_win just after the call to
+	tui_ensure_readline_initialized.
+
+	Tested on x86_64-linux.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26056
+	Change-Id: I6458acef7b0d9beda2a10715d0345f02361076d9
+
+2021-12-17  Alan Modra  <amodra@gmail.com>
+
+	asan: NULL dereference in bfd_elf_set_group_contents
+		* elf-bfd.h (struct output_elf_obj_tdata): Make num_section_syms
+		unsigned.
+		* elf.c (bfd_elf_set_group_contents): Bounds check sec->index
+		and check that entry in elf_section_syms for sec is non-NULL.
+		(_bfd_elf_symbol_from_bfd_symbol): Adjust.
+
+2021-12-17  Alan Modra  <amodra@gmail.com>
+
+	asan: use after free in _bfd_elf_mips_get_relocated_section_contents
+	Leaving entries on mips_hi16_list from a previous pass over relocs
+	leads to confusing bugs.
+
+		* elfxx-mips.c (_bfd_elf_mips_get_relocated_section_contents):
+		Free mips_hi16_list entries on error exit.
+
+2021-12-17  Alan Modra  <amodra@gmail.com>
+
+	asan: abort in wasm_scan_name_function_section
+	Macros like READ_LEB128 in wasm-module.c that alter control flow are
+	evil.  Maintainers will break your code if you have hidden ways to
+	reach labels.
+
+		* wasm-module.c (wasm_scan_name_function_section): Don't
+		attempt to bfd_release NULL.
+
+2021-12-17  Alan Modra  <amodra@gmail.com>
+
+	asan: heap-buffer-overflow in bpf_elf_generic_reloc
+	The bpf reloc howtos are a bit weird, using bitpos to specify an
+	offset from r_offset that is outside the size of the reloc as given by
+	howto.size.  That means bfd_get_reloc_size gives the wrong answer for
+	range checking, and thus bfd_reloc_offset_in_range can't be used.
+
+		* elf64-bpf.c (bpf_elf_generic_reloc): Handle bitpos offset reloc
+		range checking.
+
+2021-12-17  Alan Modra  <amodra@gmail.com>
+
+	ubsan: bfd.c:2519:8: shift exponent 34 is too large
+		* bfd.c (bfd_update_compression_header): Avoid integer overflow.
+
+	asan: buffer overflow in mmo_get_symbols
+		* mmo.c (mmo_get_symbols): Error on symbol name exceeding max length.
+
+2021-12-17  Alan Modra  <amodra@gmail.com>
+
+	asan: buffer overflow in elfnn-aarch64.c get_plt_type
+	We can't assume .dynamic is a multiple of ElfNN_External_Dyn, at least
+	not when presented with fuzzed object files.
+
+		* elfnn-aarch64.c (get_plt_type): Don't access past end of
+		improperly sized .dynamic.
+
+2021-12-17  Alan Modra  <amodra@gmail.com>
+
+	try_build_id_prefix gcc-10 -Wformat-security errors
+	dwarf.c:11300:3: error: format not a string literal and no format arguments [-Werror=format-security]
+	11300 |   f += sprintf (f, prefix);
+
+		PR 28697
+		* dwarf.c (try_build_id_prefix): Avoid -Wformat-security error.
+
+2021-12-17  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-16  Nick Clifton  <nickc@redhat.com>
+
+	Fix AVR assembler so that it creates relocs that will work with linker relaxation.
+		PR 28686
+	gas	* config/tc-avr.h (tc_fix_adjustable): Define.
+		* config/tc-avr.c (avr_fix_adjustable): New function.
+		* testsuite/gas/all/gas.exp: Skip tests that need adjustable fixups.
+		* testsuite/gas/elf/elf.exp: Likewise.
+		* testsuite/gas/avr/diffreloc_withrelax.d: Adjust expected output.
+		* testsuite/gas/avr/pc-relative-reloc.d: Adjust expected output.
+
+	ld	* testsuite/ld-avr/avr-prop-7.d: Adjust expected output.
+		* testsuite/ld-avr/avr-prop-8.d: Likewise.
+		* testsuite/ld-avr/pr13402.d: Likewise.
+
+2021-12-16  Nick Clifton  <nickc@redhat.com>
+
+	When loading separate debug info files, also attempt to locate a file based upon the build-id.
+		PR 28697
+		* dwarf.c (load_build_id_debug_file): New function.
+		(try_build_id_prefix): New function.
+		(check_for_and_load_links): Call load_build_id_debug_file.
+		(debug_displays): Add entry for .note.gnu.build-id.
+		* dwarf.h (enum dwarf_section_display_enum): Add
+		note_gnu_build_id.
+		* testsuite/binutils-all/debuginfod.exp (test_fetch_debuglink):
+		Fix regexp for loads via debuglink section.
+
+2021-12-16  Richard Sandiford  <richard.sandiford@arm.com>
+
+	arm: Add support for Armv9.1-A to Armv9.3-A
+	This patch adds AArch32 support for -march=armv9.[123]-a.
+	The behaviour of the new options can be expressed using a
+	combination of existing feature flags and tables.
+
+	The cpu_arch_ver entries for ARM_ARCH_V9_2A and ARM_ARCH_V9_3A
+	are technically redundant but it seemed less surprising to include
+	them anyway.
+
+	include/
+		* opcode/arm.h (ARM_ARCH_V9_1A, ARM_ARCH_V9_2A): New macros.
+		(ARM_ARCH_V9_3A): Likewise.
+
+	gas/
+		* doc/c-arm.texi: Add armv9.1-a, armv9.2-a and armv9.3-a.
+		* config/tc-arm.c (armv91a_ext_table, armv92a_ext_table): New macros.
+		(armv93a_ext_table): Likewise.
+		(arm_archs): Add armv9.1-a, armv9.2-a and armv9.3-a.
+		(cpu_arch_ver): Add ARM_ARCH_V9_1A, ARM_ARCH_V9_2A and ARM_ARCH_V9_3A.
+		* NEWS: Mention the above.
+		* testsuite/gas/arm/attr-march-armv9_1-a.d: New test.
+		* testsuite/gas/arm/attr-march-armv9_2-a.d: Likewise.
+		* testsuite/gas/arm/attr-march-armv9_3-a.d: Likewise.
+		* testsuite/gas/arm/bfloat16-armv9.1-a.d: Likewise.
+		* testsuite/gas/arm/bfloat16-armv9.2-a.d: Likewise.
+		* testsuite/gas/arm/bfloat16-armv9.3-a.d: Likewise.
+		* testsuite/gas/arm/i8mm-armv9.1-a.d: Likewise.
+		* testsuite/gas/arm/i8mm-armv9.2-a.d: Likewise.
+		* testsuite/gas/arm/i8mm-armv9.3-a.d: Likewise.
+
+2021-12-16  Richard Sandiford  <richard.sandiford@arm.com>
+
+	arm: Add support for Armv8.7-A and Armv8.8-A
+	This patch adds AArch32 support for -march=armv8.[78]-a.
+	The behaviour of the new options can be expressed using a
+	combination of existing feature flags and tables.
+
+	The cpu_arch_ver entries are technically redundant but
+	it seemed less surprising to include them anyway.
+
+	include/
+		* opcode/arm.h (ARM_ARCH_V8_7A, ARM_ARCH_V8_8A): New macros.
+
+	gas/
+		* doc/c-arm.texi: Add armv8.7-a and armv8.8-a.
+		* config/tc-arm.c (armv87a_ext_table, armv88a_ext_table): New macros.
+		(arm_archs): Add armv8.7-a and armv8.8-a.
+		(cpu_arch_ver): Add ARM_ARCH_V8_7A and ARM_ARCH_V8_8A.
+		* NEWS: Mention the above.
+		* testsuite/gas/arm/attr-march-armv8_7-a.d: New test.
+		* testsuite/gas/arm/attr-march-armv8_8-a.d: Likewise.
+		* testsuite/gas/arm/bfloat16-armv8.7-a.d: Likewise.
+		* testsuite/gas/arm/bfloat16-armv8.8-a.d: Likewise.
+		* testsuite/gas/arm/i8mm-armv8.7-a.d: Likewise.
+		* testsuite/gas/arm/i8mm-armv8.8-a.d: Likewise.
+
+2021-12-16  Richard Sandiford  <richard.sandiford@arm.com>
+
+	aarch64: Add support for Armv9.1-A to Armv9.3-A
+	This patch adds AArch64 support for -march=armv9.[123]-a.
+	The behaviour of the new options can be expressed using a
+	combination of existing feature flags, so we don't need to
+	eat into the vanishing number of spare AARCH64_FEATURE_* bits.
+	Hoewver, it was more convenient to separate out the |s of
+	feature flags so that Armv9.1-A could reuse the set for
+	Armv8.6-A, and so on.
+
+	include/
+		* opcode/aarch64.h (AARCH64_ARCH_V8_FEATURES): New macro,
+		split out from...
+		(AARCH64_ARCH_V8): ...here.
+		(AARCH64_ARCH_V8_1_FEATURES): New macro, split out from...
+		(AARCH64_ARCH_V8_1): ...here.
+		(AARCH64_ARCH_V8_2_FEATURES): New macro, split out from...
+		(AARCH64_ARCH_V8_2): ...here.
+		(AARCH64_ARCH_V8_3_FEATURES): New macro, split out from...
+		(AARCH64_ARCH_V8_3): ...here.
+		(AARCH64_ARCH_V8_4_FEATURES): New macro, split out from...
+		(AARCH64_ARCH_V8_4): ...here.
+		(AARCH64_ARCH_V8_5_FEATURES): New macro, split out from...
+		(AARCH64_ARCH_V8_5): ...here.
+		(AARCH64_ARCH_V8_6_FEATURES): New macro, split out from...
+		(AARCH64_ARCH_V8_6): ...here.
+		(AARCH64_ARCH_V8_7_FEATURES): New macro, split out from...
+		(AARCH64_ARCH_V8_7): ...here.
+		(AARCH64_ARCH_V8_8_FEATURES): New macro, split out from...
+		(AARCH64_ARCH_V8_8): ...here.
+		(AARCH64_ARCH_V9_FEATURES): New macro, split out from...
+		(AARCH64_ARCH_V9): ...here.
+		(AARCH64_ARCH_V9_1_FEATURES, AARCH64_ARCH_V9_1): New macros.
+		(AARCH64_ARCH_V9_2_FEATURES, AARCH64_ARCH_V9_2): New macros.
+		(AARCH64_ARCH_V9_3_FEATURES, AARCH64_ARCH_V9_3): New macros.
+
+	gas/
+		* doc/c-aarch64.texi: Add armv9.1-a, armv9-2-a and armv9.3-a.
+		* config/tc-aarch64.c (aarch64_archs): Likewise.
+		* NEWS: Mention the above.
+		* testsuite/gas/aarch64/armv9_invalid.d,
+		testsuite/gas/aarch64/armv9_invalid.s,
+		testsuite/gas/aarch64/armv9_invalid.l: New test.
+		* testsuite/gas/aarch64/armv9_1.d,
+		testsuite/gas/aarch64/armv9_1.s: Likewise.
+		* testsuite/gas/aarch64/armv9_1_invalid.d,
+		testsuite/gas/aarch64/armv9_1_invalid.s,
+		testsuite/gas/aarch64/armv9_1_invalid.l: Likewise.
+		* testsuite/gas/aarch64/armv9_2.d,
+		testsuite/gas/aarch64/armv9_2.s: Likewise.
+		* testsuite/gas/aarch64/armv9_2_invalid.d,
+		testsuite/gas/aarch64/armv9_2_invalid.s,
+		testsuite/gas/aarch64/armv9_2_invalid.l: Likewise.
+		* testsuite/gas/aarch64/armv9_3.d,
+		testsuite/gas/aarch64/armv9_3.s: Likewise.
+
+2021-12-16  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: Support svinval extension with frozen version 1.0.
+	According to the privileged spec, there are five new instructions for
+	svinval extension.  Two of them (HINVAL.VVMA and HINVAL.GVMA) need to
+	enable the hypervisor extension.  But there is no implementation of
+	hypervisor extension in mainline for now, so let's consider the related
+	issues later.
+
+	                31..25  24..20 19..15 14..12 11...7 6..2  1..0
+	sinval.vma      0001011 rs2    rs1    000    00000  11100 11
+	sfence.w.inval  0001100 00000  00000  000    00000  11100 11
+	sfence.inval.ir 0001100 00001  00000  000    00000  11100 11
+	hinval.vvma     0010011 rs2    rs1    000    00000  11100 11
+	hinval.gvma     0110011 rs2    rs1    000    00000  11100 11
+
+	This patch is cherry-picked from the riscv integration branch since the
+	svinval extension is frozen for now.  Besides, we fix the funct7 encodings
+	of hinval.vvma and hinval.gvma, from 0x0011011 and 0x0111011 to 0x0010011
+	and 0x0110011.
+
+	bfd/
+		* elfxx-riscv.c (riscv_supported_std_s_ext): Added svinval.
+		(riscv_multi_subset_supports): Handle INSN_CLASS_SVINVAL.
+	gas/
+		* testsuite/gas/riscv/svinval.d: New testcase.
+		* testsuite/gas/riscv/svinval.s: Likewise.
+	include/
+		* opcode/riscv-opc.h: Added encodings for svinval.
+		* opcode/riscv.h (enum riscv_insn_class): Added INSN_CLASS_SVINVAL.
+	opcodes/
+		* riscv-opc.c (riscv_opcodes): Added svinval instructions.
+
+2021-12-16  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: mips/or1k: drop redundant arg to bitsize macro
+	These are just using the default behavior for the 3rd arg, so drop
+	it to make it more clear.  This also makes them match all other
+	ports that only use the first 2 arguments.
+
+2021-12-16  Mike Frysinger  <vapier@gentoo.org>
+
+	bfd: unify texi generation rules
+	The logic between these rules are extremely similar, so unify them
+	into a single variable by leveraging make $@ and $< variables.
+
+	Also add automake silent rule support while we're here.
+
+2021-12-16  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: fix mingw builds with replacement gnulib open
+	The header shuffling in here broke the workaround for gnulib defining
+	"open".  Move it back before the sim-specific includes to fix.  This
+	is because the callback struct in the headers has an "open" member and
+	this file tries to call that.
+
+2021-12-16  Sandra Loosemore  <sandra@codesourcery.com>
+
+	Adjust compare_link_order for unstable qsort
+	In a cross toolchain for nios2-elf target and x86_64-w64-mingw32 host
+	using binutils 2.37, we observed a failure that didn't show up on
+	x86_64-linux-gnu host:  testcase pr25490-5.s was failing with
+
+	C:\path\to\nios2-elf-ld.exe: looping in map_segments
+	FAIL: __patchable_function_entries section 5
+
+	    	* ldelfgen.c (compare_link_order): Don't use section id in
+		sorting.  Keep original ordering instead.  Update comments.
+
+2021-12-16  Alan Modra  <amodra@gmail.com>
+
+	Re: Fix an undefined behaviour in the BFD library's DWARF parser
+	Using an unsigned int cast (to 32 bits) on a pointer difference (of
+	possibly 64 bits) is wrong.  Even though it will work on all real
+	object files, the fuzzers will eventually find this hole.
+
+		PR 28687
+		* dwarf1.c (parse_die): Cast pointer difference to size_t.
+		Catch another possible pointer overflow.
+
+2021-12-16  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: re-format with black 21.12b0
+	Run black 21.12b0 on gdb/, there is a single whitespace change.  I will
+	update the wiki [1] in parallel to bump the version of black to 21.12b0.
+
+	[1] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards
+
+	Change-Id: Ib3b859e3506c74a4f15d16f1e44ef402de3b98e2
+
+2021-12-16  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: re-format with black 21.9b0
+	Run black 21.9b0 on gdb/ (this is the version currently mentioned on the
+	wiki [1], the subsequent commit will bump that version).
+
+	[1] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards
+
+	Change-Id: I5ceaab42c42428e053e2572df172aa42a88f0f86
+
+2021-12-16  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-15  Alan Modra  <amodra@gmail.com>
+
+	PR28691, validate dwarf attribute form
+	PR28691 is a fuzzing PR that triggers a non-problem of "output changes
+	per run" with PIEs and/or different compilers.  I've closed similar
+	PRs before as wontfix, but I guess there will be no end of this type
+	of PR.  The trigger is an attribute that usually takes one of the
+	offset/constant reference DW_FORMs being given an indexed string
+	DW_FORM.  The bfd reader doesn't support indexed strings and returns
+	an error string instead.  The address of the string varies with PIE
+	runs and/or compiler, and we allow that address to appear in output.
+	Fix this by validating integer attribute forms, as we do for string
+	form attributes.
+
+		PR 28691
+		* dwarf2.c (is_str_attr): Rename to..
+		(is_str_form): ..this.  Change param type.  Update calls.
+		(is_int_form): New function.
+		(read_attribute_value): Handle DW_FORM_addrx2.
+		(find_abstract_instance): Validate form when using attr.u.val.
+		(scan_unit_for_symbols, parse_comp_unit): Likewise.
+
+2021-12-15  Luis Machado  <luis.machado@linaro.org>
+
+	New --enable-threading configure option to control use of threads in GDB/GDBserver
+	Add the --enable-threading configure option so multithreading can be disabled
+	at configure time. This is useful for statically-linked builds of
+	GDB/GDBserver, since the thread library doesn't play well with that setup.
+
+	If you try to run a statically-linked GDB built with threading, it will crash
+	when setting up the number of worker threads.
+
+	This new option is also convenient when debugging GDB in a system with lots of
+	threads, where the thread discovery code in GDB will emit too many messages,
+	like so:
+
+	[New Thread 0xfffff74d3a50 (LWP 2625599)]
+
+	If you have X threads, that message will be repeated X times.
+
+	The default for --enable-threading is "yes".
+
+2021-12-15  Nikita Popov  <npv1310@gmail.com>
+
+	Fix an undefined behaviour in the BFD library's DWARF parser.
+		PR 28687
+		* dwarf1.c (parse_die): Fix undefined behaviour in range tests.
+
+2021-12-15  Alan Modra  <amodra@gmail.com>
+
+	PR28694, Out-of-bounds write in stab_xcoff_builtin_type
+		PR 28694
+		* stabs.c (stab_xcoff_builtin_type): Make typenum unsigned.
+		Negate typenum earlier, simplifying bounds checking.  Correct
+		off-by-one indexing.  Adjust switch cases.
+
+2021-12-15  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-14  Alan Modra  <amodra@gmail.com>
+
+	loongarch32 build failure on 32-bit host
+	gas/config/tc-loongarch.c: In function ‘assember_macro_helper’:
+	gas/config/tc-loongarch.c:915:28: error: right shift count >= width of type [-Werror=shift-count-overflow]
+	  915 |       hi32 = insn->args[1] >> 32;
+	      |                            ^~
+
+	One possible fix is to make offsetT a 64-bit type for loongarch32.
+	This also makes bfd/targmatch.h (generated from bfd/config.bfd)
+	consistent since the loongarch32 match is inside #ifdef BFD64.
+
+		* config.bfd (loongarch32-*): Set want64.
+
+2021-12-14  Alan Modra  <amodra@gmail.com>
+
+	loongarch64 build failure on 32-bit host
+	gas/config/tc-loongarch.c: In function ‘loongarch_args_parser_can_match_arg_helper’:
+	gas/config/tc-loongarch.c:661:13: error: cast from pointer to integer of different size [-Werror=pointer
+	-to-int-cast]
+	  661 |       imm = (offsetT) str_hash_find (r_htab, arg);
+	      |             ^
+
+	Cast it to the correct size int, relying on normal integer promotions
+	if offsetT is larger than a pointer.
+
+		* config/tc-loongarch.c (loongarch_args_parser_can_match_arg_helper):
+		Cast return from str_hash_find to intptr_t, not offsetT.
+
+2021-12-14  Alan Modra  <amodra@gmail.com>
+
+	XCOFF C_STSYM test failure on 32-bit host
+	This test was failing here and on another similar symbol:
+	[  4](sec  1)(fl 0x00)(ty   0)(scl 143) (nx 0) 0x05d1745d11745d21 .bs
+	where correct output is
+	[  4](sec  1)(fl 0x00)(ty   0)(scl 143) (nx 0) 0x000000000000000a .bs
+
+	The problem is caused by a 32-bit host pointer being sign-extended
+	when stored into a 64-bit bfd_vma, and then that value not being
+	trimmed back to 32 bits when used.  The following belt-and-braces
+	patch fixes both the store and subsequent reads.
+
+		* coffcode.h (coff_slurp_symbol_table): Do not sign extend
+		when storing a host pointer to syment.n_value.
+		* coffgen.c (coff_get_symbol_info): Cast syment.n_value to a
+		bfd_hostptr_t before using in arithmetic.
+		(coff_print_symbol): Likewise.
+
+2021-12-14  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdbserver/tracepoint.cc: use snprintf in gdb_agent_socket_init
+	If we modify tracepoint.cc to try to use a too long unix socket name,
+	for example by modifying SOCK_DIR to be:
+
+	    #define SOCK_DIR "/tmp/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut"
+
+	... trying to start an application with libinproctrace.so loaded
+	crashes:
+
+	    $ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.6:./libinproctrace.so /bin/ls
+	    /home/smarchi/src/binutils-gdb/gdbserver/../gdbsupport/common-utils.cc:69: A problem internal to GDBserver in-process agent has been detected.
+	    xsnprintf: Assertion `ret < size' failed.
+
+	Looking at the rest of the socket initialization code, the intent seems
+	to be that if something goes wrong, we warn but let the program
+	execute.  So crashing on this failed assertions seems against the intent.
+
+	Commit 6cebaf6e1ae4 ("use xsnprintf instead of snprintf.") changed this
+	code to use xsnprintf instead of snprintf, introducing this assertion.
+	Before that, snprintf would return a value bigger that UNIX_PATH_MAX and
+	the "if" after would catch it and emit a warning, which is exactly what
+	we want.  That change was done because LynxOS didn't have snprintf.
+	Since LynxOS isn't supported anymore, we can simply revert to use
+	snprintf there.
+
+	With this patch, we get a warning (printed by the caller of
+	gdb_agent_socket_init), but the program keeps executing:
+
+	    $ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.6:./libinproctrace.so /bin/ls
+	    ipa: could not create sync socket
+	    ...
+
+	Change-Id: I78bca52d5dc3145335abeae45a42052701e3f5dd
+
+2021-12-14  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdbserver/tracepoint.cc: work around -Wstringop-truncation error
+	When building gdb with  on AArch64 with g++ 11.1.0 (and some preceding
+	versions too), -O2 and -fsanitize=address, I get this error.
+
+	      CXX    tracepoint-ipa.o
+	    cc1plus: warning: command-line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++
+	    In file included from /usr/include/string.h:519,
+	                     from ../gnulib/import/string.h:41,
+	                     from /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/common-defs.h:95,
+	                     from /home/simark/src/binutils-gdb/gdbserver/server.h:22,
+	                     from /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc:19:
+	    In function ‘char* strncpy(char*, const char*, size_t)’,
+	        inlined from ‘int init_named_socket(const char*)’ at /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc:6902:11,
+	        inlined from ‘int gdb_agent_socket_init()’ at /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc:6953:26,
+	        inlined from ‘void* gdb_agent_helper_thread(void*)’ at /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc:7204:41:
+	    /usr/include/bits/string_fortified.h:95:34: error: ‘char* __builtin_strncpy(char*, const char*, long unsigned int)’ output may be truncated copying 107 bytes from a string of length 107 [-Werror=stringop-truncation]
+	       95 |   return __builtin___strncpy_chk (__dest, __src, __len,
+	          |          ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
+	       96 |                                   __glibc_objsize (__dest));
+	          |                                   ~~~~~~~~~~~~~~~~~~~~~~~~~
+
+	Note that _FORTIFY_SOURCE changes the message a bit, but I get a similar
+	error if I use -D_FORTIFY_SOURCE=0.
+
+	I am pretty sure it's spurious and might be related to this GCC bug:
+
+	  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88780
+
+	From what I can see, we are copying from a static 108 bytes long buffer
+	(the global array agent_socket_name) to a 108 bytes long array,
+	sockaddr_un::sun_path.  I don't see anything wrong.
+
+	Still, it would make things easier if we didn't see this error.  Change
+	the code to check that the source string length is smaller than the
+	destination buffer (including space for the NULL byte) and use strcpy.
+
+	For anybody who would like to try to reproduce, the full command line
+	is:
+
+	    g++     -I. -I/home/simark/src/binutils-gdb/gdbserver -I/home/simark/src/binutils-gdb/gdbserver/../gdb/regformats -I/home/simark/src/binutils-gdb/gdbserver/.. -I/home/simark/src/binutils-gdb/gdbserver/../include -I/home/simark/src/binutils-gdb/gdbserver/../gdb -I/home/simark/src/binutils-gdb/gdbserver/../gnulib/import -I../gnulib/import -I/home/simark/src/binutils-gdb/gdbserver/.. -I..   -pthread -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-variable -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-error=maybe-uninitialized -Wno-mismatched-tags -Wsuggest-override -Wimplicit-fallthrough=3 -Wduplicated-cond -Wshadow=local -Wdeprecated-copy -Wdeprecated-copy-dtor -Wredundant-move -Wmissing-declarations -Wmissing-prototypes -Wstrict-null-sentinel -Wformat -Wformat-nonliteral -Werror -DGDBSERVER  -DCONFIG_UST_GDB_INTEGRATION -Drpl_strerror_r=strerror_r -Drpl_free=free -fPIC -DIN_PROCESS_AGENT -fvisibility=hidden -g3 -O2 -fsanitize=address   -c -o tracepoint-ipa.o -MT tracepoint-ipa.o -MMD -MP -MF ./.deps/tracepoint-ipa.Tpo /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc
+
+	Change-Id: I18e86c0487feead7e7677e69398405e7057cf464
+
+2021-12-14  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	bfd: fix -Wunused errors with clang 13+
+	Clang 13 and 14 produce some -Wunused-but-set-{variable,parameter} for
+	situations where gcc doesn't.  In particular, when a variable is set and
+	then used in a way to update its own value.  For example, if `i` is only
+	used in this way:
+
+	  int i = 2;
+	  i++;
+	  i = i + 1;
+
+	gcc won't warn, but clang will.
+
+	Fix all such errors found in an --enable-targets=all build.  It would be
+	important for somebody who knows what they're doing to just make sure
+	that these variables can indeed be deleted, and that there a no cases
+	where it's a bug, and the variable should actually be used.
+
+	The first instance of this error fix by this patch is:
+
+	      CC       elf32-score.lo
+	    /home/simark/src/binutils-gdb/bfd/elf32-score.c:450:11: error: variable 'relocation' set but not used [-Werror,-Wunused-but-set-variable]
+	      bfd_vma relocation;
+	              ^
+
+	Change-Id: I2f233ce20352645cf388aff3dfa08a651d21a6b6
+
+2021-12-14  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/mi: rename build_table to add_builtin_mi_commands
+	Just give the function build_table a more descriptive name.  There
+	should be no user visible changes after this commit.
+
+2021-12-14  Jan Vrany  <jan.vrany@labware.com>
+
+	gdb/mi: rename mi_cmd to mi_command
+	Just give this class a new name, more inline with the name of the
+	sub-classes.  I've also updated mi_cmd_up to mi_command_up in
+	mi-cmds.c inline with this new naming scheme.
+
+	There should be no user visible changes after this commit.
+
+2021-12-14  Jan Vrany  <jan.vrany@labware.com>
+
+	gdb/mi: use separate classes for different types of MI command
+	This commit changes the infrastructure in mi-cmds.{c,h} to add new
+	sub-classes for the different types of MI command.  Instances of these
+	sub-classes are then created and added into mi_cmd_table.
+
+	The existing mi_cmd class becomes the abstract base class, this has an
+	invoke method and takes care of the suppress notifications handling,
+	before calling a do_invoke virtual method which is implemented by all
+	of the sub-classes.
+
+	There's currently two different sub-classes, one of pure MI commands,
+	and a second for MI commands that delegate to CLI commands.
+
+	There should be no user visible changes after this commit.
+
+2021-12-14  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/mi: int to bool conversion in mi_execute_cli_command
+	Change an argument of mi_execute_cli_command from int to bool.  Update
+	the callers to take this into account.  Within mi_execute_cli_command,
+	update a comparison of a pointer to 0 with a comparison to nullptr,
+	and add an assert, if we are not using the argument string then the
+	string should be nullptr.  Also removed a cryptic 'gdb_????' comment,
+	which isn't really helpful.
+
+	There should be no user visible changes after this commit.
+
+2021-12-14  Jan Vrany  <jan.vrany@labware.com>
+
+	gdb/mi: use std::map for MI commands in mi-cmds.c
+	This changes the hashmap used in mi-cmds.c from a custom structure to
+	std::map.  Not only is replacing a custom container with a standard
+	one an improvement, but using std::map will make it easier to
+	dynamically add commands; which is something that is planned for a
+	later series, where we will allow MI commands to be implemented in
+	Python.
+
+	There should be no user visible changes after this commit.
+
+2021-12-14  Jan Vrany  <jan.vrany@labware.com>
+
+	gdb/mi: rename mi_lookup to mi_cmd_lookup
+	Lets give this function a more descriptive name.  I've also improved
+	the comments in the header and source files.
+
+	There should be no user visible changes after this commit.
+
+2021-12-14  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: Added ld testcases for the medlow and medany code models.
+	There are two linker scripts, code-model-01.ld and code-model-02.ld,
+	which are corresponding to the two different memory layouts,
+
+	* code-model-01.ld: the text section is in the 32-bit address range, but
+	  the data section is far away from the text section, which means the data
+	  section is over the 32-bit address range.
+
+	* code-model-02.ld: the text section is over the 32-bit address range, but
+	  the data section is placed nearly zero address.
+
+	We use the two linker scripts, to test the current medlow and medany behaviors
+	of GNU ld, including the weak symbol references and the relaxations behaviors.
+	Besides, these testcases also show the limits of the current medlow and medany
+	code models, that is - we may get the truncated to fit errors when linking
+	with the above two linker scripts.
+
+	ld/
+		* testsuite/ld-riscv-elf/code-model-01.ld: New testcases to test the
+		behaviors of the current medlow and medany code models.
+		* testsuite/ld-riscv-elf/code-model-02.ld: Likewise.
+		* testsuite/ld-riscv-elf/code-model-medany-01.d: Likewise.
+		* testsuite/ld-riscv-elf/code-model-medany-02.d: Likewise.
+		* testsuite/ld-riscv-elf/code-model-medany-weakref-01.d: Likewise.
+		* testsuite/ld-riscv-elf/code-model-medany-weakref-02.d: Likewise.
+		* testsuite/ld-riscv-elf/code-model-medlow-01.d: Likewise.
+		* testsuite/ld-riscv-elf/code-model-medlow-02.d: Likewise.
+		* testsuite/ld-riscv-elf/code-model-medlow-weakref-01.d: Likewise.
+		* testsuite/ld-riscv-elf/code-model-medlow-weakref-02.d: Likewise.
+		* testsuite/ld-riscv-elf/code-model-relax-medany-01.d: Likewise.
+		* testsuite/ld-riscv-elf/code-model-relax-medany-02.d: Likewise.
+		* testsuite/ld-riscv-elf/code-model-relax-medany-weakref-01.d: Likewise.
+		* testsuite/ld-riscv-elf/code-model-relax-medany-weakref-02.d: Likewise.
+		* testsuite/ld-riscv-elf/code-model-relax-medlow-01.d: Likewise.
+		* testsuite/ld-riscv-elf/code-model-relax-medlow-02.d: Likewise.
+		* testsuite/ld-riscv-elf/code-model-relax-medlow-weakref-01.d: Likewise.
+		* testsuite/ld-riscv-elf/code-model-relax-medlow-weakref-02.d: Likewise.
+		* testsuite/ld-riscv-elf/code-model.s: Likewise.
+		* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
+
+2021-12-14  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-13  H.J. Lu  <hjl.tools@gmail.com>
+
+	x86: Adjust linker tests for --disable-separate-code
+	Adjust linker tests for linker configured with --disable-separate-code:
+
+	1. Update expected outputs.
+	2. Pass -z max-page-size=0x1000 -z separate-code" to linker.
+
+		* testsuite/ld-i386/report-reloc-1.l: Updated.
+		* testsuite/ld-x86-64/report-reloc-1.l: Likewise.
+		* testsuite/ld-x86-64/pe-x86-64.exp: Pass
+		"-z max-page-size=0x1000 -z separate-code" to linker.
+		* testsuite/ld-x86-64/pr19609-4e.d: Likewise.
+		* testsuite/ld-x86-64/pr19609-6a.d: Likewise.
+		* testsuite/ld-x86-64/pr19609-6b.d: Likewise.
+		* testsuite/ld-x86-64/pr19609-7b.d: Likewise.
+		* testsuite/ld-x86-64/pr19609-7d.d: Likewise.
+
+2021-12-13  Carl Love  <cel@us.ibm.com>
+
+	gdb: Powerpc mark xfail in gdb.base/catch-syscall.exp
+	Powerpc is not reporting the
+
+	  Catchpoint 1 (returned from syscall execve),  ....
+
+	as expected.  The issue appears to be with the kernel not returning the
+	expected result.  This patch marks the test failure as an xfail.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28623
+
+2021-12-13  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: improve reuse of value contents when fetching array elements
+	While working on a Python script, which was interacting with a remote
+	target, I noticed some weird slowness in GDB.  In my program I had a
+	structure something like this:
+
+	  struct foo_t
+	  {
+	    int array[5];
+	  };
+
+	  struct foo_t global_foo;
+
+	Then in the Python script I was fetching a complete copy of global
+	foo, like:
+
+	  val = gdb.parse_and_eval('global_foo')
+	  val.fetch_lazy()
+
+	Then I would work with items in foo_t.array, like:
+
+	  print(val['array'][1])
+
+	I called the fetch_lazy method specifically because I knew I was going
+	to end up accessing almost all of the contents of val, and so I wanted
+	GDB to do a single remote protocol call to fetch all the contents in
+	one go, rather than trying to do lazy fetches for a couple of bytes at
+	a time.
+
+	What I observed was that, after the fetch_lazy call, GDB does,
+	correctly, fetch the entire contents of global_foo, including all of
+	the contents of array, however, when I access val.array[1], GDB still
+	goes and fetches the value of this element from the remote target.
+
+	What's going on is that in valarith.c, in value_subscript, for C like
+	languages, we always end up treating the array value as a pointer, and
+	then doing value_ptradd, and value_ind, the second of these calls
+	always returns a lazy value.
+
+	My guess is that this approach allows us to handle indexing off the
+	end of an array, when working with zero element arrays, or when
+	indexing a raw pointer as an array.  And, I agree, that in these
+	cases, where, even when the original value is non-lazy, we still will
+	not have the content of the array loaded, we should be using the
+	value_ind approach.
+
+	However, for cases where we do have the array contents loaded, and we
+	do know the bounds of the array, I think we should be using
+	value_subscripted_rvalue, which is what we use for non C like
+	languages.
+
+	One problem I did run into, exposed by gdb.base/charset.exp, was that
+	value_subscripted_rvalue stripped typedefs from the element type of
+	the array, which means the value returned will not have the same type
+	as an element of the array, but would be the raw, non-typedefed,
+	type.  In charset.exp we got back an 'int' instead of a
+	'wchar_t' (which is a typedef of 'int'), and this impacts how we print
+	the value.  Removing typedefs from the resulting value just seems
+	wrong, so I got rid of that, and I don't see any test regressions.
+
+	With this change in place, my original Python script is now doing no
+	additional memory accesses, and its performance increases about 10x!
+
+2021-12-13  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: update gdb-gdb.py.in for latest changes to struct field
+	This commit updates uses of 'loc' and 'loc_kind' to 'm_loc' and
+	'm_loc_kind' respectively, in gdb-gdb.py.in, which is required after
+	this commit:
+
+	  commit cd3f655cc7a55437a05aa8e7b1fcc9051b5fe404
+	  Date:   Thu Sep 30 22:38:29 2021 -0400
+
+	      gdb: add accessors for field (and call site) location
+
+	I have also incorporated this change:
+
+	  https://sourceware.org/pipermail/gdb-patches/2021-September/182171.html
+
+	Which means we print 'm_name' instead of 'name' when displaying the
+	'm_name' member variable.
+
+	Finally, I have also added support for the new TYPE_SPECIFIC_INT
+	fields, which were added with this commit:
+
+	  commit 20a5fcbd5b28cca88511ac5a9ad5e54251e8fa6d
+	  Date:   Wed Sep 23 09:39:24 2020 -0600
+
+	      Handle bit offset and bit size in base types
+
+	I updated the gdb.gdb/python-helper.exp test to cover all of these
+	changes.
+
+2021-12-13  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>
+
+	gdbserver/linux-low: replace direct assignment to current_thread
+	Use scoped_restore_current_thread and switch_to_thread in
+	linux_process_target::wait_for_sigstop.
+
+2021-12-13  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>
+
+	gdbserver: replace direct assignments to current_thread
+	Replace the direct assignments to current_thread with
+	switch_to_thread.  Use scoped_restore_current_thread when appropriate.
+	There is one instance remaining in linux-low.cc's wait_for_sigstop.
+	This will be handled in a separate patch.
+
+	Regression-tested on X86-64 Linux using the native-gdbserver and
+	native-extended-gdbserver board files.
+
+2021-12-13  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>
+
+	gdbserver: introduce scoped_restore_current_thread and switch_to_thread
+	Introduce a class for restoring the current thread and a function to
+	switch to the given thread.  This is a preparation for a refactoring
+	that aims to remove direct assignments to 'current_thread'.
+
+2021-12-13  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: make post_startup_inferior a virtual method on inf_ptrace_target
+	While working on a later patch that required me to understand how GDB
+	starts up inferiors, I was confused by the
+	target_ops::post_startup_inferior method.
+
+	The post_startup_inferior target function is only called from
+	inf_ptrace_target::create_inferior.
+
+	Part of the target class hierarchy looks like this:
+
+	  inf_child_target
+	     |
+	     '-- inf_ptrace_target
+	            |
+	            |-- linux_nat_target
+	            |
+	            |-- fbsd_nat_target
+	            |
+	            |-- nbsd_nat_target
+	            |
+	            |-- obsd_nat_target
+	            |
+	            '-- rs6000_nat_target
+
+	Every sub-class of inf_ptrace_target, except rs6000_nat_target,
+	implements ::post_startup_inferior.  The rs6000_nat_target picks up
+	the implementation of ::post_startup_inferior not from
+	inf_ptrace_target, but from inf_child_target.
+
+	No descendent of inf_child_target, outside the inf_ptrace_target
+	sub-tree, implements ::post_startup_inferior, which isn't really
+	surprising, as they would never see the method called (remember, the
+	method is only called from inf_ptrace_target::create_inferior).
+
+	What I find confusing is the role inf_child_target plays in
+	implementing, what is really a helper function for just one of its
+	descendents.
+
+	In this commit I propose that we formally make ::post_startup_inferior
+	a helper function of inf_ptrace_target.  To do this I will remove the
+	::post_startup_inferior from the target_ops API, and instead make this
+	a protected, pure virtual function on inf_ptrace_target.
+
+	I'll remove the empty implementation of ::post_startup_inferior from
+	the inf_child_target class, and add a new empty implementation to the
+	rs6000_nat_target class.
+
+	All the other descendents of inf_ptrace_target already provide an
+	implementation of this method and so don't need to change beyond
+	making the method protected within their class declarations.
+
+	To me, this makes much more sense now.  The helper function, which is
+	only called from within the inf_ptrace_target class, is now a part of
+	the inf_ptrace_target class.
+
+	The only way in which this change is visible to a user is if the user
+	turns on 'set debug target 1'.  With this debug flag on, prior to this
+	patch the user would see something like:
+
+	  -> native->post_startup_inferior (...)
+	  <- native->post_startup_inferior (2588939)
+
+	After this patch these lines are no longer present, as the
+	post_startup_inferior is no longer a top level target method.  For me,
+	this is an acceptable change.
+
+2021-12-13  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: have mips_nbsd_nat_target inherit from nbsd_nat_target
+	While working on another patch I had reason to look at
+	mips-netbsd-nat.c, and noticed that the class mips_nbsd_nat_target
+	inherits directly from inf_ptrace_target.
+
+	This is a little strange as alpha_bsd_nat_target,
+	arm_netbsd_nat_target, hppa_nbsd_nat_target, m68k_bsd_nat_target,
+	ppc_nbsd_nat_target, sh_nbsd_nat_target, and vax_bsd_nat_target all
+	inherit from nbsd_nat_target.
+
+	Originally, in this commit:
+
+	  commit f6ac5f3d63e03a81c4ff3749aba234961cc9090e
+	  Date:   Thu May 3 00:37:22 2018 +0100
+
+	      Convert struct target_ops to C++
+
+	When the target tree was converted to C++, all of the above classes
+	inherited from inf_ptrace_target except for hppa_nbsd_nat_target,
+	which was the only class that originally inherited from
+	nbsd_nat_target.
+
+	Later on all the remaining targets (except mips) were converted to
+	inherit from nbsd_nat_target, these are the commits:
+
+	  commit 4fed520be264b60893aa674071947890f8172915
+	  Date:   Sat Mar 14 16:05:24 2020 +0100
+
+	      Inherit alpha_netbsd_nat_target from nbsd_nat_target
+
+	  commit 6018d381a00515933016c539d2fdc18ad0d304b8
+	  Date:   Sat Mar 14 14:50:51 2020 +0100
+
+	      Inherit arm_netbsd_nat_target from nbsd_nat_target
+
+	  commit 01a801176ea15ddfc988cade2e3d84c3b0abfec3
+	  Date:   Sat Mar 14 16:54:42 2020 +0100
+
+	      Inherit m68k_bsd_nat_target from nbsd_nat_target
+
+	  commit 9faa006d11a5e08264a007463435f84b77864c9c
+	  Date:   Thu Mar 19 14:52:57 2020 +0100
+
+	      Inherit ppc_nbsd_nat_target from nbsd_nat_target
+
+	  commit 9809762324491b851332ce600ae9bde8dd34f601
+	  Date:   Tue Mar 17 15:07:39 2020 +0100
+
+	      Inherit sh_nbsd_nat_target from nbsd_nat_target
+
+	  commit d5be5fa4207da00d039a1d5a040ba316e7092cbd
+	  Date:   Sat Mar 14 13:21:58 2020 +0100
+
+	      Inherit vax_bsd_nat_target from nbsd_nat_target
+
+	I could only find mailing list threads for ppc and sh in the archive ,
+	and unfortunately, none of the commits has any real detail that might
+	explain why mips was missed out, the only extra context I could find
+	was this message:
+
+	  https://sourceware.org/pipermail/gdb-patches/2020-March/166853.html
+
+	Which says that "proper" OS support is going to be added to
+	nbsd_nat_target, hence the need to inherit from that class.
+
+	My guess is that leaving mips_nbsd_nat_target unchanged was an
+	oversight, so, in this commit, I propose changing mips_nbsd_nat_target
+	to inherit from nbsd_nat_target just like all the other nbsd targets.
+
+	My motivation for this patch relates to the post_startup_inferior
+	target method.  In a future commit I want to change how this method is
+	handled.  Currently the mips_nbsd_nat_target will pick up the empty
+	implementation of inf_child_target::post_startup_inferior rather than
+	the version in netbsd-nat.c.  This feels like a bug to me, as surely,
+	enabling of proc events is something that would need to be done for
+	all netbsd targets, regardless of architecture.
+
+	In my future patch I have a choice then, either (a) add a new, empty
+	implementation of post_startup_inferior to mips_nbsd_nat_target,
+	or (b) this commit, have mips_nbsd_nat_target inherit from
+	nbsd_nat_target.  Option (b) seems like the right way to go, hence,
+	this commit.
+
+	I've done absolutely no testing for this change, not even building it,
+	as that would require at least an environment in which I can x-build
+	mips-netbsd applications, which I have no idea how to set up.
+
+2021-12-13  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: only include mips and riscv targets if building with 64-bit bfd
+	While testing another patch I was trying to build different
+	configurations of GDB, and, during one test build I ran into a
+	problem, I configured with `--enable-targets=all
+	--host=i686-w64-mingw32` and saw this error while linking GDB:
+
+	  .../i686-w64-mingw32/bin/ld: mips-tdep.o: in function `mips_gdbarch_init':
+	  .../src/gdb/mips-tdep.c:8730: undefined reference to `disassembler_options_mips'
+	  .../i686-w64-mingw32/bin/ld: riscv-tdep.o: in function `riscv_gdbarch_init':
+	  .../src/gdb/riscv-tdep.c:3851: undefined reference to `disassembler_options_riscv'
+
+	So the `disassembler_options_mips` and `disassembler_options_riscv`
+	symbols are missing.
+
+	This turns out to be because mips-dis.c and riscv-dis.c, in which
+	these symbols are defined, are in the TARGET64_LIBOPCODES_CFILES list
+	in opcodes/Makefile.am, these files are only built when we are
+	building with a 64-bit bfd.
+
+	If we look further, into bfd/Makefile.am, we can see that all the
+	files matching elf*-riscv.lo are in the BFD64_BACKENDS list, as are
+	the elf*-mips.lo files, and (I know because I tried), the two
+	disassemblers do, not surprisingly, depend on features supplied from
+	libbfd.
+
+	So, though we can build most of GDB just fine for riscv and mips with
+	a 32-bit bfd, if I understand correctly, the final GDB
+	executable (assuming we could get it to link) would not understand
+	these architectures at the bfd level, nor would there be any
+	disassembler available.  This sounds like a pretty useless GDB to me.
+
+	So, in this commit, I move the riscv and mips targets into GDB's list
+	of targets that require a 64-bit bfd.  After this I can build GDB just
+	fine with the configure options given above.
+
+	This was discussed on the mailing list in a couple of threads:
+
+	  https://sourceware.org/pipermail/gdb-patches/2021-December/184365.html
+	  https://sourceware.org/pipermail/binutils/2021-November/118498.html
+
+	and it is agreed, that it is unfortunate that the 32-bit riscv and
+	32-bit mips targets require a 64-bit bfd.  If in the future this
+	situation ever changes then it would be expected that some (or all) of
+	this patch would be reverted.  Until then though, this patch allows
+	GDB to build when configured with --enable-targets=all, and when using
+	a 32-bit libbfd.
+
+2021-12-13  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-12  Tom Tromey  <tom@tromey.com>
+
+	C++-ify path substitution code
+	I found some uses of xfree in the path substitution code in source.c.
+	C++-ifying struct substitute_path_rule both simplifies the code and
+	removes manual memory management.
+
+	Regression tested on x86-64 Fedora 34.
+
+2021-12-12  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-11  Alan Modra  <amodra@gmail.com>
+
+	[GOLD] PowerPC64 @notoc in non-power10 code
+	Gold version of commit 7aba54da42.
+
+	elfcpp/
+		* powerpc.h (R_PPC64_REL24_P9NOTOC): Define.
+	gold/
+		* powerpc.cc (Target_powerpc::maybe_skip_tls_get_addr_call,
+		is_branch_reloc, max_branch_delta): Handle R_PPC64_REL24_P9NOTOC.
+		(Target_powerpc::Branch_info::make_stub): Likewise.
+		(struct Plt_stub_ent): Add p9notoc_, p9off_, tsize_.
+		(struct Branch_stub_ent): Add p9notoc_, p9off_.
+		(Stub_table::add_plt_call_entry): Handle R_PPC64_REL24_P9NOTOC.
+		(Stub_table::add_long_branch_entry): Likewise.
+		(Stub_table::add_eh_frame): Likewise.
+		(Stub_table::plt_call_size): Return aligned size.  Adjust callers.
+		Handle p9notoc_ sizing.
+		(Stub_table::do_write): Write out p9notoc_ stubs.
+		(Target_powerpc::Scan::get_reference_flags, local, global):
+		Handle R_PPC64_REL24_P9NOTOC.
+		(Target_powerpc::Relocate::relocate): Likewise.
+
+2021-12-11  H.J. Lu  <hjl.tools@gmail.com>
+
+	Don't return the main file as the separate debug info
+	On Fedora 35,
+
+	$ readelf -d /usr/bin/npc
+
+	caused readelf to run out of stack since load_separate_debug_info
+	returned the input main file as the separate debug info:
+
+	(gdb) bt
+	 #0  load_separate_debug_info (
+	    main_filename=main_filename@entry=0x510f50 "/export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo",
+	    xlink=xlink@entry=0x4e5180 <debug_displays+4480>,
+	    parse_func=parse_func@entry=0x431550 <parse_gnu_debuglink>,
+	    check_func=check_func@entry=0x432ae0 <check_gnu_debuglink>,
+	    func_data=func_data@entry=0x7fffffffdb60, file=file@entry=0x51d430)
+	    at /export/gnu/import/git/sources/binutils-gdb/binutils/dwarf.c:11057
+	 #1  0x000000000043328d in check_for_and_load_links (file=0x51d430,
+	    filename=0x510f50 "/export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo")
+	    at /export/gnu/import/git/sources/binutils-gdb/binutils/dwarf.c:11381
+	 #2  0x00000000004332ae in check_for_and_load_links (file=0x51b070,
+	    filename=0x518dd0 "/export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo")
+
+	Return NULL if the separate debug info is the same as the input main
+	file to avoid infinite recursion.
+
+		PR binutils/28679
+		* dwarf.c (load_separate_debug_info): Don't return the input
+		main file.
+
+2021-12-11  Alan Modra  <amodra@gmail.com>
+
+	Don't edit bogus sh_link on reading relocatable objects (Oracle fix)
+	This reverts a 1995 fix to handle bogus object files.  Presumably such
+	object files have long gone.
+
+		* elf.c (bfd_section_from_shdr): Remove old hack for Oracle
+		libraries.
+
+2021-12-11  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-10  Jan Vrany  <jan.vrany@labware.com>
+
+	gdb/testsuite: respect GDBSERVER variable in remote-stdio-gdbserver "board"
+	The comment on top of gdb/testsuite/boards/remote-stdio-gdbserver.exp says
+	that user can specify path to gdbserver on remote system by setting
+	GDBSERVER variable. However, this variable was ignored and /usr/bin/gdbserver
+	was used unconditionally.
+
+	This commit updates the code to respect GDBSERVER if set and fall back to
+	/usr/bin/gdbserver if not.
+
+2021-12-10  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	Revert "gdbsupport: remove unnecessary `#ifndef IN_PROCESS_AGENT`"
+	This reverts commit fe72c32765e1190c8a17d309fc3a7e1882d6a430.
+
+	It turns out it was wrong, libinproctrace.so does build its own
+	gdbsupport/tdesc.cc.  This broke the build:
+
+	    make[1]: Entering directory '/home/simark/build/binutils-gdb-one-target/gdbserver'
+	      CXXLD  libinproctrace.so
+	    /usr/bin/ld: gdbsupport/tdesc-ipa.o: in function `print_xml_feature::visit_pre(target_desc const*)':
+	    /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/tdesc.cc:407: undefined reference to `tdesc_architecture_name(target_desc const*)'
+	    /usr/bin/ld: /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/tdesc.cc:408: undefined reference to `tdesc_architecture_name(target_desc const*)'
+	    /usr/bin/ld: /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/tdesc.cc:411: undefined reference to `tdesc_osabi_name(target_desc const*)'
+	    /usr/bin/ld: /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/tdesc.cc:416: undefined reference to `tdesc_compatible_info_list(target_desc const*)'
+	    /usr/bin/ld: /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/tdesc.cc:418: undefined reference to `tdesc_compatible_info_arch_name(std::unique_ptr<tdesc_compatible_info, std::default_delete<tdesc_compatible_info> > const&)'
+
+2021-12-10  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-09  Alan Modra  <amodra@gmail.com>
+
+	PR28674, objdump crash
+	Not returning an error indication here leaves the attribute
+	uninitialised, which then leads to intemperate behaviour.
+
+		PR 28674
+		* dwarf2.c (read_attribute_value): Return NULL on trying to read
+		past end of attributes.
+
+2021-12-09  Alan Modra  <amodra@gmail.com>
+
+	Set sh_link for reloc sections created as normal sections
+	binutils-all/strip-13 and binutils-all/strip-14 tests create
+	SHT_REL/SHT_RELA sections by hand.  These don't have sh_link set to
+	the .symtab section as they should, leading to readelf warnings if you
+	happen to be looking at the object files.
+
+		* elf.c (assign_section_numbers): Formatting.  Set sh_link for
+		reloc sections created as normal sections in relocatable
+		objects.
+
+2021-12-09  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdbsupport: remove unnecessary `#ifndef IN_PROCESS_AGENT`
+	I suppose this code was copied from GDBserver and this ifndef was left
+	there.  As far as I know, IN_PROCESS_AGENT will never be defined when
+	building this file, so we can remove this.
+
+	Change-Id: I84fc408e330b3a29106df830a09342861cadbaf6
+
+2021-12-09  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/microblaze-tdep.c: fix -Wunused-but-set-variable
+	Fix this, seen when building with clang 14:
+
+	      CXX    microblaze-tdep.o
+	    /home/simark/src/binutils-gdb/gdb/microblaze-tdep.c:207:7: error: variable 'flags' set but not used [-Werror,-Wunused-but-set-variable]
+	      int flags = 0;
+	          ^
+
+	Change-Id: I59f726ed33e924912748bc475b6fd9a9394fc0d0
+
+2021-12-09  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/csky-tdep.c: fix -Wunused-but-set-variable error
+	Fix these, seen when building with clang 14:
+
+	      CXX    csky-tdep.o
+	    /home/simark/src/binutils-gdb/gdb/csky-tdep.c:332:7: error: variable 'need_dummy_stack' set but not used [-Werror,-Wunused-but-set-variable]
+	      int need_dummy_stack = 0;
+	          ^
+	    /home/simark/src/binutils-gdb/gdb/csky-tdep.c:805:12: error: variable 'offset' set but not used [-Werror,-Wunused-but-set-variable]
+	                  int offset = 0;
+	                      ^
+
+	Change-Id: I6703bcb50e83c50083f716f4084ef6aa30d659c4
+
+2021-12-09  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/testsuite: fix default behavior of runto
+	The documented behavior of proc runto is to not emit a PASS when
+	succeeding to to run to the specified location, but emit a FAIL when
+	failing to do so.  I suppose the intent is that it won't pollute the
+	results normally passing tests (although I don't see why we would care),
+	but make visible any problems.
+
+	However, it seems like the implementation makes it default to never
+	print anything.  "no-message" is prependend to "args", so if "message"
+	is not passed, we will always take the   path that sets print_fail to 0,
+	which will silence any failure.
+
+	This unfortunately means that tests relying on runto_main won't emit a
+	FAIL if failing to run to main.  And since commit 4dfef5be6812
+	("gdb/testsuite: make runto_main not pass no-message to runto"), tests
+	don't emit a FAIL themselves when failing to run to main.  This means
+	that tests failing to run to main just fail silently, and that's bad.
+
+	This can be reproduced by hacking gdb.base/template.exp like so:
+
+	    diff --git a/gdb/testsuite/gdb.base/template.c b/gdb/testsuite/gdb.base/template.c
+	    index bcf39c377d92..052be5b79d73 100644
+	    --- a/gdb/testsuite/gdb.base/template.c
+	    +++ b/gdb/testsuite/gdb.base/template.c
+	    @@ -15,6 +15,14 @@
+	        You should have received a copy of the GNU General Public License
+	        along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
+
+	    +#include <stdlib.h>
+	    +
+	    +__attribute__((constructor))
+	    +static void c (void)
+	    +{
+	    +  exit (1);
+	    +}
+	    +
+	     int
+	     main (void)
+	     {
+
+	Running the modified gdb.base/template.exp shows that it exits without
+	printing any result.
+
+	Remove the line that prepends no-message to args, that should make
+	runto's behavior match its documentation.
+
+	This patch will appear to add many failures, but in reality they already
+	existed, they were just silenced.
+
+	Change-Id: I2a730d5bc72b6ef0698cd6aad962d9902aa7c3d6
+
+2021-12-09  Carl Love  <cel@us.ibm.com>
+
+	gdb fix elfv1 Powerpc gdb.dwarf2/frame-inlined-in-outer-frame.exp
+	On ELFv1, the _start symbol must point to the *function descriptor* (in
+	the .opd section), not to the function code (in the .text section) like
+	with ELFv2 and other architectures.
+
+2021-12-09  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.base/maint.exp with -readnow
+	With test-case gdb.base/maint.exp and target board -readnow, I run into:
+	...
+	FAIL: gdb.base/maint.exp: maint info line-table w/o a file name
+	...
+
+	The problem is that this and other regexps anchored using '^':
+	...
+	    -re "^$gdb_prompt $" {
+	...
+	don't trigger because other regexps don't consume the entire preceding line.
+
+	This is partly due to the addition of the IS-STMT column.
+
+	Fix this by making the regexps consume entire lines.
+
+	Tested on x86_64-linux with native and target board readnow, as well as
+	check-read1 and check-readmore.
+
+2021-12-09  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.base/include-main.exp with -readnow
+	With test-case gdb.base/include-main.exp and target board readnow, I run into:
+	...
+	FAIL: gdb.base/include-main.exp: maint info symtab
+	...
+
+	The corresponding check in gdb.base/include-main.exp:
+	...
+	gdb_test_no_output "maint info symtab"
+	...
+	checks that no CU was expanded, while -readnow ensures that all CUs are
+	expanded.
+
+	Fix this by skipping the check with -readnow.
+
+	Tested on x86_64-linux, with native and target board readnow.
+
+2021-12-09  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: Clarify the behavior of .option arch directive.
+	* To be consistent with -march option, removed the "=" operator when
+	user want to reset the whole architecture string.  So the formats are,
+
+	.option arch, +<extension><version>, ...
+	.option arch, -<extension>
+	.option arch, <ISA string>
+
+	* Don't allow to add or remove the base extensions in the .option arch
+	directive.  Instead, users should reset the whole architecture string
+	while they want to change the base extension.
+
+	* The operator "+" won't update the version of extension, if the
+	extension is already in the subset list.
+
+	bfd/
+		* elfxx-riscv.c (riscv_add_subset): Don't update the version
+		if the extension is already in the subset list.
+		(riscv_update_subset): To be consistent with -march option,
+		removed the "=" operator when user want to reset the whole
+		architecture string.  Besides, Don't allow to add or remove
+		the base extensions in the .option arch directive.
+	gas/
+		* testsuite/gas/riscv/option-arch-01.s: Updated since we cannot
+		add or remove the base extensions in the .option arch directive.
+		* testsuite/gas/riscv/option-arch-02.s: Likewise.
+		* testsuite/gas/riscv/option-arch-fail.l: Likewise.
+		* testsuite/gas/riscv/option-arch-fail.s: Likewise.
+		* testsuite/gas/riscv/option-arch-01a.d: Set -misa-spec=2.2.
+		* testsuite/gas/riscv/option-arch-01b.d: Likewise.
+		* testsuite/gas/riscv/option-arch-02.d: Updated since the .option
+		arch, + won't change the version of extension, if the extension is
+		already in the subset list.
+		* testsuite/gas/riscv/option-arch-03.s: Removed the "=" operator
+		when resetting the whole architecture string.
+
+2021-12-09  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: use ## for automake comments
+	The ## marker tells automake to not include the comment in its
+	generated output, so use that in most places where the comment
+	only makes sense in the inputs.
+
+2021-12-09  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb, gdbserver: detach fork child when detaching from fork parent
+	While working with pending fork events, I wondered what would happen if
+	the user detached an inferior while a thread of that inferior had a
+	pending fork event.  What happens with the fork child, which is
+	ptrace-attached by the GDB process (or by GDBserver), but not known to
+	the core?  Sure enough, neither the core of GDB or the target detach the
+	child process, so GDB (or GDBserver) just stays ptrace-attached to the
+	process.  The result is that the fork child process is stuck, while you
+	would expect it to be detached and run.
+
+	Make GDBserver detach of fork children it knows about.  That is done in
+	the generic handle_detach function.  Since a process_info already exists
+	for the child, we can simply call detach_inferior on it.
+
+	GDB-side, make the linux-nat and remote targets detach of fork children
+	known because of pending fork events.  These pending fork events can be
+	stored in:
+
+	 - thread_info::pending_waitstatus, if the core has consumed the event
+	   but then saved it for later (for example, because it got the event
+	   while stopping all threads, to present an all-stop stop on top of a
+	   non-stop target)
+	 - thread_info::pending_follow: if we ran to a "catch fork" and we
+	   detach at that moment
+
+	Additionally, pending fork events can be in target-specific fields:
+
+	 - For linux-nat, they can be in lwp_info::status and
+	   lwp_info::waitstatus.
+	 - For the remote target, they could be stored as pending stop replies,
+	   saved in `remote_state::notif_state::pending_event`, if not
+	   acknowledged yet, or in `remote_state::stop_reply_queue`, if
+	   acknowledged.  I followed the model of remove_new_fork_children for
+	   this: call remote_notif_get_pending_events to process /
+	   acknowledge any unacknowledged notification, then look through
+	   stop_reply_queue.
+
+	Update the gdb.threads/pending-fork-event.exp test (and rename it to
+	gdb.threads/pending-fork-event-detach.exp) to try to detach the process
+	while it is stopped with a pending fork event.  In order to verify that
+	the fork child process is correctly detached and resumes execution
+	outside of GDB's control, make that process create a file in the test
+	output directory, and make the test wait $timeout seconds for that file
+	to appear (it happens instantly if everything goes well).
+
+	This test catches a bug in linux-nat.c, also reported as PR 28512
+	("waitstatus.h:300: internal-error: gdb_signal target_waitstatus::sig()
+	const: Assertion `m_kind == TARGET_WAITKIND_STOPPED || m_kind ==
+	TARGET_WAITKIND_SIGNALLED' failed.).  When detaching a thread with a
+	pending event, get_detach_signal unconditionally fetches the signal
+	stored in the waitstatus (`tp->pending_waitstatus ().sig ()`).  However,
+	that is only valid if the pending event is of type
+	TARGET_WAITKIND_STOPPED, and this is now enforced using assertions (iit
+	would also be valid for TARGET_WAITKIND_SIGNALLED, but that would mean
+	the thread does not exist anymore, so we wouldn't be detaching it).  Add
+	a condition in get_detach_signal to access the signal number only if the
+	wait status is of kind TARGET_WAITKIND_STOPPED, and use GDB_SIGNAL_0
+	instead (since the thread was not stopped with a signal to begin with).
+
+	Add another test, gdb.threads/pending-fork-event-ns.exp, specifically to
+	verify that we consider events in pending stop replies in the remote
+	target.  This test has many threads constantly forking, and we detach
+	from the program while the program is executing.  That gives us some
+	chance that we detach while a fork stop reply is stored in the remote
+	target.  To verify that we correctly detach all fork children, we ask
+	the parent to exit by sending it a SIGUSR1 signal and have it write a
+	file to the filesystem before exiting.  Because the parent's main thread
+	joins the forking threads, and the forking threads wait for their fork
+	children to exit, if some fork child is not detach by GDB, the parent
+	will not write the file, and the test will time out.  If I remove the
+	new remote_detach_pid calls in remote.c, the test fails eventually if I
+	run it in a loop.
+
+	There is a known limitation: we don't remove breakpoints from the
+	children before detaching it.  So the children, could hit a trap
+	instruction after being detached and crash.  I know this is wrong, and
+	it should be fixed, but I would like to handle that later.  The current
+	patch doesn't fix everything, but it's a step in the right direction.
+
+	Change-Id: I6d811a56f520e3cb92d5ea563ad38976f92e93dd
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28512
+
+2021-12-09  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: move clearing of tp->pending_follow to follow_fork_inferior
+	A following patch will change targets so that when they detach an
+	inferior, they also detach any pending fork children this inferior may
+	have.  While doing this, I hit a case where we couldn't differentiate
+	two cases, where in one we should detach the fork detach but not in the
+	other.
+
+	Suppose we continue past a fork with "follow-fork-mode == child" &&
+	"detach-on-fork on".  follow_fork_inferior calls target_detach to detach
+	the parent.  In that case the target should not detach the fork
+	child, as we'll continue debugging the child.  As of now, the
+	tp->pending_follow field of the thread who called fork still contains
+	the details about the fork.
+
+	Then, suppose we run to a fork catchpoint and the user types "detach".
+	In that case, the target should detach the fork child in addition to the
+	parent.  In that case as well, the tp->pending_follow field contains
+	the details about the fork.
+
+	To allow targets to differentiate the two cases, clear
+	tp->pending_follow a bit earlier, when following a fork.  Targets will
+	then see that tp->pending_follow contains TARGET_WAITKIND_SPURIOUS, and
+	won't detach the fork child.
+
+	As of this patch, no behavior changes are expected.
+
+	Change-Id: I537741859ed712cb531baaefc78bb934e2a28153
+
+2021-12-09  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb/remote.c: refactor pending fork status functions
+	In preparation for a following patch, refactor a few things that I did
+	find a bit awkward, and to make them a bit more reusable.
+
+	 - Pass an inferior to kill_new_fork_children instead of a pid.  That
+	   allows iterating on only this inferior's threads and avoid further
+	   filtering on the thread's pid.
+	 - Change thread_pending_fork_status to return a non-nullptr value only
+	   if the thread does have a pending fork status.
+	 - Remove is_pending_fork_parent_thread, as one can just use
+	   thread_pending_fork_status and check for nullptr.
+	 - Replace is_pending_fork_parent with is_fork_status, which just
+	   returns if the given target_waitkind if a fork or a vfork.  Push
+	   filtering on the pid to the callers, when it is necessary.
+
+	Change-Id: I0764ccc684d40f054e39df6fa5458cc4c5d1cd7b
+
+2021-12-09  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb/remote.c: move some things up
+	Move the stop_reply and a few functions up.  Some code above them in the
+	file will need to use them in a following patch.  No behavior changes
+	expected here.
+
+	Change-Id: I3ca57d0e3ec253f56e1ba401289d9d167de14ad2
+
+2021-12-09  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb/linux-nat: factor ptrace-detach code to new detach_one_pid function
+	The following patch will add some code paths that need to ptrace-detach
+	a given PID.  Factor out the code that does this and put it in its own
+	function, so that it can be re-used.
+
+	Change-Id: Ie65ca0d89893b41aea0a23d9fc6ffbed042a9705
+
+2021-12-09  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdbserver: hide fork child threads from GDB
+	This patch aims at fixing a bug where an inferior is unexpectedly
+	created when a fork happens at the same time as another event, and that
+	other event is reported to GDB first (and the fork event stays pending
+	in GDBserver).  This happens for example when we step a thread and
+	another thread forks at the same time.  The bug looks like (if I
+	reproduce the included test by hand):
+
+	    (gdb) show detach-on-fork
+	    Whether gdb will detach the child of a fork is on.
+	    (gdb) show follow-fork-mode
+	    Debugger response to a program call of fork or vfork is "parent".
+	    (gdb) si
+	    [New inferior 2]
+	    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...
+	    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...
+	    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...
+	    [New Thread 965190.965190]
+	    [Switching to Thread 965190.965190]
+	    Remote 'g' packet reply is too long (expected 560 bytes, got 816 bytes): ... <long series of bytes>
+
+	The sequence of events leading to the problem is:
+
+	 - We are using the all-stop user-visible mode as well as the
+	   synchronous / all-stop variant of the remote protocol
+	 - We have two threads, thread A that we single-step and thread B that
+	   calls fork at the same time
+	 - GDBserver's linux_process_target::wait pulls the "single step
+	   complete SIGTRAP" and the "fork" events from the kernel.  It
+	   arbitrarily choses one event to report, it happens to be the
+	   single-step SIGTRAP.  The fork stays pending in the thread_info.
+	 - GDBserver send that SIGTRAP as a stop reply to GDB
+	 - While in stop_all_threads, GDB calls update_thread_list, which ends
+	   up querying the remote thread list using qXfer:threads:read.
+	 - In the reply, GDBserver includes the fork child created as a result
+	   of thread B's fork.
+	 - GDB-side, the remote target sees the new PID, calls
+	   remote_notice_new_inferior, which ends up unexpectedly creating a new
+	   inferior, and things go downhill from there.
+
+	The problem here is that as long as GDB did not process the fork event,
+	it should pretend the fork child does not exist.  Ultimately, this event
+	will be reported, we'll go through follow_fork, and that process will be
+	detached.
+
+	The remote target (GDB-side), has some code to remove from the reported
+	thread list the threads that are the result of forks not processed by
+	GDB yet.  But that only works for fork events that have made their way
+	to the remote target (GDB-side), but haven't been consumed by the core
+	yet, so are still lingering as pending stop replies in the remote target
+	(see remove_new_fork_children in remote.c).  But in our case, the fork
+	event hasn't made its way to the GDB-side remote target.  We need to
+	implement the same kind of logic GDBserver-side: if there exists a
+	thread / inferior that is the result of a fork event GDBserver hasn't
+	reported yet, it should exclude that thread / inferior from the reported
+	thread list.
+
+	This was actually discussed a while ago, but not implemented AFAIK:
+
+	    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t
+	    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html
+
+	Implementation details-wise, the fix for this is all in GDBserver.  The
+	Linux layer of GDBserver already tracks unreported fork parent / child
+	relationships using the lwp_info::fork_relative, in order to avoid
+	wildcard actions resuming fork childs unknown to GDB.  This information
+	needs to be made available to the handle_qxfer_threads_worker function,
+	so it can filter the reported threads.  Add a new thread_pending_parent
+	target function that allows the Linux target to return the parent of an
+	eventual fork child.
+
+	Testing-wise, the test replicates pretty-much the sequence of events
+	shown above.  The setup of the test makes it such that the main thread
+	is about to fork.  We stepi the other thread, so that the step completes
+	very quickly, in a single event.  Meanwhile, the main thread is resumed,
+	so very likely has time to call fork.  This means that the bug may not
+	reproduce every time (if the main thread does not have time to call
+	fork), but it will reproduce more often than not.  The test fails
+	without the fix applied on the native-gdbserver and
+	native-extended-gdbserver boards.
+
+	At some point I suspected that which thread called fork and which thread
+	did the step influenced the order in which the events were reported, and
+	therefore the reproducibility of the bug.  So I made the test try  both
+	combinations: main thread forks while other thread steps, and vice
+	versa.  I'm not sure this is still necessary, but I left it there
+	anyway.  It doesn't hurt to test a few more combinations.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28288
+	Change-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990
+
+2021-12-09  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-08  Tom Tromey  <tom@tromey.com>
+
+	Use for-each more in gdb
+	There are some loops in gdb that use ARRAY_SIZE (or a wordier
+	equivalent) to loop over a static array.  This patch changes some of
+	these to use foreach instead.
+
+	Regression tested on x86-64 Fedora 34.
+
+2021-12-08  Tom Tromey  <tromey@adacore.com>
+
+	Fix error in file_and_directory patch
+	In my earlier C++-ization patch for file_and_directory, I introduced
+	an error:
+
+	-  if (strcmp (fnd.name, "<unknown>") != 0)
+	+  if (fnd.is_unknown ())
+
+	This change inverted the sense of the test, which causes failures with
+	.debug_names.
+
+	This patch fixes the bug.  Regression tested on x86-64 Fedora 34.  I
+	also tested it using the AdaCore internal test suite, with
+	.debug_names -- this was failing before, and now it works.
+
+2021-12-08  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/python: Use tp_init instead of tp_new to setup gdb.Value
+	The documentation suggests that we implement gdb.Value.__init__,
+	however, this is not currently true, we really implement
+	gdb.Value.__new__.  This will cause confusion if a user tries to
+	sub-class gdb.Value.  They might write:
+
+	  class MyVal (gdb.Value):
+	      def __init__ (self, val):
+	          gdb.Value.__init__(self, val)
+
+	  obj = MyVal(123)
+	  print ("Got: %s" % obj)
+
+	But, when they source this code they'll see:
+
+	  (gdb) source ~/tmp/value-test.py
+	  Traceback (most recent call last):
+	    File "/home/andrew/tmp/value-test.py", line 7, in <module>
+	      obj = MyVal(123)
+	    File "/home/andrew/tmp/value-test.py", line 5, in __init__
+	      gdb.Value.__init__(self, val)
+	  TypeError: object.__init__() takes exactly one argument (the instance to initialize)
+	  (gdb)
+
+	The reason for this is that, as we don't implement __init__ for
+	gdb.Value, Python ends up calling object.__init__ instead, which
+	doesn't expect any arguments.
+
+	The Python docs suggest that the reason why we might take this
+	approach is because we want gdb.Value to be immutable:
+
+	   https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_new
+
+	But I don't see any reason why we should require gdb.Value to be
+	immutable when other types defined in GDB are not.  This current
+	immutability can be seen in this code:
+
+	  obj = gdb.Value(1234)
+	  print("Got: %s" % obj)
+	  obj.__init__ (5678)
+	  print("Got: %s" % obj)
+
+	Which currently runs without error, but prints:
+
+	  Got: 1234
+	  Got: 1234
+
+	In this commit I propose that we switch to using __init__ to
+	initialize gdb.Value objects.
+
+	This does introduce some additional complexity, during the __init__
+	call a gdb.Value might already be associated with a gdb value object,
+	in which case we need to cleanly break that association before
+	installing the new gdb value object.  However, the cost of doing this
+	is not great, and the benefit - being able to easily sub-class
+	gdb.Value seems worth it.
+
+	After this commit the first example above works without error, while
+	the second example now prints:
+
+	  Got: 1234
+	  Got: 5678
+
+	In order to make it easier to override the gdb.Value.__init__ method,
+	I have tweaked the definition of gdb.Value.__init__.  The second,
+	optional argument to __init__ is a gdb.Type, if this argument is not
+	present then GDB figures out a suitable type.
+
+	However, if we want to override the __init__ method in a sub-class,
+	and still support the default argument, it is easier to write:
+
+	  class MyVal (gdb.Value):
+	      def __init__ (self, val, type=None):
+	          gdb.Value.__init__(self, val, type)
+
+	Currently, passing None for the Type will result in an error:
+
+	  TypeError: type argument must be a gdb.Type.
+
+	After this commit I now allow the type argument to be None, in which
+	case GDB figures out a suitable type just as if the type had not been
+	passed at all.
+
+	Unless a user is trying to reinitialize a value, or create sub-classes
+	of gdb.Value, there should be no user visible changes after this
+	commit.
+
+2021-12-08  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: use try/catch around a gdb_disassembler::print_insn call
+	While investigating some disassembler problems I ran into this case;
+	GDB compiled on a 32-bit arm target, with --enable-targets=all.  Then
+	in GDB:
+
+	  (gdb) set architecture i386
+	  (gdb) disassemble 0x0,+4
+	  unknown disassembler error (error = -1)
+
+	This is interesting because it shows a case where the libopcodes
+	disassembler is returning -1 without first calling the
+	memory_error_func callback.  Indeed, the return from libopcodes
+	happens from this code snippet in i386-dis.c in the print_insn
+	function:
+
+	  if (address_mode == mode_64bit && sizeof (bfd_vma) < 8)
+	    {
+	      (*info->fprintf_func) (info->stream,
+				     _("64-bit address is disabled"));
+	      return -1;
+	    }
+
+	Notice how, prior to the return the disassembler tries to print a
+	helpful message out, but GDB doesn't print this message.
+
+	The reason this message goes missing is the call stack, it looks like
+	this:
+
+	  gdb_pretty_print_disassembler::pretty_print_insn
+	    gdb_disassembler::print_insn
+	      gdbarch_print_insn
+	        ...
+	          i386-dis.c:print_insn
+
+	When i386-dis.c:print_insn returns -1 this is handled in
+	gdb_disassembler::print_insn, where an exception is thrown.  However,
+	the actual printing of the disassembler output is done in
+	gdb_pretty_print_disassembler::pretty_print_insn, and is only done if
+	an exception is not thrown.
+
+	In this commit I change this.  The pretty_print_insn now uses
+	try/catch around the call to gdb_disassembler::print_insn, if we catch
+	an error then we first print any pending output in the instruction
+	buffer, before rethrowing the exception.  As a result, even if an
+	exception is thrown we still print any pending disassembler output to
+	the screen; in the above case the helpful message will now be shown.
+
+	Before my patch we might expect to see this output:
+
+	  (gdb) disassemble 0x0,+4
+	  Dump of assembler code from 0x0 to 0x4:
+	     0x0000000000000000:	unknown disassembler error (error = -1)
+	  (gdb)
+
+	But now we see this:
+
+	  (gdb) disassemble 0x0,+4
+	  Dump of assembler code from 0x0 to 0x4:
+	     0x0000000000000000:	64-bit address is disabled
+	  unknown disassembler error (error = -1)
+
+	If the disassembler returns -1 without printing a helpful message then
+	we would still expect a change in output, something like:
+
+	  (gdb) disassemble 0x0,+4
+	  Dump of assembler code from 0x0 to 0x4:
+	     0x0000000000000000:
+	  unknown disassembler error (error = -1)
+
+	Which I think is still acceptable, though at this point I think a
+	strong case can be made that this is a disassembler bug (not printing
+	anything, but still returning -1).
+
+	Notice however, that the error message is always printed on a new line
+	now.  This is also true for the memory error case, where before we
+	might see this:
+
+	  (gdb) disassemble 0x0,+4
+	  Dump of assembler code from 0x0 to 0x4:
+	     0x00000000:	Cannot access memory at address 0x0
+
+	We now get this:
+
+	  (gdb) disassemble 0x0,+4
+	  Dump of assembler code from 0x0 to 0x4:
+	     0x00000000:
+	  Cannot access memory at address 0x0
+
+	For me, I'm happy to accept this change, having the error on a line by
+	itself, rather than just appended to the end of the previous line,
+	seems like an improvement, but I'm aware others might feel
+	differently, so I'd appreciate any feedback.
+
+2021-12-08  Jan Vrany  <jan.vrany@labware.com>
+
+	ppc: recognize all program traps
+	Permanent program breakpoints (ones inserted into the code) other than
+	the one GDB uses for POWER (0x7fe00008) did not result in stop but
+	caused GDB to loop infinitely.
+
+	This was because GDB did not recognize trap instructions other than
+	"trap". For example, "tw 12, 4, 4" was not be recognized, causing GDB
+	to loop forever.
+
+	This commit fixes this by providing POWER specific hook
+	(gdbarch_program_breakpoint_here_p) recognizing all tw, twi, td and tdi
+	instructions.
+
+	Tested on Linux on PowerPC e500 and on QEMU PPC64le.
+
+2021-12-08  Jan Vrany  <jan.vrany@labware.com>
+
+	ppc: use "trap" ("tw, 31, 0, 0") as breakpoint instruction
+	Power ISA 3.0 B spec [1], sections 3.3.11 "Fixed-Point Trap Instructions"
+	and section C.6 "Trap Mnemonics" specify "tw, 31, 0, 0" (encoded as
+	0x7fe00008) as canonical unconditional trap instruction.
+
+	This commit changes the breakpoint instruction used by GDB from
+	"tw 12, r2, r2" to unconditional "trap".
+
+	[1]: https://openpowerfoundation.org/?resource_lib=power-isa-version-3-0
+
+2021-12-08  Fangrui Song  <maskray@google.com>
+
+	bfd_section_from_shdr: Support SHT_RELR sections
+	If a.so contains an SHT_RELR section, objcopy a.so will fail with:
+
+	    a.so: unknown type [0x13] section `.relr.dyn'
+
+	This change allows objcopy to work.
+
+	bfd/
+	    * elf.c (bfd_section_from_shdr): Support SHT_RELR.
+
+2021-12-08  Alan Modra  <amodra@gmail.com>
+
+	PR28673, input file 'gcov' is the same as output file
+		PR 28673
+		* ldlang.c (open_output): Use local_sym_name when checking
+		output against input files rather than filename.
+
+2021-12-08  Tom Tromey  <tom@tromey.com>
+
+	Fix bug in source.c change
+	My earlier change to source.c ("Remove an xfree from add_path")
+	introduced a regression.  This patch fixes the problem.
+
+2021-12-08  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: make struct linespect contain vectors, not pointers to vectors
+	struct linespec contains pointers to vectors, instead of containing
+	vectors directly.  This is probably historical, when linespec_parser
+	(which contains a struct linespec field) was not C++-ified yet.  But it
+	seems easy to change the pointers to vectors to just vectors today.
+	This simplifies the code, we don't need to manually allocate and delete
+	the vectors and there's no pointer that can be NULL.
+
+	As far as I understand, there was not meaningful distinction between a
+	NULL pointer to vector and an empty vector.  So all NULL checks are
+	changed for !empty checks.
+
+	Change-Id: Ie759707da14d9d984169b93233343a86e2de9ee6
+
+2021-12-08  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-07  Tom Tromey  <tom@tromey.com>
+
+	Remove an xfree from add_path
+	This removes a temporary \0 assignment and an xfree from add_path,
+	replacing it with a simpler use of std::string.
+
+2021-12-07  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/linespec.c: simplify condition
+	We can remove the empty check: if the vector has size 1, it is obviously
+	not empty.  This code ended up like this because the empty check used to
+	be a NULL check.
+
+	Change-Id: I1571bd0228818ca93f6a6b444e9b010dc2da4c08
+
+2021-12-07  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: rename "maint agent" functions
+	Functions agent_eval_command and agent_command are used to implement
+	maintenance commands, rename them accordingly (with the maint_ prefix),
+	as well as the agent_command_1 helper function.
+
+	Change-Id: Iacf96d4a0a26298e8dd4648a0f38da649ea5ef61
+
+2021-12-07  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: make set_raw_breakpoint static
+	set_raw_breakpoint is only used in breakpoint.c, make it static.
+
+	Change-Id: I7fbeda067685309a30b88aceaf957eff7a28e310
+
+2021-12-07  John Baldwin  <jhb@FreeBSD.org>
+
+	Support AT_FXRNG and AT_KPRELOAD on FreeBSD.
+	FreeBSD's kernel has recently added two new ELF auxiliary vector
+	entries.  AT_FXRNG points to a root seed version for the kernel's
+	PRNG.  Userland can use this to reseed a userland PRNG after the
+	kernel's PRNG has reseeded.  AT_KPRELOAD is the base address of a
+	kernel-provided vDSO.
+
+	This change displays the proper name and description of these entries
+	in 'info auxv'.
+
+	include/ChangeLog:
+
+		* elf/common.h (AT_FREEBSD_FXRNG, AT_FREEBSD_KPRELOAD): Define.
+
+2021-12-07  Tom Tromey  <tromey@adacore.com>
+
+	Avoid extra work in global_symbol_searcher::expand_symtabs
+	I noticed that global_symbol_searcher::expand_symtabs always passes a
+	file matcher to expand_symtabs_matching.  However, if 'filenames' is
+	empty, then this always returns true.  It's slightly more efficient to
+	pass a null file matcher in this case, because that lets the "quick"
+	symbol implementations skip any filename checks.
+
+	Regression tested on x86-64 Fedora 34.
+
+2021-12-07  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix options arg handling in compile_jit_elf_main_as_so
+	In commit 80ad340c902 ("[gdb/testsuite] use -Ttext-segment for jit-elf tests")
+	the following change was made:
+	...
+	 proc compile_jit_elf_main_as_so {main_solib_srcfile main_solib_binfile options} {
+	-    set options [concat $options debug]
+	+    global jit_load_address jit_load_increment
+	+
+	+    set options [list \
+	+       additional_flags="-DMAIN=jit_dl_main" \
+	+       additional_flags=-DLOAD_ADDRESS=$jit_load_address \
+	+       additional_flags=-DLOAD_INCREMENT=$jit_load_increment \
+	+       debug]
+	...
+
+	Before the change, the options argument was used, but after the change not
+	anymore.
+
+	Fix this by reverting back to using "set options [concat $options ...]".
+
+	Fixing this gets us twice the -DMAIN=jit_dl_main bit, once from a caller, and
+	once from compile_jit_elf_main_as_so.  Fix this by removing the bit from
+	compile_jit_elf_main_as_so, which makes the code similar to compile_jit_main.
+
+	Tested on x86_64-linux.
+
+2021-12-07  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix FAIL in gdb.tui/basic.exp
+	On openSUSE Leap 15.2 aarch64 I ran into:
+	...
+	FAIL: gdb.tui/basic.exp: check main is where we expect on the screen
+	...
+	while this is passing on x86_64.
+
+	On x86_64-linux we have at the initial screen dump for "list -q main":
+	...
+	 0 +-/home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.tui/tui-layout.c--+
+	 1 |       15     You should have received a copy of the GNU General Public |
+	 2 |       16     along with this program.  If not, see <http://www.gnu.org/|
+	 3 |       17                                                               |
+	 4 |       18  int                                                          |
+	 5 |       19  main ()                                                      |
+	 6 |       20  {                                                            |
+	 7 |       21    return 0;                                                  |
+	 8 |       22  }                                                            |
+	 9 |       23                                                               |
+	...
+	but on aarch64:
+	...
+	 0 +-/home/tdevries/gdb/src/gdb/testsuite/gdb.tui/tui-layout.c--------------+
+	 1 |       16     along with this program.  If not, see <http://www.gnu.org/|
+	 2 |       17                                                               |
+	 3 |       18  int                                                          |
+	 4 |       19  main ()                                                      |
+	 5 |       20  {                                                            |
+	 6 |       21    return 0;                                                  |
+	 7 |       22  }                                                            |
+	 8 |       23                                                               |
+	 9 |       24                                                               |
+	...
+
+	The cause of the diffferent placement is that we have as line number for main
+	on x86_64:
+	...
+	$ gdb -q -batch outputs/gdb.tui/basic/basic -ex "info line main"
+	Line 20 of "tui-layout.c" starts at address 0x4004a7 <main> \
+	  and ends at 0x4004ab <main+4>.
+	...
+	and on aarch64 instead:
+	...
+	$ gdb -q -batch outputs/gdb.tui/basic/basic -ex "info line main"
+	Line 21 of "tui-layout.c" starts at address 0x4005f4 <main> \
+	  and ends at 0x4005f8 <main+4>.
+	...
+
+	Fix this by using a new source file main-one-line.c, that implements the
+	entire main function on a single line, in order to force the compiler to use
+	that line number.
+
+	Also try to do less hard-coding in the test-case.
+
+	Tested on x86_64-linux and aarch64-linux.
+
+2021-12-07  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/tdep] Fix inferior plt calls in PIE for i386
+	Consider test-case test.c:
+	...
+	int main (void) {
+	  void *p = malloc (10);
+	  return 0;
+	}
+	...
+
+	When compiled to a non-PIE exec:
+	...
+	$ gcc -m32 test.c
+	...
+	the call sequence looks like:
+	...
+	 8048447:       83 ec 0c                sub    $0xc,%esp
+	 804844a:       6a 0a                   push   $0xa
+	 804844c:       e8 bf fe ff ff          call   8048310 <malloc@plt>
+	...
+	which calls to:
+	...
+	08048310 <malloc@plt>:
+	 8048310:       ff 25 0c a0 04 08       jmp    *0x804a00c
+	 8048316:       68 00 00 00 00          push   $0x0
+	 804831b:       e9 e0 ff ff ff          jmp    8048300 <.plt>
+	...
+	where the first insn at 0x8048310 initially jumps to the following address
+	0x8048316, read from the .got.plt @ 0x804a00c:
+	...
+	 804a000 0c9f0408 00000000 00000000 16830408  ................
+	 804a010 26830408                             &...
+	...
+
+	Likewise, when compiled as a PIE:
+	...
+	$ gcc -m32 -fPIE -pie test.c
+	...
+	we have this call sequence (with %ebx setup to point to the .got.plt):
+	...
+	0000055d <main>:
+	 579:   83 ec 0c                sub    $0xc,%esp
+	 57c:   6a 0a                   push   $0xa
+	 57e:   89 c3                   mov    %eax,%ebx
+	 580:   e8 6b fe ff ff          call   3f0 <malloc@plt>
+	...
+	which calls to:
+	...
+	000003f0 <malloc@plt>:
+	 3f0:   ff a3 0c 00 00 00       jmp    *0xc(%ebx)
+	 3f6:   68 00 00 00 00          push   $0x0
+	 3fb:   e9 e0 ff ff ff          jmp    3e0 <.plt>
+	...
+	where the insn at 0x3f0 initially jumps to following address 0x3f6, read from
+	the .got.plt at offset 0xc:
+	...
+	 2000 f41e0000 00000000 00000000 f6030000  ................
+	 2010 06040000                             ....
+	...
+
+	When instead doing an inferior call to malloc (with nosharedlib to force
+	malloc to resolve to malloc@plt rather than the functions in ld.so or libc.so)
+	with the non-PIE exec, we have the expected:
+	...
+	$ gdb -q -batch a.out -ex start -ex nosharedlib -ex "p /x (void *)malloc (10)"
+	Temporary breakpoint 1 at 0x8048444
+
+	Temporary breakpoint 1, 0x08048444 in main ()
+	$1 = 0x804b160
+	...
+
+	But with the PIE exec, we run into:
+	...
+	$ gdb -q -batch a.out -ex start -ex nosharedlib -ex "p /x (void *)malloc (10)"
+	Temporary breakpoint 1 at 0x56c
+
+	Temporary breakpoint 1, 0x5655556c in main ()
+
+	Program received signal SIGSEGV, Segmentation fault.
+	0x565553f0 in malloc@plt ()
+	...
+
+	The segfault happens because:
+	- the inferior call mechanism doesn't setup %ebx
+	- %ebx instead is 0
+	- the jump to "*0xc(%ebx)" reads from memory at 0xc
+
+	Fix this by setting up %ebx properly in i386_thiscall_push_dummy_call.
+
+	Fixes this failure with target board unix/-m32/-pie/-fPIE reported in
+	PR28467:
+	...
+	FAIL: gdb.base/nodebug.exp: p/c (int) array_index("abcdef",2)
+	...
+
+	Tested on x86_64-linux, with target board unix/-m32 and unix/-m32/-fPIE/-pie.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28467
+
+2021-12-07  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/symtab] Support -readnow during reread
+	When running test-case gdb.base/cached-source-file.exp with target board
+	readnow, we run into:
+	...
+	FAIL: gdb.base/cached-source-file.exp: rerun program (the program exited)
+	...
+
+	The problem is that when rereading, the readnow is ignored.
+
+	Fix this by copying the readnow handling code from symbol_file_add_with_addrs
+	to reread_symbols.
+
+	Tested on x86_64-linux.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26800
+
+2021-12-07  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/ada] Fix assert in ada_is_unconstrained_packed_array_type
+	On openSUSE Leap 42.3, with system compiler gcc 4.8.5 I run into:
+	...
+	(gdb) print u_one_two_three^M
+	src/gdb/gdbtypes.h:1050: internal-error: field: \
+	 Assertion `idx >= 0 && idx < num_fields ()' failed.^M
+	...
+
+	We run into trouble while doing this in
+	ada_is_unconstrained_packed_array_type:
+	...
+	1953          return TYPE_FIELD_BITSIZE (type, 0) > 0;
+	...
+	which tries to get field 0 from a type without fields:
+	...
+	(gdb) p type->num_fields ()
+	$6 = 0
+	...
+	which is the case because the type is a typedef:
+	...
+	(gdb) p type->code ()
+	$7 = TYPE_CODE_TYPEDEF
+	...
+
+	Fix this by using the type referenced by the typedef instead.
+
+	Tested on x86_64-linux.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28323
+
+2021-12-07  Alan Modra  <amodra@gmail.com>
+
+	Re: Add support for AArch64 EFI (efi-*-aarch64)
+	Commit b69c9d41e8 was broken in multiple ways regarding the realloc
+	of the target string, most notably in that "-little" wasn't actually
+	appended to the input_target or output_target.  This caused asan
+	errors and "FAIL: Check if efi app format is recognized".  I also
+	noticed that the input_target string wasn't being copied but rather
+	the output_target when dealing with the input target.  Fix that too.
+
+		PR 26206
+		* objcopy.c (convert_efi_target): Rewrite.  Allocate modified
+		target strings here..
+		(copy_main): ..rather than here.  Do handle input_target,
+		not output_target for input.
+
+2021-12-07  Alan Modra  <amodra@gmail.com>
+
+	Error on ld output file name matching input file name
+	It's not foolproof, for example we don't catch output to a linker
+	script, to a library specified with -l, or to an element of a thin
+	archive.
+
+		* ldlang.c (open_output): Exit with error on output file matching
+		an input file.
+		* testsuite/ld-misc/just-symbols.exp: Adjust ld -r test to suit.
+
+2021-12-07  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-06  Carl Love  <cel@us.ibm.com>
+
+	gdb: Add PowerPC support to gdb.dwarf2/frame-inlined-in-outer-frame
+	This patch adds an #elif defined for PowerPC to setup the exit_0 macro.
+	This patch addes the needed macro definitionald logic to handle both elfV1
+	and elfV2.
+
+	The patch has been successfully tested on both PowerPC BE, Powerpc LE and
+	X86_64 with no regressions.
+
+2021-12-06  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Use precise align in gdb.arch/i386-{avx,sse}.exp
+	Test-cases gdb.arch/i386-{avx,sse}.exp use assembly instructions that require
+	the memory operands to be aligned to a certain boundary, and the test-cases
+	use C11's _Alignas to make that happen.
+
+	The draw-back of using _Alignas is that while it does enforce a minimum
+	alignment, the actual alignment may be bigger, which makes the following
+	scenario possible:
+	- copy say, gdb.arch/i386-avx.c as basis for a new test-case
+	- run the test-case and observe a PASS
+	- commit the new test-case in the supposition that the test-case is correct
+	  and well-tested
+	- run later into a failure on a different test setup (which may be a setup
+	  where reproduction and investigation is more difficult and time-consuming),
+	  and find out that the specified alignment was incorrect and should have been
+	  updated to say, 64 bytes.  The initial PASS occurred only because the actual
+	  alignment happened to be greater than required.
+
+	The idea of having precise alignment as a means of having more predictable
+	execution which allows flushing out bugs earlier, has been filed as PR
+	gcc/103095.
+
+	Add a new file lib/precise-aligned-alloc.c with functions
+	precise_aligned_alloc and precise_aligned_dup, to support precise alignment.
+
+	Use precise_aligned_dup in aforementioned test-cases to:
+	- verify that the specified alignment is indeed sufficient, rather
+	  than too little but accidentally over-aligned.
+	- prevent the same type of problems in any new test-cases based on these
+
+	Tested on x86_64-linux, with both gcc and clang.
+
+2021-12-06  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix data alignment in gdb.arch/i386-{avx,sse}.exp
+	When running test-case gdb.arch/i386-avx.exp with clang I ran into:
+	...
+	(gdb) PASS: gdb.arch/i386-avx.exp: set first breakpoint in main
+	continue^M
+	Continuing.^M
+	^M
+	Program received signal SIGSEGV, Segmentation fault.^M
+	0x000000000040052b in main (argc=1, argv=0x7fffffffd3c8) at i386-avx.c:54^M
+	54        asm ("vmovaps 0(%0), %%ymm0\n\t"^M
+	(gdb) FAIL: gdb.arch/i386-avx.exp: continue to breakpoint: \
+	  continue to first breakpoint in main
+	...
+
+	The problem is that the vmovaps insn requires an 256-bit (or 32-byte) aligned
+	address, and it's only 16-byte aligned:
+	...
+	(gdb) p /x $rax
+	$1 = 0x601030
+	...
+
+	Fix this by using a sufficiently aligned address, using _Alignas.
+
+	Compile using -std=gnu11 to support _Alignas.
+
+	Likewise in gdb.arch/i386-sse.exp.
+
+	Tested on x86_64-linux, with both gcc and clang.
+
+2021-12-06  Alan Modra  <amodra@gmail.com>
+
+	[GOLD] PowerPC64 inline plt sequences
+	The fixes gold failures to handle inline PLT sequences properly.
+	PowerPC gold was always turning these back into direct calls due to
+	gsym->use_plt_offset() returning false.  This is fixed for dynamic
+	linking by correcting get_reference_flags, and for static linking by
+	overriding use_plt_offset() in relocate().  The rest of the patch
+	revolves around needing to create PLT entries for inline PLT calls
+	when statically linking (for gcc -mlongcall).  The lplt section
+	handled that for local symbols, now it does globals too.
+
+		* powerpc.cc (Target_powerpc::plt_off): Return proper section
+		for static link.
+		(Target_powerpc::symval_for_branch): Make public.
+		(Target_powerpc::make_lplt_section): Add Symbol_table* param.
+		Adjust all calls.
+		(Target_powerpc::make_local_plt_entry): Likewise.
+		(Target_powerpc::make_local_plt_entry): New variant for global syms.
+		(Powerpc_relobj::do_relocate_sections): Don't write lplt contents.
+		(Output_data_plt_powerpc::do_write): Write lplt contents here.
+		(Output_data_plt_powerpc::Output_data_plt_powerpc): Save
+		symbol table pointer.  Adjust all uses.
+		(Output_data_plt_powerpc::add_entry): Add stash parameter.  Don't
+		do dynamic reloc handling when no reloc section.  Save symbol
+		for local plt entries.
+		(Output_data_plt_powerpc::add_local_entry): Save symbol.
+		(Output_data_plt_powerpc::Local_plt_ent): New class.
+		(Output_data_plt_powerpc::sym_ents_): New vector.
+		(Target_powerpc::Scan::get_reference_flags): Return
+		FUNCTION_CALL|RELATIVE_REF for inline plt relocs.
+		(Target_powerpc::Scan::global): Make entries in lplt for inline
+		plt call relocation symbols.
+		(Target_powerpc::Relocate::relocate): Rename has_plt_offset to
+		use_plt_offset.  Set use_plt_offset for inline plt relocs.
+
+2021-12-06  Clément Chigot  <clement.chigot@atos.net>
+
+	ld: improve shared tests for AIX
+	It's now possible to refer symbols in the main program from the
+	shared library. However, it still impossible to have the same
+	overriden features between shared objects and mains than ELF,
+	without using the runtime linking feature which isn't yet fully
+	available.
+
+	ld/ChangeLog:
+
+		* testsuite/ld-shared/shared.exp: Improve XCOFF support
+		* testsuite/ld-shared/main.c: Likewise.
+		* testsuite/ld-shared/sh1.c: Likewise.
+		* testsuite/ld-shared/xcoff.dat: Likewise.
+
+2021-12-06  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-05  Tom Tromey  <tom@tromey.com>
+
+	Preserve artificial CU name in process_psymtab_comp_unit_reader
+	This fixes a use-after-free that Simon pointed out.
+	process_psymtab_comp_unit_reader was allocating an artificial name for
+	a CU, and then discarding it.  However, this name was preserved in the
+	cached file_and_directory.  This patch arranges for the allocated name
+	to be preserved there.
+
+2021-12-05  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: include ansidecl.h when needed
+	Avoid implicit include deps with this to help untangle sim headers
+	so we can get rid of arch-specific sim-main.h.
+
+	sim: include stdint.h when needed
+	Avoid implicit include deps with this to help untangle sim headers
+	so we can get rid of arch-specific sim-main.h.
+
+	sim: include stdarg.h when used
+	Avoid implicit include deps with this to help untangle sim headers
+	so we can get rid of arch-specific sim-main.h.
+
+2021-12-05  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: reorder header includes
+	We're including system headers after local headers in a bunch of
+	places, but this leads to conflicts when our local headers happen
+	to define symbols that show up in the system headers.
+
+	Use the more standard order of:
+	* config.h (via defs.h)
+	* system headers
+	* local library headers (e.g. bfd & libiberty)
+	* sim specific headers
+
+2021-12-05  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdbsupport: fix memory leak in create_file_handler when re-using file handler
+	ASan made me notice a memory leak, where the memory tied to the file
+	handle name string wasn't freed.  When register a file handler with an
+	fd that is already registered, we re-use the file_handler object, so we
+	ended up creating a new std::string object and overwriting the
+	file_handler::name pointer, without free-ing the old std::string.
+
+	Fix this by allocating file_handler with new, deleting it with
+	delete, and making file_handler::name not a pointer.
+
+	Change-Id: Ie304cc78ab5ae5dfad9a1366e9890c09de651f43
+
+2021-12-05  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-04  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: moxie: hoist dtb rules up to common builds
+	These rules don't depend on the target compiler settings, so hoist
+	the build logic up to the common builds for better parallelization.
+
+	sim: m68hc11: delete unused profile flags
+	These were moved to the common configure script a while ago and have
+	the same default as these, so just delete it.
+
+	sim: msp430: delete redundant comments & settings
+	These were copied from the example docs, so aren't adding any value.
+
+	sim: erc32: drop old configure target
+	There is no configure script in here anymore to regenerate.
+
+	sim: m32c/rl78: drop redundant -Wall settings
+	We already turn these on in the configure script.
+
+2021-12-04  Tom Tromey  <tom@tromey.com>
+
+	Cache the result of find_file_and_directory
+	This changes the DWARF reader to cache the result of
+	find_file_and_directory.  This is not especially important now, but it
+	will help the new DWARF indexer.
+
+	Move file_and_directory to new file and C++-ize
+	This moves file_and_directory to a new file, and then C++-izes it --
+	replacing direct assignments with methods, and arranging for it to own
+	any string that must be computed.  Finally, the CU's objfile will only
+	be used on demand; this is an important property for the new DWARF
+	indexer's parallel mode.
+
+	Remove Irix case from find_file_and_directory
+	find_file_and_directory has a special case for the Irix 6.2 compiler.
+	Since this is long obsolete, this patch removes it.
+
+2021-12-04  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: frv: split up testsuite a bit
+	Running frv's allinsn in serial is quite slow due to the sheer number
+	of tests it contains.  By splitting it up and running in parallel, the
+	execution time on my system goes from ~100sec to ~60sec.
+
+2021-12-04  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: don't show deprecated aliases
+	I don't think it's very useful to show deprecated aliases to the
+	user.  It encourages the user to use them, when the goal is the
+	opposite.
+
+	For example, before:
+
+	    (gdb) help set index-cache enabled
+	    set index-cache enabled, set index-cache off, set index-cache on
+	      alias set index-cache off = set index-cache enabled off
+	      alias set index-cache on = set index-cache enabled on
+	    Enable the index cache.
+	    When on, enable the use of the index cache.
+
+	    (gdb) help set index-cache on
+	    Warning: 'set index-cache on', an alias for the command 'set index-cache enabled', is deprecated.
+	    Use 'set index-cache enabled on'.
+
+	    set index-cache enabled, set index-cache off, set index-cache on
+	      alias set index-cache off = set index-cache enabled off
+	      alias set index-cache on = set index-cache enabled on
+	    Enable the index cache.
+	    When on, enable the use of the index cache.
+
+	After:
+
+	    (gdb) help set index-cache enabled
+	    Enable the index cache.
+	    When on, enable the use of the index cache.
+	    (gdb) help set index-cache on
+	    Warning: 'set index-cache on', an alias for the command 'set index-cache enabled', is deprecated.
+	    Use 'set index-cache enabled on'.
+
+	    Enable the index cache.
+	    When on, enable the use of the index cache.
+
+	Change-Id: I989b618a5ad96ba975367e9d16db95523cd57a4c
+
+2021-12-04  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/testsuite: fix two "maint info line-table"-related tests
+	Commit 92228a334ba2 ("gdb: small "maintenance info line-table"
+	readability improvements") change the output format of "maint info
+	line-table" slightly, adding some empty lines between each
+	line-table.  This causes two tests to start failing, update them to
+	account for those empty lines.
+
+	Change-Id: I9d33a58fce3e860ba0554b25f5582e8066a5c519
+
+2021-12-04  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: revert one array_view copy change in ada-lang.c
+	Commit 4bce7cdaf481 ("gdbsupport: add array_view copy function") caused
+	an internal error when running gdb.ada/packed_array_assign.exp:
+
+	    print pra(1) := pr^M
+	    /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217: internal-error: copy: Assertion `dest.size () == src.size ()' failed.^M
+
+	I am not sure what's the root cause of this, whether it is a GDB bug
+	exposed by using the array_view copy function or not.  Back out the
+	change that triggers the internal error for now, while we investigate
+	it.
+
+	Change-Id: I055ab14143e4cfd3ca7ce8f4855c6c3c05db52a7
+
+2021-12-04  Mike Frysinger  <vapier@gentoo.org>
+
+	bfd: unify header generation rules
+	The logic between these rules are extremely similar, so unify them
+	into a single variable.
+
+2021-12-04  Mike Frysinger  <vapier@gentoo.org>
+
+	bfd: move header updates up a directory
+	The rules for rebuilding the bfd headers live in the doc/ subdir
+	(most likely) because they rely on the chew & related tools.  But
+	we can collapse them into the main Makefile while keeping the tools
+	in the doc subdir easily enough.  This makes the code simpler and
+	allows for rebuilding them in parallel.
+
+	Also add automake silent rule support while we're here.
+
+2021-12-04  Mike Frysinger  <vapier@gentoo.org>
+
+	bfd: convert bfdver.h to silent automake rules
+
+2021-12-04  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-03  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: small "maintenance info line-table" readability improvements
+	 - separate each entry with a newline, to visually separate them
+	 - style filenames with the filename style
+	 - print the name of the compunit_symtab
+
+	A header now looks like this, with the compunit_symtab name added (and
+	the coloring, but you can't really see it here):
+
+	    objfile: /home/simark/build/babeltrace/src/cli/.libs/babeltrace2 ((struct objfile *) 0x613000005980)
+	    compunit_symtab: babeltrace2-cfg-cli-args.c ((struct compunit_symtab *) 0x62100da1ed10)
+	    symtab: /usr/include/glib-2.0/glib/gdatetime.h ((struct symtab *) 0x62100d9ee530)
+	    linetable: ((struct linetable *) 0x0):
+
+	Change-Id: Idc23e10aaa66e2e692adb0a6a74144f72c4fa1c7
+
+2021-12-03  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: change some alias functions parameters to const-reference
+	Now that we use intrusive list to link aliases, it becomes easier to
+	pass cmd_list_element arguments by const-reference rather than by
+	pointer to some functions, change a few.
+
+	Change-Id: Id0df648ed26e9447da0671fc2c858981cda31df8
+
+2021-12-03  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: use intrusive_list for cmd_list_element aliases list
+	Change the manually-implemented linked list to use intrusive_list.  This
+	is not strictly necessary, but it makes the code much simpler.
+
+	Change-Id: Idd08090ebf2db8bdcf68e85ef72a9635f1584ccc
+
+2021-12-03  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: trivial changes to use array_view
+	Change a few relatively obvious spots using value contents to propagate
+	the use array_view a bit more.
+
+	Change-Id: I5338a60986f06d5969fec803d04f8423c9288a15
+
+2021-12-03  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: make extract_integer take an array_view
+	I think it would make sense for extract_integer, extract_signed_integer
+	and extract_unsigned_integer to take an array_view.  This way, when we
+	extract an integer, we can validate that we don't overflow the buffer
+	passed by the caller (e.g. ask to extract a 4-byte integer but pass a
+	2-byte buffer).
+
+	 - Change extract_integer to take an array_view
+	 - Add overloads of extract_signed_integer and extract_unsigned_integer
+	   that take array_views.  Keep the existing versions so we don't
+	   need to change all callers, but make them call the array_view
+	   versions.
+
+	This shortens some places like:
+
+	  result = extract_unsigned_integer (value_contents (result_val).data (),
+					     TYPE_LENGTH (value_type (result_val)),
+					     byte_order);
+
+	into
+
+	  result = extract_unsigned_integer (value_contents (result_val), byte_order);
+
+	value_contents returns an array view that is of length
+	`TYPE_LENGTH (value_type (result_val))` already, so the length is
+	implicitly communicated through the array view.
+
+	Change-Id: Ic1c1f98c88d5c17a8486393af316f982604d6c95
+
+2021-12-03  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdbsupport: add array_view copy function
+	An assertion was recently added to array_view::operator[] to ensure we
+	don't do out of bounds accesses.  However, when the array_view is copied
+	to or from using memcpy, it bypasses that safety.
+
+	To address this, add a `copy` free function that copies data from an
+	array view to another, ensuring that the destination and source array
+	views have the same size.  When copying to or from parts of an
+	array_view, we are expected to use gdb::array_view::slice, which does
+	its own bounds check.  With all that, any copy operation that goes out
+	of bounds should be caught by an assertion at runtime.
+
+	copy is implemented using std::copy and std::copy_backward, which, at
+	least on libstdc++, appears to pick memmove when copying trivial data.
+	So in the end there shouldn't be much difference vs using a bare memcpy,
+	as we do right now.  When copying non-trivial data, std::copy and
+	std::copy_backward assigns each element in a loop.
+
+	To properly support overlapping ranges, we must use std::copy or
+	std::copy_backward, depending on whether the destination is before the
+	source or vice-versa.  std::copy and std::copy_backward don't support
+	copying exactly overlapping ranges (where the source range is equal to
+	the destination range).  But in this case, no copy is needed anyway, so
+	we do nothing.
+
+	The order of parameters of the new copy function is based on std::copy
+	and std::copy_backward, where the source comes before the destination.
+
+	Change a few randomly selected spots to use the new function, to show
+	how it can be used.
+
+	Add a test for the new function, testing both with arrays of a trivial
+	type (int) and of a non-trivial type (foo).  Test non-overlapping
+	ranges as well as three kinds of overlapping ranges: source before dest,
+	dest before source, and dest == source.
+
+	Change-Id: Ibeaca04e0028410fd44ce82f72e60058d6230a03
+
+2021-12-03  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: change store_waitstatus to return a target_waitstatus by value
+	store_waitstatus is basically a translation function between a status
+	integer and an equivalent target_waitstatus object.  It would make sense
+	for it to take the integer as a parameter and return the
+	target_waitstatus by value.  Do that, and rename to
+	host_status_to_waitstatus.  Users can then do:
+
+	  ws = host_status_to_waitstatus (status)
+
+	which does the right thing, given the move constructor of
+	target_waitstatus.
+
+	Change-Id: I7a07d59d3dc19d3ed66929642f82f44f3e85d61b
+
+2021-12-03  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: return *this in target_waitstatus setters
+	While playing with some code creating target_waitstatus objects, I was
+	mildly annoyed by the fact that we can't just return a new
+	target_waitstatus object.  We have to do:
+
+	    target_waitstatus ws;
+	    ws.set_exited (123);
+	    return ws;
+
+	Make the setters return the "this" object as a reference, such that it's
+	possible to do:
+
+	    return target_waitstatus ().set_exited (123);
+
+	I initially thought of adding static creation functions, which you would
+	use like:
+
+	    return target_waitstatus::make_exited (123);
+
+	However, making the setters return a reference to the object achieves
+	pretty much the same thing, with less new code.
+
+	Change-Id: I45159b7f9fcd9db5b20603480e323020b14ed147
+
+2021-12-03  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: make saved_filename an std::string
+	Make this variable an std::string, avoiding manual memory management.
+
+	Change-Id: Ie7a8d7381449ab9c4dfc4cb8b99e63b9ffa8f947
+
+2021-12-03  Richard Sandiford  <richard.sandiford@arm.com>
+
+	aarch64: Fix uninitialised memory
+	AARCH64_OPDE_EXPECTED_A_AFTER_B and AARCH64_OPDE_A_SHOULD_FOLLOW_B
+	are not paired with an error string, but we had an assert that the
+	error was nonnull.  Previously this assert was testing uninitialised
+	memory and so could pass or fail arbitrarily.
+
+	opcodes/
+		* aarch64-opc.c (verify_mops_pme_sequence): Initialize the error
+		field to null for AARCH64_OPDE_EXPECTED_A_AFTER_B and
+		AARCH64_OPDE_A_SHOULD_FOLLOW_B.
+		* aarch64-dis.c (print_verifier_notes): Move assert.
+
+2021-12-03  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: make value_subscripted_rvalue static
+	The function value_subscripted_rvalue is only used in valarith.c, so
+	lets make it a static function.
+
+	There should be no user visible change after this commit.
+
+2021-12-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: give a test a real name
+	A test in gdb.python/py-send-packet.exp added in this commit:
+
+	  commit 24b2de7b776f8f23788d855b1eec290c6e208821
+	  Date:   Tue Aug 31 14:04:36 2021 +0100
+
+	      gdb/python: add gdb.RemoteTargetConnection.send_packet
+
+	included a large amount of binary data in the command sent to GDB.  As
+	this test didn't have a real test name the binary data was included in
+	the gdb.sum file.  The contents of the binary data could change
+	between different runs of GDB, and this makes comparing results
+	harder.
+
+	This commit gives the test a real test name.
+
+2021-12-03  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/remote: fix use after free bug
+	This commit:
+
+	  commit 288712bbaca36bff6578bc839ebcdc3707662f81
+	  Date:   Mon Nov 22 15:16:27 2021 +0000
+
+	      gdb/remote: use scoped_restore to control starting_up flag
+
+	introduced a use after free bug.  The scoped restore added in the
+	above commit resets a flag within a remote_target's remote_state
+	object.
+
+	However, in some situations, the remote_target can be unpushed before
+	the error is thrown.  If the only reference to the target is the one
+	in the target stack, then unpushing the target will cause the
+	remote_target to be deleted, which, in turn, will delete the
+	remote_state object.  The scoped restore will then try to reset the
+	flag within a deleted object.
+
+	This problem was caught in the gdb.server/server-connect.exp test,
+	which, when run with the address sanitizer enabled, highlights the
+	write after free bug described above.
+
+	This commit resolves this issue by adding a new class specifically for
+	the purpose of managing the starting_up flag.  As well as setting, and
+	then clearing the starting_up flag, this new class increments, and
+	then decrements the reference count on the remote_target object.  This
+	prevents the remote_target from being deleted until after the flag has
+	been reset.
+
+	The gdb.server/server-connect.exp now runs cleanly with the address
+	sanitizer enabled.
+
+2021-12-03  Mike Frysinger  <vapier@gentoo.org>
+
+	libctf: workaround automake bug with conditional info pages
+	It looks like automake makes assumptions about its ability to build info
+	pages based on the GNU standard behavior of shipping info pages with the
+	distributions.  So even though the info pages were conditionalized, and
+	automake disabled some of the targets, it was still creeping in by way
+	of unconditional INFO_DEPS settings.
+
+	We can workaround this by adding a stub target for the info page when
+	building info pages are disabled.  This tricks automake into disabling
+	its own extended generation target.  I'll follow up with the automake
+	folks to see what they think.
+
+2021-12-03  Chenghua Xu  <xuchenghua@loongson.cn>
+
+	Add myself and Zhensong Liu as the LoongArch port maintainer.
+
+2021-12-03  Alan Modra  <amodra@gmail.com>
+
+	Revert "Re: Don't compile some opcodes files when bfd is 32-bit only"
+	This reverts commit 7a53275579e7cec9389ccb924f5ecf69e8d89d41.
+	The bpf sim doesn't work with a 32-bit bfd after all.
+
+2021-12-03  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-02  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove unexpected xstrdup in _initialize_maint_test_settings
+	That xstrdup is not correct, since we are assigning an std::string.  The
+	result of xstrdup is used to initialize the string, and then lost
+	forever.  Remove it.
+
+	Change-Id: Ief7771055e4bfd643ef3b285ec9fb7b1bfd14335
+
+2021-12-02  Nick Clifton  <nickc@redhat.com>
+
+	Fix illegal memory access whilst parsing corrupt DWARF debug information.
+		PR 28645
+		* dwarf.c (process_cu_tu_index): Add test for overruning section
+		whilst processing slots.
+
+2021-12-02  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/tdep] Fix avx512 -m32 support in gdbserver
+	PR27257 reports a problem that can be reproduced as follows:
+	- use x86_64 machine with avx512 support
+	- compile a hello world with -m32 to a.out
+	- start a gdbserver session with a.out
+	- use gdb to connect to the gdbserver session
+
+	This makes us run into:
+	...
+	Listening on port 2346
+	Remote debugging from host ::1, port 34940
+	src/gdbserver/regcache.cc:257: \
+	  A problem internal to GDBserver has been detected.
+	Unknown register zmm16h requested
+	...
+
+	The problem is that i387_xsave_to_cache in gdbserver/i387-fp.cc can't find a
+	register zmm16h in the register cache.
+
+	To understand how this happens, first some background.
+
+	SSE has 16 128-bit wide xmm registers.
+
+	AVX extends the SSE registers set as follows:
+	- it extends the 16 existing 128-bit wide xmm registers to 256-bit wide ymm
+	  registers.
+
+	AVX512 extends the AVX register set as follows:
+	- it extends the 16 existing 256-bit wide ymm registers to 512-bit wide zmm
+	  registers.
+	- it adds 16 additional 512-bit wide zmm registers (with corresponding ymm and
+	  xmm subregisters added as well)
+
+	However, in 32-bit mode, there are only 8 xmm/ymm/zmm registers.
+
+	The problem we're running into is that gdbserver/i387-fp.cc uses these
+	constants to describe the size of the register file:
+	...
+	static const int num_avx512_zmmh_low_registers = 16;
+	static const int num_avx512_zmmh_high_registers = 16;
+	static const int num_avx512_ymmh_registers = 16;
+	static const int num_avx512_xmm_registers = 16;
+	...
+	which are all incorrect for the 32-bit case.
+
+	Fix this by replacing the constants with variables that have the appropriate
+	values in 64-bit and 32-bit mode.
+
+	Tested on x86_64-linux with native and unix/-m32.
+
+2021-12-02  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/testsuite: update tests looking for "DWARF 2" debug format
+	Commit ab557072b8ec ("gdb: use actual DWARF version in compunit's
+	debugformat field") changes the debug format string in "info source" to
+	show the actual DWARF version, rather than always show "DWARF 2".
+
+	However, it failed to consider that some tests checked for the "DWARF 2"
+	string to see if the test program is compiled with DWARF debug
+	information.  Since everything is compiled with DWARF 4 or 5 nowadays,
+	that changed the behavior of those tests.  Notably, it prevent the
+	tests using skip_inline_var_tests to run.
+
+	Grep through the testsuite for "DWARF 2" and change all occurrences I
+	could find to use "DWARF [0-9]" instead (that string is passed to TCL's
+	string match).
+
+	Change-Id: Ic7fb0217fb9623880c6f155da6becba0f567a885
+
+2021-12-02  Joel Brobecker  <brobecker@adacore.com>
+
+	(PPC64) fix handling of fixed-point values when using "return" command
+	In the gdb.ada/fixed_points_function.exp testcase, we have the following
+	Ada code...
+
+	   type FP1_Type is delta 0.1 range -1.0 .. +1.0; --  Ordinary
+	   function Call_FP1 (F : FP1_Type) return FP1_Type is
+	   begin
+	      FP1_Arg := F;
+	      return FP1_Arg;
+	   end Call_FP1;
+
+	... used as follow:
+
+	   F1 : FP1_Type := 1.0;
+	   F1 := Call_FP1 (F1);
+
+	The testcase, among other things, verifies that "return" works
+	properly as follow:
+
+	    | (gdb) return 1.0
+	    | Make pck.call_fp1 return now? (y or n) y
+	    | [...]
+	    | 9          F1 := Call_FP1 (F1);
+	    | (gdb) next
+	    | (gdb) print f1
+	    | $1 = 0.0625
+
+	The output of the last command shows that we returned the wrong
+	value. The value printed gives a clue about the problem, since
+	it is 1/16th of the value we expected, where 1/16 is FP1_Type's
+	scaling factor.
+
+	The problem, here, comes from the fact that the function
+	handling return values for base types (ppc64_sysv_abi_return_value_base)
+	writes the return value using unpack_long which, upon seeing that
+	the value being unpacked is a fixed point type, applies the scaling
+	factor, to get the integer-representation of our fixed-point value
+	(similar to what it does with floats, for instance).
+
+	So, the fix consists in teaching ppc64_sysv_abi_return_value_base
+	about fixed-point types, and to avoid the unwanted application
+	of the scaling factor.
+
+	Note that the "finish" function, on the other hand, does not
+	suffer from this issue, simply becaue the value returned by
+	the function is read from register without the use of a type,
+	thus avoiding an unwanted application of a scaling factor.
+
+	No test added, as this change is already tested by
+	gdb.ada/fixed_points_function.exp.
+
+	Co-Authored-By: Tristan Gingold <gingold@adacore.com>
+
+2021-12-02  Joel Brobecker  <brobecker@adacore.com>
+
+	(RISCV) fix handling of fixed-point type return values
+	This commit adds support for TYPE_CODE_FIXED_POINT types for
+	"finish" and "return" commands.
+
+	Consider the following Ada code...
+
+	   type FP1_Type is delta 0.1 range -1.0 .. +1.0; --  Ordinary
+	   function Call_FP1 (F : FP1_Type) return FP1_Type is
+	   begin
+	      FP1_Arg := F;
+	      return FP1_Arg;
+	   end Call_FP1;
+
+	... used as follow:
+
+	   F1 : FP1_Type := 1.0;
+	   F1 := Call_FP1 (F1);
+
+	"finish" currently behaves as follow:
+
+	    | (gdb) finish
+	    | [...]
+	    | Value returned is $1 = 0
+
+	We expect the returned value to be "1".
+
+	Similarly, "return" makes the function return the wrong value:
+
+	    | (gdb) return 1.0
+	    | Make pck.call_fp1 return now? (y or n) y
+	    | [...]
+	    | 9          F1 := Call_FP1 (F1);
+	    | (gdb) next
+	    | (gdb) print f1
+	    | $1 = 0.0625
+
+	(we expect it to print "1" instead).
+
+	This problem comes from the handling of integral return values
+	when the return value is actually fixed point type. Our type
+	here is actually a range of a fixed point type, but the same
+	principles should also apply to pure fixed-point types. For
+	the record, here is what the debugging info looks like:
+
+	 <1><238>: Abbrev Number: 2 (DW_TAG_subrange_type)
+	    <239>   DW_AT_lower_bound : -16
+	    <23a>   DW_AT_upper_bound : 16
+	    <23b>   DW_AT_name        : pck__fp1_type
+	    <23f>   DW_AT_type        : <0x248>
+
+	 <1><248>: Abbrev Number: 4 (DW_TAG_base_type)
+	    <249>   DW_AT_byte_size   : 1
+	    <24a>   DW_AT_encoding    : 13      (signed_fixed)
+	    <24b>   DW_AT_binary_scale: -4
+	    <24c>   DW_AT_name        : pck__Tfp1_typeB
+	    <250>   DW_AT_artificial  : 1
+
+	... where the scaling factor is 1/16.
+
+	Looking at the "finish" command, what happens is that riscv_arg_location
+	determines that our return value should be returned by parameter using
+	an integral convention (via builtin type long). And then,
+	riscv_return_value uses a cast to that builtin type long to
+	store the value of into a buffer with the right register size.
+	This doesn't work in our case, because the underlying value
+	returned by the function is unscaled, which means it is 16,
+	and thus the cast is like doing:
+
+	   arg_val = (FP1_Type) 16
+
+	... In other words, it is trying to create an FP1_Type enty whose
+	value is 16. Applying the scaling factor, that's 256, and because
+	the size of FP1_Type is 1 byte, we overflow and thus it ends up
+	being zero.
+
+	The same happen with the "return" function, but the other way around.
+
+	The fix consists in handling fixed-point types separately from
+	integral types.
+
+2021-12-02  Joel Brobecker  <brobecker@adacore.com>
+
+	(ARM/fixed-point) wrong value shown by "finish" command:
+	Consider the following Ada code:
+
+	   type FP1_Type is delta 0.1 range -1.0 .. +1.0; --  Ordinary
+	   FP1_Arg : FP1_Type := 0.0;
+
+	   function Call_FP1 (F : FP1_Type) return FP1_Type is
+	   begin
+	      FP1_Arg := F;
+	      return FP1_Arg;
+	   end Call_FP1;
+
+	After having stopped inside function Call_FP1 as follow:
+
+	    Breakpoint 1, pck.call_fp1 (f=1) at /[...]/pck.adb:5
+	    5             FP1_Arg := F;
+
+	Returning from that function call using "finish" should show
+	that the function return "1.0" (the same value as was passed
+	as an argument). However, this is not the case:
+
+	    (gdb) finish
+	    Run till exit from #0  pck.call_fp1 (f=1)
+	    [...]
+	    9          F1 := Call_FP1 (F1);
+	    Value returned is $1 = 0
+
+	This patch enhances the extraction of the return value to know about
+	fixed point types.
+
+2021-12-02  Xavier Roirand  <roirand@adacore.com>
+
+	(Ada/AArch64) fix fixed point argument passing in inferior funcall
+	Consider the following code:
+
+	   type FP1_Type is delta 0.1 range -1.0 .. +1.0; --  Ordinary
+
+	   function Call_FP1 (F : FP1_Type) return FP1_Type is
+	   begin
+	      return F;
+	   end Call_FP1;
+
+	When the default in GCC is to generate proper DWARF info for fixed point
+	types, then in gdb, printing the result of a call to call_fp1 with a
+	decimal parameter leads to:
+
+	  (gdb) p call_fp1(0.5)
+	  $1 = 0
+
+	The displayed value is wrong, and we actually expected:
+
+	  (gdb) p call_fp1(0.5)
+	  $1 = 0.5
+
+	What happened is that our fixed point type parameter got promoted to a
+	32bit integer because we detected that the length of that object was less
+	than 4 bytes. The compiler does not perform this promotion and therefore
+	GDB should not either.
+
+	This patch fixes the behavior described above.
+
+2021-12-02  Tom Tromey  <tromey@adacore.com>
+
+	Implement 'task apply'
+	This adds a 'task apply' command, which is the Ada tasking analogue of
+	'thread apply'.  Unlike 'thread apply', it doesn't offer the
+	'ascending' flag; but otherwise it's essentially the same.
+
+	Add "task" keyword to the "watch" command
+	Breakpoints in gdb can be made specific to an Ada task using the
+	"task" qualifier.  This patch applies this same idea to watchpoints.
+
+2021-12-02  Richard Sandiford  <richard.sandiford@arm.com>
+
+	aarch64: Update gas/NEWS for recent changes
+	gas/
+		* NEWS: Mention support for Armv8.8-A and for new system registers.
+
+2021-12-02  Richard Sandiford  <richard.sandiford@arm.com>
+
+	aarch64: Add BC instruction
+	This patch adds support for the Armv8.8-A BC instruction.
+	[https://developer.arm.com/documentation/ddi0596/2021-09/Base-Instructions/BC-cond--Branch-Consistent-conditionally-?lang=en]
+
+	include/
+		* opcode/aarch64.h (AARCH64_FEATURE_HBC): New macro.
+		(AARCH64_ARCH_V8_8): Make armv8.8-a imply AARCH64_FEATURE_HBC.
+
+	opcodes/
+		* aarch64-tbl.h (aarch64_feature_hbc): New variable.
+		(HBC, HBC_INSN): New macros.
+		(aarch64_opcode_table): Add BC.C.
+		* aarch64-dis-2.c: Regenerate.
+
+	gas/
+		* doc/c-aarch64.texi: Document +hbc.
+		* config/tc-aarch64.c (aarch64_features): Add "hbc".
+		* testsuite/gas/aarch64/hbc.s, testsuite/gas/aarch64/hbc.d: New test.
+		* testsuite/gas/aarch64/hbc-invalid.s,
+		testsuite/gas/aarch64/hbc-invalid.l,
+		testsuite/gas/aarch64/hbc-invalid.d: New test.
+
+2021-12-02  Richard Sandiford  <richard.sandiford@arm.com>
+
+	aarch64: Enforce P/M/E order for MOPS instructions
+	The MOPS instructions should be used as a triple, such as:
+
+	       cpyfp [x0]!, [x1]!, x2!
+	       cpyfm [x0]!, [x1]!, x2!
+	       cpyfe [x0]!, [x1]!, x2!
+
+	The registers should also be the same for each writeback operand.
+	This patch adds a warning for code that doesn't follow this rule,
+	along similar lines to the warning that we already emit for
+	invalid uses of MOVPRFX.
+
+	include/
+		* opcode/aarch64.h (C_SCAN_MOPS_P, C_SCAN_MOPS_M, C_SCAN_MOPS_E)
+		(C_SCAN_MOPS_PME): New macros.
+		(AARCH64_OPDE_A_SHOULD_FOLLOW_B): New aarch64_operand_error_kind.
+		(AARCH64_OPDE_EXPECTED_A_AFTER_B): Likewise.
+		(aarch64_operand_error): Make each data value a union between
+		an int and a string.
+
+	opcodes/
+		* aarch64-tbl.h (MOPS_CPY_OP1_OP2_INSN): Add scan flags.
+		(MOPS_SET_OP1_OP2_INSN): Likewise.
+		* aarch64-opc.c (set_out_of_range_error): Update after change to
+		aarch64_operand_error.
+		(set_unaligned_error, set_reg_list_error): Likewise.
+		(init_insn_sequence): Use a 3-instruction sequence for
+		MOPS P instructions.
+		(verify_mops_pme_sequence): New function.
+		(verify_constraints): Call it.
+		* aarch64-dis.c (print_verifier_notes): Handle
+		AARCH64_OPDE_A_SHOULD_FOLLOW_B and AARCH64_OPDE_EXPECTED_A_AFTER_B.
+
+	gas/
+		* config/tc-aarch64.c (operand_mismatch_kind_names): Add entries
+		for AARCH64_OPDE_A_SHOULD_FOLLOW_B and AARCH64_OPDE_EXPECTED_A_AFTER_B.
+		(operand_error_higher_severity_p): Check that
+		AARCH64_OPDE_A_SHOULD_FOLLOW_B and AARCH64_OPDE_EXPECTED_A_AFTER_B
+		come between AARCH64_OPDE_RECOVERABLE and AARCH64_OPDE_SYNTAX_ERROR;
+		their relative order is not significant.
+		(record_operand_error_with_data): Update after change to
+		aarch64_operand_error.
+		(output_operand_error_record): Likewise.  Handle
+		AARCH64_OPDE_A_SHOULD_FOLLOW_B and AARCH64_OPDE_EXPECTED_A_AFTER_B.
+		* testsuite/gas/aarch64/mops_invalid_2.s,
+		testsuite/gas/aarch64/mops_invalid_2.d,
+		testsuite/gas/aarch64/mops_invalid_2.l: New test.
+
+2021-12-02  Richard Sandiford  <richard.sandiford@arm.com>
+
+	aarch64: Add support for +mops
+	This patch adds support for FEAT_MOPS, an Armv8.8-A extension
+	that provides memcpy and memset acceleration instructions.
+
+	I took the perhaps controversial decision to generate the individual
+	instruction forms using macros rather than list them out individually.
+	This becomes useful with a follow-on patch to check that code follows
+	the correct P/M/E sequence.
+	[https://developer.arm.com/documentation/ddi0596/2021-09/Base-Instructions?lang=en]
+
+	include/
+		* opcode/aarch64.h (AARCH64_FEATURE_MOPS): New macro.
+		(AARCH64_ARCH_V8_8): Make armv8.8-a imply AARCH64_FEATURE_MOPS.
+		(AARCH64_OPND_MOPS_ADDR_Rd): New aarch64_opnd.
+		(AARCH64_OPND_MOPS_ADDR_Rs): Likewise.
+		(AARCH64_OPND_MOPS_WB_Rn): Likewise.
+
+	opcodes/
+		* aarch64-asm.h (ins_x0_to_x30): New inserter.
+		* aarch64-asm.c (aarch64_ins_x0_to_x30): New function.
+		* aarch64-dis.h (ext_x0_to_x30): New extractor.
+		* aarch64-dis.c (aarch64_ext_x0_to_x30): New function.
+		* aarch64-tbl.h (aarch64_feature_mops): New feature set.
+		(aarch64_feature_mops_memtag): Likewise.
+		(MOPS, MOPS_MEMTAG, MOPS_INSN, MOPS_MEMTAG_INSN)
+		(MOPS_CPY_OP1_OP2_PME_INSN, MOPS_CPY_OP1_OP2_INSN, MOPS_CPY_OP1_INSN)
+		(MOPS_CPY_INSN, MOPS_SET_OP1_OP2_PME_INSN, MOPS_SET_OP1_OP2_INSN)
+		(MOPS_SET_INSN): New macros.
+		(aarch64_opcode_table): Add MOPS instructions.
+		(aarch64_opcode_table): Add entries for AARCH64_OPND_MOPS_ADDR_Rd,
+		AARCH64_OPND_MOPS_ADDR_Rs and AARCH64_OPND_MOPS_WB_Rn.
+		* aarch64-opc.c (aarch64_print_operand): Handle
+		AARCH64_OPND_MOPS_ADDR_Rd, AARCH64_OPND_MOPS_ADDR_Rs and
+		AARCH64_OPND_MOPS_WB_Rn.
+		(verify_three_different_regs): New function.
+		* aarch64-asm-2.c: Regenerate.
+		* aarch64-dis-2.c: Likewise.
+		* aarch64-opc-2.c: Likewise.
+
+	gas/
+		* doc/c-aarch64.texi: Document +mops.
+		* config/tc-aarch64.c (parse_x0_to_x30): New function.
+		(parse_operands): Handle AARCH64_OPND_MOPS_ADDR_Rd,
+		AARCH64_OPND_MOPS_ADDR_Rs and AARCH64_OPND_MOPS_WB_Rn.
+		(aarch64_features): Add "mops".
+		* testsuite/gas/aarch64/mops.s, testsuite/gas/aarch64/mops.d: New test.
+		* testsuite/gas/aarch64/mops_invalid.s,
+		* testsuite/gas/aarch64/mops_invalid.d,
+		* testsuite/gas/aarch64/mops_invalid.l: Likewise.
+
+2021-12-02  Richard Sandiford  <richard.sandiford@arm.com>
+
+	aarch64: Add Armv8.8-A system registers
+	Armv8.8-A defines two new system registers: allint and icc_nmiar1_el1.
+	Both of them were previously unmapped.  allint supports a 0/1 immediate.
+	[https://developer.arm.com/documentation/ddi0595/2021-09/AArch64-Registers/ALLINT--All-Interrupt-Mask-Bit?lang=en]
+	[https://developer.arm.com/documentation/ddi0595/2021-09/AArch64-Registers/ICC-NMIAR1-EL1--Interrupt-Controller-Non-maskable-Interrupt-Acknowledge-Register-1?lang=en]
+
+	opcodes/
+		* aarch64-opc.c (SR_V8_8): New macro.
+		(aarch64_sys_regs): Add allint and icc_nmiar1_el1.
+		(aarch64_pstatefields): Add allint.
+
+	gas/
+		* testsuite/gas/aarch64/armv8_8-a-sysregs.s,
+		* testsuite/gas/aarch64/armv8_8-a-sysregs.d: New test.
+		* testsuite/gas/aarch64/armv8_8-a-sysregs-invalid.s,
+		* testsuite/gas/aarch64/armv8_8-a-sysregs-invalid.l,
+		* testsuite/gas/aarch64/armv8_8-a-sysregs-invalid.d: New test.
+
+2021-12-02  Richard Sandiford  <richard.sandiford@arm.com>
+
+	aarch64: Add id_aa64isar2_el1
+	Armv8.8-A defines a read-only system register called id_aa64isar2_el1.
+	The register was previously RES0 and should therefore be accepted
+	at all architecture levels.
+	[https://developer.arm.com/documentation/ddi0595/2021-09/AArch64-Registers/ID-AA64ISAR2-EL1--AArch64-Instruction-Set-Attribute-Register-2?lang=en]
+
+	opcodes/
+		* aarch64-opc.c (aarch64_sys_regs): Add id_aa64isar2_el1.
+
+	gas/
+		* testsuite/gas/aarch64/sysreg-diagnostic.s: Test writes to
+		id_aa64isar2_el1.
+		* testsuite/gas/aarch64/sysreg-diagnostic.d: Update accordingly.
+		* testsuite/gas/aarch64/sysreg-diagnostic.l: Likewise.
+		* testsuite/gas/aarch64/sysreg.s: Test reads from
+		id_aa64isar2_el1.
+		* testsuite/gas/aarch64/sysreg.d: Update accordingly.
+
+2021-12-02  Richard Sandiford  <richard.sandiford@arm.com>
+
+	aarch64: Add support for Armv8.8-A
+	This patch adds skeleton support for -march=armv8.8-a, testing only
+	that it correctly inherits from armv8.7-a.
+
+	include/
+		* opcode/aarch64.h (AARCH64_FEATURE_V8_8): New macro.
+		(AARCH64_ARCH_V8_8): Likewise.
+
+	gas/
+		* doc/c-aarch64.texi: Document armv8.8-a.
+		* config/tc-aarch64.c (aarch64_archs): Add armv8-8-a
+		* testsuite/gas/aarch64/v8-8-a.s,
+		* testsuite/gas/aarch64/v8-8-a.d: New test.
+
+2021-12-02  Richard Sandiford  <richard.sandiford@arm.com>
+
+	aarch64: Provide line info for unclosed sequences
+	We warn about MOVPRFX instructions that have no following
+	instruction.  This patch adds a line number to the message,
+	which is useful if the assembly code has multiple text sections.
+
+	The new code is unconditional since OBJ_ELF is always defined
+	for aarch64.
+
+	gas/
+		* config/tc-aarch64.h (aarch64_segment_info_type): Add last_file
+		and last_line.
+		* config/tc-aarch64.c (now_instr_sequence): Delete.
+		(force_automatic_sequence_close): Provide a line number when
+		reporting unclosed sequences.
+		(md_assemble): Record the location of the instruction in
+		tc_segment_info.
+		* testsuite/gas/aarch64/sve-movprfx_4.l: Add line number to error
+		message.
+		* testsuite/gas/aarch64/sve-movprfx_7.l: Likewise.
+		* testsuite/gas/aarch64/sve-movprfx_8.l: Likewise.
+
+2021-12-02  Richard Sandiford  <richard.sandiford@arm.com>
+
+	aarch64: Tweak insn sequence code
+	libopcodes has some code to check constraints across sequences
+	of consecutive instructions.  It was added to support MOVPRFX
+	sequences but is going to be useful for the Armv8.8-A MOPS
+	feature as well.
+
+	Currently the structure has one field to record the instruction
+	that started a sequence and another to record the remaining
+	instructions in the sequence.  It's more convenient for the
+	MOPS code if we put the instructions into a single array instead.
+
+	No functional change intended.
+
+	include/
+		* opcode/aarch64.h (aarch64_instr_sequence): Replace num_insns
+		and current_insns with num_added_insns and num_allocated_insns.
+
+	opcodes/
+		* aarch64-opc.c (add_insn_to_sequence): New function.
+		(init_insn_sequence): Update for new aarch64_instr_sequence layout.
+		Add the first instruction to the inst array.
+		(verify_constraints): Update for new aarch64_instr_sequence layout.
+		Don't add the last instruction to the array.
+
+2021-12-02  Richard Sandiford  <richard.sandiford@arm.com>
+
+	aarch64: Add maximum immediate value to aarch64_sys_reg
+	The immediate form of MSR has a 4-bit immediate field (in CRm).
+	However, many forms of MSR require a smaller immediate.  These cases
+	are identified by value in operand_general_constraint_met_p,
+	but they're now the common case rather than the exception.
+
+	This patch therefore adds the maximum value to the sys_reg
+	description and gets the range from there.  It also enforces
+	the minimum of 0, which avoids a situation in which:
+
+	  msr dit, #2
+
+	would give the expected:
+
+	  Error: immediate value out of range 0 to 1
+
+	whereas:
+
+	  msr dit, #-1
+
+	would give:
+
+	  Error: immediate value out of range 0 to 15
+
+	(from the later UIMM4 checking).
+
+	Also:
+
+	- we were reporting the first error above against the wrong operand
+	- TCO takes a single-bit immediate, but we previously allowed
+	  all 16 values.
+	  [https://developer.arm.com/documentation/ddi0596/2021-09/Base-Instructions/MSR--immediate---Move-immediate-value-to-Special-Register-?lang=en]
+
+	opcodes/
+		* aarch64-opc.h (F_REG_MAX_VALUE, F_GET_REG_MAX_VALUE): New macros.
+		* aarch64-opc.c (operand_general_constraint_met_p): Read the
+		maximum MSR immediate value from aarch64_pstatefields.
+		(aarch64_pstatefields): Add the maximum immediate value
+		for each register.
+
+	gas/
+		* testsuite/gas/aarch64/sysreg-4.s: Use an immediate value of 1
+		rather than 8 for the TCO test.
+		* testsuite/gas/aarch64/sysreg-4.d: Update accordingly.
+		* testsuite/gas/aarch64/armv8_2-a-illegal.l: Fix operand number
+		in MSR immediate error messages.
+		* testsuite/gas/aarch64/diagnostic.l: Likewise.
+		* testsuite/gas/aarch64/pan-illegal.l: Likewise.
+		* testsuite/gas/aarch64/ssbs-illegal1.l: Likewise.
+		* testsuite/gas/aarch64/illegal-sysreg-4b.s,
+		* testsuite/gas/aarch64/illegal-sysreg-4b.d,
+		* testsuite/gas/aarch64/illegal-sysreg-4b.l: New test.
+
+2021-12-02  Marcus Nilsson  <brainbomb@gmail.com>
+
+	Allow the --visualize-jumps feature to work with the AVR disassembler.
+		* avr-dis.c (avr_operand); Pass in disassemble_info and fill
+		in insn_type on branching instructions.
+
+2021-12-02  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb, include: replace pragmas with DIAGNOSTIC macros, fix build with g++ 4.8
+	When introducing this code, I forgot that we had some macros for this.
+	Replace some "manual" pragma diagnostic with some DIAGNOSTIC_* macros,
+	provided by include/diagnostics.h.
+
+	In diagnostics.h:
+
+	 - Add DIAGNOSTIC_ERROR, to enable a diagnostic at error level.
+	 - Add DIAGNOSTIC_ERROR_SWITCH, to enable -Wswitch at error level, for
+	   both gcc and clang.
+
+	Additionally, using DIAGNOSTIC_PUSH, DIAGNOSTIC_ERROR_SWITCH and
+	DIAGNOSTIC_POP seems to misbehave with g++ 4.8, where we see these
+	errors:
+
+	      CXX    ada-tasks.o
+	    /home/smarchi/src/binutils-gdb/gdb/ada-tasks.c: In function void read_known_tasks():
+	    /home/smarchi/src/binutils-gdb/gdb/ada-tasks.c:998:10: error: enumeration value ADA_TASKS_UNKNOWN not handled in switch [-Werror=switch]
+	       switch (data->known_tasks_kind)
+	              ^
+
+	Because of the POP, the diagnostic should go back to being disabled,
+	since it was disabled in the beginning, but that's not what we see
+	here.  Versions of GCC >= 5 compile correctly.
+
+	Work around this by making DIAGNOSTIC_ERROR_SWITCH a no-op for GCC < 5.
+
+	Note that this code (already as it exists in master today) enables
+	-Wswitch at the error level even if --disable-werror is passed.  It
+	shouldn't be a problem, as it's not like a new enumerator will appear
+	out of nowhere and cause a build error if building with future
+	compilers.  Still, for correctness, we would ideally want to ask the
+	compiler to enable -Wswitch at its default level (as if the user had
+	passed -Wswitch on the command-line).  There doesn't seem to be a way to
+	do this.
+
+	Change-Id: Id33ebec3de39bd449409ea0bab59831289ffe82d
+
+2021-12-02  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gas: re-generate configure
+	When configuring gas, I get:
+
+	  config.status: error: cannot find input file: `doc/Makefile.in'
+
+	This is because configure is out-of-date, re-generate it.
+
+	Change-Id: Iaa5980c282900d9fd23b90f0df25bf8ba3676498
+
+2021-12-02  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	libctf: re-generate configure
+	When configuring libctf, I get:
+
+	  config.status: error: cannot find input file: `doc/Makefile.in'
+
+	This is because configure is out-of-date, re-generate it.
+
+	Change-Id: Ie69acd33012211a4620661582c7d24ad6d2cd169
+
+2021-12-02  H.J. Lu  <hjl.tools@gmail.com>
+
+	x86: Skip __[start|stop]_SECNAME for --gc-sections -z start-stop-gc
+	Don't convert memory load to immediate load on __start_SECNAME and
+	__stop_SECNAME for --gc-sections -z start-stop-gc if all SECNAME
+	sections been garbage collected.
+
+	bfd/
+
+		PR ld/27491
+		* elf32-i386.c (elf_i386_convert_load_reloc): Skip __start_SECNAME
+		and __stop_SECNAME for --gc-sections -z start-stop-gc if the input
+		section been garbage collected.
+		* elf64-x86-64.c (elf_x86_64_convert_load_reloc): Likewise.
+		* elfxx-x86.h (elf_x86_start_stop_gc_p): New function.
+
+	ld/
+		PR ld/27491
+		* testsuite/ld-i386/i386.exp: Run PR ld/27491 tests.
+		* testsuite/ld-x86-64/x86-64.exp: Likewise.
+		* testsuite/ld-i386/pr27491-1.s: New file.
+		* testsuite/ld-i386/pr27491-1a.d: Likewise.
+		* testsuite/ld-i386/pr27491-1b.d: Likewise.
+		* testsuite/ld-i386/pr27491-1c.d: Likewise.
+		* testsuite/ld-i386/pr27491-2.d: Likewise.
+		* testsuite/ld-i386/pr27491-2.s: Likewise.
+		* testsuite/ld-i386/pr27491-3.d: Likewise.
+		* testsuite/ld-i386/pr27491-3.s: Likewise.
+		* testsuite/ld-i386/pr27491-4.d: Likewise.
+		* testsuite/ld-i386/pr27491-4a.s: Likewise.
+		* testsuite/ld-i386/pr27491-4b.s: Likewise.
+		* testsuite/ld-x86-64/pr27491-1.s: Likewise.
+		* testsuite/ld-x86-64/pr27491-1a.d: Likewise.
+		* testsuite/ld-x86-64/pr27491-1b.d: Likewise.
+		* testsuite/ld-x86-64/pr27491-1c.d: Likewise.
+		* testsuite/ld-x86-64/pr27491-2.d: Likewise.
+		* testsuite/ld-x86-64/pr27491-2.s: Likewise.
+		* testsuite/ld-x86-64/pr27491-3.d: Likewise.
+		* testsuite/ld-x86-64/pr27491-3.s: Likewise.
+		* testsuite/ld-x86-64/pr27491-4.d: Likewise.
+		* testsuite/ld-x86-64/pr27491-4a.s: Likewise.
+		* testsuite/ld-x86-64/pr27491-4b.s: Likewise.
+
+2021-12-02  Mike Frysinger  <vapier@gentoo.org>
+
+	bfd: delete unused proto settings
+	These have been around for decades but don't appear to be used, and
+	trying to build them (e.g. `make archive.p archive.ip`) doesn't work,
+	so just delete it all.
+
+	gas: merge doc subdir up a level
+	This avoids a recursive make into the doc subdir and speeds up the
+	build slightly.  It also allows for more parallelism.
+
+	libctf: merge doc subdir up a level
+	This avoids a recursive make into the doc subdir and speeds up the
+	build slightly.  It also allows for more parallelism.
+
+2021-12-02  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: use actual DWARF version in compunit's debugformat field
+	The "info source" command, with a DWARF-compile program, always show
+	that the debug info is "DWARF 2":
+
+	    (gdb) info source
+	    Current source file is test.c
+	    Compilation directory is /home/smarchi/build/binutils-gdb/gdb
+	    Located in /home/smarchi/build/binutils-gdb/gdb/test.c
+	    Contains 2 lines.
+	    Source language is c.
+	    Producer is GNU C17 9.3.0 -mtune=generic -march=x86-64 -g3 -gdwarf-5 -O0 -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection -fcf-protection.
+	    Compiled with DWARF 2 debugging format.
+	    Includes preprocessor macro info.
+
+	Change it to display the actual DWARF version:
+
+	    (gdb) info source
+	    Current source file is test.c
+	    Compilation directory is /home/smarchi/build/binutils-gdb/gdb
+	    Located in /home/smarchi/build/binutils-gdb/gdb/test.c
+	    Contains 2 lines.
+	    Source language is c.
+	    Producer is GNU C17 9.3.0 -mtune=generic -march=x86-64 -g3 -gdwarf-5 -O0 -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection -fcf-protection.
+	    Compiled with DWARF 5 debugging format.
+	    Includes preprocessor macro info.
+
+	The comp_unit_head::version field is guaranteed to be between 2 and 5,
+	thanks to the check in read_comp_unit_head.  So we can still use static
+	strings to pass to record_debugformat, and keep it efficient.
+
+	In the future, when somebody will update GDB to support DWARF 6, they'll
+	hit this assert and have to update this code.
+
+	Change-Id: I3270b7ebf5e9a17b4215405bd2e365662a4d6172
+
+2021-12-02  H.J. Lu  <hjl.tools@gmail.com>
+
+	elf: Discard input .note.gnu.build-id sections
+	1. Discard input .note.gnu.build-id sections.
+	2. Clear the build ID field before writing.
+	3. Use bfd_make_section_anyway_with_flags to create the output
+	.note.gnu.build-id section.
+
+		PR ld/28639
+		* ldelf.c (ldelf_after_open): Discard input .note.gnu.build-id
+		sections, excluding the first one.
+		(write_build_id): Clear the build ID field before writing.
+		(ldelf_setup_build_id): Use bfd_make_section_anyway_with_flags
+		to create the output .note.gnu.build-id section.
+		* testsuite/ld-elf/build-id.exp: New file.
+		* testsuite/ld-elf/pr28639a.rd: Likewise.
+		* testsuite/ld-elf/pr28639b.rd: Likewise.
+		* testsuite/ld-elf/pr28639c.rd: Likewise.
+		* testsuite/ld-elf/pr28639d.rd: Likewise.
+
+2021-12-02  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-12-01  Mike Frysinger  <vapier@gentoo.org>
+
+	binutils: add missing prefix for binutils/index.html rule
+
+2021-12-01  Luca Boccassi  <luca.boccassi@gmail.com>
+
+	readelf: recognize FDO Packaging Metadata ELF note.  (Correcting snafu during patch application)
+
+2021-12-01  Luca Boccassi  <luca.boccassi@gmail.com>
+
+	readelf: recognize FDO Packaging Metadata ELF note
+	As defined on: https://systemd.io/COREDUMP_PACKAGE_METADATA/
+	this note will be used starting from Fedora 36. Allow
+	readelf --notes to pretty print it:
+
+	Displaying notes found in: .note.package
+	  Owner                Data size 	Description
+	  FDO                  0x00000039	FDO_PACKAGING_METADATA
+	    Packaging Metadata: {"type":"deb","name":"fsverity-utils","version":"1.3-1"}
+
+2021-12-01  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix typo in gdb.multi/multi-arch-exec.exp
+	With gdb.multi/multi-arch-exec.exp I run into:
+	...
+	Running src/gdb/testsuite/gdb.multi/multi-arch-exec.exp ...
+	ERROR: tcl error sourcing src/gdb/testsuite/gdb.multi/multi-arch-exec.exp.
+	ERROR: wrong # args: extra words after "else" clause in "if" command
+	    while executing
+	"if [istarget "powerpc64*-*-*"] {
+	        set march "-m64"
+	    } else if [istarget "s390*-*-*"] {
+	        set march "-m31"
+	    } else {
+	        set march "-m32"
+	    }"
+	...
+
+	Fix the else if -> elseif typo.
+
+	Tested on x86_64-linux.
+
+2021-12-01  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.arch/i386-pkru.exp on linux
+	When running test-case gdb.arch/i386-pkru.exp on a machine with "Memory
+	Protection Keys for Userspace" support, we run into:
+	...
+	(gdb) PASS: gdb.arch/i386-pkru.exp: probe PKRU support
+	print $pkru^M
+	$2 = 1431655764^M
+	(gdb) FAIL: gdb.arch/i386-pkru.exp: pkru register
+	...
+
+	The test-case expects the $pkru register to have the default value 0, matching
+	the "init state" of 0 defined by the XSAVE hardware.
+
+	Since linux kernel version v4.9 containing commit acd547b29880 ("x86/pkeys:
+	Default to a restrictive init PKRU"), the register is set to 0x55555554 by
+	default (which matches the printed decimal value above).
+
+	Fix the FAIL by accepting this value for linux.
+
+	Tested on x86_64-linux.
+
+2021-12-01  Nick Clifton  <nickc@redhat.com>
+
+	Fix the fields in the x_n union inside the the x_file structure so that pointers can be stored.
+		PR 28630
+		* coff/internal.h (x_n): Use bfd_hostptr_t for the fields in this
+		structure.
+
+2021-12-01  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/remote: use scoped_restore to control starting_up flag
+	This commit makes use of a scoped_restore object to control the
+	remote_state::starting_up flag within the remote_target::start_remote
+	method.
+
+	Ideally I would have liked to create the scoped_restore inside
+	start_remote and just leave the restore in place until the end of the
+	scope, however, I'm worried that doing this would change the behaviour
+	of GDB.  Specifically, in start_remote, the following code is executed
+	once the starting_up flag has been restored to its previous value:
+
+	  if (breakpoints_should_be_inserted_now ())
+	    insert_breakpoints ();
+
+	I think (but am not 100% sure) that calling install_breakpoints could
+	end up back inside remote_target::can_download_tracepoint, which does
+	check the value of remote_state::starting_up.  And so, I'm concerned
+	that leaving the scoped_restore in place until the end of start_remote
+	will cause a possible change in behaviour.
+
+	To avoid this, and to leave things as close to the current behaviour
+	as possible, I've split remote_target::start_remote into two, there's
+	the main function body which moves into remote_target::start_remote_1,
+	this function uses the scoped_restore to change the ::starting_up
+	flag, then there's the old remote_target::start_remote, which now just
+	calls ::start_remote_1, and then does the insert_breakpoints call.
+
+	There should be no user visible changes after this commit, unless
+	there's a situation where the ::starting_up flag could previously have
+	been left set, if this was the case, then this situation should no
+	longer be possible.
+
+2021-12-01  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb.base/corefile-buildid.exp: fix DUPLICATEs when failing to generate a core file
+	When my system isn't properly configured to generate core files in the
+	local directory, I see these DUPLICATEs:
+
+	    DUPLICATE: gdb.base/corefile-buildid.exp: could not generate core file
+
+	Fix that by having a single with_test_prefix around that message and
+	what follows.
+
+	Change-Id: I4ac245fcce1c666db56e3bad3582aa17f183dcba
+
+2021-12-01  Mike Frysinger  <vapier@gentoo.org>
+
+	gold: enable silent build rules
+
+2021-12-01  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-30  Carl Love  <cel@us.ibm.com>
+
+	gdb: Powerpc fix gdb.multi/multi-arch-exec.exp test
+	The expect file has a procedure append_arch_options which sets march based
+	the istarget.  The current if / else statement does not check for
+	powerpc64.  The else statement is hit which sets march to -m32.  This
+	results in compilation errors on 64-bit PowerPC.
+
+	This patch adds an if statement to check for powerpc64 and if true sets mach
+	to -m64.
+
+	The patch was tested on a Power 10 system.  No compile errors were generated.
+	The test completes with 1 expected pass and no failures.
+
+2021-11-30  Mike Frysinger  <vapier@gentoo.org>
+
+	binutils: regenerate Makefile.in after doc/ changes
+
+2021-11-30  Roland McGrath  <mcgrathr@google.com>
+
+	Fix missing build dependency for binutils man pages
+	binutils/
+		* doc/local.mk: Give each man page target its missing dependency on
+		doc/$(am__dirstamp).
+
+2021-11-30  Richard Sandiford  <richard.sandiford@arm.com>
+
+	aarch64: Add missing system registers [PR27145]
+	This patch adds support for various system registers, up to Armv8.7-A.
+	This includes all the registers that were mentioned in the PR and that
+	hadn't become supported since.
+
+	opcodes/
+		PR aarch64/27145
+		* aarch64-opc.c (SR_V8_4): Remove duplicate definition.
+		(SR_V8_6, SR_V8_7, SR_GIC, SR_AMU): New macros.
+		(aarch64_sys_regs): Add missing entries (up to Armv8.7-A).
+
+	gas/
+		PR aarch64/27145
+		* testsuite/gas/aarch64/sysreg-8.s,
+		* testsuite/gas/aarch64/sysreg-8.d,
+		* testsuite/gas/aarch64/illegal-sysreg-8.s,
+		* testsuite/gas/aarch64/illegal-sysreg-8.d,
+		* testsuite/gas/aarch64/illegal-sysreg-8.l,
+		* testsuite/gas/aarch64/illegal-sysreg-8b.s,
+		* testsuite/gas/aarch64/illegal-sysreg-8b.d,
+		* testsuite/gas/aarch64/illegal-sysreg-8b.l: New tests.
+		* testsuite/gas/aarch64/sysreg.s: Change system register numbers
+		to ones that are still unallocated.
+		* testsuite/gas/aarch64/sysreg.d: Update accordingly.
+
+2021-11-30  Richard Sandiford  <richard.sandiford@arm.com>
+
+	aarch64: Make LOR registers conditional on +lor
+	We have a +lor feature flag for the Limited Ordering Regions
+	extension, but the associated registers didn't use it.
+
+	opcodes/
+		* aarch64-opc.c (SR_LOR): New macro.
+		(aarch64_sys_regs): Use it for lorc_el1, lorea_el1, lorn_el1 and
+		lorsa_el1.
+
+	gas/
+		* testsuite/gas/aarch64/sysreg-7.s: Enable +lor.
+		* testsuite/gas/aarch64/illegal-sysreg-7.s: Test for LOR registers
+		without +lor.
+		* testsuite/gas/aarch64/illegal-sysreg-7.d: Update accordingly.
+		* testsuite/gas/aarch64/illegal-sysreg-7.l: Likewise.
+
+2021-11-30  Richard Sandiford  <richard.sandiford@arm.com>
+
+	aarch64: Remove ZIDR_EL1
+	ZIDR_EL1 was part of an early version of SVE, but didn't make
+	it to the final release.
+
+	opcodes/
+		* aarch64-opc.c (aarch64_sys_regs): Remove zidr_el1 entry.
+
+	gas/
+		* testsuite/gas/aarch64/sve-sysreg.s: Remove zidr_el1.
+		* testsuite/gas/aarch64/sve-sysreg.d: Update accordingly.
+		* testsuite/gas/aarch64/sve-sysreg-invalid.l: Likewise.
+
+2021-11-30  Richard Sandiford  <richard.sandiford@arm.com>
+
+	aarch64: Allow writes to MFAR_EL3
+	MFAR_EL3 is a read/write register, but was incorrectly marked as
+	read-only
+	[https://developer.arm.com/documentation/ddi0601/2021-09/AArch64-Registers/MFAR-EL3--PA-Fault-Address-Register?lang=en]
+
+	opcodes/
+		* aarch64-opc.c (aarch64_sys_regs): Mark mfar_el3 as read-write.
+
+	gas/
+		* testsuite/gas/aarch64/rme.s: Test writing to mfar_el3.
+		* testsuite/gas/aarch64/rme.d: Update accordingly.
+		* testsuite/gas/aarch64/rme-invalid.s: Delete.
+		* testsuite/gas/aarch64/rme-invalid.l: Likewise.
+		* testsuite/gas/aarch64/rme-invalid.d: Likewise.
+
+2021-11-30  Richard Sandiford  <richard.sandiford@arm.com>
+
+	aarch64: Mark PMSIDR_EL1 as read-only
+	We were incorrectly allowing writes to PMSIDR_EL1, which is
+	a read-only register.
+	[https://developer.arm.com/documentation/ddi0595/2021-09/AArch64-Registers/PMSIDR-EL1--Sampling-Profiling-ID-Register?lang=en]
+
+	opcodes/
+		* aarch64-opc.c (aarch64_sys_regs): Make pmsidr_el1 as F_REG_READ.
+
+	gas/
+		* testsuite/gas/aarch64/msr.s: Remove write to pmsidr_el1.
+		* testsuite/gas/aarch64/msr.d: Update accordingly.
+		* testsuite/gas/aarch64/illegal-sysreg-2.s,
+		* testsuite/gas/aarch64/illegal-sysreg-2.d,
+		* testsuite/gas/aarch64/illegal-sysreg-2.l: New test.
+
+2021-11-30  Richard Sandiford  <richard.sandiford@arm.com>
+
+	aarch64: Remove duplicate system register entries
+	There is a lot of overlap between the ETM and ETE system registers,
+	so some registers were listed twice.
+
+	Already tested by etm.[sd] and ete.[sd].
+
+	opcodes/
+		* aarch64-opc.c (aarch64_sys_regs): Combine ETE and ETM blocks
+		and remove redundant entries.
+
+	gas/
+		* testsuite/gas/aarch64/etm.s: Remove duplicated test.
+		* testsuite/gas/aarch64/etm.d: Update accordingly.
+
+2021-11-30  Richard Sandiford  <richard.sandiford@arm.com>
+
+	aarch64: Check for register aliases before mnemonics
+	Previously we would not accept:
+
+		A .req B
+
+	if A happened to be the name of an instruction.  Adding new
+	instructions could therefore invalidate existing register aliases.
+
+	I noticed this with a test that used "zero" as a register alias
+	for "xzr", where "zero" is now also the name of an SME instruction.
+	I don't have any evidence that "real" code is doing this, but it
+	seems at least plausible.
+
+	This patch switches things so that we check for register aliases
+	first.  It might slow down parsing slightly, but the difference
+	is unlikely to be noticeable.
+
+	Things like:
+
+		b	.req + 0
+
+	still work, since create_register_alias checks for " .req ",
+	and with the input scrubber, we'll only keep whitespace after
+	.req if it's followed by another name.  If there's some valid
+	expression that I haven't thought about that is scrubbed to
+	" .req ", users could avoid the ambiguity by wrapping .req
+	in parentheses.
+
+	The new test for invalid aliases already passed.  I just wanted
+	something to exercise the !dot condition.
+
+	I can't find a way of exercising the (existing) p == base condition,
+	but I'm not brave enough to say that it can never happen.  If it does
+	happen, get_mnemonic_name would return an empty string.
+
+	gas/
+		* config/tc-aarch64.c (opcode_lookup): Move mnemonic extraction
+		code to...
+		(md_assemble): ...here.  Check for register aliases first.
+		* testsuite/gas/aarch64/register_aliases.d,
+		testsuite/gas/aarch64/register_aliases.s: Test for a register
+		alias called "zero".
+		* testsuite/gas/aarch64/register_aliases_invalid.d,
+		testsuite/gas/aarch64/register_aliases_invalid.l,
+		testsuite/gas/aarch64/register_aliases_invalid.s: New test.
+
+2021-11-30  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/python: don't use the 'p' format for parsing args
+	When running the gdb.python/py-arch.exp tests on a GDB built
+	against Python 2 I ran into some errors.  The problem is that this
+	test script exercises the gdb.Architecture.integer_type method, and
+	this method uses 'p' as an argument format specifier in a call to
+	gdb_PyArg_ParseTupleAndKeywords.
+
+	Unfortunately this specified was only added in Python 3.3, so will
+	cause an error for earlier versions of Python.
+
+	This commit switches to use the 'O' specifier to collect a PyObject,
+	and then uses PyObject_IsTrue to convert the object to a boolean.
+
+	An earlier version of this patch incorrectly switched from using 'p'
+	to use 'i', however, it was pointed out during review that this would
+	cause some changes in behaviour, for example both of these will work
+	with 'p', but not with 'i':
+
+	  gdb.selected_inferior().architecture().integer_type(32, None)
+	  gdb.selected_inferior().architecture().integer_type(32, "foo")
+
+	The new approach of using 'O' works fine with these cases.  I've added
+	some new tests to cover both of the above.
+
+	There should be no user visible changes after this commit.
+
+2021-11-30  Tom de Vries  <tdevries@sdflex.arch.suse.de>
+
+	[gdb/testsuite] Fix gdb.base/style.exp with stub-termcap
+	When running test-case gdb.base/style.exp with a gdb build using
+	stub-termcap.c, we run into:
+	...
+	(gdb) PASS: gdb.base/style.exp: all styles enabled: frame when width=20
+	^M<et width 30^M
+	(gdb) FAIL: gdb.base/style.exp: all styles enabled: set width 30
+	...
+
+	The problem is that we're trying to issue the command "set width 30" while
+	width is set to 20, which causes horizontal scrolling.
+
+	Fix this by resetting the width to 0 before issuing the "set width 30"
+	command.
+
+	Tested on x86_64-linux.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24582
+
+2021-11-30  Nick Clifton  <nickc@redhat.com>
+
+	Use dwarf_vma type for offsets, ranges and section sizes in DWARF decoder.
+		* dwarf.c (find_debug_info_for_offset): Use dwarf_vma type for
+		offsets, sizes and ranges.
+		(display_loc_list): Likewise.  Also use print_dwarf_vma to print
+		the offset.
+		(display_loclists_list): Likewise.
+		(display_loc_list_dwo): Likewise.
+		(display_debug_str): Likewise.
+		(display_debug_aranges): Likewise.
+		(display_debug_ranges_list): Likewise.
+		(display_debug_rnglists_list): Likewise.
+		(display_debug_ranges): Likewise.
+
+	ld: pru: Add pru_irq_map output section
+		* scripttempl/pru.sc (.pru_irq_map): Define output section.
+		* testsuite/ld-pru/pru_irq_map-1.d: New test.
+		* testsuite/ld-pru/pru_irq_map-2.d: New test.
+		* testsuite/ld-pru/pru_irq_map.s: New test.
+
+2021-11-30  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: check the python module is available before using it
+	The gdb.python/py-inferior-leak.exp test makes use of the tracemalloc
+	module.  When running the Python tests with a GDB built against Python
+	2 I ran into a test failure due to the tracemalloc module not being
+	available.
+
+	This commit adds a new helper function to lib/gdb-python.exp that
+	checks if a named module is available.  Using this we can then skip
+	the py-inferior-leak.exp test when the tracemalloc module is not
+	available.
+
+2021-11-30  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: fix disassembler regressions for 32-bit arm
+	After this commit:
+
+	  commit 76b43c9b5c2b275cbf4f927bfc25984410cb5dd5
+	  Date:   Tue Oct 5 15:10:12 2021 +0100
+
+	      gdb: improve error reporting from the disassembler
+
+	We started seeing FAILs in the gdb.base/all-architectures*.exp tests,
+	when running on a 32-bit ARM target, though I suspect running on any
+	target that compiles such that bfd_vma is 32-bits would also trigger
+	the failures.
+
+	The problem is that the test is expected GDB's disassembler to print
+	an error like this:
+
+	  Cannot access memory at address 0x0
+
+	However, after the above commit we see an error like:
+
+	  unknown disassembler error (error = -1)
+
+	The reason for this is this code in opcodes/i386-dis.c (in the
+	print_insn function):
+
+	  if (address_mode == mode_64bit && sizeof (bfd_vma) < 8)
+	    {
+	      (*info->fprintf_func) (info->stream,
+	                             _("64-bit address is disabled"));
+	      return -1;
+	    }
+
+	This code effectively disallows us from ever disassembling 64-bit x86
+	code if we compiled GDB with a 32-bit bfd_vma.  Notice we return
+	-1 (indicating a failure to disassemble), but never call the
+	memory_error_func callback.
+
+	Prior to the above commit GDB, when it received the -1 return value
+	would assume that a memory error had occurred and just print whatever
+	value happened to be in the memory error address variable, the default
+	value of 0 just happened to be fine because the test had asked GDB to
+	do this 'disassemble 0x0,+4'.
+
+	If we instead change the test to do 'disassemble 0x100,+4' then GDB
+	would (previously) have still reported:
+
+	  Cannot access memory at address 0x0
+
+	which makes far less sense.
+
+	In this commit I propose to fix this issue by changing the test to
+	accept either the "Cannot access memory ..." string, or the newer
+	"unknown disassembler error ..." string.  With this change done the
+	test now passes.
+
+	However, there is one weakness with this strategy; if GDB broke such
+	that we _always_ reported "unknown disassembler error ..." we would
+	never notice.  This clearly would be bad.  To avoid this issue I have
+	adjusted the all-architectures*.exp tests so that, when we disassemble
+	for the default architecture (the one selected by "auto") we _only_
+	expect to get the "Cannot access memory ..." error string.
+
+	[ Note: In an ideal world we should be able to disassemble any
+	  architecture at all times.  There's no reason why the 64-bit x86
+	  disassembler requires a 64-bit bfd_vma, other than the code happens
+	  to be written that way.  We could rewrite the disassemble to not
+	  have this requirement, but, I don't plan to do that any time soon. ]
+
+	Further, I have changed the all-architectures*.exp test so that we now
+	disassemble at address 0x100, this should avoid us being able to pass
+	by printing a default address of 0x0.  I did originally change the
+	address we disassembled at to 0x4, however, some architectures,
+	e.g. ia64, have a default instruction alignment that is greater than
+	4, so would still round down to 0x0.  I could have just picked 0x8 as
+	an address, but I figured that 0x100 was likely to satisfy most
+	architectures alignment requirements.
+
+2021-11-30  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/python: add gdb.RemoteTargetConnection.send_packet
+	This commits adds a new sub-class of gdb.TargetConnection,
+	gdb.RemoteTargetConnection.  This sub-class is created for all
+	'remote' and 'extended-remote' targets.
+
+	This new sub-class has one additional method over its base class,
+	'send_packet'.  This new method is equivalent to the 'maint
+	packet' CLI command, it allows a custom packet to be sent to a remote
+	target.
+
+	The outgoing packet can either be a bytes object, or a Unicode string,
+	so long as the Unicode string contains only ASCII characters.
+
+	The result of calling RemoteTargetConnection.send_packet is a bytes
+	object containing the reply that came from the remote.
+
+2021-11-30  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: make packet_command function available outside remote.c
+	In a later commit I will add a Python API to access the 'maint packet'
+	functionality, that is, sending a user specified packet to the target.
+
+	To make implementing this easier, this commit refactors how this
+	command is currently implemented so that the packet_command function
+	is now global.
+
+	The new global send_remote_packet function takes an object that is an
+	implementation of an abstract interface.  Two functions within this
+	interface are then called, one just before a packet is sent to the
+	remote target, and one when the reply has been received from the
+	remote target.  Using an interface object in this way allows (1) for
+	the error checking to be done before the first callback is made, this
+	means we only print out what packet it being sent once we know we are
+	going to actually send it, and (2) we don't need to make a copy of the
+	reply if all we want to do is print it.
+
+	One user visible changes after this commit are the error
+	messages, which I've changed to be less 'maint packet' command
+	focused, this will make them (I hope) better for when
+	send_remote_packet can be called from Python code.
+
+	So:      "command can only be used with remote target"
+	Becomes: "packets can only be sent to a remote target"
+
+	And:     "remote-packet command requires packet text as argument"
+	Becomes: "a remote packet must not be empty"
+
+	Additionally, in this commit, I've added support for packet replies
+	that contain binary data.  Before this commit, the code that printed
+	the reply treated the reply as a C string, it assumed that the string
+	only contained printable characters, and had a null character only at
+	the end.
+
+	One way to show the problem with this is if we try to read the auxv
+	data from a remote target, the auxv data is binary, so, before this
+	commit:
+
+	  (gdb) target remote :54321
+	  ...
+	  (gdb) maint packet qXfer:auxv:read::0,1000
+	  sending: "qXfer:auxv:read::0,1000"
+	  received: "l!"
+	  (gdb)
+
+	And after this commit:
+
+	  (gdb) target remote :54321
+	  ...
+	  (gdb) maint packet qXfer:auxv:read::0,1000
+	  sending: "qXfer:auxv:read::0,1000"
+	  received: "l!\x00\x00\x00\x00\x00\x00\x00\x00\xf0\xfc\xf7\xff\x7f\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\xff\xf>
+	  (gdb)
+
+	The binary contents of the reply are now printed as escaped hex.
+
+2021-11-30  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/python: introduce gdb.TargetConnection object type
+	This commit adds a new object type gdb.TargetConnection.  This new
+	type represents a connection within GDB (a connection as displayed by
+	'info connections').
+
+	There's three ways to find a gdb.TargetConnection, there's a new
+	'gdb.connections()' function, which returns a list of all currently
+	active connections.
+
+	Or you can read the new 'connection' property on the gdb.Inferior
+	object type, this contains the connection for that inferior (or None
+	if the inferior has no connection, for example, it is exited).
+
+	Finally, there's a new gdb.events.connection_removed event registry,
+	this emits a new gdb.ConnectionEvent whenever a connection is removed
+	from GDB (this can happen when all inferiors using a connection exit,
+	though this is not always the case, depending on the connection type).
+	The gdb.ConnectionEvent has a 'connection' property, which is the
+	gdb.TargetConnection being removed from GDB.
+
+	The gdb.TargetConnection has an 'is_valid()' method.  A connection
+	object becomes invalid when the underlying connection is removed from
+	GDB (as discussed above, this might be when all inferiors using a
+	connection exit, or it might be when the user explicitly replaces a
+	connection in GDB by issuing another 'target' command).
+
+	The gdb.TargetConnection has the following read-only properties:
+
+	  'num': The number for this connection,
+
+	  'type': e.g. 'native', 'remote', 'sim', etc
+
+	  'description': The longer description as seen in the 'info
+	                 connections' command output.
+
+	  'details': A string or None.  Extra details for the connection, for
+	             example, a remote connection's details might be
+	             'hostname:port'.
+
+2021-11-30  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: The vtype immediate with more than the defined 8 bits are preserved.
+	According the rvv spec,
+	https://github.com/riscv/riscv-v-spec/blob/master/vtype-format.adoc
+
+	The bits of vtype immediate from 8 to (xlen - 1) should be reserved.
+	Therefore, we should also dump the vtype immediate as numbers, when
+	they are set over 8-bits.  I think this is a bug that we used to support
+	vediv extension and use the bit 8 and 9 of vtype, but forgot to update
+	the behavior when removing the vediv.
+
+	Consider the testcases,
+
+	vsetvli  a0, a1,  0x700    # the reserved bit 10, 9 and 8 are used.
+	vsetvli  a0, a1,  0x400    # the reserved bit 10 is used.
+	vsetvli  a0, a1,  0x300    # the reserved bit 9 and 8 are used.
+	vsetvli  a0, a1,  0x100    # the reserved bit 8 is used.
+	vsetivli a0, 0xb, 0x300    # the reserved bit 9 and 8 are used.
+	vsetivli a0, 0xb, 0x100    # the reserved bit 8 is used.
+
+	The original objdump shows the following result,
+
+	0000000000000000 <.text>:
+	   0:   7005f557                vsetvli a0,a1,1792
+	   4:   4005f557                vsetvli a0,a1,1024
+	   8:   3005f557                vsetvli a0,a1,e8,m1,tu,mu
+	   c:   1005f557                vsetvli a0,a1,e8,m1,tu,mu
+	  10:   f005f557                vsetivli        a0,11,e8,m1,tu,mu
+	  14:   d005f557                vsetivli        a0,11,e8,m1,tu,mu
+
+	But in fact the correct result should be,
+
+	0000000000000000 <.text>:
+	   0:   7005f557                vsetvli a0,a1,1792
+	   4:   4005f557                vsetvli a0,a1,1024
+	   8:   3005f557                vsetvli a0,a1,768
+	   c:   1005f557                vsetvli a0,a1,256
+	  10:   f005f557                vsetivli        a0,11,768
+	  14:   d005f557                vsetivli        a0,11,256
+
+	gas/
+		* testsuite/gas/riscv/vector-insns.d: Added testcases to
+		test the reserved bit 8 to (xlen-1) of vtype.
+		* testsuite/gas/riscv/vector-insns.s: Likewise.
+	include/
+		* opcode/riscv.h: Removed OP_MASK_VTYPE_RES and OP_SH_VTYPE_RES,
+		since they are different for operand Vc and Vb.
+	opcodes/
+		* riscv-dis.c (print_insn_args): Updated imm_vtype_res to
+		extract the reserved immediate of vtype correctly.
+
+2021-11-30  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: Dump vset[i]vli immediate as numbers once vsew or vlmul is reserved.
+	Consider the following case,
+
+	vsetvli  a0, a1,  0x4           # unrecognized vlmul
+	vsetvli  a0, a1,  0x20          # unrecognized vsew
+	vsetivli a0, 0xb, 0x4           # unrecognized vlmul
+	vsetivli a0, 0xb, 0x20          # unrecognized vsew
+
+	For the current dis-assembler, we get the result,
+
+	0000000000000000 <.text>:
+	   0:   0045f557                vsetvli a0,a1,e8,(null),tu,mu
+	   4:   0205f557                vsetvli a0,a1,e128,m1,tu,mu
+	   8:   c045f557                vsetivli        a0,11,e8,(null),tu,mu
+	   c:   c205f557                vsetivli        a0,11,e128,m1,tu,mu
+
+	The vsew e128 and vlmul (null) are preserved according to the spec,
+	so dump these fields looks wrong.  Consider that we are used to dump
+	the unrecognized csr as csr numbers directly, we should also dump
+	the whole vset[i]vli immediates as numbers, once the vsew or vlmul
+	is reserved.  Therefore, following is what I expected,
+
+	0000000000000000 <.text>:
+	   0:   0045f557                vsetvli a0,a1,4
+	   4:   0205f557                vsetvli a0,a1,32
+	   8:   c045f557                vsetivli        a0,11,4
+	   c:   c205f557                vsetivli        a0,11,32
+
+	gas/
+		* testsuite/gas/riscv/vector-insns.d: Rewrite the vset[i]vli
+		testcases since we should dump the immediate as numbers once
+		the vsew or vlmul is reserved.
+		* testsuite/gas/riscv/vector-insns.s: Likewise.
+	opcodes/
+		* riscv-dis.c (print_insn_args): The reserved vsew and vlmul
+		are NULL string in the riscv_vsew and riscv_vlmul, so dump the
+		whole imm as numbers once one of them is NULL.
+		* riscv-opc.c (riscv_vsew): Set the reserved vsew to NULL.
+		(riscv_vlmul): Set the reserved vlmul to NULL.
+
+2021-11-30  Mike Frysinger  <vapier@gentoo.org>
+
+	zlib: enable silent build rules
+
+	ld: enable silent build rules
+	Also add $(AM_V_xxx) to various manual rules in here.
+
+	libctf: enable silent build rules
+	Also add $(AM_V_xxx) to various manual rules in here.
+
+	gprof: enable silent build rules
+	Also add $(AM_V_xxx) to various manual rules in here.
+
+	binutils: merge doc subdir up a level
+	This avoids a recursive make into the doc subdir and speeds up the
+	build slightly.  It also allows for more parallelism.
+
+	binutils: enable silent build rules
+	Also add $(AM_V_xxx) to various manual rules in here.
+
+	bfd: enable silent build rules
+	Also add $(AM_V_xxx) to various manual rules in here.
+
+	opcodes: enable silent build rules
+	Also add $(AM_V_xxx) to various manual rules in here.
+
+2021-11-30  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-29  Tom Tromey  <tom@tromey.com>
+
+	Allow DW_ATE_UTF for Rust characters
+	The Rust compiler plans to change the encoding of a Rust 'char' type
+	to use DW_ATE_UTF.  You can see the discussion here:
+
+	    https://github.com/rust-lang/rust/pull/89887
+
+	However, this fails in gdb.  I looked into this, and it turns out that
+	the handling of DW_ATE_UTF is currently fairly specific to C++.  In
+	particular, the code here assumes the C++ type names, and it creates
+	an integer type.
+
+	This comes from commit 53e710acd ("GDB thinks char16_t and char32_t
+	are signed in C++").  The message says:
+
+	    Both places need fixing.  But since I couldn't tell why dwarf2read.c
+	    needs to create a new type, I've made it use the per-arch built-in
+	    types instead, so that the types are only created once per arch
+	    instead of once per objfile.  That seems to work fine.
+
+	... which is fine, but it seems to me that it's also correct to make a
+	new character type; and this approach is better because it preserves
+	the type name as well.  This does use more memory, but first we
+	shouldn't be too concerned about the memory use of types coming from
+	debuginfo; and second, if we are, we should implement type interning
+	anyway.
+
+	Changing this code to use a character type revealed a couple of
+	oddities in the C/C++ handling of TYPE_CODE_CHAR.  This patch fixes
+	these as well.
+
+	I filed PR rust/28637 for this issue, so that this patch can be
+	backported to the gdb 11 branch.
+
+2021-11-29  Aaron Merey  <amerey@redhat.com>
+	    Tom de Vries  <tdevries@suse.de>
+
+	[PR gdb/27026] CTRL-C is ignored when debug info is downloaded
+	During debuginfod downloads, ctrl-c should result in the download
+	being cancelled and skipped.  However in some cases, ctrl-c fails to
+	get delivered to gdb during downloading.  This can result in downloads
+	being unskippable.
+
+	Fix this by ensuring that target_terminal::ours is in effect for the
+	duration of each download.
+
+	https://sourceware.org/bugzilla/show_bug.cgi?id=27026#c3
+
+2021-11-29  Nick Clifton  <nickc@redhat.com>
+
+	strings: Replace references to -u option with references to -U.
+		PR 28632
+
+2021-11-29  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/symtab] Fix segfault in search_one_symtab
+	PR28539 describes a segfault in lambda function search_one_symtab due to
+	psymbol_functions::expand_symtabs_matching calling expansion_notify with a
+	nullptr symtab:
+	...
+	          struct compunit_symtab *symtab =
+	            psymtab_to_symtab (objfile, ps);
+
+	          if (expansion_notify != NULL)
+	            if (!expansion_notify (symtab))
+	              return false;
+	...
+
+	This happens as follows.  The partial symtab ps is a dwarf2_include_psymtab
+	for some header file:
+	...
+	(gdb) p ps.filename
+	$5 = 0x64fcf80 "/usr/include/c++/11/bits/stl_construct.h"
+	...
+
+	The includer of ps is a shared symtab for a partial unit, with as user:
+	...
+	(gdb) p ps.includer().user.filename
+	$11 = 0x64fc9f0 \
+	  "/usr/src/debug/llvm13-13.0.0-1.2.x86_64/tools/clang/lib/AST/Decl.cpp"
+	...
+
+	The call to psymtab_to_symtab expands the Decl.cpp symtab (and consequently
+	the shared symtab), but returns nullptr because:
+	...
+	struct dwarf2_include_psymtab : public partial_symtab
+	{
+	  ...
+	  compunit_symtab *get_compunit_symtab (struct objfile *objfile) const override
+	  {
+	    return nullptr;
+	  }
+	...
+
+	Fix this by returning the Decl.cpp symtab instead, which fixes the segfault
+	in the PR.
+
+	Tested on x86_64-linux.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28539
+
+2021-11-29  Nick Clifton  <nickc@redhat.com>
+
+	Update description of string's -n option.
+		PR 28632
+		* strings.c (usage): Update desciption of -n option.
+		* doc/binutils.texi: Likewise.
+
+2021-11-29  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix typo in proc lines
+	Proc lines contains a typo:
+	...
+	  string_form { set $_line_string_form $value }
+	...
+
+	Remove the incorrect '$' in '$_line_string_form'.
+
+	Tested on x86_64-linux.
+
+2021-11-29  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Use unique files in gdb.dwarf2/dw2-lines.exp
+	While debugging a problem in gdb.dwarf2/dw2-lines.exp, I realized that the
+	test-case generates all executables and associated temporary files using the
+	same filenames.
+
+	Fix this by adding a new proc prefix_id in lib/gdb.exp, and using it in the
+	test-case.
+
+	Tested on x86_64-linux.
+
+2021-11-29  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.dwarf2/dw2-lines.exp with -m32
+	When running test-case gdb.dwarf2/dw2-lines.exp with target board -unix/-m32,
+	we run into another instance of PR28383, where the dwarf assembler generates
+	64-bit relocations which are not supported by the 32-bit assembler:
+	...
+	dw2-lines-dw.S: Assembler messages:^M
+	outputs/gdb.dwarf2/dw2-lines/dw2-lines-dw.S:76: Error: \
+	  cannot represent relocation type BFD_RELOC_64^M
+	...
+
+	Fix this by using _op_offset in _line_finalize_header.
+
+	Tested on x86_64-linux.
+
+2021-11-29  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: testsuite: drop most specific istarget checks
+	We'll rely on the toolchain probing to determine whether each arch's
+	tests can be run rather the current configure target.  This allows
+	testing all of the ports in a multitarget configuration.
+
+	For now, we don't reformat the files entirely to make it easier to
+	review, and in case we need to make adjustments.  Once this feels
+	like it's stable, we can flatten the code a bit by removing the if
+	statement entirely.
+
+2021-11-29  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: testsuite: support parallel execution
+	Break up the dejagnu logic so that we can parallelize the testsuite.
+	This takes a page from gcc & gdb where each .exp is run in isolation
+	instead of in serial.
+
+	For most targets, this doesn't make much of a difference as they only
+	have a single .exp.  A few (like cris & frv) have multiple .exp though
+	and will see a bit of a speed up.
+
+	The real gain is when testing a multitarget build.  This way we can
+	run all the targets in parallel and cut the execution time a bit.
+	On my system, it goes from ~155sec to ~100sec.
+
+	We can gain further speedups by splitting up some of the larger .exp
+	files into smaller groups.  We'll do that in a followup though.
+
+2021-11-29  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: testsuite: expand arch specific toolchain settings
+	Leverage the new per-port toolchain settings to initialize the env
+	for eeach set of tests.  This allows us to run all the tests in a
+	multitarget build if the user sets up the vars.  If they don't, we
+	can still skip all the tests.
+
+2021-11-29  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: testsuite: setup per-port toolchain settings for multitarget build
+	Gas does not support multitarget builds -- it still only supports
+	a single input & output format.  ld is a bit better, but requires
+	manual flags to select the right output.  This makes it impossible
+	to run the complete testsuite in a multitarget build.
+
+	To address this limitation, create a suite of FOR_TARGET variables
+	so these can be set to precompiled as & ld programs.  It requires
+	a bit of setup ahead of time, but it's a one-time cost, and makes
+	running the full testsuite at once much easier.
+
+2021-11-29  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-28  Alan Modra  <amodra@gmail.com>
+
+	PR28629 NIOS2 fallout
+	The test exactly matched wrong output.
+
+		PR 28629
+		* testsuite/gas/nios2/relax.d: Update expected output.
+
+2021-11-28  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: add checks to core headers to prevent incorrect common building
+	Some of the core sim headers rely on the SIM_AC_OPTION_BITSIZE macro
+	which can change the size of core types.  Since these haven't been
+	unified across ports, add checks to make sure they aren't accidentally
+	included when building for all ports.  This caught the sim-load file
+	using poisoned headers that it didn't actually need.
+
+	sim: unify syscall.o building
+	Now that we've unified all the syscall tables, this file does not rely
+	on any port-specific settings, so move it up to building as part of the
+	common step so we only do it once in a multibuild.
+
+	sim: drop unused gentmap & nltvals.def logic
+	Now that all ports have switched to target-newlib-* files, there's
+	no need for these files & generating things at build time.  So punt
+	the logic and make target-newlib-syscall a hard requirement.
+
+	sim: mcore: switch to new target-newlib-syscall
+	Use the new target-newlib-syscall module.  This is needed to merge all
+	the architectures into a single build, and mcore has a custom syscall
+	table for its newlib/libgloss port.
+
+	sim: riscv: switch to new target-newlib-syscall
+	Use the new target-newlib-syscall module.  This is needed to merge all
+	the architectures into a single build, and riscv has a custom syscall
+	table for its newlib/libgloss port.
+
+2021-11-28  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: cr16: switch to new target-newlib-syscall
+	Use the new target-newlib-syscall module.  This is needed to merge all
+	the architectures into a single build, and cr16 has a custom syscall
+	table for its newlib/libgloss port.
+
+	This allows cleaning up the syscall ifdef logic.  We know these will
+	always exist now.
+
+2021-11-28  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: d10v: switch to new target-newlib-syscall
+	Use the new target-newlib-syscall module.  This is needed to merge all
+	the architectures into a single build, and d10v has a custom syscall
+	table for its newlib/libgloss port.
+
+	This allows cleaning up the syscall ifdef logic.  We know these will
+	always exist now.
+
+2021-11-28  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: sh: switch to new target-newlib-syscall
+	Use the new target-newlib-syscall module.  This is needed to merge all
+	the architectures into a single build, and sh has a custom syscall
+	table for its newlib/libgloss port.
+
+2021-11-28  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: v850: switch to new target-newlib-syscall
+	Use the new target-newlib-syscall module.  This is needed to merge all
+	the architectures into a single build, and v850 has a custom syscall
+	table for its newlib/libgloss port.
+
+	This allows cleaning up the syscall ifdef logic.  We know these will
+	always exist now.
+
+2021-11-28  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: iq2000/lm32/m32c/moxie/rx: switch to new target-newlib-syscall.h
+	Use the new target-newlib-syscall.h to provide the target syscall
+	defines.  These code paths are written specifically for the newlib
+	ABI rather than being generalized, so switching them to the defines
+	rather than trying to go through the dynamic callback conversion
+	seems like the best trade-off for now.  Might have to reconsider
+	this in the future.
+
+2021-11-28  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: nltvals: pull target syscalls out into a dedicated source file
+	Like we just did for pulling out the errno map, pull out the syscall
+	maps into a dedicated common file.  Most newlib ports are using the
+	same syscall map, but not all, which means we have to do a bit more
+	work to migrate.
+
+	This commit adds the maps and switches the ports using the common
+	default syscall table over to it.  Ports using unique syscall tables
+	are still using the old targ-map.c logic.
+
+	Switching common ports over is easy by checking NL_TARGET, but the
+	ppc code needs a bit more cleanup here hence its larger diff.
+
+2021-11-28  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: frv: resolve syscalls dynamically
+	Avoid use of TARGET_<syscall> defines and rely on the callback layers
+	to resolve these dynamically so we can support multiple syscall layers
+	instead of assuming the newlib/libgloss numbers all the time.
+
+	sim: mn10300: resolve syscalls dynamically
+	Avoid use of TARGET_<syscall> defines and rely on the callback layers
+	to resolve these dynamically so we can support multiple syscall layers
+	instead of assuming the newlib/libgloss numbers all the time.
+
+	sim: nltvals: drop i960
+	This port was dropped from gdb/bfd/sim years ago, so stop including
+	its syscall constants too.
+
+	sim: moxie: fix datadir handling
+	Expand the value at `make` time rather than configure generation time
+	so that we handle $(datarootdir) setting properly.
+
+2021-11-28  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-27  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: fix typos in configure
+	The variable names used to restore CFLAGS and LDFLAGS here don't quite
+	match the names used above, resulting in losing the original CFLAGS and
+	LDFLAGS.  Fix that.
+
+	Change-Id: I9cc2c3b48b1dc30c31a7143563c893fd6f426a0a
+
+2021-11-27  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: hw: mark hw_descriptors const
+
+	sim: testsuite: add dedicated flag for init toolchain tests
+	As we setup more reliable CC_FOR_TARGET variables for each target, the
+	bfin way of overriding it to stuff custom CFLAGS doesn't scale well.
+	Add a dedicated CFLAGS_FOR_TARGET_init setting that each set of tests
+	can setup if they want to add custom options.
+
+	sim: testsuite: clean up arch specific toolchain settings
+	In a multitarget build, we process all targets in order, so make sure
+	the toolchain settings from one don't leak into the next.
+
+2021-11-27  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: cris: always search for local rvdummy tool
+	If the board info sets the sim to a basename that is found via $PATH
+	(which is the default dejagnu behavior), the logic here to use its
+	dirname to find rvdummy fails because it looks for `./rvdummy`.  So
+	switch it to always use the local build of rvdummy which is the one
+	we want to be testing against in the first place.
+
+	If we get a request for testing against a different setup, we can
+	figure out & document the needs at that point, and then setup some
+	config knobs to control it.
+
+2021-11-27  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix FAIL in gdb.base/list-missing-source.exp
+	In commit f8080fb7a44 "[gdb/testsuite] Add gdb.base/include-main.exp" a
+	file gdb.base/main.c was added, which caused the following regression:
+	...
+	(gdb) list^M
+	<gdb.base/main.c>
+	(gdb) FAIL: gdb.base/list-missing-source.exp: list
+	...
+
+	The problem is that the test-case does not expect to find a file main.c, but
+	now it finds gdb.base/main.c.
+
+	Fix this by using the more specific file name list-missing-source.c.
+
+	Tested on x86_64-linux.
+
+2021-11-27  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: testsuite: fix bits-gen EXEEXT handling
+	Add missing $(EXEEXT) to dependencies on bits-gen.  These are actually
+	build-only tools, but automake doesn't allow for build & host tools, so
+	the rules are re-using EXEEXT.
+
+2021-11-27  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: testsuite: initial support for OS-specific tests
+	We usually test against the newlib/libgloss environment, but for a
+	few ports that also support Linux apps, we want to test that logic
+	too.  A lot of the C code is written such that it works with either
+	newlib/libgloss or glibc/linux toolchains, but we have some tests
+	that end up being Linux-specific.  Cris has been using the target
+	tuple as a rough proxy for this (where cris*-*-elf is assumed to be
+	newlib/libgloss, and everything else is glibc/linux), but that is a
+	bit too rough, and it doesn't work in a multitarget build.
+
+	So lets create a few stub files that we can do compile tests with
+	to detect the different setups, and then let tests declare which
+	one they require (if they require any at all).
+
+2021-11-27  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: testsuite: unify basic C compiler checks
+	Both bfin & cris ports test the C compiler to see if it works, but in
+	their own way.  Unify the checks in the common code so we can leverage
+	them in more ports in the future, and collapse the bfin & cris code.
+
+2021-11-27  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: testsuite: rework sim_init usage
+	The sim_init function was called by runtest for each test when --tool
+	was set to sim.  When we changed to --tool '' to collapse the testsuite
+	dir, the init function was no longer called on every test.  However, it
+	was still being called explicitly by config/default.exp.  It's not clear
+	why that explicit call ever existed since, in the past, it meant it was
+	redundant.
+
+	Lets drop the single sim_init call in config/default.exp and move it out
+	to all our tests.  This replicates the runtest behavior so we can setup
+	variables on a per-test basis which allows us to recollapse the sim_path
+	logic back.  We'll also leverage this in the future for toolchain setup.
+
+	Also add a few comments clarifying the overall runtime behavior.
+
+2021-11-27  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: cris: fix testsuite hang when sim is missing
+	If the cris sim hasn't been built yet, trying to run its testsuite
+	will hang indefinitely.  The common sim APIs already have this, so
+	copy it over to the cris forks of the test+run functions.
+
+2021-11-27  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: testsuite: fix objdir handling
+	The tests assume that the cwd is the objdir directory and write its
+	intermediates to there all the time.  When using runtest's --objdir
+	setting though, this puts the files in the wrong place.  This isn't
+	a big problem currently as we never change --objdir, but in order to
+	support parallel test execution, we're going to start setting that
+	option, so clean up the code ahead of time.
+
+	We also have to tweak some of the cris tests which were making
+	assumptions about the argv[0] value.
+
+2021-11-27  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: testsuite: rename global_sim_options to SIMFLAGS_FOR_TARGET
+	Now that all the other toolchain settings have been renamed to match
+	the dejagnu settings of XXX_FOR_TARGET, rename global_sim_options to
+	SIMFLAGS_FOR_TARGET too.
+
+	sim: testsuite: replace global_ld_options with LDFLAGS_FOR_TARGET
+	Only a few tests actually use global_ld_options, but we can replace the
+	sim-specific settings with the dejagnu common LDFLAGS_FOR_TARGET and get
+	the same result.
+
+2021-11-27  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-26  John David Anglin  <danglin@gcc.gnu.org>
+
+	Fix ifunc test fails on hppa*-*-*
+	2021-11-26  John David Anglin  <danglin@gcc.gnu.org>
+
+		PR ld/27442
+
+	ld/ChangeLog:
+
+		* ld/testsuite/ld-ifunc/ifunc.exp (contains_irelative_reloc): Adjust
+		regexp.
+		Skip static ifunc-using executable test on hppa*-*-*.
+
+2021-11-26  H.J. Lu  <hjl.tools@gmail.com>
+
+	gas: Update commit 4780e5e4933
+	Update
+
+	commit 4780e5e4933a2497a5aecc4ceabbbb8e82aaf822
+	Author: Tom de Vries <tdevries@suse.de>
+	Date:   Fri Nov 26 09:59:45 2021 +0100
+
+	    [gas] Fix file 0 dir with -gdwarf-5
+
+	1. Replace i with j in
+
+	  for (j = 0; i < NUM_MD5_BYTES; ++j)
+
+	2. Pass -W to readelf to force CU: in output due to:
+
+		      if (do_wide || strlen (directory) < 76)
+			printf (_("CU: %s/%s:\n"), directory, file_table[0].name);
+		      else
+			printf ("%s:\n", file_table[0].name);
+
+		PR gas/28629
+		* dwarf2dbg.c (out_dir_and_file_list): Fix a typo in commit
+		4780e5e4933.
+		* testsuite/gas/elf/dwarf-5-nop-for-line-table.d: Pass -W to
+		readelf.
+
+2021-11-26  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: testsuite: replace global_as_options with ASFLAGS_FOR_TARGET
+	Only a few tests actually use global_as_options, but we can replace the
+	sim-specific settings with the dejagnu common ASFLAGS_FOR_TARGET and get
+	the same result.
+
+2021-11-26  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Add gdb.base/include-main.exp
+	The test-case gdb.ada/dgopt.exp uses the -gnatD switch, in combination with
+	-gnatG.
+
+	This causes the source file $src/gdb/testsuite/gdb.ada/dgopt/x.adb to be
+	expanded into $build/gdb/testsuite/outputs/gdb.ada/dgopt/x.adb.dg, and the
+	debug information should refer to the x.adb.dg file.
+
+	That is the case for the .debug_line part:
+	...
+	The Directory Table is empty.
+
+	 The File Name Table (offset 0x1c):
+	  Entry Dir     Time    Size    Name
+	  1     0       0       0       x.adb.dg
+	...
+	but not for the .debug_info part:
+	...
+	    <11>   DW_AT_name        : $src/gdb/testsuite/gdb.ada/dgopt/x.adb
+	    <15>   DW_AT_comp_dir    : $build/gdb/testsuite/outputs/gdb.ada/dgopt
+	...
+
+	Filed as PR gcc/103436.
+
+	In C we can generate similar debug information, using a source file that does
+	not contain any code, but includes another one that does:
+	...
+	 $ cat gdb/testsuite/gdb.base/include-main.c
+	 #include "main.c"
+	...
+	such that in the .debug_line part we have:
+	...
+	 The Directory Table (offset 0x1c):
+	  1     /home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.base
+
+	 The File Name Table (offset 0x57):
+	  Entry Dir     Time    Size    Name
+	  1     1       0       0       main.c
+	...
+	and in the .debug_info part:
+	...
+	    <11>   DW_AT_name        : $src/gdb/testsuite/gdb.base/include-main.c
+	    <15>   DW_AT_comp_dir    : $build/gdb/testsuite
+	...
+
+	Add a C test-case that mimics gdb.ada/dgopt.exp, that is:
+	- generate debug info as described above,
+	- issue a list of a line in include-main.c, while the corresponding
+	  CU is not expanded yet.
+
+	Tested on x86_64-linux.
+
+2021-11-26  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: testsuite: drop unused global_cc_options
+	Nothing in the testsuite is using this setting, so let's drop it.
+	Any code that wants to set compiler flags can use CFLAGS_FOR_TARGET
+	instead to get the same effect.
+
+	sim: testsuite: punt unused toolchain variables
+	These haven't been used in over 20 years.  The sim testsuite used to
+	run these tools itself directly, but back in ~1999 it switched to the
+	dejagnu helpers (e.g. target_assemble & target_link), and the dejagnu
+	logic only utilizes XXX_FOR_TARGET variables.  Punt them here to avoid
+	confusion with dead code.
+
+2021-11-26  Andrew Burgess  <aburgess@redhat.com>
+	    Simon Cook  <simon.cook@embecosm.com>
+
+	gdb: add risc-v disassembler options support
+	This commit adds support for RISC-V disassembler options to GDB.  This
+	commit is based on this patch which was never committed:
+
+	  https://sourceware.org/pipermail/binutils/2021-January/114944.html
+
+	All of the binutils refactoring has been moved to a separate, earlier,
+	commit, so this commit is pretty straight forward, just registering
+	the required gdbarch hooks.
+
+2021-11-26  Andrew Burgess  <aburgess@redhat.com>
+	    Simon Cook  <simon.cook@embecosm.com>
+
+	opcodes/riscv: add disassembler options support to libopcodes
+	In preparation for the next commit, which will add GDB support for
+	RISC-V disassembler options, this commit restructures how the
+	disassembler options are managed within libopcodes.
+
+	The implementation provided here is based on this mailing list patch
+	which was never committed:
+
+	  https://sourceware.org/pipermail/binutils/2021-January/114944.html
+
+	which in turn took inspiration from the MIPS implementation of the
+	same feature.
+
+	The biggest changes from the original mailing list post are:
+
+	  1. The GDB changes have been split into a separate patch, and
+
+	  2. The `riscv_option_args_privspec` variable, which held the valid
+	  priv-spec values is now gone, instead we use the `riscv_priv_specs`
+	  array from bfd/cpu-riscv.c instead.
+
+
+	include/ChangeLog:
+
+		* dis-asm.h (disassembler_options_riscv): Declare.
+
+	opcodes/ChangeLog:
+
+		* riscv-dis.c (enum riscv_option_arg_t): New enum typedef.
+		(riscv_options): New static global.
+		(disassembler_options_riscv): New function.
+		(print_riscv_disassembler_options): Rewrite to use
+		disassembler_options_riscv.
+
+2021-11-26  Tom de Vries  <tdevries@suse.de>
+
+	[gas] Fix file 0 dir with -gdwarf-5
+	In out_dir_and_file_list, if file 0 is copied from file 1, only the filename
+	is copied, and the dir and md5 fields are left to their default values.
+
+	Fix this by adding the copy of the dir and md5 fields.
+
+	gas/ChangeLog:
+
+	2021-11-26  Tom de Vries  <tdevries@suse.de>
+
+		PR 28629
+		* dwarf2dbg.c (out_dir_and_file_list): When copying file 1 to file 0,
+		also copy dir and md5 fields.
+		* testsuite/gas/i386/dwarf5-line-4.d: Adjust expected output.
+
+2021-11-26  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: mips: avoid _ namespace
+	Some C libraries export _P symbols in their headers (like older
+	newlib and its ctype.h), so use P_ instead to avoid conflicts.
+
+	ld: fix POSIX shell test usage
+	POSIX test uses = for compares, not == which is a bashism.
+
+	gas: enable silent build rules
+
+	ld: fix --disable-multiple-abs-defs alignment in help
+
+2021-11-26  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-25  Enze Li  <lienze2010@hotmail.com>
+
+	gdb: ensure extension_language_python is always defined
+	In this commit:
+
+	  commit c6a6aad52d9e839d6a84ac31cabe2b7e1a2a31a0
+	  Date:   Mon Oct 25 17:25:45 2021 +0100
+
+	      gdb/python: make some global variables static
+
+	building without Python was broken.  The extension_language_python
+	global was moved from being always defined, to only being defined when
+	the HAVE_PYTHON macro was defined.  As a consequence, building without
+	Python support would result in errors like:
+
+	  /usr/bin/ld: extension.o:(.rodata+0x120): undefined reference to `extension_language_python'
+
+	This commit fixes the problem by moving the definition of
+	extension_language_python outside of the HAVE_PYTHON macro protection.
+
+2021-11-25  Andrew Burgess  <aburgess@redhat.com>
+
+	Revert "gdb: add assert in remote_target::wait relating to async being off"
+	This commit introduced a test failure in gdb.server/attach-flag.exp.
+	I didn't spot this failure originally as the problem is fixed by this,
+	as yet unpushed patch:
+
+	  https://sourceware.org/pipermail/gdb-patches/2021-November/183768.html
+
+	I unfortunately didn't test each patch in the original series
+	independently.  I'll repost this patch after the above patch has been
+	merged.
+
+	This reverts commit 32b1f5e8d6b8ddd3be6e471c26dd85a1dac31dda.
+
+2021-11-25  Nick Clifton  <nickc@redhat.com>
+
+	Fix building the AArch64 assembler and disassembler when assertions are disabled.
+		PR 28614
+		* aarch64-asm.c: Replace assert(0) with real code.
+		* aarch64-dis.c: Likewise.
+		* aarch64-opc.c: Likewise.
+
+2021-11-25  Bruno Larsen  <blarsen@redhat.com>
+
+	PR gdb/28480: Improve ambiguous member detection
+	Basic ambiguity detection assumes that when 2 fields with the same name
+	have the same byte offset, it must be an unambiguous request. This is not
+	always correct. Consider the following code:
+
+	class empty { };
+
+	class A {
+	public:
+	  [[no_unique_address]] empty e;
+	};
+
+	class B {
+	public:
+	  int e;
+	};
+
+	class C: public A, public B { };
+
+	if we tried to use c.e in code, the compiler would warn of an ambiguity,
+	however, since A::e does not demand an unique address, it gets the same
+	address (and thus byte offset) of the members, making A::e and B::e have the
+	same address. however, "print c.e" would fail to report the ambiguity,
+	and would instead print it as an empty class (first path found).
+
+	The new code solves this by checking for other found_fields that have
+	different m_struct_path.back() (final class that the member was found
+	in), despite having the same byte offset.
+
+	The testcase gdb.cp/ambiguous.exp was also changed to test for this
+	behavior.
+
+2021-11-25  Jan W. Jagersma  <jwjagersma@gmail.com>
+
+	coff-go32: consistent 16-byte section alignment
+	Section alignment for coff-go32 is inconsistent - The '.text' and
+	'.data' sections are 16-byte aligned, but named sections '.text.*' and
+	'.data.*' are only 4-byte aligned.  '.gnu.linkonce.r.*' is aligned to
+	16 bytes, yet '.rodata' and '.rodata.*' are aligned to 4 bytes.  For
+	'.bss' all input sections are only aligned to 4 bytes.
+
+	This primarily can cause trouble when using SSE instructions, which
+	require their memory operands to be aligned to 16-byte boundaries.
+
+	This patch solves the issue simply by setting the section alignment
+	to 16 bytes, for all code and data sections referenced in the default
+	linker script.
+
+		* coff-go32.c (COFF_SECTION_ALIGNMENT_ENTRIES):  Use partial
+		name match for .text, .data.  Add entries for .const, .rodata,
+		.bss, .gnu.linkonce.b.
+
+2021-11-25  Alan Modra  <amodra@gmail.com>
+
+	Re: AArch64: Add support for AArch64 EFI (efi-*-aarch64)
+	Commit b69c9d41e8 edited bfd/Makefile.in rather than using automake,
+	which meant a typo in Makefile.am was not discovered and other
+	differences in Makefile.in are seen with a proper regeneration.  One
+	difference was lack of an empty line between the pe-aarch64igen.c rule
+	and the following $(BFD32_LIBS) etc. dependency rule, in the
+	regenerated file.  Not that it matters for proper "make" behaviour,
+	but it's nicer with a line between those rules.  Moving the rule
+	earlier seems to cure the missing empty line.
+
+		* Makefile.am (BFD64_BACKENDS): Correct typo.
+		(BFD_H_DEPS, LOCAL_H_DEPS): Move earlier.  Move rule using these
+		deps earlier too.
+		* Makefile.in: Regenerate.
+		* po/BLD-POTFILES.in: Regenerate.
+		* po/SRC-POTFILES.in: Regenerate.
+
+2021-11-25  Nick Clifton  <nickc@redhat.com>
+
+	Updated French translation for the opcodes directory.
+		* po/fr.po; Updated French translation.
+
+2021-11-25  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: rename source_styling_changed observer
+	In a later commit I plan to add disassembler styling.  In the same way
+	that we have a source_styling_changed observer I would need to add a
+	disassembler_styling_changed observer.
+
+	However, currently, these observers would only be notified from
+	cli-style.c:set_style_enabled, and observed in tui-winsource.c,
+	tui_source_window::style_changed, as a result, having two observers
+	seems unnecessary right now, so, in this commit, I plan to rename
+	source_styling_changed to just styling_changed, then, in the later
+	commit, when disassembler styling is added, I can use the same
+	observer for both source styling, and disassembler styling.
+
+	There should be no user visible changes after this commit.
+
+2021-11-25  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb/python: make some global variables static
+	Make a couple of global variables static in python/python.c.  To do
+	this I had to move the definition of extension_language_python to
+	later in the file.
+
+	There should be no user visible changes after this commit.
+
+2021-11-25  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: add assert in remote_target::wait relating to async being off
+	While working on another patch I ended up in a situation where I had
+	async mode disabled (with 'maint set target-async off'), but the async
+	event token got marked anyway.
+
+	In this situation GDB was continually calling into
+	remote_target::wait, however, the async token would never become
+	unmarked as the unmarking is guarded by target_is_async_p.
+
+	We could just unconditionally unmark the token, but that would feel
+	like just ignoring a bug, so, instead, lets assert that if
+	!target_is_async_p, then the async token should not be marked.
+
+	This assertion would have caught my earlier mistake.
+
+	There should be no user visible changes with this commit.
+
+2021-11-25  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: simplify remote_target::is_async_p
+	This commit simplifies remote_target::is_async_p by removing the
+	target_async_permitted check.
+
+	In previous commits I have added additional assertions around the
+	target_async_permitted flag into target.c, as a result we should now
+	be confident that if target_can_async_p returns false, a target will
+	never have async mode enabled.  Given this, it should not be necessary
+	to check target_async_permitted in remote_target::is_async_p, if this
+	flag is false ::is_async_p should return false anyway.  There is an
+	assert to this effect in target_is_async_p.
+
+	There should be no user visible change after this commit.
+
+2021-11-25  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: add asserts in target.c for target_async_permitted
+	The target_async_permitted flag allows a user to override whether a
+	target can act in async mode or not.  In previous commits I have moved
+	the checking of this flag out of the various ::can_async_p methods and
+	into the common target.c code.
+
+	In this commit I will add some additional assertions into
+	target_is_async_p and target_async.  The rules these assertions are
+	checking are:
+
+	  1. A target that returns false for target_can_async_p should never
+	  become "async enabled", and so ::is_async_p should always return
+	  false.  This is being checked in target_is_async_p.
+
+	  2. GDB should never try to enable async mode for a target that
+	  returns false for target_can_async_p, this is checked in
+	  target_async.
+
+	There are a few places where we call the ::is_async_p method directly,
+	in these cases we will obviously not pass through the assert in
+	target_is_async_p, however, there are also plenty of places where we
+	do call target_is_async_p so if GDB starts to misbehave we should
+	catch it quickly enough.
+
+	There should be no user visible changes after this commit.
+
+2021-11-25  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: hoist target_async_permitted checks into target.c
+	This commit moves the target_async_permitted check out of each targets
+	::can_async_p method and into the target_can_async_p wrapper function.
+
+	I've left some asserts in the two ::can_async_p methods that I
+	changed, which will hopefully catch any direct calls to these methods
+	that might be added in the future.
+
+	There should be no user visible changes after this commit.
+
+2021-11-25  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: introduce a new overload of target_can_async_p
+	There are a few places where we call the target_ops::can_async_p
+	member function directly, instead of using the target_can_async_p
+	wrapper.
+
+	In some of these places this is because we need to ask before the
+	target has been pushed, and in another location (in target.c) it seems
+	unnecessary to go through the wrapper when we are already in target.c
+	code.
+
+	However, in the next commit I'd like to hoist some common checks out
+	of target specific code into target.c.  To achieve this, in this
+	commit, I introduce a new overload of target_can_async_p which takes a
+	target_ops pointer, and calls the ::can_async_p method directly.  I
+	then make use of the new overload where appropriate.
+
+	There should be no user visible changes after this commit.
+
+2021-11-25  Clément Chigot  <clement.chigot@atos.net>
+
+	ld/testsuite/ld-elfvsb: correctly test "weak hidden symbol DSO last"
+	The test must be done with the shared object and not with the object
+	file which is already being tested above.
+
+	ld/
+		* testsuite/ld-elfvsb/elfvsb.exp: use .so file in "weak hidden
+		  symbol DSO last"
+
+2021-11-25  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/cli] Add "set logging enabled", deprecate "set logging on/off"
+	Before commit 3b6acaee895 "Update more calls to add_prefix_cmd" we had the
+	following output for "show logging file":
+	...
+	$ gdb -q -batch -ex "set trace-commands on" \
+	    -ex "set logging off" \
+	    -ex "show logging file" \
+	    -ex "set logging on" \
+	    -ex "show logging file"
+	+set logging off
+	+show logging file
+	Future logs will be written to gdb.txt.
+	+set logging on
+	+show logging file
+	Currently logging to "gdb.txt".
+	...
+
+	After that commit we have instead:
+	...
+	+set logging off
+	+show logging file
+	The current logfile is "gdb.txt".
+	+set logging on
+	+show logging file
+	The current logfile is "gdb.txt".
+	...
+
+	Before the commit, whether logging is enabled or not can be deduced from the
+	output of the command.  After the commit, the message is unified and it's no
+	longer clear whether logging is enabled or not.
+
+	Fix this by:
+	- adding a new command "show logging enabled"
+	- adding a corresponding new command "set logging enabled on/off"
+	- making the commands "set logging on/off" deprecated aliases of the
+	  "set logging enabled on/off" command.
+
+	Update the docs and testsuite to use "set logging enabled".  Mention the new
+	and deprecated commands in NEWS.
+
+	Tested on x86_64-linux.
+
+2021-11-25  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/cli] Fix typo in logging overwrite help text
+	Currently we have:
+	...
+	$ gdb -q -batch -ex "help set logging overwrite"
+	Set whether logging overwrites or appends to the log file.
+	If set, logging overrides the log file.
+	...
+
+	Fix overrides -> overwrites typo.
+
+2021-11-25  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-24  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: fix help doc for "set index-cache enabled"
+	When implementing this command, I put "help doc" as a placeholder for
+	the help string, and forgot to update it.  Change it for a real help
+	string.
+
+	Change-Id: Id23c2142c5073dc570bd8a706e9ec6fa8c40eb09
+
+2021-11-24  Simon Marchi  <simon.marchi@efficios.com>
+
+	Revert (part of) "gdb fix for catch-syscall.exp"
+	This reverts (par of) commit ab198279120fe7937c0970a8bb881922726678f9.
+	This commit changed what the test expects when catching the execve
+	syscall based on the behavior seen on a Linux PowerPC machine.  That is,
+	we get an "entry" event, but no "return" event.  This is not what we get
+	on Linux with other architectures, though, and it seems like a
+	PowerPC-specific bug.
+
+	Revert the part of the patch related to this, but not the other hunk.
+
+	Change-Id: I4248776e4299f10999487be96d4acd1b33639996
+
+2021-11-24  Nick Clifton  <nickc@redhat.com>
+
+	Fix an illegal memory access parsing a corrupt sysroff file.
+		PR 28564
+		* sysdump.c (getCHARS): Check for an out of bounds read.
+
+2021-11-24  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: fix crash when reading ECOFF debug information
+	In commit:
+
+	  commit 633cf2548bcd3dafe297e21a1dd3574240280d48
+	  Date:   Wed May 9 15:42:28 2018 -0600
+
+	      Remove cleanups from mdebugread.c
+
+	the following change was made in the function parse_partial_symbols in
+	mdebugread.c:
+
+	  -  fdr_to_pst = XCNEWVEC (struct pst_map, hdr->ifdMax + 1);
+	  -  old_chain = make_cleanup (xfree, fdr_to_pst);
+	  +  gdb::def_vector<struct pst_map> fdr_to_pst_holder (hdr->ifdMax + 1);
+	  +  fdr_to_pst = fdr_to_pst_holder.data ();
+
+	The problem with this change is that XCNEWVEC calls xcalloc, which in
+	turn calls calloc, and calloc zero initializes the allocated memory.
+	In contrast, the new line gdb::def_vector<struct pst_map> specifically
+	does not initialize the underlying memory.
+
+	This is a problem because, later on in this same function, we
+	increment the n_globals field within 'struct pst_map' objects stored
+	in the vector.  The incrementing is now being done from an
+	uninitialized starting point.
+
+	In this commit we switch from using gdb::def_vector to using
+	std::vector, this alone should be enough to ensure that the fields are
+	initialized to zero.
+
+	However, for extra clarity, I have also added initial values in the
+	'struct pst_map' to make it crystal clear how the struct will start
+	up.
+
+	This issue was reported on the mailing list here:
+
+	  https://sourceware.org/pipermail/gdb-patches/2021-November/183693.html
+
+	Co-Authored-By: Lightning <lightningth@gmail.com>
+
+2021-11-24  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-23  Alexandra Hájková  <ahajkova@redhat.com>
+
+	configure.ac: Check for the readline.h explicitly
+	When readline development package is missing make fails with
+	"configure: error: system readline is not new enough" which
+	might be confusing. This patch checks for the readline.h explicitly
+	and makes make to warn about the missing package.
+
+2021-11-23  Tamar Christina  <tamar.christina@arm.com>
+
+	AArch64: Add support for AArch64 EFI (efi-*-aarch64).
+	This adds support for efi-*-aarch64 by virtue of adding a new PEI target
+	pei-aarch64-little.  This is not a full target and only exists to support EFI
+	at this time.
+
+	This means that this target does not support relocation processing and is mostly
+	a container format.  This format has been added to elf based aarch64 targets
+	such that efi images can be made natively on Linux.
+
+	However this target is not valid for use with gas but only with objcopy.
+
+	With these changes the resulting file is recognized as an efi image by
+	third party tools:
+
+	>  pecli info hello.efi
+
+	Metadata
+	================================================================================
+	MD5:            598c32a778b0f0deebe977fef8578c4e
+	SHA1:           4580121edd5cb4dc40f51b28f171fd15250df84c
+	SHA256:         3154bd7cf42433d1c957f6bf55a17ad8c57ed41b29df2d485703349fd6ff1d5c
+	Imphash:
+	Size:           47561 bytes
+	Type:           PE32+ executable (EFI application) (stripped to external PDB), for MS Windows
+	Compile Time:   1970-01-01 00:00:00 (UTC - 0x0       )
+	Entry point:    0x2000 (section .text)
+
+	Sections
+	================================================================================
+	Name      RWX  VirtSize   VirtAddr   RawAddr   RawSize   Entropy  md5
+	.text     R-X  0x5bb0     0x2000     0x400     0x5c00      6.39 551fbc264256a3f387de8a891500ae0d
+	.reloc    R--  0xc        0x8000     0x6000    0x200       0.02 0c45f6d812d079821c1d54c09ab89e1d
+	.data     RW-  0x1d88     0x9000     0x6200    0x1e00      4.18 5d1137c09f01289dc62bf754f7290db3
+	.dynamic  RW-  0xf0       0xb000     0x8000    0x200       0.34 5c94ed3206f05a277e6f04fbf131f131
+	.rela     R--  0xe58      0xc000     0x8200    0x1000      1.87 8b5c6bc30f3acb7ca7bf2e6789d68519
+	.dynsym   R--  0x138      0xd000     0x9200    0x200       0.96 bdcf5101da51aadc663ca8859f88138c
+
+	Imports
+	================================================================================
+
+	Any magic number is based on the Microsoft PE specification [1].
+
+	[1] https://docs.microsoft.com/en-us/windows/win32/debug/pe-format
+
+	bfd/ChangeLog:
+
+	2021-10-21  Tamar Christina  <tamar.christina@arm.com>
+
+		PR binutils/26206
+		* .gitignore (pe-aarch64igen.c): New.
+		* Makefile.am (pei-aarch64.lo, pe-aarch64igen.lo, pei-aarch64.c,
+		pe-aarch64igen.c): Add support.
+		* Makefile.in: Likewise.
+		* bfd.c (bfd_get_sign_extend_vma): Add pei-aarch64-little.
+		* coff-aarch64.c: New file.
+		* coffcode.h (coff_set_arch_mach_hook, coff_set_flags,
+		coff_write_object_contents) Add aarch64 (aarch64_pei_vec) support.
+		* config.bfd: Likewise.
+		* configure: Likewise.
+		* configure.ac: Likewise.
+		* libpei.h (GET_OPTHDR_IMAGE_BASE, PUT_OPTHDR_IMAGE_BASE,
+		GET_OPTHDR_SIZE_OF_STACK_RESERVE, PUT_OPTHDR_SIZE_OF_STACK_RESERVE,
+		GET_OPTHDR_SIZE_OF_STACK_COMMIT, PUT_OPTHDR_SIZE_OF_STACK_COMMIT,
+		GET_OPTHDR_SIZE_OF_HEAP_RESERVE, PUT_OPTHDR_SIZE_OF_HEAP_RESERVE,
+		GET_OPTHDR_SIZE_OF_HEAP_COMMIT, PUT_OPTHDR_SIZE_OF_HEAP_COMMIT,
+		GET_PDATA_ENTRY, _bfd_peAArch64_bfd_copy_private_bfd_data_common,
+		_bfd_peAArch64_bfd_copy_private_section_data,
+		_bfd_peAArch64_get_symbol_info, _bfd_peAArch64_only_swap_filehdr_out,
+		_bfd_peAArch64_print_private_bfd_data_common,
+		_bfd_peAArch64i_final_link_postscript,
+		_bfd_peAArch64i_only_swap_filehdr_out, _bfd_peAArch64i_swap_aouthdr_in,
+		_bfd_peAArch64i_swap_aouthdr_out, _bfd_peAArch64i_swap_aux_in,
+		_bfd_peAArch64i_swap_aux_out, _bfd_peAArch64i_swap_lineno_in,
+		_bfd_peAArch64i_swap_lineno_out, _bfd_peAArch64i_swap_scnhdr_out,
+		_bfd_peAArch64i_swap_sym_in, _bfd_peAArch64i_swap_sym_out,
+		_bfd_peAArch64i_swap_debugdir_in, _bfd_peAArch64i_swap_debugdir_out,
+		_bfd_peAArch64i_write_codeview_record,
+		_bfd_peAArch64i_slurp_codeview_record,
+		_bfd_peAArch64_print_ce_compressed_pdata): New.
+		* peXXigen.c (_bfd_XXi_swap_aouthdr_in, _bfd_XXi_swap_aouthdr_out,
+		pe_print_pdata, _bfd_XX_print_private_bfd_data_common,
+		_bfd_XX_bfd_copy_private_section_data, _bfd_XXi_final_link_postscript):
+		Support COFF_WITH_peAArch64,
+		* pei-aarch64.c: New file.
+		* peicode.h (coff_swap_scnhdr_in, pe_ILF_build_a_bfd, pe_ILF_object_p):
+		Support COFF_WITH_peAArch64.
+		(jtab): Add dummy entry that traps.
+		* targets.c (aarch64_pei_vec): New.
+
+	binutils/ChangeLog:
+
+	2021-10-21  Tamar Christina  <tamar.christina@arm.com>
+
+		PR binutils/26206
+		* NEWS: Add new support.
+		* objcopy.c (convert_efi_target): Add efi-*-aarch64 support.
+		* testsuite/binutils-all/aarch64/pei-aarch64-little.d: New test.
+		* testsuite/binutils-all/aarch64/pei-aarch64-little.s: New test.
+
+	include/ChangeLog:
+
+	2021-10-21  Tamar Christina  <tamar.christina@arm.com>
+
+		PR binutils/26206
+		* coff/aarch64.h: New file.
+		* coff/pe.h (IMAGE_FILE_MACHINE_ARM64): New.
+
+2021-11-23  Alan Modra  <amodra@gmail.com>
+
+	binutils debuginfod test
+	A missing "return" resulted in this non-ELF fail:
+	x86_64-w64-mingw32  +FAIL: debuginfod (create separate debug info file)
+
+	Also, the debuginfod I have installed does not appear to handle
+	non-native ELF objects, so only run the test when native.
+
+		* testsuite/binutils-all/debuginfod.exp: Don't run test unless
+		native ELF.
+
+2021-11-23  Alan Modra  <amodra@gmail.com>
+
+	Update bug reporting address
+	https://sourceware.org/bugzilla/ everywhere
+
+	bfd/
+		* configure.ac (ACX_BUGURL): Set to https://sourceware.org/bugzilla/
+		* po/Make-in (msgid-bugs-address): Likewise.
+		* README: Report bugs to the above.
+		* configure: Regenerate.
+	binutils/
+		* po/Make-in (msgid-bugs-address): Update.
+	gas/
+		* README: Update bug address.  Delete mention of gcc.
+		* po/Make-in: Update bug address.
+	gold/
+		* po/Make-in: Update bug address.
+	gprof/
+		* po/Make-in: Update bug address.
+	ld/
+		* po/Make-in: Update bug address.
+	opcodes/
+		* po/Make-in: Update bug address.
+
+2021-11-23  Jan (janneke) Nieuwenhuizen  <janneke@gnu.org>
+
+	gdb: more compile fixes for gnu-nat.c
+	This fixes compile errors like
+
+	    ../../gdb-11.1/gdb/gnu-nat.c: In function void add_task_commands():
+	    ../../gdb-11.1/gdb/gnu-nat.c:3204:17: error: no matching function for call to add_cmd(const char [8], command_class, cmd_list_element*&, char*, cmd_list_element**)
+	     3204 |         &setlist);
+	          |                 ^
+	    In file included from ../../gdb-11.1/gdb/completer.h:21,
+	                     from ../../gdb-11.1/gdb/symtab.h:36,
+	                     from ../../gdb-11.1/gdb/infrun.h:21,
+	                     from ../../gdb-11.1/gdb/target.h:42,
+	                     from ../../gdb-11.1/gdb/inf-child.h:23,
+	                     from ../../gdb-11.1/gdb/gnu-nat.h:38,
+	                     from ../../gdb-11.1/gdb/gnu-nat.c:24:
+	    ../../gdb-11.1/gdb/command.h:160:33: note: candidate: cmd_list_element* add_cmd(const char*, command_class, void (*)(const char*, int), const char*, cmd_list_element**)
+	      160 | extern struct cmd_list_element *add_cmd (const char *, enum command_class,
+	          |                                 ^~~~~~~
+	    ../../gdb-11.1/gdb/command.h:161:30: note:   no known conversion for argument 3 from cmd_list_element* to void (*)(const char*, int)
+	      161 |       cmd_const_cfunc_ftype *fun,
+	          |       ~~~~~~~~~~~~~~~~~~~~~~~^~~
+	    ../../gdb-11.1/gdb/command.h:167:33: note: candidate: cmd_list_element* add_cmd(const char*, command_class, const char*, cmd_list_element**)
+	      167 | extern struct cmd_list_element *add_cmd (const char *, enum command_class,
+	          |                                 ^~~~~~~
+	    ../../gdb-11.1/gdb/command.h:167:33: note:   candidate expects 4 arguments, 5 provided
+	    ../../gdb-11.1/gdb/gnu-nat.c:3210:18: error: no matching function for call to add_cmd(const char [8], command_class, cmd_list_element*&, char*, cmd_list_element**)
+	     3210 |         &showlist);
+	          |                  ^
+
+	Change-Id: Ie9029363d3fb40e34e8f5b1ab503745bc44bfe3f
+
+2021-11-23  Andrea Monaco  <andrea.monaco@autistici.org>
+
+	gnu-nat.c: fix calls to add_info_alias
+	Some time ago add_info_alias was changed (commit
+	e0f25bd9717c7973197095523db7c1cdc956cea2).  These calls were not updated
+	and caused errors on compilation.
+
+	Change-Id: I354ae4e8b8926d785abc94ec7142471ffd76d2de
+
+2021-11-23  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-22  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: pass more const target_waitstatus by reference
+	While working on target_waitstatus changes, I noticed a few places where
+	const target_waitstatus objects could be passed by reference instead of
+	by pointers.  And in some cases, places where a target_waitstatus could
+	be passed as const, but was not.  Convert them as much as possible.
+
+	Change-Id: Ied552d464be5d5b87489913b95f9720a5ad50c5a
+
+2021-11-22  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: introduce target_waitkind_str, use it in target_waitstatus::to_string
+	I would like to print target_waitkind values in debug messages, so I
+	think that a target_waitkind-to-string function would be useful.  While
+	at it, use it in target_waitstatus::to_string.  This changes the output
+	of target_waitstatus::to_string a bit, but I think it is for the better.
+	The debug messages will show a string matching exactly the
+	target_waitkind enumerator (minus the TARGET_WAITKIND prefix).
+
+	As a convenience, make string_appendf return the same reference to
+	string it got as a parameter.  This allows doing this:
+
+	  return string_appendf (str, "foo");
+
+	... keeping the code concise.
+
+	Change-Id: I383dffc9c78614e7d0668b1516073905e798eef7
+
+2021-11-22  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: rename target_waitstatus_to_string to target_waitstatus::to_string
+	Make target_waitstatus_to_string a "to_string" method of
+	target_waitstatus, a bit like we have ptid_t::to_string already.  This
+	will save a bit of typing.
+
+	Change-Id: Id261b7a09fa9fa3c738abac131c191a6f9c13905
+
+2021-11-22  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: Removed the redundant NULL pointer check in the riscv_update_subset.
+	If we always use the .option arch to call the riscv_update_subset, then
+	it is almost impossible that the input string will be NULL.  Therefore,
+	just remove the redundant NULL pointer check in the riscv_update_subset.
+
+	bfd/
+		* elfxx-riscv.c (riscv_update_subset): Removed the redundant NULL
+		pointer check.
+
+2021-11-22  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: Replace .option rvc/norvc with .option arch, +c/-c.
+	Since the .option rvc/norvc directives are obsolete, replace them with
+	the new proposed diretives: .option arch, +c/-c.  And also reset the
+	riscv_opts.rvc flag for the .option arch directives.
+
+	gas/
+		* config/tc-riscv.c (s_riscv_option): Reset the riscv_opts.rvc
+		for the .option arch directives.
+		* testsuite/gas/riscv/align-1.s: Replace the obsolete .option
+		rvc/norvc with .option arch, +c/-c.
+		* testsuite/gas/riscv/c-add-addi.s: Likewise.
+		* testsuite/gas/riscv/c-nonzero-imm.s: Likewise.
+		* testsuite/gas/riscv/c-nonzero-reg.s: Likewise.
+		* testsuite/gas/riscv/c-zero-imm-64.s: Likewise.
+		* testsuite/gas/riscv/c-zero-imm.s: Likewise.
+		* testsuite/gas/riscv/c-zero-reg.s: Likewise.
+		* testsuite/gas/riscv/ext.s: Likewise.
+		* testsuite/gas/riscv/mapping-01.s: Likewise.
+		* testsuite/gas/riscv/mapping-02.s: Likewise.
+		* testsuite/gas/riscv/mapping-03.s: Likewise.
+		* testsuite/gas/riscv/mapping-04.s: Likewise.
+		* testsuite/gas/riscv/no-relax-align-2.s: Likewise.
+		* testsuite/gas/riscv/shamt-32.s: Likewise.
+		* testsuite/gas/riscv/shamt-64.s: Likewise.
+
+2021-11-22  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/build] Fix x86_64 x32 build
+	A build error on x86_64 with x32 abi was reported here (
+	https://sourceware.org/pipermail/gdb/2021-November/049787.html ):
+	...
+	gdb/nat/amd64-linux-siginfo.c:280:42: error: \
+	  'struct compat_x32_siginfo_t::<unnamed union>::<unnamed>' has no member \
+	  named 'si_addr_bnd'
+	280 | #define cpt_si_lower _sifields._sigfault.si_addr_bnd._lower
+	| ^~~~~~~~~~~
+	gdb/nat/amd64-linux-siginfo.c:337:38: note: in expansion of macro 'cpt_si_lower'
+	337 | to->cpt_si_lower = from_ptrace.cpt_si_lower;
+	| ^~~~~~~~~~~~
+	...
+
+	The problem is that code added in commit d3d7d1ba3bb "[gdb/tdep] Handle
+	si_addr_bnd in compat_siginfo_from_siginfo" doesn't compile on an x86_64 x32
+	setup, because compat_x32_siginfo_t doesn't have the si_addr_bnd fields.
+
+	Fix this conservatively by disabling the code for x32.
+
+	Tested on x86_64-linux.
+
+2021-11-22  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: PR28610, Fix ASAN heap-buffer-overflow error in riscv_update_subset.
+	The architecture parser in riscv_update_subset shouldn't check (or access)
+	the pointer space which doesn't exist.
+
+	bfd/
+		pr 28610
+		* elfxx-riscv.c (riscv_update_subset): The architecture parser
+		shouldn't access the pointer space which doesn't exist.
+
+2021-11-22  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/symtab] Support .debug_line with DW_FORM_line_strp
+	I noticed a new gcc option -gdwarf64 and tried it out (using gcc 11.2.1).
+
+	With a test-case hello.c:
+	...
+	int
+	main (void)
+	{
+	  printf ("hello\n");
+	  return 0;
+	}
+	...
+	compiled like this:
+	...
+	$ gcc -g -gdwarf64 ~/hello.c
+	...
+	I ran into:
+	...
+	$ gdb -q -batch a.out
+	DW_FORM_line_strp pointing outside of .debug_line_str section \
+	  [in module a.out]
+	...
+
+	Debugging gdb revealed that the string offset is:
+	...
+	(gdb) up
+	    objfile=0x182ab70, str_offset=1378684502312,
+	    form_name=0xeae9b5 "DW_FORM_line_strp")
+	    at src/gdb/dwarf2/section.c:208
+	208         error (_("%s pointing outside of %s section [in module %s]"),
+	(gdb) p /x str_offset
+	$1 = 0x14100000128
+	(gdb)
+	...
+	which is read when parsing a .debug_line entry at 0x1e0.
+
+	Looking with readelf at the 0x1e0 entry, we have:
+	...
+	 The Directory Table (offset 0x202, lines 2, columns 1):
+	  Entry Name
+	  0     (indirect line string, offset: 0x128): /data/gdb_versions/devel
+	  1     (indirect line string, offset: 0x141): /home/vries
+	...
+	which in a hexdump looks like:
+	...
+	  0x00000200 1f022801 00004101 00000201 1f020f02
+	...
+
+	What happens is the following:
+	- readelf interprets the DW_FORM_line_strp reference to .debug_line_str as
+	  a 4 byte value, and sees entries 0x00000128 and 0x00000141.
+	- gdb instead interprets it as an 8 byte value, and sees as first entry
+	  0x0000014100000128, which is too big so it bails out.
+
+	AFAIU, gdb is wrong.  It assumes DW_FORM_line_strp is 8 bytes on the basis
+	that the corresponding CU is 64-bit DWARF.  However, the .debug_line
+	contribution has it's own initial_length field, and encodes there that it's
+	32-bit DWARF.
+
+	Fix this by using the correct offset size for DW_FORM_line_strp references
+	in .debug_line.
+
+	Note: the described test-case does trigger this complaint (both with and
+	without this patch):
+	...
+	$ gdb -q -batch -iex "set complaints 10" a.out
+	During symbol reading: intermixed 32-bit and 64-bit DWARF sections
+	...
+
+	The reason that the CU has 64-bit dwarf is because -gdwarf64 was passed to
+	gcc.  The reason that the .debug_line entry has 32-bit dwarf is because that's
+	what gas generates.  Perhaps this is complaint-worthy, but I don't think it
+	is wrong.
+
+	Tested on x86_64-linux, using native and target board dwarf64.exp.
+
+2021-11-22  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Add target board dwarf64.exp
+	Add a new target board dwarf64.exp, that runs test with -gdwarf64.
+
+	Tested on x86_64-linux.
+
+2021-11-22  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Support .debug_line v5 in dwarf assembler
+	The v5 section version for .debug_line has:
+	- two new fields address_size and segment_selector_size
+	- a different way to encode the directory and filename tables.
+
+	Add support for this in the dwarf assembler.
+
+	For now, make the v5 directory and filename tables work with the v4 type of
+	specification in the test-cases by adding duplicate entries at position 0.
+
+	This will need to be properly fixed with an intrusive fix that changes how
+	directory and filename entries are specified in the test-cases, f.i:
+	...
+	set diridx [include_dir "${srcdir}/${subdir}"]
+	set fileidx [file_name "$srcfile" $diridx]
+	...
+
+	Tested on x86_64-linux.
+
+2021-11-22  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Factor out _line_finalize_header
+	Rather than generate dwarf immediately in procs include_dir and file_name,
+	postpone generation and store the data in variables.  Then handle the
+	generation in a new proc _line_finalize_header.
+
+	Tested on x86-64-linux.
+
+2021-11-22  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Support .debug_line v4 in dwarf assembler
+	The .debug_line header got a new field in v4:
+	maximum_operations_per_instruction.
+
+	Generate this field in the dwarf assembler, for now hardcoding the value to 1,
+	meaning non-VLIW.
+
+	Tested on x86_64-linux.
+
+2021-11-22  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Add test-case gdb.dwarf2/dw2-lines.exp
+	Add a new test-case gdb.dwarf2/dw2-lines.exp that tests various .debug_line
+	sections.
+
+	Tested on x86_64-linux.
+
+2021-11-22  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Speed up MACRO_AT_* calls
+	Currently, for each MACRO_AT_range or MACRO_AT_func in dwarf assembly the
+	following is done:
+	- $srcdir/$subdir/$srcfile is compiled to an executable using
+	  flags "debug"
+	- a new gdb instance is started
+	- the new executable is loaded.
+
+	This is inefficient, because the executable is identical within the same
+	Dwarf::assemble call.
+
+	Share the gdb instance in the same Dwarf::assemble invocation, which speeds
+	up a make check with RUNTESTFLAGS like this to catch all dwarf assembly
+	test-cases:
+	...
+	rtf=$(echo $(cd src/gdb/testsuite; find gdb.* -type f -name "*.exp" \
+	      | xargs grep -l Dwarf::assemble))
+	...
+	from:
+	...
+	real    1m39.916s
+	user    1m25.668s
+	sys     0m21.377s
+	...
+	to:
+	...
+	real    1m29.512s
+	user    1m17.316s
+	sys     0m19.100s
+	...
+
+	Tested on x86_64-linux.
+
+2021-11-22  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-21  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Remove duplicates in gdb.base/catch-signal.exp
+	When running the testsuite I have the following:
+
+	    Running .../gdb/testsuite/gdb.base/catch-signal.exp ...
+	    DUPLICATE: gdb.base/catch-signal.exp: SIGHUP: continue
+	    DUPLICATE: gdb.base/catch-signal.exp: SIGHUP: continue
+	    DUPLICATE: gdb.base/catch-signal.exp: 1: continue
+	    DUPLICATE: gdb.base/catch-signal.exp: 1: continue
+	    DUPLICATE: gdb.base/catch-signal.exp: SIGHUP SIGUSR2: continue
+	    DUPLICATE: gdb.base/catch-signal.exp: SIGHUP SIGUSR2: continue
+
+	This patch removes DUPLICATE in gdb.base/catch-signal.exp by explicitly
+	giving names to the offending 'gdb_test "continue"' statements to make
+	them distinct.
+
+	Tested on x86_64-linux.
+
+2021-11-21  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: v850: fix cpu_option testsuite handling
+	The v850 testsuite code has been testing the $opt variable, but this
+	was never actually set anywhere globally or v850-specific.  Instead,
+	this was a random variable leaking out of the sh testsuite code.  As
+	far as I can tell, it has always been this way.  That means the code
+	only ever tested the v850 cpu target (which is the default).
+
+	This failure can be easily seen in practice by running the v850 code
+	in isolation and seeing it crash:
+	$ runtest v850/allinsns.exp
+	...
+	Running target unix
+	Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target.
+	Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
+	Using ../../../sim/testsuite/config/default.exp as tool-and-target-specific interface file.
+	WARNING: Assuming target board is the local machine (which is probably wrong).
+	You may need to set your DEJAGNU environment variable.
+	Running ../../../sim/testsuite/v850/allinsns.exp ...
+	ERROR: tcl error sourcing ../../../sim/testsuite/v850/allinsns.exp.
+	ERROR: tcl error code TCL LOOKUP VARNAME opt
+	ERROR: can't read "opt": no such variable
+	    while executing
+	"switch -regexp -- $opt {
+
+	Backing up a bit, the reason for this logic in the first place is
+	because the common sim testsuite code makes an assumption about the
+	assembler options with cpu_option -- the option and its value are
+	always separated by an =.  This is not the case with v850.  So tweak
+	the core sim logic a bit to support omitting the = so that we can
+	switch v850 to the standard all_machs setting and avoid opt entirely.
+
+2021-11-21  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-20  Jeff Law  <jeffreyalaw@gmail.com>
+
+	    Fix intermittent failures on the H8, particularly H8/SX tests.
+	    The upstream GCC tester has  showed spurious execution failures on the
+	    H8 target for the H8/SX multilibs. I suspected memory corruption or an
+	    uninitialized variable early as the same binary would sometimes work and
+	    sometimes it got the wrong result. Worse yet, the point where the test
+	    determined it was getting the wrong result would change.
+
+	    Because it only happened on the H8/SX variant I was able to zero in on
+	    the "mova" support and the "short form" of those instructions in particular.
+
+	    As the code stands it checks if code->op3.type == 0 to try and identify cases
+	    where op3 wasn't filled in and thus we've got the short form of the mova
+	    instruction.
+
+	    But for the short-form of those instructions we never set any of the "op3"
+	    data structure. We get whatever was lying around -- it's usually zero and
+	     thus things usually work, but if the stale data was nonzero, then we'd
+	    fail to recognize the instruction as a short-form and fail to set up the
+	    various fields appropriately.
+
+	    I initially initialized the op3.type field to zero, but didn't like that
+	     because it was inconsistent with how other operands were initialized.
+	    Bringing consistency meant using -1 as the initializer value and adjusting
+	    the check for short form mova appropriately.
+
+	    I've had this in the upstream GCC tester for perhaps a year at this point
+	    and haven't seen any of the intermittent failures again.
+
+2021-11-20  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdbsupport: fix array-view compilation with c++11 && _GLIBCXX_DEBUG
+	When building with -std=c++11 and -D_GLIBCXX_DEBUG=1, we get some errors
+	like:
+
+	      CXX    unittests/array-view-selftests.o
+	    In file included from /home/smarchi/src/binutils-gdb/gdb/utils.h:25,
+	                     from /home/smarchi/src/binutils-gdb/gdb/defs.h:630,
+	                     from /home/smarchi/src/binutils-gdb/gdb/unittests/array-view-selftests.c:20:
+	    /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/array-view.h: In instantiation of constexpr gdb::array_view<T> gdb::array_view<T>::slice(gdb::array_view<T>::size_type, gdb::array_view<T>::size_type) const [with T = unsigned char; gdb::array_view<T>::size_type = long unsigned int:
+	    /home/smarchi/src/binutils-gdb/gdb/unittests/array-view-selftests.c:532:29:   required from here
+	    /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/array-view.h:192:3: error: body of constexpr function constexpr gdb::array_view<T> gdb::array_view<T>::slice(gdb::array_view<T>::size_type, gdb::array_view<T>::size_type) const [with T = unsigned char; gdb::array_view<T>::size_type = long unsigned int not a return-statement
+	      192 |   }
+	          |   ^
+
+	This is because constexpr functions in c++11 can only consist of a
+	single return statement, so we can't have the gdb_assert in there.  Make
+	the gdb_assert presence conditional to the __cplusplus version, to
+	enable it only for c++14 and later.
+
+	Change-Id: I2ac33f7b4bd1765ddc3ac8d07445b16ac1f340f0
+
+2021-11-20  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/build] Check if libsource-highlight is usable
+	When building gdb with g++ 4.8.5, I ran into:
+	...
+	ld: source-cache.o: in function `source_cache::ensure(symtab*)':
+	source-cache.c:207: undefined reference to \
+	  srchilite::SourceHighlight::SourceHighlight(std::string const&)
+	...
+
+	[ I configured gdb without explicit settings related to source-highlight, so
+	we're excercising the enable_source_highlight=auto scenario. ]
+
+	The problem is that:
+	- the source-highlight library is build with system compiler
+	  g++ 7.5.0 which uses the new libstdc++ library abi (see
+	  https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html )
+	- gdb is build using g++ 4.8.5 which uses the old abi.
+
+	[ There's a compatibility macro _GLIBCXX_USE_CXX11_ABI, but that doesn't work
+	for this case.  Instead, it enables the opposite case where the
+	source-highlight library is build with g++ 4.8.5 and gdb is build with
+	g++ 7.5.0. ]
+
+	Fix this by checking whether the source-highlight library is usable during
+	configuration.
+
+	In the enable_source_highlight=auto scenario, this allows the build to skip
+	the unusable library and finish successfully.
+
+	In the enable_source_highlight=yes scenario, this allows the build to error
+	out earlier.
+
+	Tested on x86_64-linux.
+
+2021-11-20  Clément Chigot  <clement.chigot@atos.net>
+
+	bfd: remove wrong comment in xcofflink.c
+	This comment was long time ago associated to the function
+	"xcoff_build_ldsyms" which have since been replaced by
+	"xcoff_build_ldsym".
+
+		* xcofflink.c: Remove wrong comment.
+
+2021-11-20  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: bfin: fix short --env usage in testsuite
+	Now that we have more than one option that matches "--env", the test
+	config here doesn't work.  Use the explicit --environment.
+
+2021-11-20  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-19  H.J. Lu  <hjl.tools@gmail.com>
+
+	elfedit: Align --[in|out]put-abiversion usage
+	Align
+
+	  --input-abiversion [0-255]  Set input ABIVERSION
+	  --output-abiversion [0-255] Set output ABIVERSION
+
+	instead of
+
+	  --input-abiversion [0-255]
+	                              Set input ABIVERSION
+	  --output-abiversion [0-255]
+	                              Set output ABIVERSION
+
+		* elfedit.c (usage): Align --[in|out]put-abiversion usage.
+
+2021-11-19  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Handle runto fail in gdb.mi/mi-var-cp.exp
+	On OBS I ran into:
+	...
+	PASS: gdb.mi/mi-var-cp.exp: run to mi-var-cp.cc:81 (set breakpoint)
+	UNRESOLVED: gdb.mi/mi-var-cp.exp: unable to start target
+	...
+	followed by 81 FAILs and two more UNRESOLVEDs.
+
+	I didn't manage to reproduce this, but I did notice that the initial
+	problem causing the UNRESOLVED caused all subsequent UNRESOLVEDs and FAILs.
+
+	I emulated the problem by commenting out the send_gdb "run\n" in
+	mi_run_cmd_full.
+
+	Fix this by:
+	- handling mi_run_cmd failure in mi_get_inline_test
+	- handling mi_run_inline_test failure in gdb.mi/mi-var-cp.exp, and
+	  other test-cases using mi_get_inline_test
+
+	Tested on x86_64-linux.
+
+2021-11-19  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix 64-bit dwarf test-cases with -m32
+	When running test-case gdb.dwarf2/loc-sec-offset.exp with target board -m32,
+	I run into:
+	...
+	builtin_spawn -ignore SIGHUP gcc -fno-stack-protector -m32 \
+	  -fdiagnostics-color=never -c -o loc-sec-offset-dw641.o \
+	  loc-sec-offset-dw64.S^M
+	as: loc-sec-offset-dw641.o: unsupported relocation type: 0x1^M
+	loc-sec-offset-dw64.S: Assembler messages:^M
+	loc-sec-offset-dw64.S:29: Error: cannot represent relocation type \
+	  BFD_RELOC_64^M
+	...
+
+	Looking at line 29, we have:
+	...
+	        .8byte        .Labbrev1_begin   /* Abbrevs */
+	...
+
+	It would be nice if the assembler could handle this somehow.  But I guess
+	it's not unreasonable that an assembler for a 32-bit architecture will object
+	to handling 64-bit labels.
+
+	Instead, work around this in the dwarf assembler by emitting:
+	...
+	        .4byte        .Labbrev1_begin   /* Abbrevs (lsw) */
+	        .4byte        0                 /* Abbrevs (msw) */
+	...
+
+	Tested on x86_64-linux with target board unix/-m32.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28383
+
+2021-11-19  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp
+	On OBS I ran into a failure in test-case gdb.threads/thread-specific-bp.exp:
+	...
+	(gdb) PASS: gdb.threads/thread-specific-bp.exp: non-stop: continue to end
+	info breakpoint^M
+	Num     Type           Disp Enb Address            What^M
+	1       breakpoint     keep y   0x0000555555555167 in main at $src:36^M
+	        breakpoint already hit 1 time^M
+	2       breakpoint     keep y   0x0000555555555151 in start at $src:23^M
+	        breakpoint already hit 1 time^M
+	3       breakpoint     keep y   0x0000555555555167 in main at $src:36 thread 2^M
+	        stop only in thread 2^M
+	4       breakpoint     keep y   0x000055555555515c in end at $src:29^M
+	        breakpoint already hit 1 time^M
+	(gdb) [Thread 0x7ffff7db1640 (LWP 19984) exited]^M
+	Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.^M
+	FAIL: gdb.threads/thread-specific-bp.exp: non-stop: \
+	  thread-specific breakpoint was deleted (timeout)
+	...
+
+	Fix this by waiting for the "[Thread 0x7ffff7db1640 (LWP 19984) exited]"
+	message before issuing the "info breakpoint command".
+
+	Tested on x86_64-linux.
+
+2021-11-19  Christina Schimpe  <christina.schimpe@intel.com>
+
+	gdb/testsuite: Extend tests for print of cv qualifiers
+	This commit supplements whatis and ptype command tests for print of
+	const-volatile qualifiers.
+
+	gdb/testsuite/ChangeLog:
+	2021-11-16  Christina Schimpe  <christina.schimpe@intel.com>
+
+		* gdb.cp/ptype-cv-cp.cc: New const and volatile typedef
+		  variables.
+		* gdb.cp/ptype-cv-cp.exp: Add new tests.
+
+2021-11-19  Christina Schimpe  <christina.schimpe@intel.com>
+
+	gdb: Print cv qualifiers if class attributes are substituted
+	Make ptype print const/volatile qualifiers when template or typedef
+	attributes are substituted.
+
+	For a programm like
+	~~~
+	template<typename DataT>
+	class Cfoo
+	{
+	  typedef float myfloat;
+	public:
+	  DataT me0;
+	  const DataT me1=1;
+	  const myfloat me2=2.0;
+	};
+
+	int main()
+	{
+	  Cfoo<int> cfoo;
+	  return 0;
+	}
+	~~~
+
+	gdb outputs the following type for cfoo's attributes:
+
+	~~~
+	(gdb) b 14
+	Breakpoint 1 at 0x1170: file tmp.cc, line 14.
+	(gdb) run
+	Starting program: /tmp
+
+	Breakpoint 1, main () at tmp.cc:14
+	14        return 0;
+	(gdb) ptype cfoo
+	type = class Cfoo<int> [with DataT = int] {
+	  public:
+	    DataT me0;
+	    DataT me1;
+	    myfloat me2;
+
+	  private:
+	    typedef float myfloat;
+	}
+
+	~~~
+
+	The cv qualifiers (const in this case) are ignored for me1 and me2.
+
+	After:
+	~~~
+	(gdb) ptype cfoo
+	type = class Cfoo<int> [with DataT = int] {
+	  public:
+	    DataT me0;
+	    const DataT me1;
+	    const myfloat me2;
+
+	  private:
+	    typedef float myfloat;
+	}
+	~~~
+
+	gdb/ChangeLog:
+	2021-11-16  Christina Schimpe  <christina.schimpe@intel.com>
+
+		* gdb/c-typeprint.c: Print cv qualifiers in case of parameter
+		  substitution.
+
+	gdb/testsuite/ChangeLog:
+	2021-11-16  Christina Schimpe  <christina.schimpe@intel.com>
+
+		* gdb.cp/templates.cc: 	New template class Cfoo with const,
+		  template, typdef and integer attributes.
+		* gdb.cp/templates.exp: Add new test using ptype and ptype/r
+		  commmands for template class CFoo.
+
+2021-11-19  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: Support new .option arch directive.
+	https://github.com/riscv/riscv-asm-manual/pull/67
+
+	Format:
+	.option arch, +<extension><version>, ...
+	.option arch, -<extension>
+	.option arch, =<ISA string>
+
+	The new direcitve is used to enable/disable extensions for the specific
+	code region.  For example,
+
+	.attribute arch, "rv64ic"   # arch = rv64i2p0_c2p0
+	.option push
+	.option arch, +d2p0, -c     # arch = rv64i2p0_f2p0_d2p0, f is added implied
+	.option arch, =rv32gc       # arch = rv32i2p0_m2p0_a2p0_f2p0_d2p0_c2p0
+	.option pop                 # arch = rv64i2p0_c2p0
+
+	Note that,
+	1. ".option rvc/norvc" have the same behavior as ".option arch +c/-c".
+	2. ".option arch -i" is illegal, since we cannot remove base i extension.
+	3. If arch=rv64i2p0, then ".option arch, +i3p0" will update the i's version
+	   from 2.0 to 3.0.
+	4. If arch=rv64i3p0, then ".option arch, +i" will update the i's version
+	   from 2.0 to the default one according to the chosen isa spec.
+
+	bfd/
+		* elfxx-riscv.c (riscv_add_subset): If the subset is already added,
+		and the new versions are not RISCV_UNKNOWN_VERSION, then update the
+		versions to the subset list.
+		(riscv_copy_subset): New function.  Copy the subset from list.
+		(riscv_copy_subset_list): New function.  Return the new copyed list.
+		(riscv_update_subset): Updated to make .option arch directives workable.
+		* elfxx-riscv.h: Updated.
+	gas/
+		* config/tc-riscv.c (riscv_subsets): Defined as a pointer.
+		(riscv_rps_as): Init the subset_list to NULL, we will set it later
+		once riscv_opts_stack is created or updated.
+		(struct riscv_option_stack, riscv_opts_stack): Moved forward.
+		(riscv_set_arch): Updated.
+		(s_riscv_option): Support new .option arch directive, to add, remove
+		or update subsets for the specific code region.
+		(riscv_write_out_attrs): Updated.
+		* doc/c-riscv.texi: Added document for new .option arch directive.
+		* testsuite/gas/riscv/option-arch-01a.d: New testcase.
+		* testsuite/gas/riscv/option-arch-01b.d: Likewise.
+		* testsuite/gas/riscv/option-arch-01.s: Likewise..
+		* testsuite/gas/riscv/option-arch-02.d: Likewise.
+		* testsuite/gas/riscv/option-arch-02.s: Likewise.
+		* testsuite/gas/riscv/option-arch-fail.d: Likewise.
+		* testsuite/gas/riscv/option-arch-fail.l: Likewise.
+		* testsuite/gas/riscv/option-arch-fail.s: Likewise.
+
+2021-11-19  Alan Modra  <amodra@gmail.com>
+
+	Re: Add multibyte character warning option to the assembler.
+	On hppa*-hp-hpux* run_dump_test edits the test file, adjusting .comm
+	directives to suit those target's unusual syntax.  Thus gas is passed
+	a temporary file name.
+
+		* testsuite/gas/all/multibyte1.l: Ignore file name.
+
+2021-11-19  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: install various doc files
+
+2021-11-19  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: Support STO_RISCV_VARIANT_CC and DT_RISCV_VARIANT_CC.
+	This is the original discussion,
+	https://github.com/riscv/riscv-elf-psabi-doc/pull/190
+
+	And here is the glibc part,
+	https://sourceware.org/pipermail/libc-alpha/2021-August/129931.html
+
+	For binutils part, we need to support a new direcitve: .variant_cc.
+	The function symbol marked by .variant_cc means it need to be resolved
+	directly without resolver for dynamic linker.  We also add a new dynamic
+	entry, STO_RISCV_VARIANT_CC, to indicate there are symbols with the
+	special attribute in the dynamic symbol table of the object.
+
+	I heard that llvm already have supported this in their mainline, so
+	I think it's time to commit this.
+
+	bfd/
+		* elfnn-riscv.c (riscv_elf_link_hash_table): Added variant_cc
+		flag. It is used to check if relocations for variant CC symbols
+		may be present.
+		(allocate_dynrelocs): If the symbol has STO_RISCV_VARIANT_CC
+		flag, then raise the variant_cc flag of riscv_elf_link_hash_table.
+		(riscv_elf_size_dynamic_sections): Added dynamic entry for
+		variant_cc.
+		(riscv_elf_merge_symbol_attribute): New function, used to merge
+		non-visibility st_other attributes, including STO_RISCV_VARIANT_CC.
+	binutils/
+		* readelf.c (get_riscv_dynamic_type): New function.
+		(get_dynamic_type): Called get_riscv_dynamic_type for riscv targets.
+		(get_riscv_symbol_other): New function.
+		(get_symbol_other): Called get_riscv_symbol_other for riscv targets.
+	gas/
+		* config/tc-riscv.c (s_variant_cc): Marked symbol that it follows a
+		variant CC convention.
+		(riscv_elf_copy_symbol_attributes): Same as elf_copy_symbol_attributes,
+		but without copying st_other.  If a function symbol has special st_other
+		value set via directives, then attaching an IFUNC resolver to that symbol
+		should not override the st_other setting.
+		(riscv_pseudo_table): Support variant_cc diretive.
+		* config/tc-riscv.h (OBJ_COPY_SYMBOL_ATTRIBUTES): Defined.
+		* testsuite/gas/riscv/variant_cc-set.d: New testcase.
+		* testsuite/gas/riscv/variant_cc-set.s: Likewise.
+		* testsuite/gas/riscv/variant_cc.d: Likewise.
+		* testsuite/gas/riscv/variant_cc.s: Likewise.
+	include/
+		* elf/riscv.h (DT_RISCV_VARIANT_CC): Defined to (DT_LOPROC + 1).
+		(STO_RISCV_VARIANT_CC): Defined to 0x80.
+	ld/
+		* testsuite/ld-riscv-elf/variant_cc-1.s: New testcase.
+		* testsuite/ld-riscv-elf/variant_cc-2.s: Likewise.
+		* testsuite/ld-riscv-elf/variant_cc-now.d: Likewise.
+		* testsuite/ld-riscv-elf/variant_cc-r.d: Likewise.
+		* testsuite/ld-riscv-elf/variant_cc-shared.d: Likewise.
+		* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
+
+2021-11-19  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: use program_transform_name for libsim
+	Instead of always using target_alias as a prefix on the name, use
+	program_transform_name instead so that the library is scoped in the
+	same way as the run program.
+
+	sim: avoid installing headers when there is no sim
+	If we aren't building any sims, don't install the sim headers as they
+	won't be useful to anyone.
+
+2021-11-19  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-18  Kevin Buettner  <kevinb@redhat.com>
+
+	dprintf-execution-x-script.exp: Adjust test for native-extended-gdbserver
+	Without this commit, doing...
+
+	make check RUNTESTFLAGS="--target_board=native-extended-gdbserver" \
+	           TESTS="gdb.base/dprintf-execution-x-script.exp"
+
+	...will show one failure.
+
+	Here's a snippet from gdb.log showing the circumstances - I've trimmed
+	the paths for readability:
+
+	builtin_spawn gdb -nw -nx -data-directory data-directory -iex set height 0 -iex set width 0 -iex set auto-connect-native-target off -iex set sysroot -ex set height unlimited -x testsuite/gdb.base/dprintf-execution-x-script.gdb --args testsuite/outputs/gdb.base/dprintf-execution-x-script/dprintf-execution-x-script
+	...
+	Reading symbols from testsuite/outputs/gdb.base/dprintf-execution-x-script/dprintf-execution-x-script...
+	Dprintf 1 at 0x40116e: file testsuite/gdb.base/dprintf-execution-x-script.c, line 38.
+	Breakpoint 2 at 0x40113a: file testsuite/gdb.base/dprintf-execution-x-script.c, line 26.
+	testsuite/gdb.base/dprintf-execution-x-script.gdb:21: Error in sourced command file:
+	Don't know how to run.  Try "help target".
+	(gdb) FAIL: gdb.base/dprintf-execution-x-script.exp: load and run script with -x
+	...
+	GNU gdb (GDB) 12.0.50.20211118-git
+	Copyright (C) 2021 Free Software Foundation, Inc.
+	...
+	(gdb) set height 0
+	(gdb) set width 0
+	(gdb) builtin_spawn gdbserver/gdbserver --once --multi localhost:2346
+	Listening on port 2346
+	target extended-remote localhost:2346
+	Remote debugging using localhost:2346
+	...
+	[Tests after this point will pass.]
+
+	Note that the command which spawns gdb prevents the gdb script from
+	using the native target via "-iex set auto-connect-native-target off".
+
+	Moreover, the script in question contains a "run" command, so GDB
+	doesn't know how to run (since it's prevented from using the native
+	target and no alternate "target" command has been issued.  But, once
+	GDB finishes starting up, the test will spawn a gdbserver and then
+	connect to it.  The other (two) tests after this point both pass.
+
+	I've fixed this by using gdb_test_multiple instead of gdb_test.
+	When a "Don't know how to run message" is received, the test is
+	unsupported.
+
+	I've also added a comment explaining the reason for needing to check
+	for "Don't know how to run" despite bailing out at the top of the test
+	via:
+
+	  if ![target_can_use_run_cmd] {
+	      return 0
+	  }
+
+2021-11-18  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: fix array-view-selftests.c build with g++ 4.8
+	When building with g++ 4.8, I get:
+
+	    CXX    unittests/array-view-selftests.o
+	  /home/smarchi/src/binutils-gdb/gdb/unittests/array-view-selftests.c:123:42: error: expected 'class' before 'Container'
+	   template<template<typename ...> typename Container>
+						    ^
+
+	I am no C++ template expert, but it looks like if I change "typename" for
+	"class", as the compiler kind of suggests, the code compiles.
+
+	Change-Id: I9c3edd29fb2b190069f0ce0dbf3bc3604d175f48
+
+2021-11-18  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: fix ia64-tdep.c build with g++ 4.8
+	When building with g++ 4.8, I get:
+
+	      CXX    ia64-tdep.o
+	    /home/smarchi/src/binutils-gdb/gdb/ia64-tdep.c:3862:1: error: could not convert '{ia64_allocate_new_rse_frame, ia64_store_argument_in_slot, ia64_set_function_addr}' from '<brace
+	-enclosed initializer list>' to 'const ia64_infcall_ops'
+	     };
+	     ^
+
+	This happens since commit 345bd07cce3 ("gdb: fix gdbarch_tdep ODR
+	violation"), which added default values for ia64_infcall_ops fields.  It
+	looks like g++ 4.8 doesn't like initializing the ia64_infcall_ops object
+	using the brace-enclosed initializer list when the ia64_infcall_ops
+	fields are assigned default values.
+
+	Later compilers don't have a problem with that, so I suppose that the
+	code is correct, but still, change it to make gcc 4.8 happy.  Don't
+	initialize the fields of ia64_infcall_ops directly, instead
+	default-initialize ia64_gdbarch_tdep::infcall_ops.
+
+	Change-Id: I35e3a61abd7b7bbcafe6cb207078c738c5266d76
+
+2021-11-18  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: move AIX_TEXT_SEGMENT_BASE to rs6000-aix-tdep.c, remove rs6000-tdep.h
+	The contents of rs6000-tdep.h (AIX_TEXT_SEGMENT_BASE) is AIX-specific,
+	so I thought that this file should be named rs6000-aix-tdep.h.  But
+	there's already a rs6000-aix-tdep.h, so then I though
+	AIX_TEXT_SEGMENT_BASE should simply be moved there, and rs6000-tdep.h
+	deleted.  But then I realized that AIX_TEXT_SEGMENT_BASE is only used in
+	rs6000-aix-tdep.c, so move it to the beginning of that file.
+
+	Change-Id: Ia212c6fae202f31aedb46575821cd642beeda7a3
+
+2021-11-18  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: rename rs6000-nat.c to rs6000-aix-nat.c
+	This file seems to be AIX-specific, according to its contents and
+	configure.nat.  Rename it to rs6000-aix-nat.c, to make that clear (and
+	to follow the convention).
+
+	Change-Id: Ib418dddc6b79b2e28f64431121742b5e87f5f4f5
+
+2021-11-18  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/doc] Fix negative repeat count examining memory example
+	The documentation for the examining memory command x contains an example:
+	...
+	You can also specify a negative repeat count to examine memory backward from
+	the given address.  For example, 'x/-3uh 0x54320' prints three halfwords (h)
+	at 0x54314, 0x54328, and 0x5431c.
+	...
+
+	The 0x54328 looks like a typo, which was intended to be 0x54318.
+
+	But the series uses a 4-byte distance, while the halfword size used in the
+	command means a 2-byte distance, so the series should be:
+	...
+	0x5431a, 0x5431c, and 0x5431e.
+	...
+
+	Fix this by updating the addresses in the example accordingly.
+
+	Reported here ( https://sourceware.org/pipermail/gdb/2021-November/049784.html
+	).
+
+2021-11-18  Nick Clifton  <nickc@redhat.com>
+
+	Add multibyte character warning option to the assembler.
+		* as.c (parse_args): Add support for --multibyte-handling.
+		* as.h (multibyte_handling): Declare.
+		* app.c (scan_for_multibyte_characters): New function.
+		(do_scrub_chars): Call the new function if multibyte warning is
+		enabled.
+		* input-scrub,c (input_scrub_next_buffer): Call the multibyte
+		scanning function if multibyte warnings are enabled.
+		* symbols.c (struct symbol_flags): Add multibyte_warned bit.
+		(symbol_init): Call the multibyte scanning function if multibyte
+		symbol warnings are enabled.
+		(S_SET_SEGMENT): Likewise.
+		* NEWS: Mention the new feature.
+		* doc/as.texi: Document the new feature.
+		* testsuite/gas/all/multibyte.s: New test source file.
+		* testsuite/gas/all/multibyte1.d: New test driver file.
+		* testsuite/gas/all/multibyte1.l: New test expected output.
+		* testsuite/gas/all/multibyte2.d: New test driver file.
+		* testsuite/gas/all/multibyte2.l: New test expected output.
+		* testsuite/gas/all/gas.exp: Run the new tests.
+
+2021-11-18  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: include gdbarch.h in all files extending gdbarch_tdep
+	Commit 345bd07cce33 ("gdb: fix gdbarch_tdep ODR violation") made a bunch
+	of files define a *_gdbarch_tdep class that inherits from a gdbarch_tdep
+	base.  But some of these files don't include gdbarch.h, where
+	gdbarch_tdep is defined.  This may cause build errors if gdbarch.h isn't
+	already included by chance by some other header file.  Avoid this by
+	making them include gdbarch.h.
+
+	Change-Id: If433d302007e274daa4f656cfc94f769cf1aa68a
+
+2021-11-18  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdbsupport: make gdb_assert_not_reached accept a format string
+	Change gdb_assert_not_reached to accept a format string plus
+	corresponding arguments.  This allows giving more precise messages.
+
+	Because the format string passed by the caller is prepended with a "%s:"
+	to add the function name, the callers can no longer pass a translated
+	string (`_(...)`).  Make the gdb_assert_not_reached include the _(),
+	just like the gdb_assert_fail macro just above.
+
+	Change-Id: Id0cfda5a57979df6cdaacaba0d55dd91ae9efee7
+
+2021-11-18  Carl Love  <cel@us.ibm.com>
+
+	gdb fix for catch-syscall.exp
+	Remove check_continue "execve" from Proc test_catch_syscall_execve.
+
+	The check_continue proceedure checs that the command, execve, starts and
+	checks for the return from the command.  The execve command starts a new
+	program and thus the return from the command causing the test to fail.
+
+	The call to proc check_continue "execve" is removed and replaced with
+	just the call to check_call_to_syscall "execve" to verify the command
+	executed.  The next test in proc test_catch_syscall_execve verifies that
+	the new program started and hit the break point in main.
+
+	Update the check for the PowerPC architecture.  Power Little Endian systems
+	include "le" in the name.  The istarget "power64-*-linux*" check fails to
+	match LE sytems.  The expected string is updated to capture both Big Endian
+	and Little Endian systems.  Power 10 LE istarget prints as:
+	powerpc64le-unknown-linux-gnu.
+
+	This patch fixes three failures and the error:
+
+	    ERROR: can't read "arch1": no such variable
+
+	Patch tested on Power 10 ppc64le GNU/Linux platform.
+
+2021-11-18  Carl Love  <cel@us.ibm.com>
+
+	gdb: PowerPC fix gdb.base/break-interp.exp
+	This patch fixes eight test failures on PowerPC for the test
+	gdb.base/break-interp.exp. The patch adds a funtion and registers it to
+	setup the displaced stepping for ppc-linux platform.  The patch moves the
+	struct ppc_inferior_data to the ppc-tdep.h include file to make it visible
+	to the ppc-linux-tdep.c and rs6000-tdep.c files.  Additionally the function
+	get_ppc_per_inferior is made external in ppc-tdep.h to make it visible in
+	both files.
+
+	Tested on Power 10 ppc64le-linux with no regressions.
+
+2021-11-18  Carl Love  <cel@us.ibm.com>
+
+	gdb fix PowerPC test gdb.arch/ppc-longdouble.exp
+	The test complains of duplicate tests.
+
+	DUPLICATE: gdb.arch/ppc-longdouble.exp: continue to breakpoint: return
+
+	The do_test calls gdb_continue_to_breakpoint "return".  The duplicates
+	are the result of calling do_test three times with different arguments.
+
+	This patch fixes the duplicate tests by adding $name to the
+	gdb_continue_to_breakpoint argument.
+
+	Patch tested on Power 10  ppc64le GNU/Linux, no duplicate tests reported,
+	no new regression errors.
+
+2021-11-18  H.J. Lu  <hjl.tools@gmail.com>
+
+	elf/x86: Issue an error on discarded output .plt section
+	Issue an error, instead of crash, on discarded output .plt section.
+
+	bfd/
+
+		PR ld/28597
+		* elf32-i386.c (elf_i386_finish_dynamic_sections): Issue an error
+		on discarded output .plt section.
+		* elf64-x86-64.c (elf_x86_64_finish_dynamic_sections): Likewise.
+
+	ld/
+
+		PR ld/28597
+		* testsuite/ld-elf/pr28597.d: New file.
+		* testsuite/ld-elf/pr28597.s: Likewise.
+		* testsuite/ld-elf/pr28597.t: Likewise.
+
+2021-11-18  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Add missing wait in gdb.base/signals-state-child.exp
+	On OBS I ran into:
+	...
+	(gdb) shell diff -s outputs/gdb.base/signals-state-child/standalone.txt \
+	  outputs/gdb.base/signals-state-child/gdb.txt^M
+	diff: outputs/gdb.base/signals-state-child/standalone.txt: \
+	  No such file or directory^M
+	(gdb) FAIL: gdb.base/signals-state-child.exp: signals states are identical
+	...
+
+	I managed to reproduce this by adding "sleep (5)" at the start of main in
+	signals-state-child.c.
+
+	Fix this by waiting on the result of the spawned command.
+
+	Tested on x86_64-linux.
+
+2021-11-18  Alan Modra  <amodra@gmail.com>
+
+	Re: Don't compile some opcodes files when bfd is 32-bit only
+	Put bpf back in the 32-bit targets, even though bpf requires a 64-bit
+	bfd.  bpf sim support apparently works without being 64-bit.
+
+		* Makefile.am (TARGET64_LIBOPCODES_CFILES): Move bpf files..
+		(TARGET32_LIBOPCODES_CFILES): ..to here.
+		* Makefile.in: Regenerate.
+
+2021-11-18  Alan Modra  <amodra@gmail.com>
+
+	Pass DEBUGINFOD_CFLAGS when compiling dwarf.c
+	Pick up the elfutils/debuginfod.h install location -I flags from
+	a variable set by debuginfod.m4 (via pkg.m4 and pkg-config).
+
+		* Makefile.am (DEBUGINFOD_CFLAGS): Define.
+		(dwarf.@OBJECT@): New rule.
+
+2021-11-18  jiawei  <jiawei@iscas.ac.cn>
+
+	RISC-V: Add testcases for z[fdq]inx
+	Use gpr when the zfinx enable, the testcases contain float
+	instructions that reuse by z[fdq]inx.
+
+	gas/ChangeLog:
+
+	* testsuite/gas/riscv/zdinx.d: New test.
+	* testsuite/gas/riscv/zdinx.s: New test.
+	* testsuite/gas/riscv/zfinx.d: New test.
+	* testsuite/gas/riscv/zfinx.s: New test.
+	* testsuite/gas/riscv/zqinx.d: New test.
+	* testsuite/gas/riscv/zqinx.s: New test.
+
+	Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
+
+2021-11-18  jiawei  <jiawei@iscas.ac.cn>
+
+	RISC-V: Add instructions and operand set for z[fdq]inx
+	Reuse float instructions in INSN_CLASS_F/D/Q, use riscv_subset_supports to
+	verify if z*inx enabled and use gpr instead of fpr when z*inx is enable.
+
+	bfd/ChangeLog:
+
+	* elfxx-riscv.c (riscv_multi_subset_supports): Added support for
+	  z*inx extension.
+
+	gas/ChangeLog:
+
+	* config/tc-riscv.c (riscv_ip): Added register choice for z*inx.
+
+	include/ChangeLog:
+
+	* opcode/riscv.h (enum riscv_insn_class): Reused INSN_CLASS_* for z*inx.
+
+	opcodes/ChangeLog:
+
+	* riscv-dis.c (riscv_disassemble_insn): Added disassemble check for
+	  z*inx.
+	* riscv-opc.c: Reused INSN_CLASS_* for z*inx.
+
+	Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
+
+2021-11-18  jiawei  <jiawei@iscas.ac.cn>
+
+	RISC-V: Add mininal support for z[fdq]inx
+	Minimal support for zfinx, zdinx, zqinx. Like f/d/q, the zqinx
+	imply zdinx and zdinx imply zfinx, where zfinx are not compatible
+	with f/d/q.
+
+	bfd/ChangeLog:
+
+	* elfxx-riscv.c (riscv_implicit_subsets): Added implicit rules
+	for z*inx extensions.
+	(riscv_supported_std_z_ext): Added entries for z*inx.
+	(riscv_parse_check_conflicts): Added conflict check for z*inx.
+
+	Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
+
+2021-11-18  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-17  Przemyslaw Wirkus  <przemyslaw.wirkus@arm.com>
+
+	aarch64: [SME] SVE2 instructions added to support SME
+	This patch is adding new SVE2 instructions added to support SME extension.
+	The following SVE2 instructions are added by the SME architecture:
+	* PSEL,
+	* REVD, SCLAMP and UCLAMP.
+
+	gas/ChangeLog:
+
+		* config/tc-aarch64.c (parse_sme_pred_reg_with_index):
+		New parser.
+		(parse_operands): New parser.
+		* testsuite/gas/aarch64/sme-9-illegal.d: New test.
+		* testsuite/gas/aarch64/sme-9-illegal.l: New test.
+		* testsuite/gas/aarch64/sme-9-illegal.s: New test.
+		* testsuite/gas/aarch64/sme-9.d: New test.
+		* testsuite/gas/aarch64/sme-9.s: New test.
+
+	include/ChangeLog:
+
+		* opcode/aarch64.h (enum aarch64_opnd): New operand
+		AARCH64_OPND_SME_PnT_Wm_imm.
+
+	opcodes/ChangeLog:
+
+		* aarch64-asm.c (aarch64_ins_sme_pred_reg_with_index):
+		New inserter.
+		* aarch64-dis.c (aarch64_ext_sme_pred_reg_with_index):
+		New extractor.
+		* aarch64-opc.c (aarch64_print_operand): Printout of
+		OPND_SME_PnT_Wm_imm.
+		* aarch64-opc.h (enum aarch64_field_kind): New bitfields
+		FLD_SME_Rm, FLD_SME_i1, FLD_SME_tszh, FLD_SME_tszl.
+		* aarch64-tbl.h (OP_SVE_NN_BHSD): New qualifier.
+		(OP_SVE_QMQ): New qualifier.
+		(struct aarch64_opcode): New instructions PSEL, REVD,
+		SCLAMP and UCLAMP.
+		aarch64-asm-2.c: Regenerate.
+		aarch64-dis-2.c: Regenerate.
+		aarch64-opc-2.c: Regenerate.
+
+2021-11-17  Przemyslaw Wirkus  <przemyslaw.wirkus@arm.com>
+
+	aarch64: [SME] Add new SME system registers
+	This patch is adding miscellaneous SME related system registers.
+
+	gas/ChangeLog:
+
+		* testsuite/gas/aarch64/sme-sysreg.d: New test.
+		* testsuite/gas/aarch64/sme-sysreg.s: New test.
+		* testsuite/gas/aarch64/sme-sysreg-illegal.d: New test.
+		* testsuite/gas/aarch64/sme-sysreg-illegal.l: New test.
+		* testsuite/gas/aarch64/sme-sysreg-illegal.s: New test.
+
+	opcodes/ChangeLog:
+
+		* aarch64-opc.c: New system registers id_aa64smfr0_el1,
+		smcr_el1, smcr_el12, smcr_el2, smcr_el3, smpri_el1,
+		smprimap_el2, smidr_el1, tpidr2_el0 and mpamsm_el1.
+
+2021-11-17  Przemyslaw Wirkus  <przemyslaw.wirkus@arm.com>
+
+	aarch64: [SME] Add SME mode selection and state access instructions
+	This patch is adding new SME mode selection and state access instructions:
+	* Add SMSTART and SMSTOP instructions.
+	* Add SVCR system register.
+
+	gas/ChangeLog:
+
+		* config/tc-aarch64.c (parse_sme_sm_za): New parser.
+		(parse_operands): New parser.
+		* testsuite/gas/aarch64/sme-8-illegal.d: New test.
+		* testsuite/gas/aarch64/sme-8-illegal.l: New test.
+		* testsuite/gas/aarch64/sme-8-illegal.s: New test.
+		* testsuite/gas/aarch64/sme-8.d: New test.
+		* testsuite/gas/aarch64/sme-8.s: New test.
+
+	include/ChangeLog:
+
+		* opcode/aarch64.h (enum aarch64_opnd): New operand
+		AARCH64_OPND_SME_SM_ZA.
+		(enum aarch64_insn_class): New instruction classes
+		sme_start and sme_stop.
+
+	opcodes/ChangeLog:
+
+		* aarch64-asm.c (aarch64_ins_pstatefield): New inserter.
+		(aarch64_ins_sme_sm_za): New inserter.
+		* aarch64-dis.c (aarch64_ext_imm): New extractor.
+		(aarch64_ext_pstatefield): New extractor.
+		(aarch64_ext_sme_sm_za): New extractor.
+		* aarch64-opc.c (operand_general_constraint_met_p):
+		New pstatefield value for SME instructions.
+		(aarch64_print_operand): Printout for OPND_SME_SM_ZA.
+		(SR_SME): New register SVCR.
+		* aarch64-opc.h (F_REG_IN_CRM): New register endcoding.
+		* aarch64-opc.h (F_IMM_IN_CRM): New immediate endcoding.
+		(PSTATE_ENCODE_CRM): Encode CRm field.
+		(PSTATE_DECODE_CRM): Decode CRm field.
+		(PSTATE_ENCODE_CRM_IMM): Encode CRm immediate field.
+		(PSTATE_DECODE_CRM_IMM): Decode CRm immediate field.
+		(PSTATE_ENCODE_CRM_AND_IMM): Encode CRm and immediate
+		field.
+		* aarch64-tbl.h (struct aarch64_opcode): New SMSTART
+		and SMSTOP instructions.
+		aarch64-asm-2.c: Regenerate.
+		aarch64-dis-2.c: Regenerate.
+		aarch64-opc-2.c: Regenerate.
+
+2021-11-17  Przemyslaw Wirkus  <przemyslaw.wirkus@arm.com>
+
+	aarch64: [SME] Add LD1x, ST1x, LDR and STR instructions
+	This patch is adding new loads and stores defined by SME instructions.
+
+	gas/ChangeLog:
+
+		* config/tc-aarch64.c (parse_sme_address): New parser.
+		(parse_sme_za_hv_tiles_operand_with_braces): New parser.
+		(parse_sme_za_array): New parser.
+		(output_operand_error_record): Print error details if
+		present.
+		(parse_operands): Support new operands.
+		* testsuite/gas/aarch64/sme-5-illegal.d: New test.
+		* testsuite/gas/aarch64/sme-5-illegal.l: New test.
+		* testsuite/gas/aarch64/sme-5-illegal.s: New test.
+		* testsuite/gas/aarch64/sme-5.d: New test.
+		* testsuite/gas/aarch64/sme-5.s: New test.
+		* testsuite/gas/aarch64/sme-6-illegal.d: New test.
+		* testsuite/gas/aarch64/sme-6-illegal.l: New test.
+		* testsuite/gas/aarch64/sme-6-illegal.s: New test.
+		* testsuite/gas/aarch64/sme-6.d: New test.
+		* testsuite/gas/aarch64/sme-6.s: New test.
+		* testsuite/gas/aarch64/sme-7-illegal.d: New test.
+		* testsuite/gas/aarch64/sme-7-illegal.l: New test.
+		* testsuite/gas/aarch64/sme-7-illegal.s: New test.
+		* testsuite/gas/aarch64/sme-7.d: New test.
+		* testsuite/gas/aarch64/sme-7.s: New test.
+
+	include/ChangeLog:
+
+		* opcode/aarch64.h (enum aarch64_opnd): New operands.
+		(enum aarch64_insn_class): Added sme_ldr and sme_str.
+		(AARCH64_OPDE_UNTIED_IMMS): New operand error kind.
+
+	opcodes/ChangeLog:
+
+		* aarch64-asm.c (aarch64_ins_sme_za_hv_tiles): New inserter.
+		(aarch64_ins_sme_za_list): New inserter.
+		(aarch64_ins_sme_za_array): New inserter.
+		(aarch64_ins_sme_addr_ri_u4xvl): New inserter.
+		* aarch64-asm.h (AARCH64_DECL_OPD_INSERTER): Added
+		ins_sme_za_list, ins_sme_za_array and ins_sme_addr_ri_u4xvl.
+		* aarch64-dis.c (aarch64_ext_sme_za_hv_tiles): New extractor.
+		(aarch64_ext_sme_za_list): New extractor.
+		(aarch64_ext_sme_za_array): New extractor.
+		(aarch64_ext_sme_addr_ri_u4xvl): New extractor.
+		* aarch64-dis.h (AARCH64_DECL_OPD_EXTRACTOR): Added
+		ext_sme_za_list, ext_sme_za_array and ext_sme_addr_ri_u4xvl.
+		* aarch64-opc.c (operand_general_constraint_met_p):
+		(aarch64_match_operands_constraint): Handle sme_ldr, sme_str
+		and sme_misc.
+		(aarch64_print_operand): New operands supported.
+		* aarch64-tbl.h (OP_SVE_QUU): New qualifier.
+		(OP_SVE_QZU): New qualifier.
+		aarch64-asm-2.c: Regenerate.
+		aarch64-dis-2.c: Regenerate.
+		aarch64-opc-2.c: Regenerate.
+
+2021-11-17  Przemyslaw Wirkus  <przemyslaw.wirkus@arm.com>
+
+	aarch64: [SME] Add ZERO instruction
+	This patch is adding ZERO (a list of 64-bit element ZA tiles)
+	instruction.
+
+	gas/ChangeLog:
+
+		* config/tc-aarch64.c (parse_sme_list_of_64bit_tiles):
+		New parser.
+		(parse_operands): Handle OPND_SME_list_of_64bit_tiles.
+		* testsuite/gas/aarch64/sme-4-illegal.d: New test.
+		* testsuite/gas/aarch64/sme-4-illegal.l: New test.
+		* testsuite/gas/aarch64/sme-4-illegal.s: New test.
+		* testsuite/gas/aarch64/sme-4.d: New test.
+		* testsuite/gas/aarch64/sme-4.s: New test.
+
+	include/ChangeLog:
+
+		* opcode/aarch64.h (enum aarch64_opnd): New operand
+		AARCH64_OPND_SME_list_of_64bit_tiles.
+
+	opcodes/ChangeLog:
+
+		* aarch64-opc.c (print_sme_za_list): New printing function.
+		(aarch64_print_operand): Handle OPND_SME_list_of_64bit_tiles.
+		* aarch64-opc.h (enum aarch64_field_kind): New bitfield
+		FLD_SME_zero_mask.
+		* aarch64-tbl.h (struct aarch64_opcode): New ZERO instruction.
+		aarch64-asm-2.c: Regenerate.
+		aarch64-dis-2.c: Regenerate.
+		aarch64-opc-2.c: Regenerate.
+
+2021-11-17  Przemyslaw Wirkus  <przemyslaw.wirkus@arm.com>
+
+	aarch64: [SME] Add MOV and MOVA instructions
+	This patch is adding new MOV (alias) and MOVA SME instruction.
+
+	gas/ChangeLog:
+
+		* config/tc-aarch64.c (enum sme_hv_slice): new enum.
+		(struct reloc_entry): Added ZAH and ZAV registers.
+		(parse_sme_immediate): Immediate parser.
+		(parse_sme_za_hv_tiles_operand): ZA tile parser.
+		(parse_sme_za_hv_tiles_operand_index): Index parser.
+		(parse_operands): Added ZA tile parser calls.
+		(REGNUMS): New macro. Regs with suffix.
+		(REGSET16S): New macro. 16 regs with suffix.
+		* testsuite/gas/aarch64/sme-2-illegal.d: New test.
+		* testsuite/gas/aarch64/sme-2-illegal.l: New test.
+		* testsuite/gas/aarch64/sme-2-illegal.s: New test.
+		* testsuite/gas/aarch64/sme-2.d: New test.
+		* testsuite/gas/aarch64/sme-2.s: New test.
+		* testsuite/gas/aarch64/sme-2a.d: New test.
+		* testsuite/gas/aarch64/sme-2a.s: New test.
+		* testsuite/gas/aarch64/sme-3-illegal.d: New test.
+		* testsuite/gas/aarch64/sme-3-illegal.l: New test.
+		* testsuite/gas/aarch64/sme-3-illegal.s: New test.
+		* testsuite/gas/aarch64/sme-3.d: New test.
+		* testsuite/gas/aarch64/sme-3.s: New test.
+		* testsuite/gas/aarch64/sme-3a.d: New test.
+		* testsuite/gas/aarch64/sme-3a.s: New test.
+
+	include/ChangeLog:
+
+		* opcode/aarch64.h (enum aarch64_opnd): New enums
+		AARCH64_OPND_SME_ZA_HV_idx_src and
+		AARCH64_OPND_SME_ZA_HV_idx_dest.
+		(struct aarch64_opnd_info): New ZA tile vector struct.
+
+	opcodes/ChangeLog:
+
+		* aarch64-asm.c (aarch64_ins_sme_za_hv_tiles):
+		New inserter.
+		* aarch64-asm.h (AARCH64_DECL_OPD_INSERTER):
+		New inserter ins_sme_za_hv_tiles.
+		* aarch64-dis.c (aarch64_ext_sme_za_hv_tiles):
+		New extractor.
+		* aarch64-dis.h (AARCH64_DECL_OPD_EXTRACTOR):
+		New extractor ext_sme_za_hv_tiles.
+		* aarch64-opc.c (aarch64_print_operand):
+		Handle SME_ZA_HV_idx_src and SME_ZA_HV_idx_dest.
+		* aarch64-opc.h (enum aarch64_field_kind): New enums
+		FLD_SME_size_10, FLD_SME_Q, FLD_SME_V and FLD_SME_Rv.
+		(struct aarch64_operand): Increase fields size to 5.
+		* aarch64-tbl.h (OP_SME_BHSDQ_PM_BHSDQ): New qualifiers
+		aarch64-asm-2.c: Regenerate.
+		aarch64-dis-2.c: Regenerate.
+		aarch64-opc-2.c: Regenerate.
+
+2021-11-17  Przemyslaw Wirkus  <przemyslaw.wirkus@arm.com>
+
+	aarch64: [SME] Add SME instructions
+	Patch is adding new SME matrix instructions. Please note additional
+	instructions will be added in following patches.
+
+	gas/ChangeLog:
+
+		* config/tc-aarch64.c (parse_sme_zada_operand):
+		New parser.
+		* config/tc-aarch64.c (parse_reg_with_qual):
+		New reg parser.
+		* config/tc-aarch64.c (R_ZA): New egister type.
+		(parse_operands): New parser.
+		* testsuite/gas/aarch64/sme-illegal.d: New test.
+		* testsuite/gas/aarch64/sme-illegal.l: New test.
+		* testsuite/gas/aarch64/sme-illegal.s: New test.
+		* testsuite/gas/aarch64/sme.d: New test.
+		* testsuite/gas/aarch64/sme.s: New test.
+		* testsuite/gas/aarch64/sme-f64.d: New test.
+		* testsuite/gas/aarch64/sme-f64.s: New test.
+		* testsuite/gas/aarch64/sme-i64.d: New test.
+		* testsuite/gas/aarch64/sme-i64.s: New test.
+
+	include/ChangeLog:
+
+		* opcode/aarch64.h (enum aarch64_opnd): New operands
+		AARCH64_OPND_SME_ZAda_2b, AARCH64_OPND_SME_ZAda_3b and
+		AARCH64_OPND_SME_Pm.
+		(enum aarch64_insn_class): New instruction class sme_misc.
+
+	opcodes/ChangeLog:
+
+		* aarch64-opc.c (aarch64_print_operand):
+		Print OPND_SME_ZAda_2b and OPND_SME_ZAda_3b operands.
+		(verify_constraints): Handle OPND_SME_Pm.
+		* aarch64-opc.h (enum aarch64_field_kind):
+		New bit fields FLD_SME_ZAda_2b, FLD_SME_ZAda_3b and FLD_SME_Pm.
+		* aarch64-tbl.h (OP_SME_ZADA_PN_PM_ZN_S): New qualifier set.
+		(OP_SME_ZADA_PN_PM_ZN_D): New qualifier.
+		(OP_SME_ZADA_PN_PM_ZN_ZM): New qualifier.
+		(OP_SME_ZADA_S_PM_PM_S_S): New qualifier.
+		(OP_SME_ZADA_D_PM_PM_D_D): New qualifier.
+		(OP_SME_ZADA_S_PM_PM_H_H): New qualifier.
+		(OP_SME_ZADA_S_PM_PM_B_B): New qualifier.
+		(OP_SME_ZADA_D_PM_PM_H_H): New qualifier.
+		(SME_INSN): New instruction macro.
+		(SME_F64_INSN): New instruction macro.
+		(SME_I64_INSN): New instruction macro.
+		(SME_INSNC): New instruction macro.
+		(struct aarch64_opcode): New SME instructions.
+		aarch64-asm-2.c: Regenerate.
+		aarch64-dis-2.c: Regenerate.
+		aarch64-opc-2.c: Regenerate.
+
+2021-11-17  Przemyslaw Wirkus  <przemyslaw.wirkus@arm.com>
+
+	aarch64: [SME] Add +sme option to -march
+	This series of patches (tagged [SME]) add support for the Scalable
+	Matrix Extension. Patch introduces new command line options: +sme, +sme-f64 and
+	+sme-i64 to -march command line options.
+
+	gas/ChangeLog:
+
+		* NEWS: Updated docs.
+		* config/tc-aarch64.c: New SME command line options.
+		* doc/c-aarch64.texi: Update docs.
+
+	include/ChangeLog:
+
+		* opcode/aarch64.h (AARCH64_FEATURE_SME): New flag.
+		(AARCH64_FEATURE_SME_F64): New flag.
+		(AARCH64_FEATURE_SME_I64): New flag.
+
+	opcodes/ChangeLog:
+
+		* aarch64-tbl.h (SME): New feature object.
+
+2021-11-17  Jeremy Drake  <cygwin@jdrake.com>
+
+	Set the default DLL chracteristics to 0 for Cygwin based targets.
+		* emultempl/pep.em (DEFAULT_DLL_CHARACTERISTICS): Set to 0 for
+		Cygwin targets.
+		* emultempl/pep.em (DEFAULT_DLL_CHARACTERISTICS): Likewise.
+
+2021-11-17  Nick Clifton  <nickc@redhat.com>
+
+	Fix the linker script parser so that it will recognise the PT_GNU_RELRO segment type, and the linker itself so that it will gracefully handle being unable to assign any sections to such a segment.
+		PR 28452
+	bfd	* elf.c (assign_file_positions_for_non_load_sections): Replace
+		assertion with a warning message.
+
+	ld	* ldgram.y: Add support for PT_GNU_RELRO and PT_GNU_PROPERTY.
+		* ldgram.c: Regenerate.
+
+2021-11-17  Andreas Arnez  <arnez@linux.ibm.com>
+
+	[gdb/build, s390x] Fix build after gdbarch_tdep changes
+	Commit 345bd07cce33 ("gdb: fix gdbarch_tdep ODR violation") changes a
+	declaration in s390-tdep.h from
+
+	   struct gdbarch_tdep { ... };
+
+	to
+
+	   struct s390_gdbarch_tdep : gdbarch_tdep { ... };
+
+	and now requires that gdbarch_tdep has been declared before.  Which is
+	usually the case, except when compiling s390-linux-nat.c, where
+	s390-tdep.h is included before gdbarch.h.  Thus the s390x build errors out
+	with the compiler complaining about a missing class name after the colon.
+
+	Fix this in s390-linux-nat.c, by including gdbarch.h before s390-tdep.h.
+
+2021-11-17  Luis Machado  <luis.machado@linaro.org>
+
+	Expose the BTI BTYPE more explicitly in the registers
+	Augment the register description XML to expose the BTI BTYPE field contained
+	in the CPSR register. It will be displayed like so:
+
+	cpsr           0x60001000          [ EL=0 BTYPE=0 SSBS C Z ]
+
+2021-11-17  H.J. Lu  <hjl.tools@gmail.com>
+
+	elfedit: Add --output-abiversion option to update ABIVERSION
+		* NEWS: Mention --output-abiversion.
+		* elfedit.c (input_elf_abiversion): New.
+		(output_elf_abiversion): Likewise.
+		(update_elf_header): Update EI_ABIVERSION.
+		(command_line_switch): Add OPTION_INPUT_ABIVERSION and
+		OPTION_OUTPUT_ABIVERSION.
+		(options): Add --input-abiversion and --output-abiversion.
+		(usage): Likewise.
+		(main): Handle --input-abiversion and --output-abiversion.
+		* doc/binutils.texi: Document --input-abiversion and
+		--output-abiversion.
+		* testsuite/binutils-all/elfedit.exp: Run elfedit-6.
+		* testsuite/binutils-all/elfedit-6.d: New file.
+
+2021-11-17  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: Support rvv extension with released version 1.0.
+	2021-11-17  Jim Wilson  <jimw@sifive.com>
+	            Kito Cheng  <kito.cheng@sifive.com>
+	            Nelson Chu  <nelson.chu@sifive.com>
+
+	This patch is porting from the following riscv github,
+	https://github.com/riscv/riscv-binutils-gdb/tree/rvv-1.0.x
+
+	And here is the vector spec,
+	https://github.com/riscv/riscv-v-spec
+
+	bfd/
+		* elfxx-riscv.c (riscv_implicit_subsets): Added imply rules
+		of v, zve and zvl extensions.
+		(riscv_supported_std_ext): Updated verison of v to  1.0.
+		(riscv_supported_std_z_ext): Added zve and zvl extensions.
+		(riscv_parse_check_conflicts): The zvl extensions need to
+		enable either v or zve extension.
+		(riscv_multi_subset_supports): Check the subset list to know
+		if the INSN_CLASS_V and INSN_CLASS_ZVEF instructions are supported.
+	gas/
+		* config/tc-riscv.c (enum riscv_csr_class): Added CSR_CLASS_V.
+		(enum reg_class): Added RCLASS_VECR and RCLASS_VECM.
+		(validate_riscv_insn): Check whether the rvv operands are valid.
+		(md_begin): Initialize register hash for rvv registers.
+		(macro_build): Added rvv operands when expanding rvv pseudoes.
+		(vector_macro): Expand rvv macros into one or more instructions.
+		(macro): Likewise.
+		(my_getVsetvliExpression): Similar to my_getVsetvliExpression,
+		but used for parsing vsetvli operands.
+		(riscv_ip): Parse and encode rvv operands.  Besides, The rvv loads
+		and stores with EEW 64 cannot be used when zve32x is enabled.
+		* testsuite/gas/riscv/priv-reg-fail-version-1p10.d: Updated -march
+		to rv32ifv_zkr.
+		* testsuite/gas/riscv/priv-reg-fail-version-1p11.d: Likewise.
+		* testsuite/gas/riscv/priv-reg-fail-version-1p9p1.d: Likewise.
+		* testsuite/gas/riscv/priv-reg.s: Added rvv csr testcases.
+		* testsuite/gas/riscv/priv-reg-version-1p10.d: Likewise.
+		* testsuite/gas/riscv/priv-reg-version-1p11.d: Likewise.
+		* testsuite/gas/riscv/priv-reg-version-1p9p1.d: Likewise.
+		* testsuite/gas/riscv/march-imply-v.d: New testcase.
+		* testsuite/gas/riscv/vector-insns-fail-zve32xf.d: Likewise.
+		* testsuite/gas/riscv/vector-insns-fail-zve32xf.l: Likewise.
+		* testsuite/gas/riscv/vector-insns-fail-zvl.d: Likewise.
+		* testsuite/gas/riscv/vector-insns-fail-zvl.l: Likewise.
+		* testsuite/gas/riscv/vector-insns-vmsgtvx.d: Likewise.
+		* testsuite/gas/riscv/vector-insns-vmsgtvx.s: Likewise.
+		* testsuite/gas/riscv/vector-insns-zero-imm.d: Likewise.
+		* testsuite/gas/riscv/vector-insns-zero-imm.s: Likewise.
+		* testsuite/gas/riscv/vector-insns.d: Likewise.
+		* testsuite/gas/riscv/vector-insns.s: Likewise.
+	include/
+		* opcode/riscv-opc.h: Defined mask/match encodings and csrs for rvv.
+		* opcode/riscv.h: Defined rvv immediate encodings and fields.
+		(enum riscv_insn_class): Added INSN_CLASS_V and INSN_CLASS_ZVEF.
+		(INSN_V_EEW64): Defined.
+		(M_VMSGE, M_VMSGEU): Added for the rvv pseudoes.
+	opcodes/
+		* riscv-dis.c (print_insn_args): Dump the rvv operands.
+		* riscv-opc.c (riscv_vecr_names_numeric): Defined rvv registers.
+		(riscv_vecm_names_numeric): Likewise.
+		(riscv_vsew): Likewise.
+		(riscv_vlmul): Likewise.
+		(riscv_vta): Likewise.
+		(riscv_vma): Likewise.
+		(match_vs1_eq_vs2): Added for rvv Vu operand.
+		(match_vd_eq_vs1_eq_vs2): Added for rvv Vv operand.
+		(riscv_opcodes): Added rvv v1.0 instructions.
+
+2021-11-17  Sergei Trofimovich  <siarheit@google.com>
+
+	gdb/nat/linux-osdata.c: fix build on gcc-12 (string overfow)
+	On gcc-12 build fails as:
+
+	    ../../gdbserver/../gdb/nat/linux-osdata.c: In function 'void linux_xfer_osdata_processes(buffer*)':
+	    ../../gdbserver/../gdb/nat/linux-osdata.c:330:39: error:
+	      '__builtin___sprintf_chk' may write a terminating nul past the end of the destination [-Werror=format-overflow=]
+	      330 |                 sprintf (core_str, "%d", i);
+	          |                                       ^
+
+	It's an off-by-one case in an infeasible scenario for negative
+	huge core count. The change switches to std::string for memory
+	handling.
+
+	Tested by running 'info os processes' and checking CPU cores column.
+
+2021-11-17  Aaron Merey  <amerey@redhat.com>
+
+	gdb: Add aliases for read_core_file_mappings callbacks
+	Add aliases read_core_file_mappings_loop_ftype and
+	read_core_file_mappings_pre_loop_ftype.  Intended for use with
+	read_core_file_mappings.
+
+	Also add build_id parameter to read_core_file_mappings_loop_ftype.
+
+2021-11-17  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: testsuite: add support for $pwd replacements
+	Extend the common test framework to support $pwd replacements in
+	settings.  This allows replacing the custom cris @exedir@ with it.
+
+	sim: cris: replace @srcdir@ test extension with $srcdir/$subdir
+	The common framework supports $srcdir & $subdir replacements already,
+	so replace the custom @srcdir@ logic with those.  Since the replace
+	happens in slurp_options that cris already uses, we don't have any
+	logic to port over there.  We have to duplicate that into the cris
+	slurp_rv helper though.
+
+2021-11-17  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: cris: drop custom "dynamic" test field
+	This tag is used to force tests to be built dynamically (i.e. without
+	-static linking).  This is because cris-sim.exp in dejagnu turns on
+	static linking in ldflags.
+
+	The default configs and runtest flags shouldn't load these boards.
+	If these settings are still needed, we should figure out a different
+	way of suppressing the stock settings wholesale.  We want these to
+	all pass out of the box with little to no configuration so that they
+	can run in a multitarget build.
+
+	With dropping "dynamic", it'll be easier to merge the custom cris
+	test logic with the common sim test logic.
+
+2021-11-17  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: testsuite: add more silent build rules
+	site.exp is still verbose, but that comes from automake, so have
+	to get it fixed upstream.
+
+2021-11-17  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-16  Sergei Trofimovich  <siarheit@google.com>
+
+	sim: cr16: fix build on gcc-12 (NULL comparison)
+	On gcc-12 build fails as:
+
+	    sim/cr16/interp.c: In function 'lookup_hash':
+	    sim/cr16/interp.c:89:25: error:
+	      the comparison will always evaluate as 'true'
+	      for the address of 'mnimonic' will never be NULL [-Werror=address]
+	       89 |   if ((h->ops->mnimonic != NULL) &&
+	          |                         ^~
+
+	'mnimonic' is a sharr array within ops. It can never be NULL.
+
+	While at it renamed 'mnimonic' to 'mnemonic'.
+
+2021-11-16  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: fix length of array view returned by some value_contents functions
+	In commit 50888e42dcd3 ("gdb: change functions returning value contents
+	to use gdb::array_view"), I believe I made a mistake with the length of
+	the array views returned by some functions.  All functions return a view
+	of `TYPE_LENGTH (value_type (type))` length.  This is not correct when
+	the value's enclosing type is larger than the value's type.  In that
+	case, the value's contents buffer is of the size of the enclosing type,
+	and the value's actual contents is a slice of that (as returned by
+	value_contents).  So, functions value_contents_all_raw,
+	value_contents_for_printing and value_contents_for_printing_const are
+	not correct.  Since they are meant to return the value's contents buffer
+	as a whole, they should have the size of the enclosing type.
+
+	There is nothing that uses the returned array view size at the moment,
+	so this didn't cause a problem.  But it became apparent when trying to
+	adjust some callers.
+
+	Change-Id: Ib4e8837e1069111d2b2784d3253d5f3002419e68
+
+2021-11-16  Fangrui Song  <maskray@google.com>
+
+	readelf: Support SHT_RELR/DT_RELR for -r
+	The -r output for SHT_RELR looks like:
+
+	Relocation section '.relr.dyn' at offset 0x530 contains 4 entries:
+	  7 offsets
+	00000000000028c0
+	00000000000028c8
+	0000000000003ad0
+	0000000000003ad8
+	0000000000003ae0
+	0000000000003ae8
+	0000000000003af0
+
+	For --use-dynamic, the header looks like
+
+	    'RELR' relocation section at offset 0x530 contains 32 bytes:
+
+	include/
+	    * elf/common.h (DT_ENCODING): Bump to 38.
+	    * elf/external.h (Elf32_External_Relr): New.
+	    (Elf64_External_Relr): New.
+	binutils/
+	    * readelf.c (enum relocation_type): New.
+	    (slurp_relr_relocs): New.
+	    (dump_relocations): Change is_rela to rel_type.
+	    Dump RELR.
+	    (dynamic_relocations): Add DT_RELR.
+	    (process_relocs): Check SHT_RELR and DT_RELR.
+	    (process_dynamic_section): Store into dynamic_info for
+	    DT_RELR/DT_RELRENT/DT_RELRSZ.
+
+2021-11-16  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdbsupport: remove FUNCTION_NAME
+	__func__ is standard C++11:
+
+	    https://en.cppreference.com/w/cpp/language/function
+
+	Also, in C++11, __func__ expands to the demangled function name, so the
+	mention in the comment above FUNCTION_NAME doesn't apply anymore.
+	Finally, in places where FUNCTION_NAME is used, I think it's enough to
+	print the function name, no need to print the whole signature.
+	Therefore, I propose to just remove FUNCTION_NAME and update users to
+	use the standard __func__.
+
+	Change-Id: I778f28155422b044402442dc18d42d0cded1017d
+
+2021-11-16  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/gdbsupport: make xstrprintf and xstrvprintf return a unique_ptr
+	The motivation is to reduce the number of places where unmanaged
+	pointers are returned from allocation type routines.  All of the
+	callers are updated.
+
+	There should be no user visible changes after this commit.
+
+2021-11-16  Andrew Burgess  <aburgess@redhat.com>
+
+	gdbsupport: move xfree into its own file
+	In the next commit I'd like to reference gdb_unique_ptr within the
+	common-utils.h file.  However, this requires that I include
+	gdb_unique_ptr.h, which requires that xfree be defined.
+
+	Interestingly, gdb_unique_ptr.h doesn't actually include anything that
+	defines xfree, but I was finding that when I added a gdb_unique_ptr.h
+	include to common-utils.h I was getting a dependency cycle; before my
+	change xfree was defined when gdb_unique_ptr.h was processed, while
+	after my change it was not, and this made g++ unhappy.
+
+	To break this cycle, I propose to move xfree into its own header file,
+	gdb-xfree.h, which I'll then include into gdb_unique_ptr.h and
+	common-utils.cc.
+
+2021-11-16  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb: throw OPTIMIZED_OUT_ERROR rather than GENERIC_ERROR
+	While reviewing this patch:
+
+	  https://sourceware.org/pipermail/gdb-patches/2021-November/183227.html
+
+	I spotted that the patch could be improved if we threw
+	OPTIMIZED_OUT_ERROR rather than GENERIC_ERROR in a few places.
+
+	This commit updates error_value_optimized_out and
+	require_not_optimized_out to throw OPTIMIZED_OUT_ERROR.
+
+	I ran the testsuite and saw no regressions.  This doesn't really
+	surprise me, we don't usually write code like:
+
+	  catch (const gdb_exception_error &ex)
+	    {
+	      (if ex.error == GENERIC_ERROR)
+	        ...
+	      else
+	        ...
+	    }
+
+	There are a three places where we write something like:
+
+	  catch (const gdb_exception_error &ex)
+	    {
+	      (if ex.error == OPTIMIZED_OUT_ERROR)
+	        ...
+	    }
+
+	In frame.c:unwind_pc, stack.c:info_frame_command_core, and
+	value.c:value_optimized_out, but if we are hitting these cases then
+	it's not significantly changing GDB's behaviour.
+
+2021-11-16  Tom Tromey  <tromey@adacore.com>
+
+	Remove config.cache in gdbserver's "distclean"
+	PR gdb/28586 points out that "make distclean" fails to delete
+	config.cache from gdbserver/.  This patch fixes the bug, and removes a
+	duplicate "Makefile" deletion that was also pointed out in the PR.
+
+2021-11-16  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Remove inferior output in gdb.base/foll-vfork.exp
+	Test-case gdb.base/foll-vfork.exp has inferior output that is not needed, but
+	which makes the regexp matching more difficult (see commit 1f28b70def1
+	"[gdb/testsuite] Fix regexp in gdb.base/foll-vfork.exp").
+
+	Remove the inferior output, and revert commit 1f28b70def1 to make the matching
+	more restrictive.
+
+	Tested on x86_64-linux.
+
+2021-11-16  H.J. Lu  <hjl.tools@gmail.com>
+
+	x86: Don't allow KMOV in TLS code sequences
+	Don't allow KMOV in TLS code sequences which require integer MOV
+	instructions.
+
+		PR target/28595
+		* config/tc-i386.c (match_template): Don't allow KMOV in TLS
+		code sequences.
+		* testsuite/gas/i386/i386.exp: Run inval-tls and x86-64-inval-tls
+		tests.
+		* testsuite/gas/i386/inval-tls.l: New file.
+		* testsuite/gas/i386/inval-tls.s: Likewise.
+		* testsuite/gas/i386/x86-64-inval-tls.l: Likewise.
+		* testsuite/gas/i386/x86-64-inval-tls.s: Likewise.
+
+2021-11-16  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: run: support concise env var settings
+	Support the same syntax as other common utilities where env vars can
+	be specified before the program to be run without an explicit option.
+
+	This behavior can be suppressed by using the -- marker.
+
+2021-11-16  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: nrun: add --env-{set,unset,clear} command line options
+	Provide explicit control over the program's environment with the
+	basic set/unset/clear options.  These are a bit clunky to use,
+	but they're functional.
+
+	The env set operation is split out into a separate function as it'll
+	be used in the next commit.
+
+	With these in place, we can adjust the custom cris testsuite to use
+	the now standard options and not its one-off hack.
+
+2021-11-16  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: syscall: hoist argc/argn/argnlen to common code
+	Now that the callback framework supports argv & envp, we can move
+	the Blackfin implementation of these syscalls to the common code.
+
+	sim: syscall: fix argvlen & argv implementation
+	Now that we have access to the argv & envp strings, finish implementing
+	these syscalls.  Delete unused variables, fix tbuf by incrementing the
+	pointer instead of setting to the length, and make sure we don't write
+	more data than the bufsize says is available.
+
+	sim: callback: expose argv & environ
+	Pass the existing strings data to the callbacks so that common
+	libgloss syscalls can be implemented (which we'll do shortly).
+
+2021-11-16  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: keep track of program environment strings
+	We've been passing the environment strings to sim_create_inferior,
+	but most ports don't do anything with them.  A few will use ad-hoc
+	logic to stuff the stack for user-mode programs, but that's it.
+
+	Let's formalize this across the board by storing the strings in the
+	normal sim state.  This will allow (in future commits) supporting
+	more functionality in the run interface, and to unify some of the
+	libgloss syscalls.
+
+2021-11-16  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: iq2000: fix some missing prototypes warnings
+	Turns out some of these were hiding real bugs like not passing the
+	pc variable down.
+
+2021-11-16  jiawei  <jiawei@iscas.ac.cn>
+
+	RISC-V: Scalar crypto instruction and entropy source CSR testcases.
+	Add testcases for Scalar Crypto extension, with total testcase contain all
+	instructions in k-ext/k-ext-64 and sub-extension testcase for zbk* zk*. Also
+	add testcase for new CSR name 'seed' which is the Entropy Source in zkr.
+
+	In fact these whole testcases can be combined into one file, after we have
+	supported the .option arch +-= directives.
+
+	gas/
+		* testsuite/gas/riscv/k-ext-64.d: New testcase for crypto instructions.
+		* testsuite/gas/riscv/k-ext-64.s: Likewise.
+		* testsuite/gas/riscv/k-ext.d: Likewise.
+		* testsuite/gas/riscv/k-ext.s: Likewise.
+		* testsuite/gas/riscv/zbkb-32.d: Likewise.
+		* testsuite/gas/riscv/zbkb-32.s: Likewise.
+		* testsuite/gas/riscv/zbkb-64.d: Likewise.
+		* testsuite/gas/riscv/zbkb-64.s: Likewise.
+		* testsuite/gas/riscv/zbkc-32.d: Likewise.
+		* testsuite/gas/riscv/zbkc-64.d: Likewise.
+		* testsuite/gas/riscv/zbkc.s: Likewise.
+		* testsuite/gas/riscv/zbkx-32.d: Likewise.
+		* testsuite/gas/riscv/zbkx-64.d: Likewise.
+		* testsuite/gas/riscv/zbkx.s: Likewise.
+		* testsuite/gas/riscv/zknd-32.d: Likewise.
+		* testsuite/gas/riscv/zknd-32.s: Likewise.
+		* testsuite/gas/riscv/zknd-64.d: Likewise.
+		* testsuite/gas/riscv/zknd-64.s: Likewise.
+		* testsuite/gas/riscv/zkne-32.d: Likewise.
+		* testsuite/gas/riscv/zkne-32.s: Likewise.
+		* testsuite/gas/riscv/zkne-64.d: Likewise.
+		* testsuite/gas/riscv/zkne-64.s: Likewise.
+		* testsuite/gas/riscv/zknh-32.d: Likewise.
+		* testsuite/gas/riscv/zknh-32.s: Likewise.
+		* testsuite/gas/riscv/zknh-64.d: Likewise.
+		* testsuite/gas/riscv/zknh-64.s: Likewise.
+		* testsuite/gas/riscv/zksed-32.d: Likewise.
+		* testsuite/gas/riscv/zksed-64.d: Likewise.
+		* testsuite/gas/riscv/zksed.s: Likewise.
+		* testsuite/gas/riscv/zksh-32.d: Likewise.
+		* testsuite/gas/riscv/zksh-64.d: Likewise.
+		* testsuite/gas/riscv/zksh.s: Likewise.
+		* testsuite/gas/riscv/priv-reg-fail-zkr.d: New testcase for zkr
+		csr check.
+		* testsuite/gas/riscv/priv-reg-fail-zkr.l: Likewise.
+		* testsuite/gas/riscv/priv-reg-fail-version-1p10.d: Updated march to
+		rv32if_zkr.
+		* testsuite/gas/riscv/priv-reg-fail-version-1p11.d: Likewise.
+		* testsuite/gas/riscv/priv-reg-fail-version-1p9p1.d: Likewise.
+		* testsuite/gas/riscv/priv-reg-version-1p10.d: Added Crypto seed csr.
+		* testsuite/gas/riscv/priv-reg-version-1p11.d: Likewise.
+		* testsuite/gas/riscv/priv-reg-version-1p9p1.d: Likewise.
+		* testsuite/gas/riscv/priv-reg.s: Likewise.
+
+2021-11-16  jiawei  <jiawei@iscas.ac.cn>
+
+	RISC-V: Scalar crypto instructions and operand set.
+	Add instructions in k-ext, some instruction in zbkb, zbkc is reuse from
+	zbb,zbc, we just change the class attribute to make them both support.
+	The 'aes64ks1i' and 'aes64ks2' instructions are present in both the Zknd
+	and Zkne extensions on rv64.  Add new operand letter 'y' to present 'bs'
+	symbol and 'Y' to present 'rnum' symbolc  for zkn instructions.  Also add
+	a new Entropy Source CSR define 'seed' located at address 0x015.
+
+	bfd/
+		* elfxx-riscv.c (riscv_multi_subset_supports): Added support for
+		crypto extension.
+	gas/
+		*config/tc-riscv.c (enum riscv_csr_class): Added CSR_CLASS_ZKR.
+		(riscv_csr_address): Checked for CSR_CLASS_ZKR.
+		(validate_riscv_insn): Added y and Y for bs and rnum operands.
+		(riscv_ip): Handle y and Y operands.
+	include/
+		* opcode/riscv-opc.h: Added encodings of crypto instructions.
+		Also defined new csr seed, which address is 0x15.
+		* opcode/riscv.h: Defined OP_* and INSN_CLASS_* for crypto.
+	opcodes/
+		* riscv-dis.c (print_insn_args): Recognized new y and Y operands.
+		* riscv-opc.c (riscv_opcodes): Added crypto instructions.
+
+2021-11-16  jiawei  <jiawei@iscas.ac.cn>
+
+	RISC-V: Minimal support of scalar crypto extension.
+	Minimal support of scalar crypto extension, add "k" in the
+	riscv_supported_std_ext, to make the order check right with
+	"zk" behind "zb".
+
+	bfd/
+		* elfxx-riscv.c (riscv_implicit_subsets): Added implicit
+		rules for zk* extensions.
+		(riscv_supported_std_ext): Added entry for k.
+		(riscv_supported_std_z_ext): Added entries for zk*.
+
+2021-11-16  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: rework "set debuginfod" commands
+	As discussed here [1], do some re-work in the "set debuginfod commands".
+
+	First, use "set debuginfod enabled on/off/ask" instead of "set
+	debuginfod on/off/ask".  This is more MI-friendly, and it gives an
+	output that makes more sense in "info set", for example.
+
+	Then, make the show commands not call "error" when debuginfod support is
+	not compiled in.  This makes the commands "show" and "show debuginfod"
+	stop early, breaking gdb.base/default.exp:
+
+	    Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/default.exp ...
+	    FAIL: gdb.base/default.exp: info set
+	    FAIL: gdb.base/default.exp: show
+
+	 - Make the "debuginfod enabled" setting default to "off" when debuginfod
+	   support is not compiled in, and "ask" otherwise.
+	 - Make the setter of "debuginfod enabled" error out when debuginfod
+	   support is not compiled in, so that "debuginfod enabled" will always
+	   remain "off" in that case.
+	 - Make the setter of "debuginfod verbose" work in any case.  I don't
+	   see the harm in letting the user change that setting, since the user will
+	   hit an error if they try to enable the use of debuginfod.
+	 - I would do the same for the "debuginfod urls" setter, but because
+	   this one needs to see the DEBUGINFOD_URLS_ENV_VAR macro, provided by
+	   libdebuginfod, I made that one error out as well if debuginfod
+	   support is not compiled it (otherwise, I would have left it like
+	   "debuginfod verbose".  Alternatively, we could hard-code
+	   "DEBUGINFOD_URLS" in the code (in fact, it was prior to this patch,
+	   but I think it was an oversight, as other spots use
+	   DEBUGINFOD_URLS_ENV_VAR), or use a dummy string to store the setting,
+	   but I don't really see the value in that.
+
+	Rename debuginfod_enable to debuginfod_enabled, just so it matches the
+	setting name.
+
+	[1] https://sourceware.org/pipermail/gdb-patches/2021-October/182937.html
+
+	Change-Id: I45fdb2993f668226a5639228951362b7800f09d5
+	Co-Authored-By: Aaron Merey <amerey@redhat.com>
+
+2021-11-16  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: adjust gdbarch_tdep calls in nat files
+	Commit 345bd07cce33 ("gdb: fix gdbarch_tdep ODR violation") forgot to
+	update the gdbarch_tdep calls in the native files other than x86-64
+	Linux.  This patch updates them all (to the best of my knowledge).
+	These are the files I was able to build-test:
+
+	  aarch64-linux-nat.c
+	  amd64-bsd-nat.c
+	  arm-linux-nat.c
+	  ppc-linux-nat.c
+	  windows-nat.c
+	  xtensa-linux-nat.c
+
+	And these are the ones I could not build-test:
+
+	  aix-thread.c
+	  arm-netbsd-nat.c
+	  ppc-fbsd-nat.c
+	  ppc-netbsd-nat.c
+	  ia64-tdep.c (the part that needs libunwind)
+	  ppc-obsd-nat.c
+	  rs6000-nat.c
+
+	If there are still some build problems related to gdbarch_tdep in them,
+	they should be pretty obvious to fix.
+
+	Change-Id: Iaa3d791a850e4432973757598e634e3da6061428
+
+2021-11-16  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove unused variables in xtensa-linux-nat.c
+	While build-testing this file, the compiler complained about these two
+	unused variables, remove them.
+
+	Change-Id: I3c54f779f12c16ef6184af58aca75eaad042ce4e
+
+2021-11-16  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: add arc-newlib-tdep.c to ALL_TARGET_OBS
+	This file is currently not compiled in an --enable-targets=all build,
+	but it should be.  Add it to ALL_TARGET_OBS.
+
+	Update the gdbarch_tdep call that commit 345bd07cce33 ("gdb: fix
+	gdbarch_tdep ODR violation") forgot to update.
+
+	Change-Id: I86248a01493eea5e70186e9c46a298ad3994b034
+
+2021-11-16  Jim Wilson  <wilson@tuliptree.org>
+
+	Update my email address.
+	I've left SiFive and have a new gmail account because it is convenient
+	to use with git send-email.  I'm planning to use this for my RISC-V
+	work.  My tuliptree address still works, it just isn't as convenient.
+
+		binutils:
+		* MAINTAINERS (RISC-V): Update my address.
+
+2021-11-16  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-15  Tom de Vries  <tdevries@suse.de>
+
+	[gdb] Don't use gdb_stdlog for inferior-events
+	The test-case gdb.base/foll-vfork.exp contains:
+	...
+	if [gdb_debug_enabled] {
+	    untested "debug is enabled"
+	    return 0
+	}
+	...
+
+	To understand what it does, I disabled this bit and ran with GDB_DEBUG=infrun,
+	like so:
+	...
+	$ cd $build/gdb/testsuite
+	$ make check GDB_DEBUG=infrun RUNTESTFLAGS=gdb.base/foll-vfork.exp
+	...
+	and ran into:
+	...
+	(gdb) PASS: gdb.base/foll-vfork.exp: exec: \
+	  vfork parent follow, through step: set follow-fork parent
+	next^M
+	33        if (pid == 0) {^M
+	(gdb) FAIL: gdb.base/foll-vfork.exp: exec: \
+	  vfork parent follow, through step: step
+	...
+
+	The problem is that the test-case expects:
+	...
+	(gdb) PASS: gdb.base/foll-vfork.exp: exec: \
+	  vfork parent follow, through step: set follow-fork parent
+	next^M
+	[Detaching after vfork from child process 28169]^M
+	33        if (pid == 0) {^M
+	(gdb) PASS: gdb.base/foll-vfork.exp: exec: \
+	  vfork parent follow, through step: step
+	...
+	but the "Detaching" line has been redirected to
+	$outputs/gdb.base/foll-vfork/gdb.debug.
+
+	I looked at the documentation of "set logging debugredirect [on|off]":
+	...
+	  By default, GDB debug output will go to both the terminal and the logfile.
+	  Set debugredirect if you want debug output to go only to the log file.
+	...
+	and my interpretation of it was that "debug output" did not match the
+	"messages" description of inferior-events:
+	...
+	The set print inferior-events command allows you to enable or disable printing
+	of messages when GDB notices that new inferiors have started or that inferiors
+	have exited or have been detached.
+	...
+
+	Fix the discrepancy by not using gdb_stdlog for inferior-events.
+
+	Update the gdb.base/foll-vfork.exp test-case to not require
+	gdb_debug_enabled == 0.
+
+	Tested on x86_64-linux.
+
+	Tested test-case gdb.base/foll-vfork.exp with and without GDB_DEBUG=infrun.
+
+2021-11-15  Roland McGrath  <mcgrathr@google.com>
+
+	ld: Fix testsuite failures under --enable-textrel-check=error
+	ld/
+		* testsuite/ld-aarch64/dt_textrel.d: Pass explicit -z notext in
+		case ld was configured with --enable-textrel-check=error.
+		* testsuite/ld-aarch64/pr22764.d: Likewise.
+		* testsuite/ld-aarch64/pr20402.d: Likewise.
+
+2021-11-15  Luis Machado  <luis.machado@linaro.org>
+
+	Extend the prologue analyzer to handle the bti instruction
+	Handle the BTI instruction in the prologue analyzer. The patch handles all
+	the variations of the BTI instruction.
+
+2021-11-15  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: fix gdbarch_tdep ODR violation
+	I would like to be able to use non-trivial types in gdbarch_tdep types.
+	This is not possible at the moment (in theory), because of the one
+	definition rule.
+
+	To allow it, rename all gdbarch_tdep types to <arch>_gdbarch_tdep, and
+	make them inherit from a gdbarch_tdep base class.  The inheritance is
+	necessary to be able to pass pointers to all these <arch>_gdbarch_tdep
+	objects to gdbarch_alloc, which takes a pointer to gdbarch_tdep.
+
+	These objects are never deleted through a base class pointer, so I
+	didn't include a virtual destructor.  In the future, if gdbarch objects
+	deletable, I could imagine that the gdbarch_tdep objects could become
+	owned by the gdbarch objects, and then it would become useful to have a
+	virtual destructor (so that the gdbarch object can delete the owned
+	gdbarch_tdep object).  But that's not necessary right now.
+
+	It turns out that RISC-V already has a gdbarch_tdep that is
+	non-default-constructible, so that provides a good motivation for this
+	change.
+
+	Most changes are fairly straightforward, mostly needing to add some
+	casts all over the place.  There is however the xtensa architecture,
+	doing its own little weird thing to define its gdbarch_tdep.  I did my
+	best to adapt it, but I can't test those changes.
+
+	Change-Id: Ic001903f91ddd106bd6ca09a79dabe8df2d69f3b
+
+2021-11-15  Clément Chigot  <clement.chigot@atos.net>
+
+	COFF: avoid modifications over C_FILE filename aux entries.
+	Commit e86fc4a5bc37 ("PR 28447: implement multiple parameters for .file
+	on XCOFF") introduces C_FILE entries which can store additional
+	information.
+	However, some modifications are needed by them but not by the original
+	C_FILE entries, usually representing the filename.
+	This patch ensures that filename entries are kept as is, in order to
+	protect targets not supporting the additional entries.
+
+		* coffgen.c (coff_write_symbol): Protect filename entries
+		(coff_write_symbols): Likewise.
+		(coff_print_symbol): Likewise.
+
+2021-11-15  Eric Botcazou  <ebotcazou@gcc.gnu.org>
+
+	Deal with full path in .file 0 directive
+	Gas uses the directory part, if present, of the .file 0 directive to set
+	entry 0 of the directory table in DWARF 5, which represents the "current
+	directory".
+
+	Now Gas also uses the file part of the same directive to set entry 0 of the
+	file table, which represents the "current compilation file".  But the latter
+	need not be located in the former so GCC will use a full path in the file
+	part when it is passed a full path:
+
+	gcc -c /full/path/test.c -save-temps
+
+	yields:
+
+	 .file 0 "/current/directory" "/full/path/test.c"
+
+	in the assembly file and:
+
+	 The Directory Table (offset 0x22, lines 2, columns 1):
+	  Entry Name
+	  0     (indirect line string, offset: 0x25): /current/directory
+	  1     (indirect line string, offset: 0x38): /full/path
+
+	 The File Name Table (offset 0x30, lines 2, columns 2):
+	  Entry Dir     Name
+	  0     0       (indirect line string, offset: 0x43): /full/path/test.c
+
+	in the object file.  Note the full path and the questionable Dir value in
+	the 0 entry of the file table.
+
+2021-11-15  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: cris: make error message test a little more flexible
+	The point of this test is to just make sure the usage text is shown,
+	not the exact details of the usage text.  So shorten the output test
+	to match the beginning.  This fixes breakage when the output changed
+	slightly to include [--].
+
+	sim: run: fix crash in argc==0 error situation
+	The new argv processing code assumed that we were always passed a
+	command line.  If we weren't, make sure we don't crash before we
+	get a chance to output an error message about incorrect usage.
+
+	sim: cris: touch up rvdummy handling
+	Add quiet build support and make sure it's removed with `make clean`.
+
+	sim: cris: replace custom "dest" test field with new --argv0
+	The #dest field used in the cris testsuite is a bit of hack to set the
+	argv[0] for the tests to read out later on.  Now that the sim has an
+	option to set argv[0] explicitly, we don't need this custom field, so
+	let's drop it to harmonize the testsuites a little.
+
+	sim: run: add --argv0 option to control argv[0]
+	We default argv[0] to the program we run which is a standard *NIX
+	convention, but sometimes we want to be able to control the argv[0]
+	setting independently (especially for programs that inspect argv[0]
+	to change their behavior or output).  Add an option to control it.
+
+2021-11-15  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: split program path out of argv vector
+	We use the program argv to both find the program to run (argv[0]) and
+	to hold the arguments to the program.  Most of the time this is fine,
+	but if we want to let programs specify argv[0] independently (which is
+	possible in standard *NIX programs), this double duty doesn't work.
+
+	So let's split the path to the program to run out into a separate
+	field by itself.  This simplifies the various sim_open funcs too.
+
+	By itself, this code is more of a logical cleanup than something that
+	is super useful.  But it will open up customization of argv[0] in a
+	follow up commit.  Split the changes to make it easier to review.
+
+2021-11-15  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: bfin: fix mach/xfail usage in tests
+	Set the mach to the right value all the time, and update xfail to
+	say the test fails on all targets.  WIth multitarget testing, the
+	idea of target here doesn't make much sense.
+
+2021-11-15  Alan Modra  <amodra@gmail.com>
+
+	-Waddress fixes for gold testsuite
+	Current mainline gcc.
+	common_test_1.c: In function 'main':
+	common_test_1.c:56:14: error: comparison between two arrays [-Werror=array-compare]
+	   56 |   assert (c5 > c4);
+	      |              ^
+	common_test_1.c:56:14: note: use '&c5[0] > &c4[0]' to compare the addresses
+
+		* testsuite/common_test_1.c: Avoid -Waddress warnings.
+		* testsuite/common_test_1_v1.c: Likewise.
+		* testsuite/common_test_1_v2.c: Likewise.
+		* testsuite/script_test_2.cc: Likewise.
+
+2021-11-15  Alan Modra  <amodra@gmail.com>
+
+	PowerPC64 @notoc in non-power10 code
+	R_PPC64_REL24_P9NOTOC is a variant of R_PPC64_REL24_NOTOC for use on
+	@notoc cals from non-power10 code in the rare case that using such a
+	construct is useful.  R_PPC64_REL24_P9NOTOC will be emitted by gas
+	rather than R_PPC64_REL24_NOTOC when @notoc is used in a branch
+	instruction if power10 instructions are not enabled at that point.
+	The new relocation tells the linker to not use power10 instructions on
+	any stub emitted for that branch, unless overridden by
+	--power10-stubs=yes.
+
+	The current linker heuristic of only generating power10 instructions
+	for stubs if power10-only relocations are detected, continues to be
+	used.
+
+	include/
+		* elf/ppc64.h (R_PPC64_REL24_P9NOTOC): Define.
+	bfd/
+		* reloc.c (BFD_RELOC_PPC64_REL24_P9NOTOC): Define.
+		* elf64-ppc.c (ppc64_elf_howto_raw): Add entry for new reloc.
+		(ppc64_elf_reloc_type_lookup): Handle it.
+		(enum ppc_stub_type): Delete.
+		(enum ppc_stub_main_type, ppc_stub_sub_type): New.
+		(struct ppc_stub_type): New.
+		(struct ppc_stub_hash_entry): Use the above new type.
+		(struct ppc_link_hash_table): Update stub_count.
+		(is_branch_reloc, ppc64_elf_check_relocs),
+		(toc_adjusting_stub_needed): Handle new reloc.
+		(stub_hash_newfunc, select_alt_stub, ppc_merge_stub),
+		(ppc_type_of_stub, plt_stub_size, build_plt_stub),
+		(build_tls_get_addr_head, build_tls_get_addr_tail),
+		(ppc_build_one_stub, ppc_size_one_stub, ppc64_elf_size_stubs),
+		(ppc64_elf_build_stubs, ppc64_elf_relocate_section): Handle new
+		reloc.  Modify stub handling to suit new scheme.
+		* bfd-in2.h: Regenerate.
+		* libbfd.h: Regenerate.
+	gas/
+		* config/tc-ppc.c (ppc_elf_suffix): When power10 is not enabled
+		return BFD_RELOC_PPC64_REL24_P9NOTOC for @notoc.
+		(fixup_size, ppc_force_relocation, ppc_fix_adjustable): Handle
+		BFD_RELOC_PPC64_REL24_P9NOTOC.
+	ld/
+		* testsuite/ld-powerpc/callstub-2.s: Add .machine power10.
+
+2021-11-15  Alan Modra  <amodra@gmail.com>
+
+	Regenerate a couple of files
+	A couple of files changed on my latest --enable-maintainer-mode
+	build.  ld/Makefile.in had a missing dependency but better sorting of
+	the loongson entries.
+
+	intl/
+		* configure: Regenerate.
+	ld/
+		* Makefile.am: Sort loongson entries.
+		* Makefile.in: Regenerate.
+
+2021-11-15  Pedro Alves  <pedro@palves.net>
+
+	Fix build with current GCC: EL_EXPLICIT(location) always non-NULL
+	Compiling GDB with current GCC (1b4a63593b) runs into this:
+
+	  src/gdb/location.c: In function 'int event_location_empty_p(const event_location*)':
+	  src/gdb/location.c:963:38: error: the address of 'event_location::<unnamed union>::explicit_loc' will never be NULL [-Werror=address]
+	    963 |       return (EL_EXPLICIT (location) == NULL
+		|                                      ^
+	  src/gdb/location.c:57:30: note: 'event_location::<unnamed union>::explicit_loc' declared here
+	     57 |     struct explicit_location explicit_loc;
+		|                              ^~~~~~~~~~~~
+
+	GCC is right, EL_EXPLICIT is defined as returning the address of an
+	union field:
+
+	      /* An explicit location.  */
+	      struct explicit_location explicit_loc;
+	  #define EL_EXPLICIT(P) (&((P)->u.explicit_loc))
+
+	and thus must always be non-NULL.
+
+	Change-Id: Ie74fee7834495a93affcefce03c06e4d83ad8191
+
+2021-11-15  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-14  Lancelot SIX  <lsix@lancelotsix.com>
+
+	[PR gdb/16238] Add completer for the show user command
+	The 'show user' command (which shows the definition of non-python/scheme
+	user defined commands) is currently missing a completer. This is
+	mentioned in PR 16238.  Having one can improve the user experience.
+
+	In this commit I propose an implementation for such completer as well as
+	the associated tests.
+
+	Tested on x86_64 GNU/Linux.
+
+	All feedbacks are welcome.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16238
+
+2021-11-14  Alan Modra  <amodra@gmail.com>
+
+	sync libbacktrace from gcc
+
+2021-11-14  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-13  H.J. Lu  <hjl.tools@gmail.com>
+
+	Sync Makefile.tpl with GCC
+		* Makefile.tpl: Sync with GCC.
+		* Makefile.in: Regenerate.
+
+2021-11-13  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: sh: fix switch-bool warnings
+	This code triggers -Werror=switch-bool warnings with <=gcc-5 versions.
+	Rework it to use if statements instead as it also simplifies a bit.
+
+	sim: sh: rework carry checks to not rely on integer overflows
+	In <=gcc-7 versions, -fstrict-overflow is enabled by default, and that
+	triggers warnings in this code that relies on integer overflows to test
+	for carries.  Change the logic to test against the limit directly.
+
+2021-11-13  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-12  Carl Love  <cel@us.ibm.com>
+
+	Fix gdb.base/sigstep.exp test for ppc
+	The test stops at <signal_handler called> which is the call to the handler
+	rather than in the handler as intended.  This patch replaces the
+	gdb_test "$enter_cmd to handler" with a gdb_test_multiple test.  The multiple
+	test looks for the stop at <signal_handler called>.  If found, the command
+	is issued again.  The test passes if gdb stops in the handler as expected.
+
+	(gdb) PASS: gdb.base/sigstep.exp: stepi to handler, nothing in handler, step
+	from handler: continue to signal
+	stepi
+	<signal handler called>
+	1: x/i $pc
+	=> 0x7ffff7f80440 <__kernel_start_sigtramp_rt64>:       bctrl
+	(gdb) stepi
+	handler (sig=551) at sigstep.c:32
+	32      {
+	1: x/i $pc
+	=> 0x10000097c <handler>:       addis   r2,r12,2
+	(gdb) PASS: gdb.base/sigstep.exp: stepi to handler, nothing in handler,
+	step from handler: stepi to handler
+
+	Patch has been tested on x86_64-linux and ppc64le-linux with no test failures.
+
+2021-11-12  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix regexp in gdb.base/foll-vfork.exp
+	On OBS I ran into:
+	...
+	(gdb) PASS: gdb.base/foll-vfork.exp: exit: \
+	  vfork relations in info inferiors: continue to child exit
+	info inferiors^M
+	  Num  Description       Connection           Executable        ^M
+	  1    <null>                                 foll-vfork-exit ^M
+	* 2    <null>                                 foll-vfork-exit ^M
+	(gdb) I'm the proud parent of child #5044!^M
+	FAIL: gdb.base/foll-vfork.exp: exit: vfork relations in info inferiors: \
+	  vfork relation no longer appears in info inferiors (timeout)
+	...
+
+	Fix this by removing the '$' anchor in the corresponding '$gdb_prompt $'
+	regexps.
+
+	Tested on x86_64-linux.
+
+2021-11-12  Alan Modra  <amodra@gmail.com>
+
+	Don't compile some opcodes files when bfd is 32-bit only
+		* Makefile.am (TARGET_LIBOPCODES_CFILES): Split into..
+		(TARGET64_LIBOPCODES_CFILES): ..this and..
+		(TARGET32_LIBOPCODES_CFILES): ..this.
+		(ALL_MACHINES): Likewise split to
+		(ALL64_MACHINES, ALL32_MACHINES): ..this.
+		* disassemble.c: Define some ARCH_* when ARCH_all only if BFD64.
+		* configure.ac (BFD_MACHINES): Defined depending on BFD_ARCH_SIZE.
+		* Makefile.in: Regenerate.
+		* configure: Regenerate.
+
+	Import Makefile.def from gcc
+		* Makefile.def: Import from gcc.
+		* Makefile.in: Regenerate.
+
+2021-11-12  Alan Modra  <amodra@gmail.com>
+
+	Fix demangle style usage info
+	Extract allowed styles from libiberty, so we don't have to worry about
+	our help messages getting out of date.  The function probably belongs
+	in libiberty/cplus-dem.c but it can be here for a while to iron out
+	bugs.
+
+		PR 28581
+		* demanguse.c: New file.
+		* demanguse.h: New file.
+		* nm.c (usage): Break up output.  Use display_demangler_styles.
+		* objdump.c (usage): Use display_demangler_styles.
+		* readelf.c (usage): Likewise.
+		* Makefile.am: Add demanguse.c and demanguse.h.
+		* Makefile.in: Regenerate.
+		* po/POTFILESin: Regenerate.
+
+2021-11-12  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-11  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: fix "set scheduler-locking" thread exit hang
+	GDB hangs when doing this:
+
+	 - launch inferior with multiple threads
+	 - multiple threads hit some breakpoint(s)
+	 - one breakpoint hit is presented as a stop, the rest are saved as
+	   pending wait statuses
+	 - "set scheduler-locking on"
+	 - resume the currently selected thread (because of scheduler-locking,
+	   it's the only one resumed), let it execute until exit
+	 - GDB hangs, not showing the prompt, impossible to interrupt with ^C
+
+	When the resumed thread exits, we expect the target to return a
+	TARGET_WAITKIND_NO_RESUMED event, and that's what we see:
+
+	    [infrun] fetch_inferior_event: enter
+	      [infrun] scoped_disable_commit_resumed: reason=handling event
+	      [infrun] random_pending_event_thread: None found.
+	    [Thread 0x7ffff7d9c700 (LWP 309357) exited]
+	      [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
+	      [infrun] print_target_wait_results:   -1.0.0 [process -1],
+	      [infrun] print_target_wait_results:   status->kind = no-resumed
+	      [infrun] handle_inferior_event: status->kind = no-resumed
+	      [infrun] handle_no_resumed: TARGET_WAITKIND_NO_RESUMED (ignoring: found resumed)
+	      [infrun] prepare_to_wait: prepare_to_wait
+	      [infrun] reset: reason=handling event
+	      [infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target native, no resumed threads
+	    [infrun] fetch_inferior_event: exit
+
+	The problem is in handle_no_resumed: we check if some other thread is
+	actually resumed, to see if we should ignore that event (see comments in
+	that function for more info).  If this condition is true:
+
+	    (thread->executing () || thread->has_pending_waitstatus ())
+
+	... then we ignore the event.  The problem is that there are some non-resumed
+	threads with a pending event, which makes us ignore the event.  But these
+	threads are not resumed, so we end up waiting while nothing executes, hence
+	waiting for ever.
+
+	My first fix was to change the condition to:
+
+	    (thread->executing ()
+	     || (thread->resumed () && thread->has_pending_waitstatus ()))
+
+	... but then it occured to me that we could simply check for:
+
+	    (thread->resumed ())
+
+	Since "executing" implies "resumed", checking simply for "resumed"
+	covers threads that are resumed and executing, as well as threads that
+	are resumed with a pending status, which is what we want.
+
+	Change-Id: Ie796290f8ae7f34c026ca3a8fcef7397414f4780
+
+2021-11-11  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/build] Fix Wimplicit-exception-spec-mismatch in clang build
+	When building with clang 13 (and -std=gnu++17 to work around an issue in
+	string_view-selftests.c), we run into a few Wimplicit-exception-spec-mismatch
+	warnings:
+	...
+	src/gdbsupport/new-op.cc:102:1: error: function previously declared with an \
+	  explicit exception specification redeclared with an implicit exception \
+	  specification [-Werror,-Wimplicit-exception-spec-mismatch]
+	operator delete (void *p)
+	^
+	/usr/include/c++/11/new:130:6: note: previous declaration is here
+	void operator delete(void*) _GLIBCXX_USE_NOEXCEPT
+	     ^
+	...
+
+	These are due to recent commit 5fff6115fea "Fix
+	LD_PRELOAD=/usr/lib64/libasan.so.6 gdb".
+
+	Fix this by adding the missing noexcept.
+
+	Build on x86_64-linux, using gcc 7.5.0 and clang 13.0.0.
+
+2021-11-11  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/build] Fix build with -std=c++11
+	When building with -std=c++11, we run into two Werror=missing-declarations:
+	...
+	new-op.cc: In function 'void operator delete(void*, std::size_t)':
+	new-op.cc:114:1: error: no previous declaration for \
+	  'void operator delete(void*, std::size_t)' [-Werror=missing-declarations]
+	 operator delete (void *p, std::size_t) noexcept
+	 ^~~~~~~~
+	new-op.cc: In function 'void operator delete [](void*, std::size_t)':
+	new-op.cc:132:1: error: no previous declaration for \
+	  'void operator delete [](void*, std::size_t)' [-Werror=missing-declarations]
+	 operator delete[] (void *p, std::size_t) noexcept
+	 ^~~~~~~~
+	...
+
+	These are due to recent commit 5fff6115fea "Fix
+	LD_PRELOAD=/usr/lib64/libasan.so.6 gdb".
+
+	The declarations are provided by <new> (which is included) for c++14 onwards,
+	but they are missing for c++11.
+
+	Fix this by adding the missing declarations.
+
+	Tested on x86_64-linux, with gcc 7.5.0, both without (implying -std=gnu++14) and
+	with -std=c++11.
+
+2021-11-11  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Add gdb.arch/ppc64-break-on-_exit.exp
+	Add a regression test-case for commit a50bdb99afe "[gdb/tdep, rs6000] Don't
+	skip system call in skip_prologue":
+	- set a breakpoint on a local copy of glibc's _exit, and
+	- verify that it triggers.
+
+	The test-case uses an assembly file by default, but also has the possibility
+	to use a C source file instead.
+
+	Tested on ppc64le-linux.  Verified that the test-case fails without
+	aforementioned commit, and passes with the commit.  Both with assembly
+	and C source.
+
+2021-11-11  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: Dump objects according to the elf architecture attribute.
+	For now we should always generate the elf architecture attribute both for
+	elf and linux toolchains, so that we could dump the objects correctly
+	according to the generated architecture string.  This patch resolves the
+	problem that we probably dump an object with c.nop instructions, but
+	in fact the c extension isn't allowed.  Consider the following case,
+
+	nelson@LAPTOP-QFSGI1F2:~/test$ cat temp.s
+	.option norvc
+	.option norelax
+	.text
+	add     a0, a0, a0
+	.byte   0x1
+	.balign 16
+	nelson@LAPTOP-QFSGI1F2:~/test$ ~/binutils-dev/build-elf32-upstream/build-install/bin/riscv32-unknown-elf-as temp.s -o temp.o
+	nelson@LAPTOP-QFSGI1F2:~/test$ ~/binutils-dev/build-elf32-upstream/build-install/bin/riscv32-unknown-elf-objdump -d temp.o
+
+	temp.o:     file format elf32-littleriscv
+
+	Disassembly of section .text:
+
+	00000000 <.text>:
+	   0:   00a50533                add     a0,a0,a0
+	   4:   01                      .byte   0x01
+	   5:   00                      .byte   0x00
+	   6:   0001                    nop
+	   8:   00000013                nop
+	   c:   00000013                nop
+	nelson@LAPTOP-QFSGI1F2:~/test$ ~/binutils-dev/build-elf32-upstream/build-install/bin/riscv32-unknown-elf-readelf -A temp.o
+	Attribute Section: riscv
+	File Attributes
+	  Tag_RISCV_arch: "rv32i2p0_m2p0_a2p0_f2p0_d2p0"
+
+	The c.nop at address 0x6 is generated for alignment, but since the rvc isn't
+	allowed for this object, dump it as a c.nop instruction looks wrong.  After
+	applying this patch, I get the following result,
+
+	nelson@LAPTOP-QFSGI1F2:~/test$ ~/binutils-dev/build-elf32-upstream/build-install/bin/riscv32-unknown-elf-objdump -d temp.o
+
+	temp.o:     file format elf32-littleriscv
+
+	Disassembly of section .text:
+
+	00000000 <.text>:
+	   0:   00a50533                add     a0,a0,a0
+	   4:   01                      .byte   0x01
+	   5:   00                      .byte   0x00
+	   6:   0001                    .2byte  0x1
+	   8:   00000013                nop
+	   c:   00000013                nop
+
+	For the current objdump, we dump data to .byte/.short/.word/.dword, and
+	dump the unknown or unsupported instructions to .2byte/.4byte/.8byte, which
+	respectively are 2, 4 and 8 bytes instructions.  Therefore, we shouldn't
+	dump the 0x0001 as a c.nop instruction in the above case, we should dump
+	it to .2byte 0x1 as a unknown instruction, since the rvc is disabled.
+
+	However, consider that some people may use the new objdump to dump the old
+	objects, which don't have any elf attributes.  We usually set the default
+	architecture string to rv64g by bfd/elfxx-riscv.c:riscv_set_default_arch.
+	But this will cause rvc instructions to be unrecognized.  Therefore, we
+	set the default architecture string to rv64gc for disassembler, to keep
+	the previous behavior.
+
+	This patch pass the riscv-gnu-toolchain gcc/binutils regressions for
+	rv32emc-elf, rv32gc-linux, rv32i-elf, rv64gc-elf and rv64gc-linux
+	toolchains.  Also, tested by --enable-targets=all and can build
+	riscv-gdb successfully.
+
+	bfd/
+		* elfnn-riscv.c (riscv_merge_arch_attr_info): Tidy the
+		codes for riscv_parse_subset_t setting.
+		* elfxx-riscv.c (riscv_get_default_ext_version): Updated.
+		(riscv_subset_supports): Moved from gas/config/tc-riscv.c.
+		(riscv_multi_subset_supports): Likewise.
+		* elfxx-riscv.h: Added extern for riscv_subset_supports and
+		riscv_multi_subset_supports.
+	gas/
+		* config/tc-riscv.c (riscv_subset_supports): Moved to
+		bfd/elfxx-riscv.c.
+		(riscv_multi_subset_supports): Likewise.
+		(riscv_rps_as): Defined for architectrue parser.
+		(riscv_set_arch): Updated.
+		(riscv_set_abi_by_arch): Likewise.
+		(riscv_csr_address): Likewise.
+		(reg_lookup_internal): Likewise.
+		(riscv_ip): Likewise.
+		(s_riscv_option): Updated.
+		* testsuite/gas/riscv/mapping-04b.d: Updated.
+		* testsuite/gas/riscv/mapping-norelax-03b.d: Likewise.
+		* testsuite/gas/riscv/mapping-norelax-04b.d: Likewise.
+	opcodes/
+		* riscv-dis.c: Include elfxx-riscv.h since we need the
+		architecture parser.  Also removed the cpu-riscv.h, it
+		is already included in elfxx-riscv.h.
+		(default_isa_spec): Defined since the parser need this
+		to set the default architecture string.
+		(xlen): Moved out from riscv_disassemble_insn as a global
+		variable, it is more convenient to initialize riscv_rps_dis.
+		(riscv_subsets): Defined to recoed the supported
+		extensions.
+		(riscv_rps_dis): Defined for architectrue parser.
+		(riscv_disassemble_insn): Call riscv_multi_subset_supports
+		to make sure if the instructions are valid or not.
+		(print_insn_riscv): Initialize the riscv_subsets by parsing
+		the elf architectrue attribute.  Otherwise, set the default
+		architectrue string to rv64gc.
+
+2021-11-11  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: testsuite: drop sim_compile cover function
+	Most code isn't using this, and the only call site (in one cris file)
+	can use target_compile directly.  So switch it over to simplify.
+
+	sim: cris: stop testing a.out explicitly [ld/13900]
+	Since gcc dropped support for a.out starting with 4.4.0 in 2009, it's
+	been impossible to verify this code actually still works.  Since it
+	crashes in ld, and it uses a config option that no other tests uses
+	and we want to remove, drop the test to avoid all the trouble.
+
+	sim: io: tweak compiler workaround with error output
+	Outputting an extra space broke a cris test.  Change the workaround
+	to use %s with an empty string to avoid the compiler warning but not
+	output an extra space.
+
+	sim: testsuite: delete unused arm remote host logic
+	There's no need to sync testutils.inc with remote hosts.  The one
+	we have in the source tree is all we need and only thing we test.
+	Delete it to simplify.
+
+	sim: synacor: simplify test generation
+	Objcopy was used to create a binary file of just the executable code
+	since the environment requires code to based at address 0.  We can
+	accomplish the same thing with the -Ttext=0 flag, so switch to that
+	to get rid of custom logic.
+
+2021-11-11  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-10  Tom Tromey  <tromey@adacore.com>
+
+	Handle PIE in .debug_loclists
+	Simon pointed out that my recent patches to .debug_loclists caused
+	some regressions.  After a brief discussion we realized it was because
+	his system compiler defaults to PIE.
+
+	This patch changes this code to unconditionally apply the text offset
+	here.  It also changes loclist_describe_location to work more like
+	dwarf2_find_location_expression.
+
+	I tested this by running the gdb.dwarf2 tests both with and without
+	-pie.
+
+2021-11-10  Przemyslaw Wirkus  <przemyslaw.wirkus@arm.com>
+
+	arm: enable Cortex-A710 CPU
+	This patch is adding support for Cortex-A710 CPU in Arm.
+
+	bfd/
+
+		* cpu-arm.c (processors): Add cortex-a710.
+
+	gas/
+
+		* NEWS: Update docs.
+		* config/tc-arm.c (arm_cpus): Add cortex-a710 to -mcpu.
+		* doc/c-arm.texi: Update docs.
+		* testsuite/gas/arm/cpu-cortex-a710.d: New test.
+
+2021-11-10  Clément Chigot  <clement.chigot@atos.net>
+
+	gdb: adjust x_file fields on COFF readers
+	Commit e86fc4a5bc37 ("PR 28447: implement multiple parameters for .file
+	on XCOFF") changes the structure associated to the internal
+	representation of files in COFF formats.  However, gdb directory update
+	has been forgotten, leading to compilation errors of this kind:
+
+	      CXX    coffread.o
+	    /home/simark/src/binutils-gdb/gdb/coffread.c: In function 'const char* coff_getfilename(internal_auxent*)':
+	    /home/simark/src/binutils-gdb/gdb/coffread.c:1343:29: error: 'union internal_auxent::<unnamed struct>::<unnamed>' has no member named 'x_zeroes'
+	     1343 |   if (aux_entry->x_file.x_n.x_zeroes == 0)
+	          |                             ^~~~~~~~
+
+	Fix it by adjusting the COFF code in GDB.
+
+	Change-Id: I703fa134bc722d47515efbd72b88fa5650af6c3c
+
+2021-11-10  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Add gdb.opt/break-on-_exit.exp
+	Add a test-case to excercise the problem scenario reported in PR28527 and
+	fixed in commit a50bdb99afe "[gdb/tdep, rs6000] Don't skip system call in
+	skip_prologue":
+	- set a breakpoint on _exit, and
+	- verify that it triggers.
+
+	Note that this is not a regression test for that commit.  Since the actual
+	code in _exit may vary across os instances, we cannot guarantee that the
+	problem will always trigger with this test-case.
+
+	Rather, this test-case is a version of the original test-case
+	(gdb.threads/process-dies-while-detaching.exp) that is minimal while still
+	reproducing the problem reported in PR28527, in that same setting.
+
+	The benefit of this test-case is that it exercise real-life code and may
+	expose similar problems in other settings.  Also, it provides a much easier
+	test-case to investigate in case a similar problem occurs.
+
+	Tested on x86_64-linux and ppc64le-linux.
+
+2021-11-10  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: frv: flip trapdump default back to off
+	When I refactored this by scoping it to sim-frv-xxx in commit
+	e7954ef5e5ed90fb7d28c013518f4c2e6bcd20a1 ("sim: frv: scope the
+	unique configure flag"), I changed the default from off to on.
+	While the feature is nice for developers, it breaks a bunch of
+	tests which aren't expecting this extra output.  So flip it back
+	to off by default.
+
+2021-11-10  Pekka Seppänen  <pexu@sourceware.mail.kapsi.fi>
+
+	PR28575, readelf.c and strings.c use undefined type uint
+	Since --unicode support (commit b3aa80b45c4) both binutils/readelf.c
+	and binutils/strings.c use 'uint' in a few locations.  It likely
+	should be 'unsigned int' since there isn't anything defining 'uint'
+	within binutils (besides zlib) and AFAIK it isn't a standard type.
+
+		* readelf.c (print_symbol): Replace uint with unsigned int.
+		* strings.c (string_min, display_utf8_char): Likewise.
+		(print_unicode_stream_body, print_unicode_stream): Likewise.
+		(print_strings): Likewise.
+		(get_unicode_byte): Wrap long line.
+
+2021-11-10  Clément Chigot  <clement.chigot@atos.net>
+
+	ld: set correct flags for AIX shared tests
+	Previous flags were aimed to be run with XLC.
+	Nowadays, only GCC is being tested with GNU toolchain. Moreover,
+	recent XLC versions might also accept "-shared".
+
+		* testsuite/ld-shared/shared.exp: Adjust shared flags.
+
+2021-11-10  Clément Chigot  <clement.chigot@atos.net>
+
+	PR 28447: implement multiple parameters for .file on XCOFF
+	On XCOFF, ".file" pseudo-op allows 3 extras parameters to provide
+	additional information to AIX linker, or its debugger. These are
+	stored in auxiliary entries of the C_FILE symbol.
+
+	bfd/
+		PR 28447
+		* coffcode.h (combined_entry_type): Add extrap field.
+		(coff_bigobj_swap_aux_in): Adjust names of x_file fields.
+		(coff_bigobj_swap_aux_out): Likewise.
+		* coffgen.c (coff_write_auxent_fname): New function.
+		(coff_fix_symbol_name): Write x_file using
+		 coff_write_auxent_fname.
+		(coff_write_symbol): Likewise.
+		(coff_write_symbols): Add C_FILE auxiliary entries to
+		string table if needed.
+		(coff_get_normalized_symtab): Adjust names of x_file fields.
+		Normalize C_FILE auxiliary entries.
+		(coff_print_symbol): Print C_FILE auxiliary entries.
+		* coff-rs6000.c (_bfd_xcoff_swap_aux_in): Adjust names of
+		x_file fields.
+		(_bfd_xcoff_swap_aux_out): Likewise.
+		* coff64-rs6000.c (_bfd_xcoff64_swap_aux_in): Likewise.
+		(_bfd_xcoff64_swap_aux_out): Likewise.
+		* cofflink.c (_bfd_coff_final_link): Likewise.
+		(_bfd_coff_link_input_bfd): Likewise.
+		* coffswap.h (coff_swap_aux_in): Likewise.
+		* peXXigen.c (_bfd_XXi_swap_aux_in): Likewise.
+		(_bfd_XXi_swap_aux_out): Likewise.
+		* xcofflink.c (xcoff_link_input_bfd): Likewise.
+		* libcoff.h: Regenerate.
+	gas/
+		* config/tc-ppc.c (ppc_file): New function.
+		* config/tc-ppc.h (OBJ_COFF_MAX_AUXENTRIES): Change to 4.
+		* testsuite/gas/ppc/aix.exp: Add tests.
+		* testsuite/gas/ppc/xcoff-file-32.d: New test.
+		* testsuite/gas/ppc/xcoff-file-64.d: New test.
+		* testsuite/gas/ppc/xcoff-file.s: New test.
+	include/
+		* coff/internal.h (union internal_auxent): Change x_file to be a
+		  struct instead of a union. Add x_ftype field.
+		* coff/rs6000.h (union external_auxent): Add x_resv field.
+		* coff/xcoff.h (XFT_FN): New define.
+		(XFT_CT): Likewise.
+		(XFT_CV): Likewise.
+		(XFT_CD): Likewise.
+
+2021-11-10  Kevin Buettner  <kevinb@redhat.com>
+
+	Test case for Bug 28308
+	The purpose of this test is described in the comments in
+	dprintf-execution-x-script.exp.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28308
+
+	The name of this new test was based on that of an existing test,
+	bp-cmds-execution-x-script.exp.  I started off by copying that test,
+	adding to it, and then rewriting almost all of it.  It's different
+	enough that I decided that listing the copyright year as 2021
+	was sufficient.
+
+2021-11-10  Kevin Buettner  <kevinb@redhat.com>
+
+	Fix PR 28308 - dprintf breakpoints not working when run from script
+	This commit fixes Bug 28308, titled "Strange interactions with
+	dprintf and break/commands":
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28308
+
+	Since creating that bug report, I've found a somewhat simpler way of
+	reproducing the problem.  I've encapsulated it into the GDB test case
+	which I've created along with this bug fix.  The name of the new test
+	is gdb.base/dprintf-execution-x-script.exp, I'll demonstrate the
+	problem using this test case, though for brevity, I've placed all
+	relevant files in the same directory and have renamed the files to all
+	start with 'dp-bug' instead of 'dprintf-execution-x-script'.
+
+	The script file, named dp-bug.gdb, consists of the following commands:
+
+	dprintf increment, "dprintf in increment(), vi=%d\n", vi
+	break inc_vi
+	commands
+	  continue
+	end
+	run
+
+	Note that the final command in this script is 'run'.  When 'run' is
+	instead issued interactively, the  bug does not occur.  So, let's look
+	at the interactive case first in order to see the correct/expected
+	output:
+
+	$ gdb -q -x dp-bug.gdb dp-bug
+	... eliding buggy output which I'll discuss later ...
+	(gdb) run
+	Starting program: /mesquite2/sourceware-git/f34-master/bld/gdb/tmp/dp-bug
+	vi=0
+	dprintf in increment(), vi=0
+
+	Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26
+	26	in dprintf-execution-x-script.c
+	vi=1
+	dprintf in increment(), vi=1
+
+	Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26
+	26	in dprintf-execution-x-script.c
+	vi=2
+	dprintf in increment(), vi=2
+
+	Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26
+	26	in dprintf-execution-x-script.c
+	vi=3
+	[Inferior 1 (process 1539210) exited normally]
+
+	In this run, in which 'run' was issued from the gdb prompt (instead
+	of at the end of the script), there are three dprintf messages along
+	with three 'Breakpoint 2' messages.  This is the correct output.
+
+	Now let's look at the output that I snipped above; this is the output
+	when 'run' is issued from the script loaded via GDB's -x switch:
+
+	$ gdb -q -x dp-bug.gdb dp-bug
+	Reading symbols from dp-bug...
+	Dprintf 1 at 0x40116e: file dprintf-execution-x-script.c, line 38.
+	Breakpoint 2 at 0x40113a: file dprintf-execution-x-script.c, line 26.
+	vi=0
+	dprintf in increment(), vi=0
+
+	Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26
+	26	dprintf-execution-x-script.c: No such file or directory.
+	vi=1
+
+	Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26
+	26	in dprintf-execution-x-script.c
+	vi=2
+
+	Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26
+	26	in dprintf-execution-x-script.c
+	vi=3
+	[Inferior 1 (process 1539175) exited normally]
+
+	In the output shown above, only the first dprintf message is printed.
+	The 2nd and 3rd dprintf messages are missing!  However, all three
+	'Breakpoint 2...' messages are still printed.
+
+	Why does this happen?
+
+	bpstat_do_actions_1() in gdb/breakpoint.c contains the following
+	comment and code near the start of the function:
+
+	  /* Avoid endless recursion if a `source' command is contained
+	     in bs->commands.  */
+	  if (executing_breakpoint_commands)
+	    return 0;
+
+	  scoped_restore save_executing
+	    = make_scoped_restore (&executing_breakpoint_commands, 1);
+
+	Also, as described by this comment prior to the 'async' field
+	in 'struct ui' in top.h, the main UI starts off in sync mode
+	when processing command line arguments:
+
+	  /* True if the UI is in async mode, false if in sync mode.  If in
+	     sync mode, a synchronous execution command (e.g, "next") does not
+	     return until the command is finished.  If in async mode, then
+	     running a synchronous command returns right after resuming the
+	     target.  Waiting for the command's completion is later done on
+	     the top event loop.  For the main UI, this starts out disabled,
+	     until all the explicit command line arguments (e.g., `gdb -ex
+	     "start" -ex "next"') are processed.  */
+
+	This combination of things, the state of the static global
+	'executing_breakpoint_commands' plus the state of the async
+	field in the main UI causes this behavior.
+
+	This is a backtrace after hitting the dprintf breakpoint for
+	the second time when doing 'run' from the script file, i.e.
+	non-interactively:
+
+	Thread 1 "gdb" hit Breakpoint 3, bpstat_do_actions_1 (bsp=0x7fffffffc2b8)
+	    at /ironwood1/sourceware-git/f34-master/bld/../../worktree-master/gdb/breakpoint.c:4431
+	4431	  if (executing_breakpoint_commands)
+
+	 #0  bpstat_do_actions_1 (bsp=0x7fffffffc2b8)
+	     at gdb/breakpoint.c:4431
+	 #1  0x00000000004d8bc6 in dprintf_after_condition_true (bs=0x1538090)
+	     at gdb/breakpoint.c:13048
+	 #2  0x00000000004c5caa in bpstat_stop_status (aspace=0x116dbc0, bp_addr=0x40116e, thread=0x137f450, ws=0x7fffffffc718,
+	     stop_chain=0x1538090) at gdb/breakpoint.c:5498
+	 #3  0x0000000000768d98 in handle_signal_stop (ecs=0x7fffffffc6f0)
+	     at gdb/infrun.c:6172
+	 #4  0x00000000007678d3 in handle_inferior_event (ecs=0x7fffffffc6f0)
+	     at gdb/infrun.c:5662
+	 #5  0x0000000000763cd5 in fetch_inferior_event ()
+	     at gdb/infrun.c:4060
+	 #6  0x0000000000746d7d in inferior_event_handler (event_type=INF_REG_EVENT)
+	     at gdb/inf-loop.c:41
+	 #7  0x00000000007a702f in handle_target_event (error=0, client_data=0x0)
+	     at gdb/linux-nat.c:4207
+	 #8  0x0000000000b8cd6e in gdb_wait_for_event (block=block@entry=0)
+	     at gdbsupport/event-loop.cc:701
+	 #9  0x0000000000b8d032 in gdb_wait_for_event (block=0)
+	     at gdbsupport/event-loop.cc:597
+	 #10 gdb_do_one_event () at gdbsupport/event-loop.cc:212
+	 #11 0x00000000009d19b6 in wait_sync_command_done ()
+	     at gdb/top.c:528
+	 #12 0x00000000009d1a3f in maybe_wait_sync_command_done (was_sync=0)
+	     at gdb/top.c:545
+	 #13 0x00000000009d2033 in execute_command (p=0x7fffffffcb18 "", from_tty=0)
+	     at gdb/top.c:676
+	 #14 0x0000000000560d5b in execute_control_command_1 (cmd=0x13b9bb0, from_tty=0)
+	     at gdb/cli/cli-script.c:547
+	 #15 0x000000000056134a in execute_control_command (cmd=0x13b9bb0, from_tty=0)
+	     at gdb/cli/cli-script.c:717
+	 #16 0x00000000004c3bbe in bpstat_do_actions_1 (bsp=0x137f530)
+	     at gdb/breakpoint.c:4469
+	 #17 0x00000000004c3d40 in bpstat_do_actions ()
+	     at gdb/breakpoint.c:4533
+	 #18 0x00000000006a473a in command_handler (command=0x1399ad0 "run")
+	     at gdb/event-top.c:624
+	 #19 0x00000000009d182e in read_command_file (stream=0x113e540)
+	     at gdb/top.c:443
+	 #20 0x0000000000563697 in script_from_file (stream=0x113e540, file=0x13bb0b0 "dp-bug.gdb")
+	     at gdb/cli/cli-script.c:1642
+	 #21 0x00000000006abd63 in source_gdb_script (extlang=0xc44e80 <extension_language_gdb>, stream=0x113e540,
+	     file=0x13bb0b0 "dp-bug.gdb") at gdb/extension.c:188
+	 #22 0x0000000000544400 in source_script_from_stream (stream=0x113e540, file=0x7fffffffd91a "dp-bug.gdb",
+	     file_to_open=0x13bb0b0 "dp-bug.gdb")
+	     at gdb/cli/cli-cmds.c:692
+	 #23 0x0000000000544557 in source_script_with_search (file=0x7fffffffd91a "dp-bug.gdb", from_tty=1, search_path=0)
+	     at gdb/cli/cli-cmds.c:750
+	 #24 0x00000000005445cf in source_script (file=0x7fffffffd91a "dp-bug.gdb", from_tty=1)
+	     at gdb/cli/cli-cmds.c:759
+	 #25 0x00000000007cf6d9 in catch_command_errors (command=0x5445aa <source_script(char const*, int)>,
+	     arg=0x7fffffffd91a "dp-bug.gdb", from_tty=1, do_bp_actions=false)
+	     at gdb/main.c:523
+	 #26 0x00000000007cf85d in execute_cmdargs (cmdarg_vec=0x7fffffffd1b0, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND,
+	     ret=0x7fffffffd18c) at gdb/main.c:615
+	 #27 0x00000000007d0c8e in captured_main_1 (context=0x7fffffffd3f0)
+	     at gdb/main.c:1322
+	 #28 0x00000000007d0eba in captured_main (data=0x7fffffffd3f0)
+	     at gdb/main.c:1343
+	 #29 0x00000000007d0f25 in gdb_main (args=0x7fffffffd3f0)
+	     at gdb/main.c:1368
+	 #30 0x00000000004186dd in main (argc=5, argv=0x7fffffffd508)
+	     at gdb/gdb.c:32
+
+	There are two frames for bpstat_do_actions_1(), one at frame #16 and
+	the other at frame #0.  The one at frame #16 is processing the actions
+	for Breakpoint 2, which is a 'continue'.  The one at frame #0 is attempting
+	to process the dprintf breakpoint action.  However, at this point,
+	the value of 'executing_breakpoint_commands' is 1, forcing an early
+	return, i.e. prior to executing the command(s) associated with the dprintf
+	breakpoint.
+
+	For the sake of comparison, this is what the stack looks like when hitting
+	the dprintf breakpoint for the second time when issuing the 'run'
+	command from the GDB prompt.
+
+	Thread 1 "gdb" hit Breakpoint 3, bpstat_do_actions_1 (bsp=0x7fffffffccd8)
+	    at /ironwood1/sourceware-git/f34-master/bld/../../worktree-master/gdb/breakpoint.c:4431
+	4431	  if (executing_breakpoint_commands)
+
+	 #0  bpstat_do_actions_1 (bsp=0x7fffffffccd8)
+	     at gdb/breakpoint.c:4431
+	 #1  0x00000000004d8bc6 in dprintf_after_condition_true (bs=0x16b0290)
+	     at gdb/breakpoint.c:13048
+	 #2  0x00000000004c5caa in bpstat_stop_status (aspace=0x116dbc0, bp_addr=0x40116e, thread=0x13f0e60, ws=0x7fffffffd138,
+	     stop_chain=0x16b0290) at gdb/breakpoint.c:5498
+	 #3  0x0000000000768d98 in handle_signal_stop (ecs=0x7fffffffd110)
+	     at gdb/infrun.c:6172
+	 #4  0x00000000007678d3 in handle_inferior_event (ecs=0x7fffffffd110)
+	     at gdb/infrun.c:5662
+	 #5  0x0000000000763cd5 in fetch_inferior_event ()
+	     at gdb/infrun.c:4060
+	 #6  0x0000000000746d7d in inferior_event_handler (event_type=INF_REG_EVENT)
+	     at gdb/inf-loop.c:41
+	 #7  0x00000000007a702f in handle_target_event (error=0, client_data=0x0)
+	     at gdb/linux-nat.c:4207
+	 #8  0x0000000000b8cd6e in gdb_wait_for_event (block=block@entry=0)
+	     at gdbsupport/event-loop.cc:701
+	 #9  0x0000000000b8d032 in gdb_wait_for_event (block=0)
+	     at gdbsupport/event-loop.cc:597
+	 #10 gdb_do_one_event () at gdbsupport/event-loop.cc:212
+	 #11 0x00000000007cf512 in start_event_loop ()
+	     at gdb/main.c:421
+	 #12 0x00000000007cf631 in captured_command_loop ()
+	     at gdb/main.c:481
+	 #13 0x00000000007d0ebf in captured_main (data=0x7fffffffd3f0)
+	     at gdb/main.c:1353
+	 #14 0x00000000007d0f25 in gdb_main (args=0x7fffffffd3f0)
+	     at gdb/main.c:1368
+	 #15 0x00000000004186dd in main (argc=5, argv=0x7fffffffd508)
+	     at gdb/gdb.c:32
+
+	This relatively short backtrace is due to the current UI's async field
+	being set to 1.
+
+	Yet another thing to be aware of regarding this problem is the
+	difference in the way that commands associated to dprintf breakpoints
+	versus regular breakpoints are handled.  While they both use a command
+	list associated with the breakpoint, regular breakpoints will place
+	the commands to be run on the bpstat chain constructed in
+	bp_stop_status().  These commands are run later on.  For dprintf
+	breakpoints, commands are run via the 'after_condition_true' function
+	pointer directly from bpstat_stop_status().  (The 'commands' field in
+	the bpstat is cleared in dprintf_after_condition_true().  This
+	prevents the dprintf commands from being run again later on when other
+	commands on the bpstat chain are processed.)
+
+	Another thing that I noticed is that dprintf breakpoints are the only
+	type of breakpoint which use 'after_condition_true'.  This suggests
+	that one possible way of fixing this problem, that of making dprintf
+	breakpoints work more like regular breakpoints, probably won't work.
+	(I must admit, however, that my understanding of this code isn't
+	complete enough to say why.  I'll trust that whoever implemented it
+	had a good reason for doing it this way.)
+
+	The comment referenced earlier regarding 'executing_breakpoint_commands'
+	states that the reason for checking this variable is to avoid
+	potential endless recursion when a 'source' command appears in
+	bs->commands.  We know that a dprintf command is constrained to either
+	1) execution of a GDB printf command, 2) an inferior function call of
+	a printf-like function, or 3) execution of an agent-printf command.
+	Therefore, infinite recursion due to a 'source' command cannot happen
+	when executing commands upon hitting a dprintf breakpoint.
+
+	I chose to fix this problem by having dprintf_after_condition_true()
+	directly call execute_control_commands().  This means that it no
+	longer attempts to go through bpstat_do_actions_1() avoiding the
+	infinite recursion check for potential 'source' commands on the
+	command chain.  I think it simplifies this code a little bit too, a
+	definite bonus.
+
+	Summary:
+
+		* breakpoint.c (dprintf_after_condition_true): Don't call
+		bpstat_do_actions_1().  Call execute_control_commands()
+		instead.
+
+2021-11-10  Alan Modra  <amodra@gmail.com>
+
+	Re: Add --unicode option
+		* objdump: Whitespace fixes.
+		(long_options): Correct "ctf" entry.
+
+2021-11-10  Alan Modra  <amodra@gmail.com>
+
+	Re: Add --unicode option
+	At low optimisation levels gcc may warn.
+
+		* strings.c (print_unicode_stream_body): Avoid bogus "may be
+		used unitialised" warning.
+
+2021-11-10  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-09  Alan Modra  <amodra@gmail.com>
+
+	PR28543, readelf entered an infinite loop
+	This little tweak terminates fuzzed binary readelf output a little
+	quicker.
+
+		PR 28543
+		* dwarf.c (read_and_display_attr_value): Consume a byte when
+		form is unrecognized.
+
+2021-11-09  Alan Modra  <amodra@gmail.com>
+
+	PR28542, Undefined behaviours in readelf.c
+		PR 28542
+		* readelf.c (dump_relocations): Check that section headers have
+		been read before attempting to access section name.
+		(print_dynamic_symbol): Likewise.
+		(process_mips_specific): Delete dead code.
+
+2021-11-09  Pedro Alves  <pedro@palves.net>
+
+	gdb::array_view slicing/container selftest - test std::array too
+	Change-Id: I2141b0b8a09f6521a59908599eb5ba1a19b18dc6
+
+2021-11-09  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb.debuginfod/fetch_src_and_symbols.exp: fix when GDB is built with AddressSanitizer
+	This test fails for me, showing:
+
+	    ERROR: tcl error sourcing /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.debuginfod/fetch_src_and_symbols.exp.
+	    ERROR: This GDB was configured as follows:
+	       configure --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
+	                 --with-auto-load-dir=$debugdir:$datadir/auto-load
+	                 --with-auto-load-safe-path=$debugdir:$datadir/auto-load
+	    ... and much more ...
+
+	The problem is that TCL's exec throws an error as soon as the exec'ed
+	process outputs on stderr.  When GDB is built with ASan, it prints some
+	warnings about pre-existing signal handlers:
+
+	    warning: Found custom handler for signal 7 (Bus error) preinstalled.
+	    warning: Found custom handler for signal 8 (Floating point exception) preinstalled.
+	    warning: Found custom handler for signal 11 (Segmentation fault) preinstalled.
+
+	Pass --quiet to GDB to avoid these warnings.
+
+	Change-Id: I3751d89b9b1df646da19149d7cb86775e2d3e80f
+
+2021-11-09  Tom Tromey  <tromey@adacore.com>
+
+	Correctly handle DW_LLE_start_end
+	When the code to handle DW_LLE_start_end was added (as part of some
+	DWARF 5 work), it was written to add the base address.  However, this
+	seems incorrect -- the DWARF standard describes this as an address,
+	not an offset from the base address.
+
+	This patch changes a couple of spots in dwarf2/loc.c to fix this
+	problem.  It then changes decode_debug_loc_addresses to return
+	DEBUG_LOC_OFFSET_PAIR instead, which preserves the previous semantics.
+
+	This only showed up on the RISC-V target internally, due to the
+	combination of DWARF 5 and a newer version of GCC.  I've updated a
+	couple of existing loclists test cases to demonstrate the bug.
+
+2021-11-09  Tom Tromey  <tromey@adacore.com>
+
+	Fix build on rhES5
+	The rhES5 build failed due to an upstream import a while back.  The
+	bug here is that, while the 'personality' function exists,
+	ADDR_NO_RANDOMIZE is only defined in <linux/personality.h>, not
+	<sys/personality.h>.
+
+	However, <linux/personality.h> does not declare the 'personality'
+	function, and <sys/personality.h> and <linux/personality.h> cannot
+	both be included.
+
+	This patch restores one of the removed configure checks and updates
+	the code to check it.
+
+	We had this as a local patch at AdaCore, because it seemed like there
+	was no interest upstream.  However, now it turns out that this fixes
+	PR build/28555, so I'm sending it now.
+
+2021-11-09  H.J. Lu  <hjl.tools@gmail.com>
+
+	doc/ctf-spec.texi: Remove "@validatemenus off"
+	Remove @validatemenus from ctf-spec.texi, which has been removed from
+	texinfo by
+
+	commit a16dd1a9ece08568a1980b9a65a3a9090717997f
+	Author: Gavin Smith <gavinsmith0123@gmail.com>
+	Date:   Mon Oct 12 16:32:37 2020 +0100
+
+	    * doc/texinfo.texi
+	    (Writing a Menu, Customization Variables for @-Commands)
+	    (Command List),
+	    * doc/refcard/txirefcard.tex
+	    Remove @validatemenus.
+	    * tp/Texinfo/XS/Makefile.am (command_ids.h): Use gawk instead
+	    of awk.  Avoid discouraged "$p" usage, using "$(p)" instead.
+	    * tp/Texinfo/XS/configure.ac: Check for gawk.
+
+	commit 128acab3889b51809dc3bd3c6c74b61d13f7f5f4
+	Author: Gavin Smith <gavinsmith0123@gmail.com>
+	Date:   Thu Jan 3 14:51:53 2019 +0000
+
+	    Update refcard.
+
+	    * doc/refcard/txirefcard.tex: @setfilename is no longer
+	    mandatory.  Do not mention @validatemenus or explicitly giving
+	    @node pointers, as these are not very important features.
+
+		PR libctf/28567
+		* doc/ctf-spec.texi: Remove "@validatemenus off".
+
+2021-11-09  Nick Clifton  <nickc@redhat.com>
+
+	Add --unicode option to control how unicode characters are handled by display tools.
+		* nm.c: Add --unicode option to control how unicode characters are
+		handled.
+		* objdump.c: Likewise.
+		* readelf.c: Likewise.
+		* strings.c: Likewise.
+		* binutils.texi: Document the new feature.
+		* NEWS: Document the new feature.
+		* testsuite/binutils-all/unicode.exp: New file.
+		* testsuite/binutils-all/nm.hex.unicode
+		* testsuite/binutils-all/strings.escape.unicode
+		* testsuite/binutils-all/objdump.highlight.unicode
+		* testsuite/binutils-all/readelf.invalid.unicode
+
+2021-11-09  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: sh: simplify testsuite a bit
+	Switch from the centralized list in the exp file to each test declaring
+	its own requirements which they're already (mostly) doing.  This will
+	increase coverage slightly by running more tests in more configurations
+	since the hardcoded exp list was a little out of date.
+
+	We have to mark the psh* tests as shdsp only (to match what the exp
+	file was doing), mark the fsca & fsrra tests as failing (since they
+	weren't even being run by the exp file), and to fix the expected
+	output & status of the fail test.
+
+2021-11-09  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: cris: clean up missing func prototype warnings
+	Move some unused funcs under existing #if 0 protection, mark a few
+	local funcs as static, and add missing prototypes for the rest which
+	are used from other files.  This fixes all the fatal warnings in the
+	mloop files so we can turn -Werror on here fully.
+
+2021-11-09  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-08  Lancelot SIX  <lsix@lancelotsix.com>
+
+	Improve gdb::array_view ctor from contiguous containers
+	While reading the interface of gdb::array_view, I realized that the
+	constructor that builds an array_view on top of a contiguous container
+	(such as std::vector, std::array or even gdb::array_view) can be
+	missused.
+
+	Lets consider the following code sample:
+
+		struct Parent
+		{
+		  Parent (int a): a { a } {}
+		  int a;
+		};
+
+		std::ostream &operator<< (std::ostream& os, const Parent & p)
+		{ os << "Parent {a=" << p.a << "}"; return os; }
+
+		struct Child : public Parent
+		{
+		  Child (int a, int b): Parent { a }, b { b } {}
+		  int b;
+		};
+
+		std::ostream &operator<< (std::ostream& os, const Child & p)
+		{ os << "Child {a=" << p.a << ", b=" << p.b << "}"; return os; }
+
+		template <typename T>
+		void print (const gdb::array_view<const T> &p)
+		{
+		  std::for_each (p.begin (), p.end (), [](const T &p) { std::cout << p << '\n'; });
+		}
+
+	Then with the current interface nothinng prevents this usage of
+	array_view to be done:
+
+		const std::array<Child, 3> elts = {
+		  Child {1, 2},
+		  Child {3, 4},
+		  Child {5, 6}
+		};
+		print_all<Parent> (elts);
+
+	This compiles fine and produces the following output:
+
+		Parent {a=1}
+		Parent {a=2}
+		Parent {a=3}
+
+	which is obviously wrong.  There is nowhere in memory a Parent-like
+	object for which the A member is 2 and this call to print_all<Parent>
+	shold not compile at all (calling print_all<Child> is however fine).
+
+	This comes down to the fact that a Child* is convertible into a Parent*,
+	and that an array view is constructed to a pointer to the first element
+	and a size.  The valid type pointed to that can be used with this
+	constructor are restricted using SFINAE, which requires that a
+	pointer to a member into the underlying container can be converted into a
+	pointer the array_view's data type.
+
+	This patch proposes to change the constraints on the gdb::array_view
+	ctor which accepts a container now requires that the (decayed) type of
+	the elements in the container match the (decayed) type of the array_view
+	being constructed.
+
+	Applying this change required minimum adjustment in GDB codebase, which
+	are also included in this patch.
+
+	Tested by rebuilding.
+
+2021-11-08  Lancelot SIX  <lsix@lancelotsix.com>
+
+	Add a const version of gdb_argv:as_array_view
+	This commits adds const versions for the GET and AS_ARRAX_VIEW methods
+	of gdb_argv.  Those methods will be required in the following patch of
+	the series.
+
+2021-11-08  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: fix nulltr -> nullptr typo
+	Change-Id: I04403bd85ec3fa75ea14130d68daba675a2a8aeb
+
+2021-11-08  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: tweak scoped_disable_commit_resumed uses when resuming all threads in non-stop
+	When doing "continue -a" in non-stop mode, each thread is individually
+	resumed while the commit resumed state is enabled.  This forces the
+	target to commit each resumption immediately, instead of being able to
+	batch things.
+
+	The reason is that there is no scoped_disable_commit_resumed around the
+	loop over threads in continue_1, when "non_stop && all_threads" is true.
+	Since the proceed function is called once for each thread, the
+	scoped_disable_commit_resumed in proceed therefore forces commit-resumed
+	between each thread resumption.  Add the necessary
+	scoped_disable_commit_resumed in continue_1 to avoid that.
+
+	I looked at the MI side of things, the function exec_continue, and found
+	that it was correct.  There is a similar iteration over threads, and
+	there is a scoped_disable_commit_resumed at the function scope.  This is
+	not wrong, but a bit more than we need.  The branches that just call
+	continue_1 do not need it, as continue_1 takes care of disabling commit
+	resumed.  So, move the scoped_disable_commit_resumed to the inner scope
+	where we iterate on threads and proceed them individually.
+
+	Here's an example debugging a multi-threaded program attached by
+	gdbserver (debug output trimmed for brevity):
+
+	    $ ./gdb -nx -q --data-directory=data-directory -ex "set non-stop" -ex "tar rem :1234"
+	    (gdb) set debug remote
+	    (gdb) set debug infrun
+	    (gdb) c -a
+	    Continuing.
+	    [infrun] proceed: enter
+	      [infrun] scoped_disable_commit_resumed: reason=proceeding
+	      [remote] Sending packet: $vCont;c:p14388.14388#90
+	      [infrun] reset: reason=proceeding
+	      [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote
+	      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote
+	    [infrun] proceed: exit
+	    [infrun] proceed: enter
+	      [infrun] scoped_disable_commit_resumed: reason=proceeding
+	      [remote] Sending packet: $vCont;c:p14388.1438a#b9
+	      [infrun] reset: reason=proceeding
+	      [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote
+	      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote
+	    [infrun] proceed: exit
+	    ... and so on for each thread ...
+
+	Notice how we send one vCont;c for each thread.  With the patch applied, we
+	send a single vCont;c at the end:
+
+	    [infrun] scoped_disable_commit_resumed: reason=continue all threads in non-stop
+	    [infrun] proceed: enter
+	      [infrun] scoped_disable_commit_resumed: reason=proceeding
+	      [infrun] reset: reason=proceeding
+	    [infrun] proceed: exit
+	    [infrun] clear_proceed_status_thread: Thread 85790.85792
+	    [infrun] proceed: enter
+	      [infrun] scoped_disable_commit_resumed: reason=proceeding
+	      [infrun] reset: reason=proceeding
+	    [infrun] proceed: exit
+	    ... proceeding threads individually ...
+	    [infrun] reset: reason=continue all threads in non-stop
+	    [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote
+	    [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote
+	    [remote] Sending packet: $vCont;c#a8
+
+	Change-Id: I331dd2473c5aa5114f89854196fed2a8fdd122bb
+
+2021-11-08  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: make dwarf2_find_containing_comp_unit take a dwarf2_per_bfd
+	While reading another patch, I saw that this function didn't need to
+	take a dwarf2_per_objfile, but could take a dwarf2_per_bfd instead.
+	It doesn't change the behavior, but doing this shows that this function
+	is objfile-independent (can work with only the shared per-bfd data).
+
+	Change-Id: I58f9c9cef6688902e95226480285da2d0005d77f
+
+2021-11-08  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove bpstat typedef, rename bpstats to bpstat
+	I don't find that the bpstat typedef, which hides a pointer, is
+	particularly useful.  In fact, it confused me many times, and I just see
+	it as something to remember that adds cognitive load.  Also, with C++,
+	we might want to be able to pass bpstats objects by const-reference, not
+	necessarily by pointer.
+
+	So, remove the bpstat typedef and rename struct bpstats to bpstat (since
+	it represents one bpstat, it makes sense that it is singular).
+
+	Change-Id: I52e763b6e54ee666a9e045785f686d37b4f5f849
+
+2021-11-08  Nick Alcock  <nick.alcock@oracle.com>
+
+	libctf: add CTF format specification
+	It's been a long time since most of this was written: it's long past
+	time to put it in the binutils source tree.  It's believed correct and
+	complete insofar as it goes: it documents format v3 (the current
+	version) but not the libctf API or any earlier versions.  (The
+	earlier versions can be read by libctf but not generated by it, and you
+	are highly unlikely ever to see an example of any of them.)
+
+	libctf/ChangeLog
+	2021-11-08  Nick Alcock  <nick.alcock@oracle.com>
+
+		* doc/ctf-spec.texi: New file.
+		* configure.ac (MAKEINFO): Add.
+		(BUILD_INFO): Likewise.
+		(AC_CONFIG_FILES) [doc/Makefile]: Add.
+		* Makefile.am [BUILD_INFO] (SUBDIRS): Add doc/.
+		* doc/Makefile.am: New file.
+		* doc/Makefile.in: Likewise.
+		* configure: Regenerated.
+		* Makefile.in: Likewise.
+
+2021-11-08  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-07  Alan Modra  <amodra@gmail.com>
+
+	Correct ld script wildcard matching description
+	Goes with commit 68bbb9f788d0
+
+		* ld.texi (Input Section Wildcards): Delete paragraph incorrectly
+		saying '*' does not match '/'.
+
+2021-11-07  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: sh: fix conversion of PC to an integer
+	On LLP64 targets where sizeof(long) != sizeof(void*), this code fails:
+	sim/sh/interp.c:704:24: error: cast from pointer to integer of different size  -Werror=pointer-to-int-cast]
+	  704 |   do { memstalls += ((((long) PC & 3) != 0) ? (n) : ((n) - 1)); } while (0)
+	      |                        ^
+
+	Since this code simply needs to check alignment, cast it using uintptr_t
+	which is the right type for this.
+
+2021-11-07  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: sh: clean up time(NULL) call
+	Casting 0 to a pointer via (long *) doesn't work on LLP64 targets:
+	error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
+
+	It's also unnecessary here.  We can simply pass NULL like every other
+	bit of code does.
+
+2021-11-07  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: sh: break utime logic out of _WIN32 check
+	Some _WIN32 targets provide utime (like mingw), so move the header
+	include out from _WIN32 and under the specific HAVE_UTIME_H check.
+
+	sim: sh: drop errno extern
+	This isn't needed on any reasonable target nowadays, and no other
+	source does this, and breaks with some mingw targets, so punt the
+	extern entirely.
+
+	sim: sh: fix isnan redefinition with mingw targets
+	The code assumes that all _WIN32 targets are the same and can
+	define isnan to _isnan.  For mingw targets, they provide an isnan
+	define already, so no need for the fallback here.
+
+	sim: arm/bfin/rx: undefine page size from system headers
+	Some targets (like cygwin) will export page size defines that clash
+	with our local usage here.  Undefine the system one to fix building
+	for these targets.
+
+	sim: ppc: switch to libiberty environ.h
+	Drop our compat code and assume environ exists to simplify.
+	We did this for all other targets already, but ppc was missed.
+
+	sim: sh: enable -Werror everywhere
+	With most of the warnings fixed in interp.c, we can enable -Werror
+	here too now.  There are some -Wmaybe-uninitialized warnings still
+	lurking that look legitimate, but we don't flag those are fatal,
+	and I don't have the expertise to dive into each opcode to figure
+	out the right way to clean them up.
+
+	sim: sh: fix uninitialized variable usage with pdmsb
+	This block of code relies on i to control which bits to test and how
+	many times to run through the loop, but it never actually initialized
+	it.  There is another chunk of code that handles the pdmsb instruction
+	that sets i to 16, so use that here too assuming it's correct.  The
+	programming manual suggests this is the right value too, but I am by
+	no means a SuperH DSP expert.  The tests are still passing though ...
+
+	sim: sh: constify a few read-only lookup tables
+
+	sim: sh: fix various parentheses warnings
+	Add parentheses to a bunch of places where the compiler suggests we
+	do to avoid confusion to most readers.
+
+	sim: sh: fix unused-value warnings
+	These macro expansions are deliberate in not using the computed value
+	so that they trigger side-effects (possible invalid memory accesses)
+	but while otherwise being noops.  Add a (void) cast so the compiler
+	knows these are intentional.
+
+	sim: sh: rework register layout with anonymous unions & structs
+	Now that we require C11, we can leverage anonymous unions & structs
+	to fix a long standing issue with the SH register layout.  The use
+	of sregs.i for sh-dsp has generated a lot of compiler warnings about
+	the access being out of bounds -- it only has 7 elements declared,
+	but code goes beyond that to reach into the fregs that follow.  But
+	now that we have anonymous unions, we can reduce the nested names
+	and have sregs cover all of these registers.
+
+2021-11-07  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-06  Tiezhu Yang  <yangtiezhu@loongson.cn>
+
+	sim: mips: use sim_fpu_to{32,64}u to fix build warnings
+	Since the first argument type is unsigned32 or unsigned64, just use
+	sim_fpu_to{32,64}u instead of sim_fpu_to{32,64}i to fix the following
+	build warnings:
+
+	  CC     cp1.o
+	.../sim/mips/cp1.c: In function 'convert':
+	.../sim/mips/cp1.c:1425:32: warning: pointer targets in passing argument 1 of 'sim_fpu_to32i' differ in signedness [-Wpointer-sign]
+	       status |= sim_fpu_to32i (&result32, &wop, round);
+	                                ^~~~~~~~~
+	In file included from .../sim/mips/sim-main.h:67,
+	                 from .../sim/mips/cp1.c:46:
+	.../sim/mips/../common/sim-fpu.h:270:22: note: expected 'signed32 *' {aka 'int *'} but argument is of type 'unsigned32 *' {aka 'unsigned int *'}
+	 INLINE_SIM_FPU (int) sim_fpu_to32i (signed32 *i, const sim_fpu *f,
+	                      ^~~~~~~~~~~~~
+	.../sim/mips/cp1.c:1429:32: warning: pointer targets in passing argument 1 of 'sim_fpu_to64i' differ in signedness [-Wpointer-sign]
+	       status |= sim_fpu_to64i (&result64, &wop, round);
+	                                ^~~~~~~~~
+	In file included from .../sim/mips/sim-main.h:67,
+	                 from .../sim/mips/cp1.c:46:
+	.../sim/mips/../common/sim-fpu.h:274:22: note: expected 'signed64 *' {aka 'long int *'} but argument is of type 'unsigned64 *' {aka 'long unsigned int *'}
+	 INLINE_SIM_FPU (int) sim_fpu_to64i (signed64 *i, const sim_fpu *f,
+	                      ^~~~~~~~~~~~~
+	.../sim/mips/cp1.c: In function 'convert_ps':
+	.../sim/mips/cp1.c:1528:34: warning: pointer targets in passing argument 1 of 'sim_fpu_to32i' differ in signedness [-Wpointer-sign]
+	       status_u |= sim_fpu_to32i (&res_u, &wop_u, round);
+	                                  ^~~~~~
+	In file included from .../sim/mips/sim-main.h:67,
+	                 from .../sim/mips/cp1.c:46:
+	.../sim/mips/../common/sim-fpu.h:270:22: note: expected 'signed32 *' {aka 'int *'} but argument is of type 'unsigned32 *' {aka 'unsigned int *'}
+	 INLINE_SIM_FPU (int) sim_fpu_to32i (signed32 *i, const sim_fpu *f,
+	                      ^~~~~~~~~~~~~
+	.../sim/mips/cp1.c:1529:34: warning: pointer targets in passing argument 1 of 'sim_fpu_to32i' differ in signedness [-Wpointer-sign]
+	       status_l |= sim_fpu_to32i (&res_l, &wop_l, round);
+	                                  ^~~~~~
+	In file included from .../sim/mips/sim-main.h:67,
+	                 from .../sim/mips/cp1.c:46:
+	.../sim/mips/../common/sim-fpu.h:270:22: note: expected 'signed32 *' {aka 'int *'} but argument is of type 'unsigned32 *' {aka 'unsigned int *'}
+	 INLINE_SIM_FPU (int) sim_fpu_to32i (signed32 *i, const sim_fpu *f,
+	                      ^~~~~~~~~~~~~
+
+2021-11-06  Alan Modra  <amodra@gmail.com>
+
+	Modernise yyerror
+	Newer versions of bison emit a prototype for yyerror
+		void yyerror (const char *);
+	This clashes with some of our old code that declares yyerror to return
+	an int.  Fix that in most cases by modernizing yyerror.  bfin-parse.y
+	uses the return value all over the place, so for there disable
+	generation of the prototype as specified by posix.
+
+	binutils/
+		* arparse.y (yyerror): Return void.
+		* dlltool.c (yyerror): Likewise.
+		* dlltool.h (yyerror): Likewise.
+		* sysinfo.y (yyerror): Likewise.
+		* windmc.h (yyerror): Likewise.
+		* mclex.c (mc_error): Extract from ..
+		(yyerror): ..here, both now returning void.
+	gas/
+		* config/bfin-parse.y (yyerror): Define.
+		(yyerror): Make static.
+		* itbl-parse.y (yyerror): Return void.
+	ld/
+		* deffilep.y (def_error): Return void.
+
+2021-11-06  Alan Modra  <amodra@gmail.com>
+
+	ubsan: undefined shift in mach-o.c
+	This one was logically wrong too.  If file_ptr was 64 bits, then -1U
+	is extended to 0x00000000ffffffff, probably not what was intended
+	here.
+
+		* mach-o.c (FILE_ALIGN): Correct expression.
+
+2021-11-06  Fangrui Song  <maskray@google.com>
+
+	readelf: Support RELR in -S and -d and output
+	readelf -r dumping support is not added in this patch.
+
+	include/
+		* elf/common.h: Add SHT_RELR, DT_RELR{,SZ,ENT}
+	bfd/
+		* elf.c (_bfd_elf_print_private_bfd_data): Add DT_RELR{,SZ,ENT}.
+	binutils/
+		* readelf.c (get_dynamic_type): Add DT_RELR{,SZ,ENT}.
+		(get_section_type_name): Add SHT_RELR.
+
+2021-11-06  Fangrui Song  <maskray@google.com>
+
+	readelf: Make DT_PREINIT_ARRAYSZ's output style match DT_INIT_ARRAYSZ
+	The output now looks like:
+
+	- 0x0000000000000021 (PREINIT_ARRAYSZ)    0x10
+	+ 0x0000000000000021 (PREINIT_ARRAYSZ)    16 (bytes)
+	  0x0000000000000019 (INIT_ARRAY)         0xbefc90
+	  0x000000000000001b (INIT_ARRAYSZ)       536 (bytes)
+
+		* readelf.c (process_dynamic_section): Handle DT_PREINIT_ARRAYSZ.
+
+2021-11-06  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: clarify license text via COPYING file
+	The project has been using GPL v3 for a while now in the source files,
+	and the arm & ppc ports have carried a copy of the COPYING file.  Lets
+	move those up to the top sim dir like other projects to make it clear.
+
+	Also drop the ppc/COPYING.LIB as it's not really referenced by any
+	source as everything is GPL v3.
+
+2021-11-06  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-05  Tom Tromey  <tom@tromey.com>
+
+	Introduce make_unique_xstrndup
+	This adds a new make_unique_xstrndup function, which is the "n"
+	analogue of make_unique_xstrdup.  It also updates a couple existing
+	places to use this function.
+
+2021-11-05  Pedro Alves  <pedro@palves.net>
+
+	Avoid /proc/pid/mem races (PR 28065)
+	PR 28065 (gdb.threads/access-mem-running-thread-exit.exp intermittent
+	failure) shows that GDB can hit an unexpected scenario -- it can
+	happen that the kernel manages to open a /proc/PID/task/LWP/mem file,
+	but then reading from the file returns 0/EOF, even though the process
+	hasn't exited or execed.
+
+	"0" out of read/write is normally what you get when the address space
+	of the process the file was open for is gone, because the process
+	execed or exited.  So when GDB gets the 0, it returns memory access
+	failure.  In the bad case in question, the process hasn't execed or
+	exited, so GDB fails a memory access when the access should have
+	worked.
+
+	GDB has code in place to gracefully handle the case of opening the
+	/proc/PID/task/LWP/mem just while the LWP is exiting -- most often the
+	open fails with EACCES or ENOENT.  When it happens, GDB just tries
+	opening the file for a different thread of the process.  The testcase
+	is written such that it stresses GDB's logic of closing/reopening the
+	/proc/PID/task/LWP/mem file, by constantly spawning short lived
+	threads.
+
+	However, there's a window where the kernel manages to find the thread,
+	but the thread exits just after and clears its address space pointer.
+	In this case, the kernel creates a file successfully, but the file
+	ends up with no address space associated, so a subsequent read/write
+	returns 0/EOF too, just like if the whole process had execed or
+	exited.  This is the case in question that GDB does not handle.
+
+	Oleg Nesterov gave this suggestion as workaround for that race:
+
+	    gdb can open(/proc/pid/mem) and then read (say) /proc/pid/statm.
+	    If statm reports something non-zero, then open() was "successfull".
+
+	I think that might work.  However, I didn't try it, because I realized
+	we have another nasty race that that wouldn't fix.
+
+	The other race I realized is that because we close/reopen the
+	/proc/PID/task/LWP/mem file when GDB switches to a different inferior,
+	then it can happen that GDB reopens /proc/PID/task/LWP/mem just after
+	a thread execs, and before GDB has seen the corresponding exec event.
+	I.e., we can open a /proc/PID/task/LWP/mem file accessing the
+	post-exec address space thinking we're accessing the pre-exec address
+	space.
+
+	A few months back, Simon, Oleg and I discussed a similar race:
+
+	  [Bug gdb/26754] Race condition when resuming threads and one does an exec
+	  https://sourceware.org/bugzilla/show_bug.cgi?id=26754
+
+	The solution back then was to make the kernel fail any ptrace
+	operation until the exec event is consumed, with this kernel commit:
+
+	 commit dbb5afad100a828c97e012c6106566d99f041db6
+	 Author:     Oleg Nesterov <oleg@redhat.com>
+	 AuthorDate: Wed May 12 15:33:08 2021 +0200
+	 Commit:     Linus Torvalds <torvalds@linux-foundation.org>
+	 CommitDate: Wed May 12 10:45:22 2021 -0700
+
+	     ptrace: make ptrace() fail if the tracee changed its pid unexpectedly
+
+	This however, only applies to ptrace, not to the /proc/pid/mem file
+	opening case.  Also, even if it did apply to the file open case, we
+	would want to support current kernels until such a fix is more wide
+	spread anyhow.
+
+	So all in all, this commit gives up on the idea of only ever keeping
+	one /proc/pid/mem file descriptor open.  Instead, make GDB open a
+	/proc/pid/mem per inferior, and keep it open until the inferior exits,
+	is detached or execs.  Make GDB open the file right after the inferior
+	is created or is attached to or forks, at which point we know the
+	inferior is stable and stopped and isn't thus going to exec, or have a
+	thread exit, and so the file open won't fail (unless the whole process
+	is SIGKILLed from outside GDB, at which point it doesn't matter
+	whether we open the file).
+
+	This way, we avoid both races described above, at the expense of using
+	more file descriptors (one per inferior).
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28065
+	Change-Id: Iff943b95126d0f98a7973a07e989e4f020c29419
+
+2021-11-05  Andrew Burgess  <aburgess@redhat.com>
+
+	gdb/testsuite: use gdb_get_line_number
+	Replaces a hard coded line number with a use of gdb_get_line_number.
+
+	I suspect that the line number has, over time, come adrift from where
+	it was supposed to be stopping.  When the test was first added, line
+	770 pointed at the final 'return 0' in function main.  Over time, as
+	things have been added, line 770 now points at some random location in
+	the middle of main.
+
+	So, I've marked the 'return 0' with a comment, and now the test will
+	always stop there.
+
+	I also removed an old comment from 1997 talking about how these tests
+	will only pass with the HP compiler, followed by an additional comment
+	from 2000 saying that the tests now pass with GCC.
+
+	I get the same results before and after this change.
+
+2021-11-05  Alan Modra  <amodra@gmail.com>
+
+	PR28541, unstable cie offset in the output of readelf
+	Calculating "0 - pointer" can indeed result in seeming randomness as
+	the pointer address varies.
+
+		PR 28541
+		* dwarf.c (display_debug_frames): Don't print cie offset when
+		invalid, print "invalid" instead.  Remove now redundant warning.
+
+2021-11-05  Alan Modra  <amodra@gmail.com>
+
+	Missing va_end in aarch64-dis.c
+		* aarch64-dis.c (extract_fields): Invoke va_end.
+
+2021-11-05  Alan Modra  <amodra@gmail.com>
+
+	PR28530, Hang in objdump on machine with 196GB RAM
+	Investigating the PR28530 testcase, which has a fuzzed compression
+	header with an enormous size, I noticed that decompress_contents is
+	broken when the size doesn't fit in strm.avail_out.  It wouldn't be
+	too hard to support larger sizes (patches welcome!) but for now just
+	stop decompress_contents from returning rubbish.
+
+		PR 28530
+		* compress.c (decompress_contents): Fail when uncompressed_size
+		is too big.
+		(bfd_init_section_decompress_status): Likewise.
+
+2021-11-05  Alan Modra  <amodra@gmail.com>
+
+	asan: alpha-vms: objdump buffer overflows
+		* vms-alpha.c (evax_bfd_print_desc): Sanity check buffer access.
+		(evax_bfd_print_valspec, evax_bfd_print_typspec): Likewise.
+		(evax_bfd_print_dst): Likewise.
+
+2021-11-05  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-04  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: introduce "set index-cache enabled", deprecate "set index-cache on/off"
+	The "set index-cache" command is used at the same time as a prefix
+	command (prefix for "set index-cache directory", for example), and a
+	boolean setting for turning the index-cache on and off.  Even though I
+	did introduce that, I now don't think it's a good idea to do something
+	non-standard like this.
+
+	First, there's no dedicated CLI command to show whether the index-cache
+	is enabled, so it has to be custom output in the "show index-cache
+	handler".  Also, it means there's no good way a MI frontend can find out
+	if the index-cache is enabled.  "-gdb-show index-cache" doesn't show it
+	in the MI output record:
+
+	    (gdb) interpreter-exec mi "-gdb-show index-cache"
+	    ~"\n"
+	    ~"The index cache is currently disabled.\n"
+	    ^done,showlist={option={name="directory",value="/home/simark/.cache/gdb"}}
+
+	Fix this by introducing "set/show index-cache enabled on/off", regular
+	boolean setting commands.  Keep commands "set index-cache on" and "set
+	index-cache off" as deprecated aliases of "set index-cache enabled",
+	with respectively the default arguments "on" and "off".
+
+	Update tests using "set index-cache on/off" to use the new command.
+	Update the regexps in gdb.base/maint.exp to figure out whether the
+	index-cache is enabled or not.  Update the doc to mention the new
+	commands.
+
+	Change-Id: I7d5aaaf7fd22bf47bd03e0023ef4fbb4023b37b3
+
+2021-11-04  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: pass/return setting setter/getter scalar values by value
+	The getter and setter in struct setting always receive and return values
+	by const reference.  This is not necessary for scalar values (like bool
+	and int), but more importantly it makes it a bit annoying to write a
+	getter, you have to use a scratch static variable or something similar
+	that you can refer to:
+
+	  const bool &
+	  my_getter ()
+	  {
+	    static bool value;
+	    value = function_returning_bool ();
+	    return value;
+	  }
+
+	Change the getter and setter function signatures to receive and return
+	value by value instead of by reference, when the underlying data type is
+	scalar.  This means that string-based settings will still use
+	references, but all others will be by value.  The getter above would
+	then be re-written as:
+
+	  bool
+	  my_getter ()
+	  {
+	    return function_returning_bool ();
+	  }
+
+	This is useful for a patch later in this series that defines a boolean
+	setting with a getter and a setter.
+
+	Change-Id: Ieca3a2419fcdb75a6f75948b2c920b548a0af0fd
+
+2021-11-04  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove command_class enum class_deprecated
+	The class_deprecated enumerator isn't assigned anywhere, so remove it.
+	Commands that are deprecated have cmd_list_element::cmd_deprecated set
+	instead.
+
+	Change-Id: Ib35e540915c52aa65f13bfe9b8e4e22e6007903c
+
+2021-11-04  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove unnecessary cmd_list_element::aliases nullptr checks
+	Remove two unnecessary nullptr checks.  If aliases is nullptr, then the
+	for loops will simply be skipped.
+
+	Change-Id: I9132063bb17798391f8d019af305383fa8e0229f
+
+2021-11-04  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdbserver: re-generate configure
+	I get some diffs when running autoconf in gdbserver, probably leftovers
+	from commit 5dfe4bfcb969 ("Fix format_pieces selftest on Windows").
+	Re-generate configure in that directory.
+
+	Change-Id: Icdc9906af95fbaf1047a579914b2983f8ec5db08
+
+2021-11-04  H.J. Lu  <hjl.tools@gmail.com>
+
+	Revert "bfd: Always check sections with the corrupt size"
+	This reverts commit e0f7ea91436dd308a094c4c101fd4169e8245a91.
+
+2021-11-04  H.J. Lu  <hjl.tools@gmail.com>
+
+	bfd: Always check sections with the corrupt size
+	Always check sections with the corrupt size for non-MMO files.  Skip MMO
+	files for compress_status == COMPRESS_SECTION_NONE since MMO has special
+	handling for COMPRESS_SECTION_NONE.
+
+		PR binutils/28530
+		* compress.c (bfd_get_full_section_contents): Always check
+		sections with the corrupt size.
+
+2021-11-04  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: Clarify the behavior of .option rvc or norvc.
+	Add/Remove the rvc extension to/from the riscv_subsets once the
+	.option rvc/norvc is set.  So that we don't need to always check
+	the riscv_opts.rvc in the riscv_subset_supports, just call the
+	riscv_lookup_subset to search the subset list is enough.
+
+	Besides, we will need to dump the instructions according to the
+	elf architecture attributes.  That means the dis-assembler needs
+	to parse the architecture string from the elf attribute before
+	dumping any instructions, and also needs to recognized the
+	INSN_CLASS* classes from riscv_opcodes.  Therefore, I suppose
+	some functions will need to be moved from gas/config/tc-riscv.c
+	to bfd/elfxx-riscv.c, including riscv_multi_subset_supports and
+	riscv_subset_supports.  This is one of the reasons why we need
+	this patch.
+
+	This patch passes the gcc/binutils regressions of rv32emc-elf,
+	rv32i-elf, rv64gc-elf and rv64gc-linux toolchains.
+
+	bfd/
+		* elfxx-riscv.c (riscv_remove_subset): Remove the extension
+		from the subset list.
+		(riscv_update_subset): Add/Remove an extension to/from the
+		subset list.  This is used for the .option rvc or norvc.
+		* elfxx-riscv.h: Added the extern bool riscv_update_subset.
+	gas/
+		* config/tc-riscv.c (riscv_set_options): Removed the unused
+		rve flag.
+		(riscv_opts): Likewise.
+		(riscv_set_rve): Removed.
+		(riscv_subset_supports): Removed the riscv_opts.rvc check.
+		(riscv_set_arch): Don't need to call riscv_set_rve.
+		(reg_lookup_internal): Call riscv_subset_supports to check
+		whether the rve is supported.
+		(s_riscv_option): Add/Remove the rvc extension to/from the
+		subset list once the .option rvc/norvc is set.
+
+2021-11-04  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: mips: fix missing prototype in multi-run generation
+	The multi-run logic for mips involves a bit of codegen and rewriting
+	of files to include per-architecture prefixes.  That can result in
+	files with missing prototypes which cause compiler errors.  In the
+	case of mips-sde-elf targets, we have:
+	$srcdir/m16run.c -> $builddir/m16mips64r2_run.c
+	  sim_engine_run -> m16mips64r2_engine_run
+	$srcdir/micromipsrun.c -> micromipsmicromips_run.c
+	  sim_engine_run -> micromips64micromips_engine_run
+
+	micromipsmicromips_run.c:80:1: error: no previous prototype for 'micromips64micromips_engine_run' [-Werror=missing-prototypes]
+	   80 | micromips64micromips_engine_run (SIM_DESC sd, int next_cpu_nr, int nr_cpus,
+
+	We generate headers for those prototypes in the configure script,
+	but only include them in the generated multi-run.c file.  Update the
+	rewrite logic to turn the sim-engine.h include into the relevant
+	generated engine include so these files also have their prototypes.
+	$srcdir/m16run.c -> $builddir/m16mips64r2_run.c
+	  sim-engine.h -> m16mips64r2_engine.h
+	$srcdir/micromipsrun.c -> micromipsmicromips_run.c
+	  sim-engine.h -> micromips64micromips_engine.h
+
+2021-11-04  Alan Modra  <amodra@gmail.com>
+
+	PR28540, segmentation fault on NULL byte_get
+		PR 28540
+		* objdump.c (dump_bfd): Don't attempt load_separate_debug_files
+		when byte_get is NULL.
+
+2021-11-04  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-03  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: ppc: inline common sim-fpu.c logic
+	We will never bother building w/out a ../common/ sim directory,
+	so drop ancient logic supporting that method.
+
+2021-11-03  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: ppc: switch to common builds for callback objects
+	We don't need to build this anymore ourselves since the common build
+	includes it and produces the same object code.  We also need to pull
+	in the split constant modules after the refactoring and pulling them
+	out of nltvals.def & targ-map.o.  This doesn't matter for the sim
+	directly, but does for gdb and other users of libsim.
+
+	We also delete some conditional source tree logic since we already
+	require this be the "new" combined tree with a ../common/ dir.  This
+	has been the case for decades at this point.
+
+2021-11-03  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: fix gnu-nat build
+	When building gnu-nat.c, we get:
+
+	      CXX    gnu-nat.o
+	    gnu-nat.c: In member function 'virtual void gnu_nat_target::create_inferior(const char*, const string&, char**, int)':
+	    gnu-nat.c:2117:13: error: 'struct inf' has no member named 'target_is_pushed'
+	     2117 |   if (!inf->target_is_pushed (this))
+	          |             ^~~~~~~~~~~~~~~~
+	    gnu-nat.c:2118:10: error: 'struct inf' has no member named 'push_target'
+	     2118 |     inf->push_target (this);
+	          |          ^~~~~~~~~~~
+
+	This is because of a confusion between the generic `struct inferior`
+	variable and the gnu-nat-specific `struct inf` variable.  Fix by
+	referring to `inferior`, not `inf`.
+
+	Adjust the comment on top of `struct inf` to clarify the purpose of that
+	type.
+
+	Co-Authored-By: Andrea Monaco <andrea.monaco@autistici.org>
+	Change-Id: I2fe2f7f6ef61a38d79860fd262b08835c963fc77
+
+2021-11-03  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/testsuite: set ASAN_OPTIONS=detect_leaks=0 while running tests
+	We see some additional failures when running the testsuite against a GDB
+	compiled with ASan, compared to a GDB compiled without ASan.  Some of
+	them are caused by the memory leak report shown by the GDB process when
+	it exits, and the fact that it makes it exit with a non-zero exit code.
+
+	I generally try to remember to set ASAN_OPTIONS=detect_leaks=0 in my
+	environment when running the tests, but I don't always do it.  I think
+	it would be nice if the testsuite did it.  I don't see any use to have
+	leak detection when running the tests.  That is, unless we ever have a
+	test that ensures GDB doesn't leak memory, which isn't going to happen
+	any time soon.
+
+	Here are some tests I found that were affected by this:
+
+	    gdb.base/batch-exit-status.exp
+	    gdb.base/many-headers.exp
+	    gdb.base/quit.exp
+	    gdb.base/with-mf.exp
+	    gdb.dwarf2/gdb-add-index.exp
+	    gdb.dwarf2/gdb-add-index-symlink.exp
+	    gdb.dwarf2/imported-unit-runto-main.exp
+
+	Change-Id: I784c7df8a13979eb96587f735c1d33ba2cc6e0ca
+
+2021-11-03  Tom Tromey  <tromey@adacore.com>
+
+	Use section name in warnings in display_debug_loc
+	While looking at an apparently malformed executable with
+	"readelf --debug-dump=loc", I got this warning:
+
+	    readelf: ./main: Warning: There is a hole [0x89 - 0x95] in .debug_loc section.
+
+	However, the executable only has a .debug_loclists section.
+
+	This patch fixes the warning messages in display_debug_loc to use the
+	name of the section that is being processed.
+
+	binutils/ChangeLog
+	2021-11-03  Tom Tromey  <tromey@adacore.com>
+
+		* dwarf.c (display_debug_loc): Use section name in warnings.
+
+2021-11-03  Luis Machado  <luis.machado@linaro.org>
+
+	[AArch64] Make gdbserver register set selection dynamic
+	The current register set selection mechanism for AArch64 is static, based
+	on a pre-populated array of register sets.
+
+	This means that we might potentially probe register sets that are not
+	available. This is OK if the kernel errors out during ptrace, but probing the
+	tag_ctl register, for example, does not result in a ptrace error if the kernel
+	supports the tagged address ABI but not MTE (PR 28355).
+
+	Making the register set selection dynamic, based on feature checks, solves
+	this and simplifies the code a bit. It allows us to list all of the register
+	sets only once, and pick and choose based on HWCAP/HWCAP2 or other properties.
+
+	I plan to backport this fix to GDB 11 as well.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28355
+
+2021-11-03  Jan Kratochvil  <jan.kratochvil@redhat.com>
+
+	Fix LD_PRELOAD=/usr/lib64/libasan.so.6 gdb
+	Currently for a binary compiled normally (without -fsanitize=address) but with
+	LD_PRELOAD of ASAN one gets:
+
+	$ ASAN_OPTIONS=detect_leaks=0:alloc_dealloc_mismatch=1:abort_on_error=1:fast_unwind_on_malloc=0 LD_PRELOAD=/usr/lib64/libasan.so.6 gdb
+	=================================================================
+	==1909567==ERROR: AddressSanitizer: alloc-dealloc-mismatch (malloc vs operator delete []) on 0x602000001570
+	    #0 0x7f1c98e5efa7 in operator delete[](void*) (/usr/lib64/libasan.so.6+0xb0fa7)
+	...
+	0x602000001570 is located 0 bytes inside of 2-byte region [0x602000001570,0x602000001572)
+	allocated by thread T0 here:
+	    #0 0x7f1c98e5cd1f in __interceptor_malloc (/usr/lib64/libasan.so.6+0xaed1f)
+	    #1 0x557ee4a42e81 in operator new(unsigned long) (/usr/libexec/gdb+0x74ce81)
+	SUMMARY: AddressSanitizer: alloc-dealloc-mismatch (/usr/lib64/libasan.so.6+0xb0fa7) in operator delete[](void*)
+	==1909567==HINT: if you don't care about these errors you may set ASAN_OPTIONS=alloc_dealloc_mismatch=0
+	==1909567==ABORTING
+
+	Despite the code called properly operator new[] and operator delete[].
+	But GDB's new-op.cc provides its own operator new[] which gets translated into
+	malloc() (which gets recogized as operatore new(size_t)) but as it does not
+	translate also operators delete[] Address Sanitizer gets confused.
+
+	The question is how many variants of the delete operator need to be provided.
+	There could be 14 operators new but there are only 4, GDB uses 3 of them.
+	There could be 16 operators delete but there are only 6, GDB uses 2 of them.
+	It depends on libraries and compiler which of the operators will get used.
+	Currently being used:
+	                 U operator new[](unsigned long)
+	                 U operator new(unsigned long)
+	                 U operator new(unsigned long, std::nothrow_t const&)
+	                 U operator delete[](void*)
+	                 U operator delete(void*, unsigned long)
+
+	Tested on x86_64-linux.
+
+2021-11-03  Alan Modra  <amodra@gmail.com>
+
+	asan: dlltool buffer overflow: embedded NUL in string
+	yyleng gives the pattern length, xstrdup just copies up to the NUL.
+	So it is quite possible writing at an index of yyleng-2 overflows
+	the xstrdup allocated string buffer.  xmemdup quite handily avoids
+	this problem, even writing the terminating NUL over the trailing
+	quote.  Use it in ldlex.l too where we'd already had a report of this
+	problem and fixed it by hand, and to implement xmemdup0 in gas.
+
+	binutils/
+		* deflex.l (single and double quote strings): Use xmemdup.
+	gas/
+		* as.h (xmemdup0): Use xmemdup.
+	ld/
+		PR 20906
+		* ldlex.l (double quote string): Use xmemdup.
+
+2021-11-03  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: mloop: mark a few conditionally used funcs as unused
+	These are marked inline, so building w/gcc at higher optimization
+	levels will automatically discard them.  But building with -O0 will
+	trigger unused function warnings, so fix that.
+
+	The common before/after cover functions in the common mloop generator
+	are not used by all architecture ports.  Doesn't seem to be a hard
+	requirement, so marking them optional (i.e. unused) is fine.
+
+	The cris execute function is conditionally used depending on the
+	fast-build mode settings, so mark it unused too.
+
+2021-11-03  Alan Modra  <amodra@gmail.com>
+
+	asan: assert (addr_ranges) <= (start)
+	That assert would be more obvious if it were reported as
+	"addr_ranges <= end_ranges".  Fix that by using the obvious variable
+	in the final loop.  Stop the assertion by using a signed comparison:
+	It's possible for the rounding up of the arange pointer to exceed the
+	end of the block when the block size is fuzzed.
+
+		* dwarf.c (display_debug_aranges): Use "end_ranges" in loop
+		displaying ranges rather that "start".  Simplify rounding up
+		to 2*address_size boundary.  Use signed comparison in loop.
+
+2021-11-03  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: hoist cgen mloop rules up to common builds
+	These rules don't depend on the target compiler settings, so hoist
+	the build logic up to the common builds for better parallelization.
+
+	We have to extend the genmloop.sh logic a bit to allow outputting
+	to a subdir since it always assumed cwd was the right place.
+
+	We leave the cgen maintainer rules in the subdirs for now as they
+	aren't normally run, and they rely on cgen logic that has not yet
+	been generalized.
+
+2021-11-03  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: hoist mn10300 & v850 igen rules up to common builds
+	These rules don't depend on the target compiler settings, so hoist
+	the build logic up to the common builds for better parallelization.
+
+	We leave the mips rules in place as they depend on complicated
+	arch-specific configure logic that needs to be untangled first.
+
+2021-11-03  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: hoist gencode & opc2c build rules up to common builds
+	These rules don't depend on the target compiler settings, so hoist
+	the build logic up to the common builds for better parallelization.
+
+2021-11-03  Mike Frysinger  <vapier@gentoo.org>
+
+	opcodes: d10v: simplify header includes
+	This file doesn't use anything from bfd (sysdep.h), so drop that
+	include.  This avoids an implicit dependency on the generated
+	config.h which can be problematic for build-time tools.
+
+	Also swap stdio.h for stddef.h.  This file isn't doing or using
+	any I/O structures, but it does need NULL.
+
+2021-11-03  Alan Modra  <amodra@gmail.com>
+
+	PR28523, ld.bfd created undefined symbols on ppc64
+	This patch removes any fake (linker created) function descriptor
+	symbol if its code entry symbol isn't dynamic, to ensure bogus dynamic
+	symbols are not created.  The change to func_desc_adjust requires that
+	it be run only once, which means ppc64_elf_tls_setup can't call it for
+	just a few selected symbols.
+
+		PR 28523
+		* elf64-ppc.c (func_desc_adjust): If a function entry sym is
+		not dynamic and has no plt entry, hide any associated fake
+		function descriptor symbol.
+		(ppc64_elf_edit): Move func_desc_adjust iteration over syms to..
+		(ppc64_elf_tls_setup): ..here.
+
+2021-11-03  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-02  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/tdep, rs6000] Don't skip system call in skip_prologue
+	I ran into a case where a breakpoint on _exit never triggered, because it was
+	set past the end of the _exit prologue, past the end of the exit_group system
+	call (which does not return).
+
+	More concretely, the breakpoint was set at the last insn show here:
+	...
+	Dump of assembler code for function _exit:
+	   0x00007ffff7e42ea0 <+0>:     12 00 4c 3c     addis   r2,r12,18
+	   0x00007ffff7e42ea4 <+4>:     60 43 42 38     addi    r2,r2,17248
+	   0x00007ffff7e42ea8 <+8>:     00 00 00 60     nop
+	   0x00007ffff7e42eac <+12>:    f8 ff e1 fb     std     r31,-8(r1)
+	   0x00007ffff7e42eb0 <+16>:    78 1b 7f 7c     mr      r31,r3
+	   0x00007ffff7e42eb4 <+20>:    f0 ff c1 fb     std     r30,-16(r1)
+	   0x00007ffff7e42eb8 <+24>:    ea 00 00 38     li      r0,234
+	   0x00007ffff7e42ebc <+28>:    a0 8b 22 e9     ld      r9,-29792(r2)
+	   0x00007ffff7e42ec0 <+32>:    78 fb e3 7f     mr      r3,r31
+	   0x00007ffff7e42ec4 <+36>:    14 6a c9 7f     add     r30,r9,r13
+	   0x00007ffff7e42ec8 <+40>:    02 00 00 44     sc
+	   0x00007ffff7e42ecc <+44>:    26 00 00 7c     mfcr    r0
+	   0x00007ffff7e42ed0 <+48>:    00 10 09 74     andis.  r9,r0,4096
+	...
+
+	Fix this by treating system calls the same as branches in skip_prologue:
+	by default, don't skip, such that the breakpoint is set at 0x00007ffff7e42eb8
+	instead.
+
+	Tested on ppc64le-linux, on a power 8 machine.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28527
+
+2021-11-02  Tom de Vries  <tdevries@zinfandel-3.arch.suse.de>
+
+	[gdb/testsuite] Handle SIGILL in two gdb.arch powerpc test-cases
+	On powerpc64le-linux, with test-case gdb.arch/powerpc-addpcis.exp I run into
+	SIGILL:
+	...
+	(gdb) PASS: gdb.arch/powerpc-addpcis.exp: get hexadecimal valueof "$r3"
+	stepi^M
+	^M
+	Program terminated with signal SIGILL, Illegal instruction.^M
+	The program no longer exists.^M
+	(gdb) PASS: gdb.arch/powerpc-addpcis.exp: set r4
+	...
+	because it's a power9 insn, and I'm running on a power8 machine.
+
+	Fix this by handling the SIGILL.  Likewise in gdb.arch/powerpc-lnia.exp.
+
+	Tested on powerpc64le-linux.
+
+2021-11-02  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb/sim: update my email address
+	gdb:
+
+		* MAINTAINERS (Global Maintainers): Update my address.
+		(Responsible Maintainers): Likewise.
+		(Write After Approval): Likewise.
+
+	sim:
+
+		* MAINTAINERS (Global Maintainers): Update my address.
+
+2021-11-02  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix stepi test-cases with unix/-m32/-fPIE/-pie
+	When running test-case gdb.base/step-indirect-call-thunk.exp with target board
+	unix/-m32/-fPIE/-pie, I run into:
+	...
+	(gdb) stepi^M
+	0x5655552e      22      {                /* inc.1 */^M
+	(gdb) stepi^M
+	0x56555530      22      {                /* inc.1 */^M
+	(gdb) stepi^M
+	0x565555f7 in __x86.get_pc_thunk.ax ()^M
+	(gdb) FAIL: gdb.base/step-indirect-call-thunk.exp: stepi into return thunk
+	...
+
+	In contrast, with unix/-m32 we have instead:
+	...
+	(gdb) stepi^M
+	0x08048407      22      {                /* inc.1 */^M
+	(gdb) stepi^M
+	23        return x + 1;  /* inc.2 */^M
+	(gdb) stepi^M
+	0x0804840c      23        return x + 1;  /* inc.2 */^M
+	(gdb) stepi^M
+	24      }                /* inc.3 */^M
+	(gdb) stepi^M
+	0x08048410      24      }                /* inc.3 */^M
+	(gdb) stepi^M
+	0x0804848f in __x86_return_thunk ()^M
+	(gdb) PASS: gdb.base/step-indirect-call-thunk.exp: stepi into return thunk
+	...
+
+	The test-case doesn't expect to run into __x86.get_pc_thunk.ax, which is a
+	PIC helper function for x86_64-linux.
+
+	Fix this by insn-stepping through it.
+
+	Likewise in a few other test-cases.
+
+	Tested on x86_64-linux.
+
+2021-11-02  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-11-01  Alan Modra  <amodra@gmail.com>
+
+	ARM: match armeb output for unwind-pacbti-m test
+		* testsuite/gas/arm/unwind-pacbti-m.d: Match armeb output.
+
+2021-11-01  Bruno Larsen  <blarsen@redhat.com>
+
+	[gdb/doc]: Updated manpages to be consistent with help
+	Updated manpages to be consistent with help information provided by the
+	binary. The main changes are:
+
+	* Making all long-form options have '--', instead of a single '-';
+	* added most of the missing options to the manpage;
+	* removed the information about using '+' instead of '-', since it
+	  doesn't seem to be supported anymore.
+
+	This also fixes 2 upstream bugs:
+	* https://sourceware.org/bugzilla/show_bug.cgi?id=23965; by adding
+	--args to the manpage
+	* https://sourceware.org/bugzilla/show_bug.cgi?id=10619; by adding the
+	double dashes
+
+2021-11-01  Alan Modra  <amodra@gmail.com>
+
+	macho-o archive sanity checks
+	Anti-fuzzing checks.
+
+		* mach-o.c (bfd_mach_o_fat_archive_p): Sanity check entry offset
+		and size against file size.
+
+2021-11-01  Alan Modra  <amodra@gmail.com>
+
+	objcopy buffer overflow
+	"tocopy" in this code was an int, which when the size to be copied was
+	larger than MAXINT could result in tocopy being negative.  A negative
+	value of course is less than BUFSIZE, but when converted to
+	bfd_size_type is extremely large.
+
+		PR 995
+		* objcopy.c (copy_unknown_object): Correct calculation of "tocopy".
+		Use better variable types.
+
+2021-11-01  Przemyslaw Wirkus  <przemyslaw.wirkus@arm.com>
+
+	arm: add armv9-a architecture to -march
+	Update also include:
+		+ New value of Tag_CPU_arch EABI attribute (22) is added.
+		+ Updated missing Tag_CPU_arch EABI attributes.
+		+ Updated how we combine archs 'v4t_plus_v6_m' as this mechanism
+		  have to handle new Armv9 as well.
+
+	Regression tested on `arm-none-eabi` cross Binutils and no issues.
+
+	bfd/
+
+		* archures.c: Define bfd_mach_arm_9.
+		* bfd-in2.h (bfd_mach_arm_9): Define bfd_mach_arm_9.
+		* cpu-arm.c: Add 'armv9-a' option to -march.
+		* elf32-arm.c (using_thumb2_bl): Update assert check.
+		(arch_has_arm_nop): Add TAG_CPU_ARCH_V9.
+		(bfd_arm_get_mach_from_attributes): Add case for TAG_CPU_ARCH_V9.
+		Update assert.
+		(tag_cpu_arch_combine): Updated table.
+		(v9): New table..
+
+	binutils/
+
+		* readelf.c (arm_attr_tag_CPU_arch): Update with
+
+	elfcpp/
+
+		* arm.h: Update TAG_CPU_ARCH_ enums with correct values.
+
+	gas/
+
+		* NEWS: Update docs.
+		* config/tc-arm.c (get_aeabi_cpu_arch_from_fset): Return Armv9-a
+		for -amarch=all.
+		(aeabi_set_public_attributes): Update assert.
+		* doc/c-arm.texi: Update docs.
+		* testsuite/gas/arm/armv9-a_arch.d: New test.
+		* testsuite/gas/arm/attr-march-all.d: Update test with v9.
+
+	include/
+
+		* elf/arm.h Update TAG_CPU_ARCH_ defines with correct values.
+		* opcode/arm.h (ARM_EXT3_V9A): New macro.
+		(ARM_ARCH_NONE): Updated with arm_feature_set.core size.
+		(FPU_NONE): Updated.
+		(ARM_ANY): Updated.
+		(ARM_ARCH_UNKNOWN): New macro.
+		(ARM_FEATURE_LOW): Updated.
+		(ARM_FEATURE_CORE): Updated.
+		(ARM_FEATURE_CORE_LOW): Updated.
+		(ARM_FEATURE_CORE_HIGH): Updated.
+		(ARM_FEATURE_COPROC): Updated.
+		(ARM_FEATURE): Updated.
+		(ARM_FEATURE_ALL): New macro.
+
+	opcodes/
+
+		* arm-dis.c (select_arm_features): Support bfd_mach_arm_9.
+		Also Update bfd_mach_arm_unknown to use new macro ARM_ARCH_UNKNOWN.
+
+2021-11-01  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: iq2000: reduce -Wno-error scope
+	Clean up the warnings in sim-if, then reduce the -Werror disable to
+	the files that still aren't clean that now that we require GNU make
+	and can set variables on a per-object basis.
+
+	sim: lm32: reduce -Wno-error scope
+	Clean up some warnings in dv-lm32cpu, and all in sim-if, then reduce
+	the -Werror disable to the files that still aren't clean that now that
+	we require GNU make and can set variables on a per-object basis.
+
+	sim: frv: reduce -Wno-error scope
+	Only two files in here still generates warnings, so reduce the -Werror
+	disable to that now that we require GNU make and can set variables on
+	a per-object basis.
+
+	sim: m32r: reduce -Wno-error scope
+	Only two files in here still generates warnings, so reduce the -Werror
+	disable to that now that we require GNU make and can set variables on
+	a per-object basis.
+
+	sim: mips: reduce -Wno-error scope
+	Fix a few printf warnings in sim-main.c, and then we're left with only
+	one file in here still generating warnings, so reduce the -Werror
+	disable to that alone now that we require GNU make and can set variables
+	on a per-object basis.
+
+	sim: erc32: reduce -Wno-error scope
+	Only one file in here still generates warnings, so reduce the -Werror
+	disable to that alone now that we require GNU make and can set variables
+	on a per-object basis.
+
+	sim: cris: reduce -Wno-error scope
+	Only two files in here still generates warnings, so reduce the -Werror
+	disable to that now that we require GNU make and can set variables on
+	a per-object basis.
+
+	sim: sh: reduce -Wno-error scope
+	Only one file in here still generates warnings, so reduce the -Werror
+	disable to that alone now that we require GNU make and can set variables
+	on a per-object basis.
+
+	sim: or1k: build with -Werror
+	The only warnings left in this port are a few maybe-uninitialized,
+	but we don't abort the build for them, so turn on -Werror everywhere.
+
+	sim: igen: minor build output alignment fix
+	The custom echo was off by one space relative to all the others.
+
+	sim: ppc: fix the printf fix for 32-bit systems
+	The time delta is a 64-bit value too.
+
+	sim: m68hc11: clean up pointer casts
+	The void *data field is used to past arbitrary data between event
+	handlers, and these are using it to pass an integer.  Fix up the
+	casts to avoid using (long) to cast to/from pointers since there
+	is no guarantee that's the right size.
+
+	sim: d10v: clean up pointer casts
+	Use %p to print pointers instead of trying to cast them to longs.
+
+	sim: bfin: cast pointers using uintptr_t
+	We can't assume that sizeof(long) == sizeof(void*), so change all
+	these casts over to uintptr_t.
+
+	sim: ppc: clean up printf format handling
+	Don't blindly cast every possible type to (long).  Change to the right
+	printf format specifier whether it be a 64-bit type or a pointer.
+
+	sim: ppc: switch core types to stdint.h types
+	There's no need to define these ourselves anymore, so switch to the
+	stdint.h types.  This will be important when we start using PRI*
+	defines with printf formats.
+
+	sim: mn10300: clean up pointer casts
+	The void *data field is used to past arbitrary data between event
+	handlers, and these are using it to pass an enum.  Fix up the casts
+	to avoid using (long) to cast to/from pointers since there is no
+	guarantee that's the right size.
+
+	sim: events: clean up trace casts
+	Don't blindly cast every possible type to (long).  Change to the right
+	printf format specifier whether it be a 64-bit type or a pointer.
+
+	sim: ppc: handle \r in igen inputs [PR sim/28476]
+	Make sure we consume & ignore \r bytes in inputs in case the file
+	encodings are from a non-LF systems (e.g. Windows).
+
+	sim: ppc: constify strings in igen tooling
+
+2021-11-01  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-31  Tom Tromey  <tom@tromey.com>
+
+	Fix latent bug in DWARF test case
+	On my branch that replaces the DWARF psymtab reader,
+	dw2-stack-boundary.exp started failing.  However, when I look at the
+	output in gdb.log, it is correct:
+
+	    file /home/tromey/gdb/build/gdb/testsuite/outputs/gdb.dwarf2/dw2-stack-boundary/dw2-stack-boundary
+	    Reading symbols from /home/tromey/gdb/build/gdb/testsuite/outputs/gdb.dwarf2/dw2-stack-boundary/dw2-stack-boundary...
+	    During symbol reading: location description stack overflow
+	    During symbol reading: location description stack underflow
+
+	What happens to cause the failure is that the two branches in
+	gdb_test_multiple appear in this order:
+
+	    -re "\r\nDuring symbol reading: location description stack underflow" {
+	    [...]
+	    -re "\r\nDuring symbol reading: location description stack overflow" {
+
+	The first one will match the above, without causing the second one to
+	ever match -- leading to a spurious failure.
+
+	Anchoring the regexps seems to fix the problem, and works for the
+	current gdb as well.
+
+2021-10-31  Tom Tromey  <tom@tromey.com>
+
+	Fix unittest.exp failure due to 'set debuginfod' addition
+	The 'set debuginfod' change caused a regression in unittest.exp:
+
+	    Running selftest help_doc_invariants.
+	    help doc broken invariant: command 'info set debuginfod' help doc first line is not terminated with a '.' character
+	    help doc broken invariant: command 'set debuginfod' help doc first line is not terminated with a '.' character
+	    help doc broken invariant: command 'show debuginfod' help doc first line is not terminated with a '.' character
+	    Self test failed: self-test failed at ../../binutils-gdb/gdb/unittests/command-def-selftests.c:100
+
+	This patch fixes the problem.  I'm checking it in.
+
+2021-10-31  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: ppc: use silent build rules here too
+	The ppc codebase is unique and doesn't leverage common/, so have to
+	add silent rules to it specifically.
+
+	sim: rl78: drop obsolete manual dependency rules
+	We have GNU make generate these for us automatically now, so there's
+	no need to manually specify any deps.
+
+	sim: drop unused targ-vals.h includes
+	This is used in a few places where it's not needed.  Drop the include
+	to avoid the build-time generated header file as we move to drop it.
+
+	sim: unify callback.o building
+	Now that the use of TARGET_xxx defines have been removed, we can move
+	this to the common logic so we only build it once for multi-targets.
+
+	sim: nltvals: pull target open flags out into a dedicated source file
+	Like we just did for pulling out the errno & signal maps, pull out the
+	open flag map into a dedicated common file.  All newlib ports are using
+	the same map which makes it easy.
+
+	sim: nltvals: localize TARGET_<open> defines
+	Code should not be using these directly, instead they should be
+	resolving these dynamically via the open_map.  Rework the common
+	callback code that was using the defines to use symbolic names
+	instead, and localize some of the defines in the ARM code (since
+	it's a bit unclear how many different APIs it supports currently),
+	then remove the defines out of the header so no new code can rely on
+	them.
+
+	sim: nltvals: pull target signal out into a dedicated source file
+	Like we just did for pulling out the errno map, pull out the signal
+	map into a dedicated common file.  All newlib ports are using the
+	same signal map which makes it easy.
+
+2021-10-31  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: nltvals: pull target errno out into a dedicated source file
+	The current system maintains a list of target errno constants in the
+	nltvals.def file, then runs a build-time tool to turn that into a C
+	file.  This list of errno values is the same for all arches, so we
+	don't need the arch-specific flexibility.  Further, these are only
+	for newlib/libgloss environments, which makes it confusing to support
+	other userland runtimes (like Linux).  Let's simplify to make this
+	easier to understand & build.  We don't namespace the variables yet,
+	but sets up the framework for it.
+
+	Create a new target-newlib-errno.c template file.  The template file
+	is hand written, but the inline map is still automatically generated.
+
+	This allows us to move it to the common set of objects so it's only
+	built once in a multi-target build.
+
+	Now we can remove the output from the gentmap build-time tool since
+	it's checked into the tree.
+
+	Then we stop including the errno lists in nltvals.def since nothing
+	uses it.
+
+2021-10-31  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: erc32: use silent build rules with sis linkage
+
+2021-10-31  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: erc32: fix a few more build warnings
+	Tweak the if indentation & brace style to avoid ambiguous warnings.
+
+	Add ATTRIBUTE_UNUSED to UART functions that aren't used when FAST_UART
+	is defined (which is the default).
+
+2021-10-31  Orgad Shaneh  <orgads@gmail.com>
+
+	sim: erc32: fix signedness compatibility and redefinition warnings
+
+2021-10-31  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: add arch-specific conditional logic
+	This will make it easy to include arch-specific logic (build files)
+	as we migrate ports to the common top level build.
+
+	sim: v850: delete old gencode logic
+	The v850 port used to have a gencode helper, but it was deleted long
+	ago.  Clean up the settings that no longer make sense w/out it.
+
+	sim: common: merge multiple clean commands
+	This provides a minor speedup when cleaning in a multi-target build.
+
+	sim: m32c: tighten up opc2c build output
+	Drop the single debugging line that repeats the command line option,
+	and use the silent build helpers to tighten up output.
+
+	sim: tighten up build regen rules
+	Update the makefile & configure related rules to use the silent
+	build helpers.
+
+	sim: tighten up gencode output
+	Update the gencode rules to use the silent build helpers.
+
+	sim: igen: tighten up build output
+	Add a new stamp helper for quiet builds, and don't dump the command
+	line options when it runs.  That isn't standard tool behavior, and
+	doesn't really seem necessary in any way.
+
+	sim: tighten up stamp rules
+	Add a new ECHO_STAMP helper and convert existing stamp code over
+	to it.  This is mostly common rules and cgen mloop rules.
+
+	sim: silence stamp touch rules
+	We pretty much never care about these stamp touches, so silence them.
+	Also switch to using $@ when it makes sense.
+
+	sim: standardize move-if-change rules
+	Use the srcroot path and make them all silent.
+
+	sim: mips/v850: remove redundant variable setup
+	The common/Make-common.in fragment already provides these variables.
+
+2021-10-31  Orgad Shaneh  <orgads@gmail.com>
+
+	sim: fix compilation on mingw64 [PR sim/28476]
+	...by reordering includes.
+
+	1. sim-utils.c
+
+	sim/mips/sim-main.h defines UserMode, while there is a struct in winnt.h
+	which has UserMode as a member. So if sim-main.h is included before winnt.h,
+	compilation fails.
+
+	2. ppc
+
+	registers.h defines CR, which is used as a member in winnt.h.
+
+	winsock2.h is included by sys/time.h, so sys/time.h has to be included
+	before registers.h.
+
+	Bug: https://sourceware.org/PR28476
+
+2021-10-31  Alan Modra  <amodra@gmail.com>
+
+	Don't include coff/pe.h in coff-x86_64.c
+	This (and other) code from coffcode.h is broken for x86_64_coff_vec,
+	and has been ever since support was added in 2006 commit 99ad839030c1
+	Here, bfd_coff_aoutsz must match coff_swap_aouthdr_out otherwise we
+	end up writing garbage.
+
+	      /* Note that peicode.h fills in a PEAOUTHDR, not an AOUTHDR.
+		 include/coff/pe.h sets AOUTSZ == sizeof (PEAOUTHDR)).  */
+	      char * buff;
+	      bfd_size_type amount = bfd_coff_aoutsz (abfd);
+
+	      buff = (char *) bfd_malloc (amount);
+	      if (buff == NULL)
+		return false;
+
+	      coff_swap_aouthdr_out (abfd, & internal_a, buff);
+	      amount = bfd_bwrite (buff, amount, abfd);
+
+	We have removed support for --target=x86_64-coff, likely because it
+	never worked properly, but still produce coff-x86_64.o with
+	--enable-targets=all.  This means objcopy can recognize x86_64 COFF
+	files but will write garbage to the output file, a fact found by
+	fuzzers.  I suspect x86_64 COFF is still broken after this fix, and
+	mention of coff-x86_64.* should be removed from bfd/Makefile.am.
+
+		* coff-x86_64.c: Don't include coff/pe.h.
+		(COFF_WITH_pex64): Don't define here.
+		* pe-x86_64.c: Include coff/pe.h and other headers.
+		(PEI_HEADERS): Define.
+
+2021-10-31  Alan Modra  <amodra@gmail.com>
+
+	Re: PR28420, ecoff fuzzing failures
+	sym_ptr_ptr NULL results in segfaults.
+
+		PR 28420
+		* ecoff.c (ecoff_slurp_reloc_table): Don't leave sym_ptr_ptr NULL.
+
+2021-10-31  Alan Modra  <amodra@gmail.com>
+
+	ubsan: alpha-vms: undefined shift
+		* vms-alpha.c (evax_bfd_print_image): Shift left 1u.
+
+	PR28518: signed integer overflow & free on unmalloced address
+		PR 28518
+		* vms-alpha.c (build_module_list): Don't lose malloc buffer address.
+		Use unsigned variables.
+
+2021-10-31  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-30  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: fix gdb.gdb/unittest.exp with C++17 compiler
+	On a machine with gcc 11, I get:
+
+	    FAIL: gdb.gdb/unittest.exp: test_completion: tab complete "maintenance selftest string_v" (second tab) (timeout)
+	    FAIL: gdb.gdb/unittest.exp: test_completion: tab complete "maintenance selftest string_vie" (timeout)
+
+	That's because when compiling with C++ >= 17, we use the standard
+	version of string_view, and don't have a selftest for it.  So the list
+	of selftests shown by the tab completion when completing "string_v"
+	differs.
+
+	Change the test to use the copy_* tests instead.
+
+	Change-Id: I85f6aa44ee5fc9652b9bd4451e0506b89773526b
+
+2021-10-30  Aaron Merey  <amerey@redhat.com>
+
+	gdb.texinfo: Expand documentation for debuginfod
+	Add section describing GDB's usage of debuginfod.
+
+	Refer to this new section in the description of the '--with-debuginfod'
+	configure option.
+
+	Mention debuginfod in the 'Separate Debug Files' section.
+
+2021-10-30  Aaron Merey  <amerey@redhat.com>
+
+	gdb: add set/show commands for managing debuginfod
+	Add 'set debuginfod' command.  Accepts 'on', 'off' or 'ask' as an
+	argument.  'on' enables debuginfod for the current session.  'off'
+	disables debuginfod for the current session.  'ask' will prompt
+	the user to either enable or disable debuginfod when the next query
+	is about to be performed:
+
+	    This GDB supports auto-downloading debuginfo from the following URLs:
+	    <URL1> <URL2> ...
+	    Enable debuginfod for this session? (y or [n]) y
+	    Debuginfod has been enabled.
+	    To make this setting permanent, add 'set debuginfod on' to .gdbinit.
+
+	For interactive sessions, 'ask' is the default.  For non-interactive
+	sessions, 'off' is the default.
+
+	Add 'show debuginfod status' command.  Displays whether debuginfod
+	is set to 'on', 'off' or 'ask'.
+
+	Add 'set/show debuginfod urls' commands. Accepts a string of
+	space-separated debuginfod server URLs to be queried.  The default
+	value is copied from the DEBUGINFOD_URLS environment variable.
+
+	Finally add 'set/show debuginfod verbose' commands to control whether
+	debuginfod-related output is displayed.  Verbose output is enabled
+	by default.
+
+	    (gdb) run
+	    Starting program: /bin/sleep 5
+	    Download failed: No route to host.  Continuing without debug info for /lib64/libc.so.6.
+
+	If GDB is not built with debuginfod then these commands will just display
+
+	    Support for debuginfod is not compiled into GDB.
+
+2021-10-30  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-29  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove TYPE_FIELD_DWARF_BLOCK
+	Remove TYPE_FIELD_DWARF_BLOCK, replace with type::field +
+	field::loc_dwarf_block.
+
+	Change-Id: I10af9410bb5f46d342b8358a7956998c7e804b64
+
+2021-10-29  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove TYPE_FIELD_STATIC_PHYSADDR
+	Remove TYPE_FIELD_STATIC_PHYSADDR replace with type::field +
+	field::loc_physaddr.
+
+	Change-Id: Ica9bc4a48f34750ec82ec86c298d3ecece81bcbd
+
+2021-10-29  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove TYPE_FIELD_STATIC_PHYSNAME
+	Remove TYPE_FIELD_STATIC_PHYSNAME, replace with type::field +
+	field::loc_physname.
+
+	Change-Id: Ie35d446b67dd1d02f39998b406001bdb7e6d5abb
+
+2021-10-29  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove TYPE_FIELD_ENUMVAL
+	Remove TYPE_FIELD_ENUMVAL, replace with type::field +
+	field::loc_enumval.
+
+	Change-Id: I2ada73e4635aad3363ce2eb22c1dc52698ee2072
+
+2021-10-29  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove TYPE_FIELD_BITPOS
+	Remove TYPE_FIELD_BITPOS, replace its uses with type::field +
+	field::loc_bitpos.
+
+	Change-Id: Iccd8d5a77e5352843a837babaa6bd284162e0320
+
+2021-10-29  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove TYPE_FIELD_LOC_KIND
+	Remove TYPE_FIELD_LOC_KIND, replace its uses with type::field +
+	field::loc_kind.
+
+	Change-Id: Ib124a26365df82ac1d23df7962d954192913bd90
+
+2021-10-29  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove FIELD_DWARF_BLOCK macro
+	Remove FIELD_DWARF_BLOCK, replace its uses with field::loc_dwarf_block.
+
+	Change-Id: I66b7d6a960cb5e341e61e21bd3cc9a6ac26de6a8
+
+2021-10-29  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove FIELD_STATIC_PHYSADDR macro
+	Remove FIELD_LOC_KIND_PHYSADDR, replace its uses with
+	field::loc_physaddr.
+
+	Change-Id: Ifd8b2bdaad75f42bfb1404ef8c396ffe7e10ac55
+
+2021-10-29  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove FIELD_STATIC_PHYSNAME macro
+	Remove FIELD_STATIC_PHYSNAME, replace its uses with field::loc_physname.
+
+	Change-Id: Iaa8952410403b4eb5bbd68411feea27e2405d657
+
+2021-10-29  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove FIELD_ENUMVAL macro
+	Remove FIELD_ENUMVAL, replace its uses with field::loc_enumval.
+
+	Change-Id: Id4861cee91a8bb583a9836f1aa5da0a320fbf4d9
+
+2021-10-29  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove FIELD_BITPOS macro
+	Remove FIELD_BITPOD, replace its uses with field::loc_bitpos.
+
+	Change-Id: Idb99297e0170661254276c206383a7e9bf1a935a
+
+2021-10-29  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove FIELD_LOC_KIND macro
+	Remove FIELD_LOC_KIND, replace its uses with field::loc_kind or
+	call_site_target::loc_kind.
+
+	Change-Id: I0368d8c3ea269d491bb215aa70e32edbdf55f389
+
+2021-10-29  Tom Tromey  <tromey@adacore.com>
+
+	Add gdb.Architecture.integer_type Python function
+	This adds a new Python function, gdb.Architecture.integer_type, which
+	can be used to look up an integer type of a given size and
+	signed-ness.  This is useful to avoid dependency on debuginfo when a
+	particular integer type would be useful.
+
+	v2 moves this to be a method on gdb.Architecture and addresses other
+	review comments.
+
+2021-10-29  Tom Tromey  <tromey@adacore.com>
+
+	Remove ada_value_print_inner
+	I noticed that the only caller of ada_value_print_inner is
+	valprint.c:do_val_print (via ada_language::value_print_inner), meaning
+	that the try/catch logic in this function is redundant.  This patch
+	removes the wrapper function.
+
+	Regression tested on x86-64 Fedora 34.
+
+2021-10-29  Tom Tromey  <tromey@adacore.com>
+
+	Document resolve_dynamic_type oddity
+	Today I re-learned that resolve_dynamic_type can return a type for
+	which is_dynamic_type returns true.  This can happen for an array
+	whose elements have dynamic type -- the array is reported as dynamic,
+	but resolving the elements would be incorrect, because each element
+	might have a different type after resolution.
+
+	You can see the special case in resolve_dynamic_array_or_string:
+
+	  if (ary_dim != NULL && ary_dim->code () == TYPE_CODE_ARRAY)
+	...
+	  else
+	...
+
+	I looked into having the TYPE_CODE_ARRAY case in
+	is_dynamic_type_internal follow this same logic, but that breaks down
+	on the gdb.fortran/dynamic-ptype-whatis.exp test case.  In particular
+	this code in fortran_undetermined::evaluate:
+
+	  value *callee = std::get<0> (m_storage)->evaluate (nullptr, exp, noside);
+	  if (noside == EVAL_AVOID_SIDE_EFFECTS
+	      && is_dynamic_type (value_type (callee)))
+	    callee = std::get<0> (m_storage)->evaluate (nullptr, exp, EVAL_NORMAL);
+
+	... relies on is_dynamic_type returning true for such an array.
+
+	I wasn't really sure of the best way to fix this, so in the meantime I
+	wrote this patch, which documents the oddity so that I might have a
+	chance of remembering this in the future.
+
+2021-10-29  Tom Tromey  <tromey@adacore.com>
+
+	Avoid self-test failures on x86-linux
+	The disassembly tests in "maint selftest" will fail on x86-linux.
+	This happens because opcodes rejects an attempt to disassemble for an
+	arch with a 64-bit address size when bfd_vma is 32-bit.
+
+	This patch avoids this problem by avoiding the test in this case.  I
+	chose to do it this way because this seems to be the only situation
+	where opcodes checks the size of bfd_vma.
+
+	For v2 of this patch, I've also updated memory_error_test to do the
+	same thing.  This is needed due to the "improve error reporting from
+	the disassembler" patch.
+
+2021-10-29  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/build] Fix build with --disable-unit-tests
+	A build with --disable-unit-tests currently run into:
+	...
+	ld: maint.o: in function \
+	  `maintenance_selftest_completer(cmd_list_element*, completion_tracker&,
+	                                  char const*, char const*)':
+	src/gdb/maint.c:1183: undefined reference to \
+	  `selftests::for_each_selftest(
+	    gdb::function_view<
+	      void (std::__cxx11::basic_string<char,std::char_traits<char>,
+	                                       std::allocator<char> > const&)>)'
+	...
+
+	Fix this by guarding the call to selftests::for_each_selftest in
+	maintenance_selftest_completer with GDB_SELF_TEST, such that the "-verbose"
+	completion still works.
+
+	Rebuild on x86_64-linux and ran gdb.gdb/unittest.exp.
+
+2021-10-29  Enze Li  <lienze2010@hotmail.com>
+
+	Document "memory-tag-violations".
+	* gdb/doc/gdb.texinfo: (Data): Document	'-memory-tag-violations'.
+	 (Command Options): Update the example.
+
+2021-10-29  Tejas Belagod  <tejas.belagod@arm.com>
+
+	Support for a new pacbti unwind opcode.
+	This patch adds readelf support for decoding the exception table
+	opcode for restoring the RA_AUTH_CODE pseudo register defined by the
+	EHABI
+	(https://github.com/ARM-software/abi-aa/releases/download/2021Q1/ehabi32.pdf
+	Section 10.3).
+
+		* readelf.c (decode_arm_unwind_bytecode): Add support to decode
+		restoring RA_AUTH_CODE pseudo register.
+
+2021-10-29  Alan Modra  <amodra@gmail.com>
+
+	Re: arm: add unwinder encoding support for PACBTI
+	Move the gas testsuite files to where they belong.
+
+2021-10-29  Alan Modra  <amodra@gmail.com>
+
+	ELF core file size checks
+	Catch fuzzed segments where p_offset + p_filesz wraps, and limit error
+	output.
+
+		* elfcore.h (elf_core_file_p): Rewrite segment checks using
+		bfd_get_file_size.  Set read_only on file size errors.
+		* elfcode.h (elf_swap_shdr_in): Don't repeat error message.
+
+2021-10-29  Alan Modra  <amodra@gmail.com>
+
+	obcopy vs. files with silly section alignment
+	We already ignore stupid segment alignment when rewriting headers,
+	ignore section alignment too.
+
+		* elf.c (rewrite_elf_program_header): Ignore section alignment
+		power greater than 62.
+
+2021-10-29  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-28  Stafford Horne  <shorne@gmail.com>
+
+	gdb: Add OpenRISC gdbserver and native config news
+	The previous patches added gdbserver and native debugging support
+	for OpenRISC targets.  This patch documents that in the news.
+
+	gdb: or1k: add single step for linux native debugging
+	Needed for single stepping in Linux, this adds the or1k implementation
+	of or1k_software_single_step.  Most of the implementation is borrowed
+	from the bare metal single step code from or1k_single_step_through_delay
+	which has been extracted and shared in helper function
+	or1k_delay_slot_p.
+
+2021-10-28  Stafford Horne  <shorne@gmail.com>
+
+	gdb: or1k: add native linux support
+	This patch adds support for running gdb natively on OpenRISC linux.
+	Debugging support is provided via the linux PTRACE interface which is
+	mostly handled by GDB genric code.  This patch provides the logic of how
+	to read and write the ptrace registers between linux and GDB.
+
+	Single stepping is privided in a separate patch.
+
+2021-10-28  Stafford Horne  <shorne@gmail.com>
+
+	gdb: or1k: add generated linux descriptor file
+
+	gdb: or1k: fixup linux regcache comment
+	The old comment was not properly updated from the RISC-V example used.
+	Update it to match OpenRISC.
+
+2021-10-28  Stafford Horne  <shorne@gmail.com>
+
+	gdb: or1k: implement gdb server
+	This patch adds gdbserver support for OpenRISC.  This has been used for
+	debugging the glibc port that in being worked on here:
+
+	  https://github.com/openrisc/or1k-glibc/tree/or1k-port-2
+
+	Hence the comment about registers definitions being inline with glibc.
+
+2021-10-28  Christian Biesinger  <cbiesinger@google.com>
+
+	[sim] Include defs.h in ppc/hw_memory.c
+	To fix this error (seen on cygwin):
+	/../../sim/ppc/../common ../../../sim/ppc/hw_memory.c
+	In file included from ../../gnulib/import/stdlib.h:100,
+	                 from ../../../sim/ppc/hw_memory.c:28:
+	../../gnulib/import/unistd.h:663:3: error: #error "Please include config.h first."
+	  663 |  #error "Please include config.h first."
+	      |   ^~~~~
+	../../gnulib/import/unistd.h:665:24: error: expected ';' before 'extern'
+	  665 | _GL_INLINE_HEADER_BEGIN
+	      |                        ^
+	      |                        ;
+	../../gnulib/import/unistd.h:2806:22: error: expected ';' before 'extern'
+	 2806 | _GL_INLINE_HEADER_END
+	      |                      ^
+	      |                      ;
+
+2021-10-28  Markus Klein  <markus.klein@sma.de>
+
+	ARM assembler: Allow up to 32 single precision registers in the VPUSH and VPOP instructions.
+		PR 28436
+		* config/tc-arm.c (do_vfp_nsyn_push_pop_check): New function.
+		(do_vfp_nsyn_pop): Use the new function.
+		(do_vfp_nsyn_push): Use the new function.
+		* testsuite/gas/arm/v8_1m-mve.s: Add new instructions.
+		* testsuite/gas/arm/v8_1m-mve.d: Updated expected disassembly.
+
+2021-10-28  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: use ptid_t::to_string in infrun debug messages
+	In debug messages, I think it would be more helpful to print ptid using
+	the simple "pid.lwp.tid" notation in infrun debug messages.  I am
+	currently debugging some fork issues, and find the pid_to_str output not
+	so useful, as it doesn't tell which process a thread belongs to.
+
+	It currently shows up like this:
+
+	    [infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=0, current thread [Thread 0x7ffff7d95740 (LWP 892942)] at 0x55555555521f
+
+	With the patch, it shows up like this:
+
+	    [infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=1, current thread [894072.894077.0] at 0x5555555551d9
+
+	Change-Id: I130796d7dfb0d8e763b8358d8a6002701d80c4ea
+
+2021-10-28  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: add selftest name completion
+	After the previous commit, it is easy to add completion for selftest
+	names.  Again, this is not particularly high value, but I rarely touched
+	completion, so it served as a simple example to get some practice.
+
+	Change the for_each_selftest_ftype parameter to gdb::function_view, so
+	that we can pass a lambda that captures things.
+
+	Change-Id: I87cac299ddca9ca7eb0ffab78342e850a98d954c
+
+2021-10-28  Tejas Belagod  <Tejas.Belagod@arm.com>
+
+	arm: add unwinder encoding support for PACBTI
+	This patch adds support for encoding the Return Address Authentication pseudo
+	register - '.save {ra_auth_code}' as defined by the DWARF ABI - in the
+	exception tables where the opcode is defined by the EHABI
+
+	gas/Changelog:
+
+		* config/tc-arm.c (arm_reg_type): Add new type REG_TYPE_PSEUDO.
+		(reg_expected_msgs): Add message for pseudo reg type.
+		(reg_list_els): Add new reg list type REGLIST_PSEUDO.
+		(parse_reg_list): Handle new REGLIST_PSEUDO type.
+		(s_arm_unwind_save_pseudo): Encode pseudo reg list save in exception
+		tables.
+		(s_arm_unwind_save): Handle new REG_TYPE_PSEUDO.
+		(reg_names): Add ra_auth_code pseudo register.
+		* testsuite/gas/arm/unwind-pacbti-m.s: New test.
+		* testsuite/gas/arm/unwind-pacbti-m.d: New test.
+		* testsuite/gas/arm/unwind-pacbti-m-readelf.d: New test.
+
+2021-10-28  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: add "maint set/show selftest verbose" commands and use process_options
+	I saw the new -verbose switch to "maint selftests" and thought it would
+	be nice for it to use the option framework.  For example, that makes
+	having completion easy.  It's not that high value, given this is a
+	maintenance command, but I had never used the framework myself, so it
+	was a good way to practice.
+
+	This patch also adds the "maint set/show selftest verbose" setting.  It
+	would be possible to use option framework without adding the setting,
+	but using the framework makes adding the option almost trivial, so I
+	thought why not.
+
+	Change-Id: I6687faa0713ff3da60b398253211777100094144
+
+2021-10-28  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Update some test-cases to GPLv3
+	I noticed some files in the test-suite have GPLv2 notices.
+
+	Update these to GPLv3.
+
+2021-10-28  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: add add_setshow_prefix_cmd
+	There's a common pattern to call add_basic_prefix_cmd and
+	add_show_prefix_cmd to add matching set and show commands.  Add the
+	add_setshow_prefix_cmd function to factor that out and use it at a few
+	places.
+
+	Change-Id: I6e9e90a30e9efb7b255bf839cac27b85d7069cfd
+
+2021-10-28  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Require python in gdb.server/server-kill-python.exp
+	I came across this when running test-case gdb.server/server-kill-python.exp
+	with a gdb configured without python:
+	...
+	builtin_spawn gdb -nw -nx -data-directory data-directory -iex set height 0 \
+	  -iex set width 0 -quiet -iex set height 0 -iex set width 0 \
+	  -ex source outputs/gdb.server/server-kill-python/file1.py^M
+	FAIL: gdb.server/server-kill-python.exp: ensure inferior is running
+	Executing on target: kill -9 28535    (timeout = 300)
+	builtin_spawn -ignore SIGHUP kill -9 28535^M
+	file1.py:1: Error in sourced command file:^M
+	Undefined command: "import".  Try "help".^M
+	...
+
+	Fix this by testing for python support in the test-case.
+
+	Tested on aarch64-linux (with python support disabled) and x86_64-linux (with
+	python support enabled).
+
+2021-10-28  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix assembly comments in gdb.dwarf2/clang-debug-names.exp.tcl
+	On openSUSE Leap 15.2 aarch64 I ran into:
+	...
+	clang-debug-names-debug.S:72: \
+	  Error: junk at end of line, first unrecognized character is `#'
+	...
+	due to:
+	...
+	    71  .Ldebug_names_start:
+	    72    .short 5                      # Header: version
+	...
+
+	Fix this by using the /* ... */ comment style instead:
+	...
+	$ sed -i 's% #\([^"]*\)%/*\1 */%' clang-debug-names.exp.tcl
+	...
+
+	Tested on aarch64-linux and x86_64-linux.
+
+2021-10-28  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/symtab] Handle DW_AT_string_length with location list
+	Consider a fortran routine where a string variable s is modified:
+	...
+	subroutine f(s)
+	  character*(*) s
+	  print *, s
+	  s(1:3) = 'oof'
+	  print *, s
+	end subroutine f
+	...
+
+	When compiling with optimization level -O1 and printing the type of
+	variable s we get:
+	...
+	$ gdb -q -batch outputs/gdb.opt/fortran-string/fortran-string \
+	  -ex "b f" \
+	  -ex run \
+	  -ex "ptype s"
+	Breakpoint 1 at 0x4006f7: file fortran-string.f90, line 21.
+
+	Breakpoint 1, f (s=..., _s=_s@entry=3) at fortran-string.f90:21
+	21      subroutine f(s)
+	type = character*1
+	...
+	while with -O0 we have instead:
+	...
+	type = character (3)
+	...
+
+	The problem is that the type of s is:
+	...
+	 <1><2d6>: Abbrev Number: 21 (DW_TAG_string_type)
+	    <2d7>   DW_AT_string_length: 0xbf (location list)
+	    <2db>   DW_AT_byte_size   : 4
+	...
+	where the DW_AT_string_length is a location list, a case that is not handled
+	by attr_to_dynamic_prop.
+
+	Fix this by handling attr->form_is_section_offset () in attr_to_dynamic_prop.
+
+	Tested on x86_64-linux.
+
+	The test-case is based on gdb.opt/fortran-string.exp from
+	https://src.fedoraproject.org/rpms/gdb/raw/f32/f/gdb-archer-vla-tests.patch .
+	I've updated the copyrights to stretch to 2021.
+
+	[ I've tried to create a dwarf assembly test-case for this, but didn't
+	manage. ]
+
+	Co-Authored-By: Jan Kratochvil <jan.kratochvil@redhat.com>
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26910
+
+2021-10-28  Kavitha Natarajan  <kavitha.natarajan@amd.com>
+
+	[gdb/testsuite] Initialize anonymous union in gdb.cp/koenig.cc
+	GDB test fails while running the test case gdb.cp/koenig.exp using
+	clang compiler:
+	[...]
+	p foo (p_union)
+	No symbol "p_union" in current context.
+	(gdb) FAIL: gdb.cp/koenig.exp: p foo (p_union)
+	[...]
+
+	In the testcase, "p_union" is an unused/uninitialized variable of
+	anonymous union type. Clang does not emit symbol for unused anonymous
+	union/struct variables at any optimization level. Since the compiler
+	itself is not emitting the symbol for "p_union", debug info is also
+	not emitted when built with debug option. If the anonymous union is
+	initialized (or used), then clang emits the symbol "p_union" which
+	enables emitting debug info for "p_union".
+	[...]
+	p foo (p_union)
+	Cannot resolve function foo to any overloaded instance
+	(gdb) PASS: gdb.cp/koenig.exp: p foo (p_union)
+	[...]
+
+2021-10-28  Alan Modra  <amodra@gmail.com>
+
+	asan: mmo: NULL dereferenc in mmo_xore_32
+	mmo_get_loc can return NULL.  It's commented even, and that the caller
+	then must handle a split field.  mmo_xore_* don't handle split fields,
+	instead just segfault.  Stop that happening, and refuse to recognise
+	fuzzed mmo files that trigger this problem.
+
+		* mmo.c (mmo_get_loc): Don't declare inline.
+		(mmo_xore_64, mmo_xore_32, mmo_xore_16): Remove forward decls.
+		Return pointer, don't dereference NULL.
+		(mmo_scan): Return error on mmo_get_loc returning NULL.
+
+2021-10-28  Alan Modra  <amodra@gmail.com>
+
+	bfd: remove use of INLINE
+	No need to use anything fancy, plain inline works just as well.
+
+		* bfd-in.h (INLINE): Don't define.
+		* bfd-in2.h: Regenerate.
+		* aoutx.h: Replace use of INLINE with inline.
+		* elf-eh-frame.c: Likewise.
+		* elf32-score7.c: Likewise.
+		* elfxx-mips.c: Likewise.
+		* ihex.c: Likewise.
+		* mach-o.c: Likewise.
+		* mmo.c: Likewise.
+
+2021-10-28  Alan Modra  <amodra@gmail.com>
+
+	ASSERT in empty output section with address
+		* ldlang.c (lang_do_assignments_1): Correct "dot" inside ignored
+		sections.
+		* testsuite/ld-scripts/empty-address-4.d,
+		* testsuite/ld-scripts/empty-address-4.s,
+		* testsuite/ld-scripts/empty-address-4.t: New test.
+		* testsuite/ld-scripts/empty-address.exp: Run it.
+
+2021-10-28  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-27  Alan Modra  <amodra@gmail.com>
+
+	asan: alpha-vms: buffer overflows
+	Yet more anti-fuzzer sanity checking
+
+		* vms-alpha.c (evax_bfd_print_egsd): Sanity check record and
+		name lengths before access.
+		(evax_bfd_print_etir_stc_ir, evax_bfd_print_etir): Likewise.
+
+2021-10-27  Alan Modra  <amodra@gmail.com>
+
+	ubsan: arm: undefined shift
+	left shift of 2 by 31 places cannot be represented in type 'int'
+
+		* arm-dis.c (print_insn_thumb16): Avoid undefined behaviour.
+
+2021-10-27  Tom Tromey  <tromey@adacore.com>
+
+	Fix watchpoints with multiple threads on Windows
+	A recent internal change pointed out that watchpoints were not working
+	on Windows when the inferior was multi-threaded.  This happened
+	because the debug registers were only updated for certain threads --
+	in particular, those that were being resumed and that were not marked
+	as suspended.  In the case of single-stepping, the need to update the
+	debug registers in other threads could also be "forgotten".
+
+	This patch changes windows-nat.c to mark all threads needing a debug
+	register update.  This brings the code closer to what gdbserver does
+	(though, unfortunately, it still seems more complicated than needed).
+
+2021-10-27  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix port detection in gdb.debuginfod/fetch_src_and_symbols.exp
+	On OBS I ran into this failure with test-case
+	gdb.debuginfod/fetch_src_and_symbols.exp:
+	...
+	Failed to listen for connections: Address already in use^M
+	[Thu Oct 21 11:48:49 2021] (559/559): started http server on IPv6 port=8000^M
+	  ...
+	FAIL: gdb.debuginfod/fetch_src_and_symbols.exp: local_url: find port timeout
+	...
+
+	The test-case is trying to start debuginfod on a port to see if it's
+	available, and it handles either this message:
+	  "started http server on IPv4 IPv6 port=$port"
+	meaning success, or:
+	  "failed to bind to port"
+	meaning failure, in which case the debuginfod instance is killed, and we try
+	the next port.
+
+	The test-case only uses the v4 address 127.0.0.1, so fix this by:
+	- accepting "started http server on IPv4 port=$port"
+	- rejecting "started http server on IPv6 port=$port"
+
+	Tested on x86_64-linux.
+
+2021-10-27  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: fix value.c build on 32-bits
+	When building on ARM (32-bits), we errors like this:
+
+	    /home/smarchi/src/binutils-gdb/gdb/value.c: In function 'gdb::array_view<const unsigned char> value_contents_for_printing(value*)':
+	    /home/smarchi/src/binutils-gdb/gdb/value.c:1252:35: error: narrowing conversion of 'length' from 'ULONGEST' {aka 'long long unsigned int'} to 'size_t' {aka 'unsigned int'} [-Werror=narrowing]
+	     1252 |   return {value->contents.get (), length};
+	          |                                   ^~~~~~
+
+	Fix that by using gdb::make_array_view, which does the appropriate
+	conversion.
+
+	Change-Id: I7d6f2e75d7440d248b8fb18f8272ee92954b404d
+
+2021-10-27  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: Tidy riscv assembler and disassembler.
+	Tidy the gas/config/tc-riscv.c and opcodes/riscv-dis.c, to prepare for
+	moving the released extensions (including released vendor extensions)
+	from integration branch back to mainline.
+
+	* Added parts of missing comments.
+
+	* Updated md_show_usage.
+
+	* For validate_riscv_insn, riscv_ip and print_insn_args, unify the
+	  following pointer names,
+	  - oparg: pointed to the parsed operand defined in the riscv_opcodes.
+	  - asarg: pointed to the parsed operand from assembly.
+	  - opargStart: recorded the parsed operand name from riscv_opcodes.
+	  - asargStart: recorded the parsed operand name from assembly.
+
+	gas/
+		* config/tc-riscv.c: Added parts of missind comments and updated
+		the md_show_usage.
+		(riscv_multi_subset_supports): Tidy codes.
+		(validate_riscv_insn): Unify the pointer names, oparg, asarg,
+		opargStart and asargStart, to prepare for moving the released
+		extensions from integration branch back to mainline.
+		(riscv_ip): Likewise.
+		(macro_build): Added fmtStart, also used to prepare for moving
+		released extensions.
+		(md_show_usage): Added missing descriptions for new options.
+	opcodes/
+		* riscv-dis.c (print_insn_args): Unify the pointer names,
+		oparg and opargStart, to prepare for moving the released
+		extensions from integration branch back to mainline.
+
+2021-10-27  Maciej W. Rozycki  <macro@embecosm.com>
+
+	opcodes: Fix RPATH not being set for dynamic libbfd dependency
+	If built as a shared library, libopcodes has a load-time dependency on
+	libbfd, which is recorded in the dynamic section, however without a
+	corresponding RPATH entry for the directory to find libbfd in.  This
+	causes loading to fail whenever libbfd is only pulled by libopcodes
+	indirectly and libbfd has been installed in a directory that is not in
+	the dynamic loader's search path.
+
+	It does not happen with the programs included with binutils or GDB,
+	because they all also pull libbfd when using libopcodes, but it can
+	happen with external software, e.g.:
+
+	$ gdbserver --help
+	gdbserver: error while loading shared libraries: libbfd-[...].so: cannot open shared object file: No such file or directory
+	$
+
+	(not our `gdbserver').
+
+	Indirect dynamic dependencies are handled by libtool automatically by
+	adding RPATH entries as required, however our setup for libopcodes
+	prevents this from happening by linking in libbfd with an explicit file
+	reference sneaked through to the linker directly behind libtool's back
+	via the `-Wl' linker command-line option rather than via `-l' combined
+	with a suitable library search path specified via `-L', as it would be
+	usually the case, or just referring to the relevant .la file in a fully
+	libtool-enabled configuration such as ours.
+
+	According to an observation in the discussion back in 2007[1][2][3] that
+	has led to the current arrangement it is to prevent libtool from picking
+	up the wrong version of libbfd.  It does not appear to be needed though,
+	not at least with our current libtool incarnation, as directly referring
+	`libbfd.la' does exactly what it should, as previously suggested[4], and
+	with no link-time reference to the installation directory other than to
+	set RPATH.  Uninstalled version of libopcodes has libbfd's build-time
+	location prepended to RPATH too, as also expected.
+
+	Use a direct reference to `libbfd.la' then, making the load error quoted
+	above go away.  Alternatively `-L' and `-l' could be used to the same
+	effect, but it seems an unnecessary complication and just another way to
+	circumvent rather than making use of libtool.
+
+	References:
+
+	[1] "compile failure due to undefined symbol",
+	    <https://sourceware.org/ml/binutils/2007-08/msg00476.html>
+
+	[2] same, <https://sourceware.org/ml/binutils/2007-09/msg00000.html>
+
+	[3] same, <https://sourceware.org/ml/binutils/2007-10/msg00019.html>
+
+	[4] same, <https://sourceware.org/ml/binutils/2007-10/msg00034.html>
+
+		opcodes/
+		* Makefile.am: Remove obsolete comment.
+		* configure.ac: Refer `libbfd.la' to link shared BFD library
+		except for Cygwin.
+		* Makefile.in: Regenerate.
+		* configure: Regenerate.
+
+2021-10-27  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-27  H.J. Lu  <hjl.tools@gmail.com>
+
+	gold: Place .note.gnu.property section before other note sections
+	Place the .note.gnu.property section before all other note sections to
+	avoid being placed between other note sections with different alignments.
+
+		PR gold/28494
+		* layout.cc (Layout::create_note): Set order to ORDER_PROPERTY_NOTE
+		for the .note.gnu.property section.
+		* layout.h (Output_section_order): Add ORDER_PROPERTY_NOTE.
+
+2021-10-26  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/doc] Fix print inferior-events default
+	In the docs about print inferior-events we read:
+	...
+	By default, these messages will not be printed.
+	...
+
+	That used to be the case, but is no longer so since commit f67c0c91715 "Enable
+	'set print inferior-events' and improve detach/fork/kill/exit messages".
+
+	Fix this by updating the docs.
+
+2021-10-26  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-25  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: change functions returning value contents to use gdb::array_view
+	The bug fixed by this [1] patch was caused by an out-of-bounds access to
+	a value's content.  The code gets the value's content (just a pointer)
+	and then indexes it with a non-sensical index.
+
+	This made me think of changing functions that return value contents to
+	return array_views instead of a plain pointer.  This has the advantage
+	that when GDB is built with _GLIBCXX_DEBUG, accesses to the array_view
+	are checked, making bugs more apparent / easier to find.
+
+	This patch changes the return types of these functions, and updates
+	callers to call .data() on the result, meaning it's not changing
+	anything in practice.  Additional work will be needed (which can be done
+	little by little) to make callers propagate the use of array_view and
+	reap the benefits.
+
+	[1] https://sourceware.org/pipermail/gdb-patches/2021-September/182306.html
+
+	Change-Id: I5151f888f169e1c36abe2cbc57620110673816f3
+
+2021-10-25  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdbsupport: add assertions in array_view
+	Add assertions to ensure we don't access an array_view out of bounds.
+	Enable these assertions only when _GLIBCXX_DEBUG is set, as we did for
+	gdb::optional.
+
+	Change-Id: Iffaee38252405073735ed123c8e57fde6b2c6be3
+
+2021-10-25  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdbserver: make target_pid_to_str return std::string
+	I wanted to write a warning that included two target_pid_to_str calls,
+	like this:
+
+	    warning (_("Blabla %s, blabla %s"),
+		     target_pid_to_str (ptid1),
+		     target_pid_to_str (ptid2));
+
+	This doesn't work, because target_pid_to_str stores its result in a
+	static buffer, so my message would show twice the same ptid.  Change
+	target_pid_to_str to return an std::string to avoid this.  I don't think
+	we save much by using a static buffer, but it is more error-prone.
+
+	Change-Id: Ie3f649627686b84930529cc5c7c691ccf5d36dc2
+
+2021-10-25  H.J. Lu  <hjl.tools@gmail.com>
+
+	x86: Also handle stores for -muse-unaligned-vector-move
+		* config/tc-i386.c (encode_with_unaligned_vector_move): Also
+		handle stores.
+		* testsuite/gas/i386/unaligned-vector-move.s: Add stores.
+		* testsuite/gas/i386/unaligned-vector-move.d: Updated.
+		* testsuite/gas/i386/x86-64-unaligned-vector-move.d: Likewise.
+
+2021-10-25  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix duplicate in gdb.mi/mi-var-cp.exp
+	With test-case gdb.mi/mi-var-cp.exp I run into this duplicate:
+	...
+	PASS: gdb.mi/mi-var-cp.exp: run to mi-var-cp.cc:104 (set breakpoint)
+	PASS: gdb.mi/mi-var-cp.exp: create varobj for s
+	PASS: gdb.mi/mi-var-cp.exp: create varobj for s
+	DUPLICATE: gdb.mi/mi-var-cp.exp: create varobj for s
+	...
+
+	This is due to a duplicate test name here:
+	...
+	$ cat -n gdb/testsuite/gdb.mi/mi-var-cp.cc
+	  ...
+	   100  int reference_to_struct ()
+	   101  {
+	   102    /*: BEGIN: reference_to_struct :*/
+	   103    S s = {7, 8};
+	   104    S& r = s;
+	   105    /*:
+	   106      mi_create_varobj S s "create varobj for s"
+	   107      mi_create_varobj R r "create varobj for s"
+	...
+
+	Fix this by using "create varobj for r" instead.
+
+	Tested on x86_64-linux.
+
+2021-10-25  Nick Alcock  <nick.alcock@oracle.com>
+
+	libctf, ld: handle nonrepresentable types better
+	ctf_type_visit (used, among other things, by the type dumping code) was
+	aborting when it saw a nonrepresentable type anywhere: even a single
+	structure member with a nonrepresentable type caused an abort with
+	ECTF_NONREPRESENTABLE.  This is not useful behaviour, given that the
+	abort comes from a type-resolution we are only doing in order to
+	determine whether the type is a structure or union.  We know
+	nonrepresentable types can't be either, so handle that case and
+	pass the nonrepresentable type down.
+
+	(The added test verifies that the dumper now handles this case and
+	prints nonrepresentable structure members as it already does
+	nonrepresentable top-level types, rather than skipping the whole
+	structure -- or, without the previous commit, skipping the whole types
+	section.)
+
+	ld/ChangeLog
+	2021-10-25  Nick Alcock  <nick.alcock@oracle.com>
+
+		* testsuite/ld-ctf/nonrepresentable-member.*: New test.
+
+	libctf/ChangeLog
+	2021-10-25  Nick Alcock  <nick.alcock@oracle.com>
+
+		* ctf-types.c (ctf_type_rvisit): Handle nonrepresentable types.
+
+2021-10-25  Nick Alcock  <nick.alcock@oracle.com>
+
+	libctf: dump: do not stop dumping types on error
+	If dumping of a single type fails, we obviously can't dump it; but just
+	as obviously this doesn't make the other types in the types section
+	invalid or undumpable.  So we should not propagate errors seen when
+	type-dumping, but rather ignore them and carry on, so we dump as many
+	types as we can (leaving out the ones we can't grok).
+
+	libctf/ChangeLog
+	2021-10-25  Nick Alcock  <nick.alcock@oracle.com>
+
+		* ctf-dump.c (ctf_dump_type): Do not abort on error.
+
+2021-10-25  Nick Alcock  <nick.alcock@oracle.com>
+
+	binutils, ld: make objdump --ctf's parameter optional
+	ld by default (and always, unless adjusted with a hand-rolled linker
+	script) emits deduplicated CTF into the .ctf section.  But viewing
+	it needs you to explicitly tell objdump this: it doesn't default
+	its argument, even though what you always end up typing is
+	--ctf=.ctf.
+
+	This is annoying, so make the argument optional.
+
+	binutils/ChangeLog
+	2021-10-25  Nick Alcock  <nick.alcock@oracle.com>
+
+		* objdump.c (usage): --ctf now has an optional argument.
+		(main): Adjust accordingly.
+		(dump_ctf): Default it.
+		* doc/ctf.options.texi: Adjust.
+
+	ld/ChangeLog
+	2021-10-25  Nick Alcock  <nick.alcock@oracle.com>
+
+		* testsuite/ld-ctf/array.d: Change --ctf=.ctf to --ctf.
+		* testsuite/ld-ctf/conflicting-cycle-1.B-1.d: Likewise.
+		* testsuite/ld-ctf/conflicting-cycle-1.B-2.d: Likewise.
+		* testsuite/ld-ctf/conflicting-cycle-1.parent.d: Likewise.
+		* testsuite/ld-ctf/conflicting-cycle-2.A-1.d: Likewise.
+		* testsuite/ld-ctf/conflicting-cycle-2.A-2.d: Likewise.
+		* testsuite/ld-ctf/conflicting-cycle-2.parent.d: Likewise.
+		* testsuite/ld-ctf/conflicting-cycle-3.C-1.d: Likewise.
+		* testsuite/ld-ctf/conflicting-cycle-3.C-2.d: Likewise.
+		* testsuite/ld-ctf/conflicting-cycle-3.parent.d: Likewise.
+		* testsuite/ld-ctf/conflicting-enums.d: Likewise.
+		* testsuite/ld-ctf/conflicting-typedefs.d: Likewise.
+		* testsuite/ld-ctf/cross-tu-cyclic-conflicting.d: Likewise.
+		* testsuite/ld-ctf/cross-tu-cyclic-nonconflicting.d: Likewise.
+		* testsuite/ld-ctf/cross-tu-into-cycle.d: Likewise.
+		* testsuite/ld-ctf/cross-tu-noncyclic.d: Likewise.
+		* testsuite/ld-ctf/cycle-1.d: Likewise.
+		* testsuite/ld-ctf/cycle-2.A.d: Likewise.
+		* testsuite/ld-ctf/cycle-2.B.d: Likewise.
+		* testsuite/ld-ctf/cycle-2.C.d: Likewise.
+		* testsuite/ld-ctf/data-func-conflicted.d: Likewise.
+		* testsuite/ld-ctf/diag-cttname-null.d: Likewise.
+		* testsuite/ld-ctf/diag-cuname.d: Likewise.
+		* testsuite/ld-ctf/diag-parlabel.d: Likewise.
+		* testsuite/ld-ctf/enum-forward.d: Likewise.
+		* testsuite/ld-ctf/enums.d: Likewise.
+		* testsuite/ld-ctf/forward.d: Likewise.
+		* testsuite/ld-ctf/function.d: Likewise.
+		* testsuite/ld-ctf/nonrepresentable.d: Likewise.
+		* testsuite/ld-ctf/slice.d: Likewise.
+		* testsuite/ld-ctf/super-sub-cycles.d: Likewise.
+
+2021-10-25  Nick Alcock  <nick.alcock@oracle.com>
+
+	binutils: make objdump/readelf --ctf-parent actually useful
+	This option has been present since the very early days of the
+	development of libctf as part of binutils, and it shows.  Back in the
+	earliest days, I thought we might handle ambiguous types by introducing
+	new ELF sections on the fly named things like .ctf.foo.c for ambiguous
+	types found only in foo.c, etc.  This turned out to be a terrible idea,
+	so we moved to using a CTF archive in the .ctf section which contained
+	all the CTF dictionaries -- but the --ctf-parent option in objdump and
+	readelf was never adjusted, and lingered as a mechanism to specify CTF
+	parent dictionaries in sections other than .ctf, even though the linker
+	has no way to produce parent dictionaries in different sections from
+	their children, libctf's ctf_open can't handle such split-up
+	parent/child dicts, and they are never found in the wild, emitted by GNU
+	ld or by any known third-party linking tool.
+
+	Meanwhile, the actually-useful ctf_link feature (albeit not used by ld)
+	which lets you remap the names of CTF archive members (so you can end up
+	with a parent archive member named something other than ".ctf", still
+	contained with all its children in a single .ctf section) had no support
+	in objdump or readelf: there was no way to tell them that these members
+	were parents, so all the types in the associated child dicts always
+	appeared corrupted, referencing nonexistent types from a parent objdump
+	couldn't find.
+
+	So adjust --ctf-parent so that rather than taking a section name it
+	takes a member name instead (if not specified, the name is ".ctf", which
+	is what GNU ld emits).  Because the option was always useless before
+	now, this is expected to have no backward-compatibility implications.
+
+	As part of this, we have to slightly adjust the code which skips the
+	archive member name if redundant: right now it skips it if it's ".ctf",
+	on the assumption that this name will almost always be at the start
+	of the objdump output and thus we'll end up with a shared dump
+	and then smaller, headed dumps for the per-TU child dicts; but if
+	the parent name has been changed, that won't be true any more.
+
+	So change the rules to "members named .ctf which appear first in the
+	first have their member name skipped".  Since we now need to count
+	members, move from ctf_archive_iter (for which passing in extra
+	parameters requires defining a new struct and is clumsy) to
+	ctf_archive_next, allowing us to just *call* dump_ctf_archive_member and
+	maintain a member count in the obvious way.  In the process we fix a
+	tiny difference between readelf and objdump: if a ctf_dump ever failed,
+	readelf skipped every later member, while objdump tried to keep going as
+	much as it could.  For a dumping tool the former is clearly preferable.
+
+	binutils/ChangeLog
+	2021-10-25  Nick Alcock  <nick.alcock@oracle.com>
+
+		* objdump.c (usage): --ctf-parent now takes a name, not a section.
+		(dump_ctf): Don't open a separate section; use the parent_name in
+		ctf_dict_open instead.  Use ctf_archive_next, not ctf_archive_iter,
+		so we can pass down a member count.
+		(dump_ctf_archive_member): Add the member count; don't return
+		anything.  Import parents into children no matter what the
+		parent's name, while still avoiding displaying the header for the
+		common parent name of ".ctf".
+		* readelf.c (usage): Adjust similarly.
+		(dump_section_as_ctf): Likewise.
+		(dump_ctf_archive_member): Likewise.  Never stop iterating over
+		archive members, even if ctf_dump of one member fails.
+		* doc/ctf.options.texi: Adjust.
+
+2021-10-25  Alan Modra  <amodra@gmail.com>
+
+	objdump doesn't accept -L option
+	A followup to commit ca0e11aa4b.
+
+		* objdump.c (main): Add 'L' to short options and sort them.
+
+2021-10-25  Alan Modra  <amodra@gmail.com>
+
+	bfd_nonfatal_message, localise va_start
+	Nothing to see here, just a little tidier.
+
+		* bucomm.c (bfd_nonfatal_message): Localise va_list args.
+
+2021-10-25  Alan Modra  <amodra@gmail.com>
+
+	ubsan: _bfd_xcoff64_swap_aux_in left shift of negative value
+		* coff64-rs6000.c (_bfd_xcoff64_swap_aux_in): Use bfd_vma for h.
+
+	asan: evax_bfd_print_image buffer overflow
+		* vms-alpha.c (evax_bfd_print_image): Sanity check printing of
+		"image activator fixup" section.
+		(evax_bfd_print_relocation_records): Sanity check buffer offsets.
+		(evax_bfd_print_address_fixups): Likewise.
+		(evax_bfd_print_reference_fixups): Likewise.
+
+2021-10-25  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-24  Alan Modra  <amodra@gmail.com>
+
+	asan: c4x, c54x coff_canonicalize_reloc buffer overflow
+	Sometimes the investigation of a fuzzing bug report leads into areas
+	you'd rather not go.  In this instance by the time I'd figured out the
+	real cause was a target variant that had never been properly supported
+	in binutils, the time needed to fix it was less than the time needed
+	to rip it out.
+
+		* coffcode.h (coff_set_alignment_hook): Call bfd_coff_swap_reloc_in
+		not coff_swap_reloc_in.
+		(coff_slurp_reloc_table): Likewise.  Don't use RELOC type.
+		(ticoff0_swap_table): Use coff_swap_reloc_v0_out and
+		coff_swap_reloc_v0_in.
+		* coffswap.h (coff_swap_reloc_v0_in, coff_swap_reloc_v0_out): New.
+		* coff-tic54x.c (tic54x_lookup_howto): Don't abort.
+		* coffgen.c (coff_get_normalized_symtab): Use PTR_ADD.
+		* bfd-in.h (PTR_ADD, NPTR_ADD): Avoid warnings when passing an
+		expression.
+		* bfd-in2.h: Regenerate.
+
+2021-10-24  Alan Modra  <amodra@gmail.com>
+
+	asan: arm-darwin: buffer overflow
+		PR 21813
+		* mach-o-arm.c (bfd_mach_o_arm_canonicalize_one_reloc): Sanity
+		check PAIR reloc in other branch of condition as was done for
+		PR21813.  Formatting.  Delete debug printf.
+
+	asan: aout: heap buffer overflow
+		* aoutx.h (aout_get_external_symbols): Sanity check before writing
+		zero index entry.  Remove outdated comment.
+		* pdp11.c (aout_get_external_symbols): Likewise.
+
+2021-10-24  liuzhensong  <liuzhensong@loongson.cn>
+
+	LoongArch ld support
+	2021-10-22  Chenghua Xu  <xuchenghua@loongson.cn>
+		    Zhensong Liu  <liuzhensong@loongson.cn>
+		    Weinan Liu  <liuweinan@loongson.cn>
+		    Xiaolin Tang  <tangxiaolin@loongson.cn>
+
+	ld/
+		* Makefile.am: Add LoongArch.
+		* NEWS: Mention LoongArch support.
+		* configure.tgt: Add LoongArch.
+		* emulparams/elf32loongarch-defs.sh: New.
+		* emulparams/elf32loongarch.sh: Likewise.
+		* emulparams/elf64loongarch-defs.sh: Likewise.
+		* emulparams/elf64loongarch.sh: Likewise.
+		* emultempl/loongarchelf.em: Likewise.
+		* Makefile.in: Regenerate.
+		* po/BLD-POTFILES.in: Regenerate.
+	ld/testsuite/
+		* ld-loongarch-elf/disas-jirl.d: New.
+		* ld-loongarch-elf/disas-jirl.s: Likewise.
+		* ld-loongarch-elf/jmp_op.d: Likewise.
+		* ld-loongarch-elf/jmp_op.s: Likewise.
+		* ld-loongarch-elf/ld-loongarch-elf.exp: Likewise.
+		* ld-loongarch-elf/macro_op.d: Likewise.
+		* ld-loongarch-elf/macro_op.s: Likewise.
+		* ld-loongarch-elf/syscall-0.s: Likewise.
+		* ld-loongarch-elf/syscall-1.s: Likewise.
+		* ld-loongarch-elf/syscall.d: Likewise.
+		* ld-srec/srec.exp: Add LoongArch.
+		* ld-unique/pr21529.d: Likewise.
+
+2021-10-24  liuzhensong  <liuzhensong@loongson.cn>
+
+	LoongArch gas support
+	2021-10-22  Chenghua Xu  <xuchenghua@loongson.cn>
+	            Zhensong Liu  <liuzhensong@loongson.cn>
+	            Weinan Liu  <liuweinan@loongson.cn>
+		    Xiaolin Tang  <tangxiaolin@loongson.cn>
+
+	gas/
+		* Makefile.am: Add LoongArch.
+		* NEWS: Mention LoongArch support.
+		* config/loongarch-lex-wrapper.c: New.
+		* config/loongarch-lex.h: New.
+		* config/loongarch-lex.l: New.
+		* config/loongarch-parse.y: New.
+		* config/tc-loongarch.c: New.
+		* config/tc-loongarch.h: New.
+		* configure.ac: Add LoongArch.
+		* configure.tgt: Likewise.
+		* doc/as.texi: Likewise.
+		* doc/c-loongarch.texi: Likewise.
+		* Makefile.in: Regenerate.
+		* configure: Regenerate.
+		* po/POTFILES.in: Regenerate.
+	gas/testsuite/
+		* gas/all/gas.exp: Add LoongArch.
+		* gas/elf/elf.exp: Likewise.
+		* gas/loongarch/4opt_op.d: New.
+		* gas/loongarch/4opt_op.s: Likewise.
+		* gas/loongarch/fix_op.d: Likewise.
+		* gas/loongarch/fix_op.s: Likewise.
+		* gas/loongarch/float_op.d: Likewise.
+		* gas/loongarch/float_op.s: Likewise.
+		* gas/loongarch/imm_op.d: Likewise.
+		* gas/loongarch/imm_op.s: Likewise.
+		* gas/loongarch/jmp_op.d: Likewise.
+		* gas/loongarch/jmp_op.s: Likewise.
+		* gas/loongarch/load_store_op.d: Likewise.
+		* gas/loongarch/load_store_op.s: Likewise.
+		* gas/loongarch/loongarch.exp: Likewise.
+		* gas/loongarch/macro_op.d: Likewise.
+		* gas/loongarch/macro_op.s: Likewise.
+		* gas/loongarch/nop.d: Likewise.
+		* gas/loongarch/nop.s: Likewise.
+		* gas/loongarch/privilege_op.d: Likewise.
+		* gas/loongarch/privilege_op.s: Likewise.
+		* gas/loongarch/syscall.d: Likewise.
+		* gas/loongarch/syscall.s: Likewise.
+		* lib/gas-defs.exp: Add LoongArch.
+
+2021-10-24  liuzhensong  <liuzhensong@loongson.cn>
+
+	LoongArch binutils support
+	2021-10-22  Chenghua Xu  <xuchenghua@loongson.cn>
+		    Zhensong Liu  <liuzhensong@loongson.cn>
+		    Weinan Liu  <liuweinan@loongson.cn>
+	binutils/
+		* NEWS: Mention LoongArch support.
+		* readelf.c: Add LoongArch.
+		* testsuite/binutils-all/objdump.exp: Add LoongArch.
+
+2021-10-24  liuzhensong  <liuzhensong@loongson.cn>
+
+	LoongArch opcodes support
+	2021-10-22  Chenghua Xu  <xuchenghua@loongson.cn>
+		    Zhensong Liu  <liuzhensong@loongson.cn>
+		    Weinan Liu  <liuweinan@loongson.cn>
+
+	include/
+		* opcode/loongarch.h: New.
+		* dis-asm.h: Declare print_loongarch_disassembler_options.
+	opcodes/
+		* Makefile.am: Add LoongArch.
+		* configure.ac: Likewise.
+		* disassemble.c: Likewise.
+		* disassemble.h: Declare print_insn_loongarch.
+		* loongarch-coder.c: New.
+		* loongarch-dis.c: New.
+		* loongarch-opc.c: New.
+		* Makefile.in: Regenerate.
+		* configure: Regenerate.
+		* po/POTFILES.in: Regenerate.
+
+2021-10-24  liuzhensong  <liuzhensong@loongson.cn>
+
+	LoongArch bfd support
+	2021-10-22  Chenghua Xu  <xuchenghua@loongson.cn>
+		    Zhensong Liu  <liuzhensong@loongson.cn>
+		    Weinan Liu  <liuweinan@loongson.cn>
+	bfd/
+		* Makefile.am: Add LoongArch.
+		* archures.c: Likewise.
+		* config.bfd: Likewise.
+		* configure.ac: Likewise.
+		* cpu-loongarch.c: New.
+		* elf-bfd.h: Add LoongArch.
+		* elf.c: Add LoongArch elfcore_grok_xxx.
+		* elfnn-loongarch.c: New.
+		* elfxx-loongarch.c: New.
+		* elfxx-loongarch.h: New.
+		* reloc.c: Add LoongArch BFD RELOC ENUM.
+		* targets.c: Add LoongArch target.
+		* Makefile.in: Regenerate.
+		* bfd-in2.h: Regenerate.
+		* configure: Regenerate.
+		* libbfd.h: Regenerate.
+		* po/BLD-POTFILES.in: Regenerate.
+		* po/SRC-POTFILES.in: Regenerate.
+
+	include/
+		* elf/common.h: Add NT_LARCH_{CPUCFG,CSR,LSX,LASX}.
+		* elf/loongarch.h: New.
+
+2021-10-24  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-23  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-22  H.J. Lu  <hjl.tools@gmail.com>
+
+	x86: Add -muse-unaligned-vector-move to assembler
+	Unaligned load/store instructions on aligned memory or register are as
+	fast as aligned load/store instructions on modern Intel processors.  Add
+	a command-line option, -muse-unaligned-vector-move, to x86 assembler to
+	encode encode aligned vector load/store instructions as unaligned
+	vector load/store instructions.
+
+		* NEWS: Mention -muse-unaligned-vector-move.
+		* config/tc-i386.c (use_unaligned_vector_move): New.
+		(encode_with_unaligned_vector_move): Likewise.
+		(md_assemble): Call encode_with_unaligned_vector_move for
+		-muse-unaligned-vector-move.
+		(OPTION_MUSE_UNALIGNED_VECTOR_MOVE): New.
+		(md_longopts): Add -muse-unaligned-vector-move.
+		(md_parse_option): Handle -muse-unaligned-vector-move.
+		(md_show_usage): Add -muse-unaligned-vector-move.
+		* doc/c-i386.texi: Document -muse-unaligned-vector-move.
+		* testsuite/gas/i386/i386.exp: Run unaligned-vector-move and
+		x86-64-unaligned-vector-move.
+		* testsuite/gas/i386/unaligned-vector-move.d: New file.
+		* testsuite/gas/i386/unaligned-vector-move.s: Likewise.
+		* testsuite/gas/i386/x86-64-unaligned-vector-move.d: Likewise.
+
+2021-10-22  Tom Tromey  <tromey@adacore.com>
+
+	Fix 'uninstall' target
+	This adds some missing code to the 'uninstall' targets in gdb and
+	gdbserver.  It also changes gdb's uninstall target so that it no
+	longer tries to remove any man page -- this is already done (and more
+	correctly) by doc/Makefile.in.
+
+	I tested this with 'make install' followed by 'make uninstall', then
+	examining the install tree for regular files.  Only the 'dir' file
+	remains, but this appears to just be how 'install-info' is intended to
+	work.
+
+2021-10-22  Tom Tromey  <tromey@adacore.com>
+
+	Remove unused variables from gdbserver's Makefile
+	This removes a number of unused variables from gdbserver's Makefile.
+	I found these while working on the subsequent patches, and figured it
+	would be cleaner to have a separate patch for the deletions.
+
+2021-10-22  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.threads/linux-dp.exp
+	On openSUSE Tumbleweed with glibc-debuginfo installed I get:
+	...
+	 (gdb) PASS: gdb.threads/linux-dp.exp: continue to breakpoint: thread 5's print
+	 where^M
+	 #0  print_philosopher (n=3, left=33 '!', right=33 '!') at linux-dp.c:105^M
+	 #1  0x0000000000401628 in philosopher (data=0x40537c) at linux-dp.c:148^M
+	 #2  0x00007ffff7d56b37 in start_thread (arg=<optimized out>) \
+	                          at pthread_create.c:435^M
+	 #3  0x00007ffff7ddb640 in clone3 () \
+	                          at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81^M
+	 (gdb) PASS: gdb.threads/linux-dp.exp: first thread-specific breakpoint hit
+	...
+	while without debuginfo installed I get instead:
+	...
+	 (gdb) PASS: gdb.threads/linux-dp.exp: continue to breakpoint: thread 5's print
+	 where^M
+	 #0  print_philosopher (n=3, left=33 '!', right=33 '!') at linux-dp.c:105^M
+	 #1  0x0000000000401628 in philosopher (data=0x40537c) at linux-dp.c:148^M
+	 #2  0x00007ffff7d56b37 in start_thread () from /lib64/libc.so.6^M
+	 #3  0x00007ffff7ddb640 in clone3 () from /lib64/libc.so.6^M
+	 (gdb) FAIL: gdb.threads/linux-dp.exp: first thread-specific breakpoint hit
+	...
+
+	The problem is that the regexp used:
+	...
+	  "\(from .*libpthread\|at pthread_create\|in pthread_create\)"
+	...
+	expects the 'from' part to match libpthread, but in glibc 2.34 libpthread has
+	been merged into libc.
+
+	Fix this by updating the regexp.
+
+	Tested on x86_64-linux.
+
+2021-10-22  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix FAILs in gdb.mi/mi-breakpoint-changed.exp
+	Since commit e36788d1354 "[gdb/testsuite] Fix handling of nr_args < 3 in
+	mi_gdb_test" we run into:
+	...
+	PASS: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: mi runto main
+	Expecting: ^(-break-insert -f pendfunc1[^M
+	]+)?((&.*)*.*~"Breakpoint 2 at.*\\n".*=breakpoint-created,\
+	  bkpt=\{number="2",type="breakpoint".*\}.*\n\^done[^M
+	]+[(]gdb[)] ^M
+	[ ]*)
+	-break-insert -f pendfunc1^M
+	^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",\
+	  addr="0x00007ffff7bd559e",func="pendfunc1",\
+	  file="gdb/testsuite/gdb.mi/pendshr1.c",\
+	  fullname="gdb/testsuite/gdb.mi/pendshr1.c",line="21",thread-groups=["i1"],\
+	  times="0",original-location="pendfunc1"}^M
+	(gdb) ^M
+	FAIL: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: \
+	  -break-insert -f pendfunc1 (unexpected output)
+	...
+
+	The regexp expects a breakpoint-created event, but that's actually suppressed
+	by the command:
+	...
+	DEF_MI_CMD_MI_1 ("break-insert", mi_cmd_break_insert,
+	                   &mi_suppress_notification.breakpoint),
+	...
+
+	Fix this by updating the regexp.
+
+	Likewise for the following:
+	...
+	PASS: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: \
+	  -break-insert -f pendfunc1
+	Expecting: ^(-break-enable count 1 2[^M
+	]+)?(=breakpoint-modified,\
+	  bkpt=\{number="2",type="breakpoint",disp="dis",enabled="y".*\}.*\n\^done[^M
+	]+[(]gdb[)] ^M
+	[ ]*)
+	-break-enable count 1 2^M
+	^done^M
+	(gdb) ^M
+	FAIL: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: \
+	  -break-enable count 1 2 (unexpected out\
+	put)
+	...
+
+	Tested on x86_64-linux.
+
+2021-10-22  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb/python: move gdb.Membuf support into a new file
+	In a future commit I'm going to be creating gdb.Membuf objects from a
+	new file within gdb/python/py*.c.  Currently all gdb.Membuf objects
+	are created directly within infpy_read_memory (as a result of calling
+	gdb.Inferior.read_memory()).
+
+	Initially I split out the Membuf creation code into a new function,
+	and left the new function in gdb/python/py-inferior.c, however, it
+	felt a little random that the Membuf creation code should live with
+	the inferior handling code.
+
+	So, then I moved all of the Membuf related code out into a new file,
+	gdb/python/py-membuf.c, the interface is gdbpy_buffer_to_membuf, which
+	wraps an array of bytes into a gdb.Membuf object.
+
+	Most of the code is moved directly from py-inferior.c with only minor
+	tweaks to layout and replacing NULL with nullptr, hence, I've left the
+	copyright date on py-membuf.c as 2009-2021 to match py-inferior.c.
+
+	Currently, the only user of this code is still py-inferior.c, but in
+	later commits this will change.
+
+	There should be no user visible changes after this commit.
+
+2021-10-22  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb/python: new gdb.architecture_names function
+	Add a new function to the Python API, gdb.architecture_names().  This
+	function returns a list containing all of the supported architecture
+	names within the current build of GDB.
+
+	The values returned in this list are all of the possible values that
+	can be returned from gdb.Architecture.name().
+
+2021-10-22  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: make disassembler fprintf callback a static member function
+	The disassemble_info structure has four callbacks, we have three of
+	them as static member functions within gdb_disassembler, the fourth is
+	just a global static function.
+
+	However, this fourth callback, is still only used from the
+	disassemble_info struct, so there's no real reason for its special
+	handling.
+
+	This commit makes fprintf_disasm a static method within
+	gdb_disassembler.
+
+	There should be no user visible changes after this commit.
+
+2021-10-22  Lewis Revill  <lewis.revill@embecosm.com>
+
+	RISC-V: Added ld testcase for pcgp relaxation.
+	Consider the the pcgp-relax-02 testcase,
+
+	        .text
+	        .globl _start
+	_start:
+	.L1:    auipc   a0, %pcrel_hi(data_a)
+	.L2:    auipc   a1, %pcrel_hi(data_b)
+	        addi    a0, a0, %pcrel_lo(.L1)
+	        addi    a1, a1, %pcrel_lo(.L2)
+
+	        .data
+	        .word 0x0
+	        .globl data_a
+	data_a:
+	        .word 0x1
+
+	        .section .rodata
+	        .globl data_b
+	data_b:
+	        .word 0x2
+
+	If the first auipc is deleted, but we are still building the pcgp
+	table (connect the high and low pcrel relocations), then there is
+	an aliasing issue that we need some way to disambiguate which of
+	the two symbols we are targeting.  Therefore, Palmer thought of a
+	way to use R_RISCV_DELETE to split this into two phases, so we
+	could resolve the addresses before creating the ambiguities.
+
+	This patch just add the ld testcase for the above case, in case we
+	have changed something but break this.
+
+	ld/
+		* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Renamed pcgp-relax
+		to pcgp-relax-01, and added pcgp-relax-02.
+		* testsuite/ld-riscv-elf/pcgp-relax-01.d: Renmaed from pcgp-relax.
+		* testsuite/ld-riscv-elf/pcgp-relax-01.s: Likewise.
+		* testsuite/ld-riscv-elf/pcgp-relax-02.d: New testcase.
+		* testsuite/ld-riscv-elf/pcgp-relax-02.s: Likewise.
+
+2021-10-22  Lewis Revill  <lewis.revill@embecosm.com>
+
+	RISC-V: Don't separate pcgp relaxation to another relax pass.
+	Commit abd20cb637008da9d32018b4b03973e119388a0a and
+	ebdcad3fddf6ec21f6d4dcc702379a12718cf0c4 introduced additional
+	complexity into the paths run by the RISC-V relaxation pass in order to
+	resolve the issue of accurately keeping track of pcrel_hi and pcrel_lo
+	pairs. The first commit split up relaxation of these relocs into a pass
+	which occurred after other relaxations in order to prevent the situation
+	where bytes were deleted in between a pcrel_lo/pcrel_hi pair, inhibiting
+	our ability to find the corresponding pcrel_hi relocation from the
+	address attached to the pcrel_lo.
+
+	Since the relaxation was split into two passes the 'again' parameter
+	could not be used to perform the entire relaxation process again and so
+	the second commit added a way to restart ldelf_map_segments, thus
+	starting the whole process again.
+
+	Unfortunately this process could not account for the fact that we were
+	not finished with the relaxation process so in some cases - such as the
+	case where code would not fit in a memory region before the
+	R_RISCV_ALIGN relocation was relaxed - sanity checks in generic code
+	would fail.
+
+	This patch fixes all three of these concerns by reverting back to a
+	system of having only one target relax pass but updating entries in the
+	table of pcrel_hi/pcrel_lo relocs every time any bytes are deleted. Thus
+	we can keep track of the pairs accurately, and we can use the 'again'
+	parameter to restart the entire target relax pass, behaving in the way
+	that generic code expects. Unfortunately we must still have an
+	additional pass to delay deleting AUIPC bytes to avoid ambiguity between
+	pcrel_hi relocs stored in the table after deletion. This pass can only
+	be run once so we may potentially miss out on relaxation opportunities
+	but this is likely to be rare.
+
+	https://sourceware.org/bugzilla/show_bug.cgi?id=28410
+
+	bfd/
+		* elfnn-riscv.c (riscv_elf_link_hash_table): Removed restart_relax.
+		(riscv_elf_link_hash_table_create): Updated.
+		(riscv_relax_delete_bytes): Moved after the riscv_update_pcgp_relocs.
+		Update the pcgp_relocs table whenever bytes are deleted.
+		(riscv_update_pcgp_relocs): Add function to update the section
+		offset of pcrel_hi and pcrel_lo, and also update the symbol value
+		of pcrel_hi.
+		(_bfd_riscv_relax_call): Need to update the pcgp_relocs table
+		when deleting codes.
+		(_bfd_riscv_relax_lui): Likewise.
+		(_bfd_riscv_relax_tls_le): Likewise.
+		(_bfd_riscv_relax_align): Once we've handled an R_RISCV_ALIGN,
+		we can't relax anything else, so set the sec->sec_flg0 to true.
+		Besides, we don't need to update the pcgp_relocs table at this
+		stage, so just pass NULL pointer as the pcgp_relocs table for
+		riscv_relax_delete_bytes.
+		(_bfd_riscv_relax_section): Use only one pass for all target
+		relaxations.
+		(_bfd_riscv_relax_delete): Likewise, we don't need to update
+		the pcgp_relocs table at this stage, and don't need to set
+		the `again' since restart_relax mechanism is abandoned.
+		(bfd_elfNN_riscv_restart_relax_sections): Removed.
+		(_bfd_riscv_relax_section): Updated.
+		* elfxx-riscv.h (bfd_elf32_riscv_restart_relax_sections): Removed.
+		(bfd_elf64_riscv_restart_relax_sections): Likewise.
+	ld/
+		* emultempl/riscvelf.em: Revert restart_relax changes and set
+		relax_pass to 3.
+		* testsuite/ld-riscv-elf/align-small-region.d: New testcase.
+		* testsuite/ld-riscv-elf/align-small-region.ld: Likewise.
+		* testsuite/ld-riscv-elf/align-small-region.s: Likewise.
+		* testsuite/ld-riscv-elf/restart-relax.d: Removed sine the
+		restart_relax mechanism is abandoned.
+		* testsuite/ld-riscv-elf/restart-relax.s: Likewise.
+		* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
+
+2021-10-22  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: fix remote-sim.c build
+	Commit 183be222907a ("gdb, gdbserver: make target_waitstatus safe")
+	broke the remote-sim.c build.  In fact, it does some wrong changes,
+	result of a bad sed invocation.
+
+	Fix it by adjusting the code to the new target_waitstatus API.
+
+	Change-Id: I3236ff7ef7681fc29215f68be210ff4263760e91
+
+2021-10-22  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-21  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb, gdbserver: make target_waitstatus safe
+	I stumbled on a bug caused by the fact that a code path read
+	target_waitstatus::value::sig (expecting it to contain a gdb_signal
+	value) while target_waitstatus::kind was TARGET_WAITKIND_FORKED.  This
+	meant that the active union field was in fact
+	target_waitstatus::value::related_pid, and contained a ptid.  The read
+	signal value was therefore garbage, and that caused GDB to crash soon
+	after.  Or, since that GDB was built with ubsan, this nice error
+	message:
+
+	    /home/simark/src/binutils-gdb/gdb/linux-nat.c:1271:12: runtime error: load of value 2686365, which is not a valid value for type 'gdb_signal'
+
+	Despite being a large-ish change, I think it would be nice to make
+	target_waitstatus safe against that kind of bug.  As already done
+	elsewhere (e.g. dynamic_prop), validate that the type of value read from
+	the union matches what is supposed to be the active field.
+
+	 - Make the kind and value of target_waitstatus private.
+	 - Make the kind initialized to TARGET_WAITKIND_IGNORE on
+	   target_waitstatus construction.  This is what most users appear to do
+	   explicitly.
+	 - Add setters, one for each kind.  Each setter takes as a parameter the
+	   data associated to that kind, if any.  This makes it impossible to
+	   forget to attach the associated data.
+	 - Add getters, one for each associated data type.  Each getter
+	   validates that the data type fetched by the user matches the wait
+	   status kind.
+	 - Change "integer" to "exit_status", "related_pid" to "child_ptid",
+	   just because that's more precise terminology.
+	 - Fix all users.
+
+	That last point is semi-mechanical.  There are a lot of obvious changes,
+	but some less obvious ones.  For example, it's not possible to set the
+	kind at some point and the associated data later, as some users did.
+	But in any case, the intent of the code should not change in this patch.
+
+	This was tested on x86-64 Linux (unix, native-gdbserver and
+	native-extended-gdbserver boards).  It was built-tested on x86-64
+	FreeBSD, NetBSD, MinGW and macOS.  The rest of the changes to native
+	files was done as a best effort.  If I forgot any place to update in
+	these files, it should be easy to fix (unless the change happens to
+	reveal an actual bug).
+
+	Change-Id: I0ae967df1ff6e28de78abbe3ac9b4b2ff4ad03b7
+
+2021-10-21  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdbserver: initialize the members of lwp_info in-class
+	Add a constructor to initialize the waitstatus members.  Initialize the
+	others in the class directly.
+
+	Change-Id: I10f885eb33adfae86e3c97b1e135335b540d7442
+
+2021-10-21  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdbserver: make thread_info non-POD
+	Add a constructor and a destructor.  The constructor takes care of the
+	initialization that happened in add_thread, while the destructor takes
+	care of the freeing that happened in free_one_thread.  This is needed to
+	make target_waitstatus non-POD, as thread_info contains a member of that
+	type.
+
+	Change-Id: I1db321b4de9dd233ede0d5c101950f1d6f1d13b7
+
+2021-10-21  Andrew Pinski  <apinski@marvell.com>
+
+	Fix ARMv8.4 for hw watchpoint and breakpoint
+	Just like my previoius patch for ARMv8.1 and v8.2 (49ecef2a7da2ee9df4),
+	this adds ARMv8.4 debug arch as being compatible for hw watchpoint
+	and breakpoints.
+
+	Refactor code slightly in nat/aarch64-linux-hw-point.c (aarch64_linux_get_debug_reg_capacity)
+	Since the two locations which check the debug arch are the same code currently, it is
+	a good idea to factor it out to a new function and just use that function from
+	aarch64_linux_get_debug_reg_capacity. This is also the first step to support
+	ARMv8.4 debug arch.
+
+2021-10-21  Carl Love  <cel@us.ibm.com>
+
+	Fixes for gdb.mi/mi-break.exp
+	Update the expected pattern for two of the tests.
+
+	Matching pattern \" doesn't work.  Use .*  to match the \* pattern.
+
+2021-10-21  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/tui] Fix breakpoint display functionality
+	In commit 81e6b8eb208 "Make tui-winsource not use breakpoint_chain", a loop
+	body was transformed into a lambda function body:
+	...
+	-      for (bp = breakpoint_chain;
+	-           bp != NULL;
+	-           bp = bp->next)
+	+      iterate_over_breakpoints ([&] (breakpoint *bp) -> bool
+	...
+	and consequently:
+	- a continue was replaced by a return, and
+	- a final return was added.
+
+	Then in commit 240edef62f0 "gdb: remove iterate_over_breakpoints function", we
+	transformed back to a loop body:
+	...
+	-      iterate_over_breakpoints ([&] (breakpoint *bp) -> bool
+	+      for (breakpoint *bp : all_breakpoints ())
+	...
+	but without reverting the changes that introduced the two returns.
+
+	Consequently, breakpoints no longer show up in the tui source window.
+
+	Fix this by reverting the changes that introduced the two returns.
+
+	Build on x86_64-linux, tested with all .exp test-cases that contain
+	tuiterm_env.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28483
+
+2021-10-21  Carl Love  <cel@us.ibm.com>
+
+	Fix test step-and-next-inline.cc
+	The test expect the runto_main to stop at the first line of the function.
+	Depending on the optimization level, gdb may stop in the prolog or after
+	the prolog at the first line.  To ensure the test stops at the first line
+	of main, have it explicitly stop at a break point on the first line of the
+	function.
+
+	On PowerPC, the test passes when compiled with no optimization but fails
+	with all levels of optimization due to gdb stopping in the prolog.
+
+2021-10-21  Tom Tromey  <tromey@adacore.com>
+
+	Fix latent Ada bug when accessing field offsets
+	The "add accessors for field (and call site) location" patch caused a
+	gdb crash when running the internal AdaCore testsuite.  This turned
+	out to be a latent bug in ada-lang.c.
+
+	The immediate cause of the bug is that find_struct_field
+	unconditionally uses TYPE_FIELD_BITPOS.  This causes an assert for a
+	dynamic type.
+
+	This patch fixes the problem by doing two things.  First, it changes
+	find_struct_field to use a dummy value for the field offset in the
+	situation where the offset is not actually needed by the caller.  This
+	works because the offset isn't used in any other way -- only as a
+	result.
+
+	Second, this patch assures that calls to find_struct_field use a
+	resolved type when the offset is needed.  For
+	value_tag_from_contents_and_address, this is done by resolving the
+	type explicitly.  In ada_value_struct_elt, this is done by passing
+	nullptr for the out parameters when they are not needed (the second
+	call in this function already uses a resolved type).
+
+	Note that, while we believe the parent field probably can't occur at a
+	variable offset, the patch still updates this code path, just in case.
+
+	I've updated an existing test case to reproduce the crash.
+	I'm checking this in.
+
+2021-10-21  Alan Modra  <amodra@gmail.com>
+
+	-Waddress warning in ldelf.c
+	ldelf.c: In function 'ldelf_after_open':
+	ldelf.c:1049:43: warning: the comparison will always evaluate as 'true' for the address of 'elf_header' will never be NULL [-Waddress]
+	 1049 |           && elf_tdata (abfd)->elf_header != NULL
+	      |                                           ^~
+	In file included from ldelf.c:37:
+	../bfd/elf-bfd.h:1957:21: note: 'elf_header' declared here
+	 1957 |   Elf_Internal_Ehdr elf_header[1];      /* Actual data, but ref like ptr */
+
+		* ldelf.c (ldelf_after_open): Remove useless elf_header test.
+
+2021-10-21  Alan Modra  <amodra@gmail.com>
+
+	Avoid -Waddress warnings in readelf
+	Mainline gcc:
+	readelf.c: In function 'find_section':
+	readelf.c:349:8: error: the comparison will always evaluate as 'true' for the pointer operand in 'filedata->section_headers + (sizetype)((long unsigned int)i * 80)' must not be NULL [-Werror=address]
+	  349 |   ((X) != NULL                                                          \
+	      |        ^~
+	readelf.c:761:9: note: in expansion of macro 'SECTION_NAME_VALID'
+	  761 |     if (SECTION_NAME_VALID (filedata->section_headers + i)
+	      |         ^~~~~~~~~~~~~~~~~~
+
+	This will likely be fixed in gcc, but inline functions are nicer than
+	macros.
+
+		* readelf.c (SECTION_NAME, SECTION_NAME_VALID),
+		(SECTION_NAME_PRINT, VALID_SYMBOL_NAME, VALID_DYNAMIC_NAME),
+		(GET_DYNAMIC_NAME): Delete.  Replace with..
+		(section_name, section_name_valid, section_name_print),
+		(valid_symbol_name, valid_dynamic_name, get_dynamic_name): ..these
+		new inline functions.  Update use throughout file.
+
+2021-10-21  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-20  Alan Modra  <amodra@gmail.com>
+
+	PR28417, std::string no longer allows accepting nullptr_t
+		PR 28417
+		* incremental.cc (Sized_relobj_incr::do_section_name): Avoid
+		std:string undefined behaviour.
+		* options.h (Search_directory::Search_directory): Likewise.
+
+2021-10-20  Alan Modra  <amodra@gmail.com>
+
+	Re: PR27625, powerpc64 gold __tls_get_addr calls
+	My previous PR27625 patch had a problem or two.  For one, the error
+	"__tls_get_addr call lacks marker reloc" on processing some calls
+	before hitting a call without markers typically isn't seen.  Instead a
+	gold assertion fails.  Either way it would be a hard error, which
+	triggers on a file contained in libphobos.a when running the gcc
+	testsuite.  A warning isn't even appropriate since the call involved
+	is one built by hand without any of the arg setup relocations that
+	might result in linker optimisation.
+
+	So this patch reverts most of commit 0af4fcc25dd5, instead entirely
+	ignoring the problem of mis-optimising old-style __tls_get_addr calls
+	without marker relocs.  We can't handle them gracefully without
+	another pass over relocations before decisions are made about GOT
+	entries in Scan::global or Scan::local.  That seems too costly, just
+	to link object files from 2009.  What's more, there doesn't seem to be
+	any way to allow the libphobos explicit __tls_get_addr call, but not
+	old TLS sequences without marker relocs.  Examining instructions
+	before the __tls_get_addr call is out of the question: program flow
+	might reach the call via a branch.  Putting an R_PPC64_TLSGD marker
+	with zero sym on the call might be a solution, but current linkers
+	will then merrily optimise away the call!
+
+		PR gold/27625
+		* powerpc.cc (Powerpc_relobj): Delete no_tls_marker_, tls_marker_,
+		and tls_opt_error_ variables and accessors.  Remove all uses.
+
+2021-10-20  Tom Tromey  <tom@tromey.com>
+
+	Use std::string in print_one_catch_syscall
+	This changes print_one_catch_syscall to use std::string, removing a
+	bit of manual memory management.
+
+	Use unique_xmalloc_ptr in breakpoint
+	This changes struct breakpoint to use unique_xmalloc_ptr in a couple
+	of spots, removing a bit of manual memory management.
+
+	Use unique_xmalloc_ptr in bp_location
+	This changes struct bp_location to use a unique_xmalloc_ptr, removing
+	a bit of manual memory management.
+
+	Use unique_xmalloc_ptr in watchpoint
+	This changes struct watchpoint to use unique_xmalloc_ptr in a couple
+	of places, removing a bit of manual memory management.
+
+	Use unique_xmalloc_ptr in exec_catchpoint
+	This changes struct exec_catchpoint to use a unique_xmalloc_ptr,
+	removing a bit of manual memory management.
+
+	Use unique_xmalloc_ptr in solib_catchpoint
+	This changes struct solib_catchpoint to use a unique_xmalloc_ptr,
+	removing a bit of manual memory management.
+
+2021-10-20  Christian Biesinger  <cbiesinger@google.com>
+
+	Make c-exp.y work with Bison 3.8+
+	When using Bison 3.8, we get this error:
+
+	    ../../gdb/c-exp.y:3455:1: error: 'void c_print_token(FILE*, int, YYSTYPE)' defined but not used [-Werror=unused-function]
+
+	That's because bison 3.8 removed YYPRINT support:
+	https://savannah.gnu.org/forum/forum.php?forum_id=10047
+
+	Accordingly, this patch only defines that function for Bison < 3.8.
+
+	Change-Id: I3cbf2f317630bb72810b00f2d9b2c4b99fa812ad
+
+2021-10-20  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-19  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Reimplement gdb.gdb/python-interrupts.exp as unittest
+	The test-case gdb.gdb/python-interrupts.exp:
+	- runs to captured_command_loop
+	- sets a breakpoint at set_active_ext_lang
+	- calls a python command
+	- verifies the command triggers the breakpoint
+	- sends a signal and verifies the result
+
+	The test-case is fragile, because (f.i. with -flto) it cannot be guaranteed
+	that captured_command_loop and set_active_ext_lang are available for setting
+	breakpoints.
+
+	Reimplement the test-case as unittest, using:
+	- execute_command_to_string to capture the output
+	- try/catch to catch the "Error while executing Python code" exception
+	- a new hook selftests::hook_set_active_ext_lang to raise the signal
+
+	Tested on x86_64-linux.
+
+2021-10-19  Tom Tromey  <tromey@adacore.com>
+
+	Check index in type::field
+	This changes gdb to check the index that is passed to type::field.
+	This caught one bug in the Ada code when running the test suite
+	(actually I found the bug first, then realized that the check would
+	have helped), so this patch fixes that as well.
+
+	Regression tested on x86-64 Fedora 34.
+
+2021-10-19  Tom Tromey  <tromey@adacore.com>
+
+	Fix Rust lex selftest when using libiconv
+	The Rust lex selftest fails on our Windows build.  I tracked this down
+	to a use of UTF-32 as a parameter to convert_between_encodings.  Here,
+	iconv_open succeeds, but the actual conversion of a tab character
+	fails with EILSEQ.  I suspect that "UTF-32" is being interpreted as
+	big-endian, as changing the call to use "UTF-32LE" makes it work.
+	This patch implements this fix.
+
+2021-10-19  Tom Tromey  <tromey@adacore.com>
+
+	Fix format_pieces selftest on Windows
+	The format_pieces selftest currently fails on Windows hosts.
+
+	The selftest doesn't handle the "%ll" -> "%I64" rewrite that the
+	formatter may perform, but also gdbsupport was missing a configure
+	check for PRINTF_HAS_LONG_LONG.  This patch fixes both issues.
+
+2021-10-19  Tom Tromey  <tromey@adacore.com>
+
+	Fix bug in dynamic type resolution
+	A customer-reported problem led us to a bug in dynamic type
+	resolution.  resolve_dynamic_struct will recursively call
+	resolve_dynamic_type_internal, passing it the sub-object for the
+	particular field being resolved.  While it offsets the address here,
+	it does not also offset the "valaddr" -- the array of bytes describing
+	the memory.
+
+	This patch fixes the bug, by offsetting both.  A test case is included
+	that can be used to reproduce the bug.
+
+2021-10-19  Tom Tromey  <tromey@adacore.com>
+
+	Always use std::function for self-tests
+	Now that there is a register_test variant that accepts std::function,
+	it seems to me that the 'selftest' struct and accompanying code is
+	obsolete -- simply always using std::function is simpler.  This patch
+	implements this idea.
+
+2021-10-19  Daniel Black  <daniel@mariadb.org>
+
+	Fix PR gdb/17917 Lookup build-id in remote binaries
+	GDB doesn't support loading debug files using build-id from remote
+	target filesystems.
+
+	This is the case when gdbserver attached to a process and a gdb target
+	remote occurs over tcp.
+
+	With this change we make build-id lookups possible:
+
+	    (gdb) show debug-file-directory
+	    The directory where separate debug symbols are searched for is "/usr/local/lib/debug".
+	    (gdb) set debug-file-directory /usr/lib/debug
+	    (gdb) show sysroot
+	    The current system root is "target:".
+	    (gdb) target extended-remote :46615
+	    Remote debugging using :46615
+	    warning: Can not parse XML target description; XML support was disabled at compile time
+	    Reading /usr/sbin/mariadbd from remote target...
+	    warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
+	    Reading /usr/sbin/mariadbd from remote target...
+	    Reading symbols from target:/usr/sbin/mariadbd...
+	    Reading /usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
+	    Reading /usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
+	    Reading symbols from target:/usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug...
+	    Reading /lib/x86_64-linux-gnu/libpcre2-8.so.0 from remote target...
+	    ...
+
+	Before this change, the lookups would have been (GNU gdb (GDB) Fedora 10.2-3.fc34):
+
+	    (gdb) target extended-remote :46615
+	    Remote debugging using :46615
+	    Reading /usr/sbin/mariadbd from remote target...
+	    warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
+	    Reading /usr/sbin/mariadbd from remote target...
+	    Reading symbols from target:/usr/sbin/mariadbd...
+	    Reading /usr/sbin/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
+	    Reading /usr/sbin/.debug/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
+	    Reading /usr/lib/debug//usr/sbin/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
+	    Reading /usr/lib/debug/usr/sbin//0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
+	    Reading target:/usr/lib/debug/usr/sbin//0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
+	    Missing separate debuginfo for target:/usr/sbin/mariadbd
+	    Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug
+	    (No debugging symbols found in target:/usr/sbin/mariadbd)
+
+	Observe it didn't look for
+	/usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug
+	on the remote target (where it is) and expected them to be installed
+	locally.
+
+	As a minor optimization, this also changes the build-id lookup such that
+	if sysroot is empty, no second lookup of the same location is performed.
+
+	Change-Id: I5181696d271c325a25a0805a8defb8ab7f9b3f55
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17917
+
+2021-10-19  Nick Clifton  <nickc@redhat.com>
+
+	Fix a potential illegal memory access when testing for a special LTO symbol name.
+	bfd	* linker.c (_bfd_generic_link_add_one_symbol): Test for a NULL
+		name before checking to see if the symbol is __gnu_lto_slim.
+		* archive.c (_bfd_compute_and_write_armap): Likewise.
+	binutils
+		* nm.c (filter_symbols): Test for a NULL name before checking to
+		see if the symbol is __gnu_lto_slim.
+		* objcopy.c (filter_symbols): Likewise.
+
+2021-10-19  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-18  Weimin Pan  <weimin.pan@oracle.com>
+
+	CTF: incorrect underlying type setting for enumeration types
+	A bug was filed against the incorrect underlying type setting for
+	an enumeration type, which was caused by a copy and paste error.
+	This patch fixes the problem by setting it by calling objfile_int_type,
+	which was originally dwarf2_per_objfile::int_type, with ctf_type_size bits.
+	Also add error checking on ctf_func_type_info call.
+
+2021-10-18  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-17  Alan Modra  <amodra@gmail.com>
+
+	PR28459, readelf issues bogus warning
+	I'd missed the fact that the .debug_rnglists dump doesn't exactly
+	display the contents of the section.  Instead readelf rummages through
+	.debug_info looking for DW_AT_ranges entries, then displays the
+	entries in .debug_rnglists pointed at, sorted.  A simpler dump of the
+	actual section contents might be more useful and robust, but it was
+	likely done that way to detect overlap and holes.
+
+	Anyway, the headers in .debug_rnglists besides the first are ignored,
+	and limiting to the unit length of the first header fails if there is
+	more than one unit.
+
+		PR 28459
+		* dwarf.c (display_debug_ranges): Don't constrain data to length
+		in header.
+
+2021-10-17  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-16  H.J. Lu  <hjl.tools@gmail.com>
+
+	ld: Adjust pr28158.rd for glibc 2.34
+	Adjust pr28158.rd for glibc 2.34:
+
+	$ readelf -W --dyn-syms tmpdir/pr28158
+
+	Symbol table '.dynsym' contains 4 entries:
+	   Num:    Value          Size Type    Bind   Vis      Ndx Name
+	     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
+	     1: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.34 (2)
+	     2: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
+	     3: 000000000040401c     4 OBJECT  GLOBAL DEFAULT   23 foo@VERS_2.0 (3)
+	$
+
+	vs older glibc:
+
+	$ readelf -W --dyn-syms tmpdir/pr28158
+
+	Symbol table '.dynsym' contains 4 entries:
+	   Num:    Value          Size Type    Bind   Vis      Ndx Name
+	     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
+	     1: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.2.5 (3)
+	     2: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
+	     3: 000000000040401c     4 OBJECT  GLOBAL DEFAULT   23 foo@VERS_2.0 (2)
+
+	$
+
+		* testsuite/ld-elf/pr28158.rd: Adjusted for glibc 2.34.
+
+2021-10-16  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-15  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-14  Carl Love  <cel@us.ibm.com>
+
+	Powerpc: Add support for openat and fstatat syscalls
+	[gdb] update ppc-linux-tdep.c
+
+	Add argument to ppc_canonicalize_syscall for the wordsize.
+	Add syscall entries for the openat and fstatat system calls.
+
+2021-10-14  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Add .debug_loc support in dwarf assembler
+	Add .debug_loc support in the dwarf assembler, and use it in new test-case
+	gdb.dwarf2/loc-sec-offset.exp (which is based on
+	gdb.dwarf2/loclists-sec-offset.exp).
+
+	Tested on x86_64-linux.
+
+2021-10-14  Alan Modra  <amodra@gmail.com>
+
+	[GOLD] Re: PowerPC64: Don't pretend to support multi-toc
+	We can't get at section->address() until everything is laid out, so
+	trying to generalise the offset calculation rather than using a value
+	of 0x8000 (the old object->toc_base_offset()) was bound to fail.
+	got->g_o_t() is a little better than a hard-coded 0x8000.
+
+		* powerpc.cc (Target_powerpc::Scan::local, global): Don't use
+		toc_pointer() here.
+
+2021-10-14  Alan Modra  <amodra@gmail.com>
+
+	[GOLD] Two GOT sections for PowerPC64
+	Split .got into two piece, one with the header and entries for small
+	model got entries, the other with entries for medium/large model got
+	entries.  The idea is to better support mixed pcrel/non-pcrel code
+	where non-pcrel small-model .toc entries need to be within 32k of the
+	toc pointer.
+
+		* target.h (Target::tls_offset_for_local): Add got param.
+		(Target::tls_offset_for_global): Likewise.
+		(Target::do_tls_offset_for_local, do_tls_offset_for_global): Likewise.
+		* output.h (Output_data_got::Got_entry::write): Add got param.
+		* output.cc (Output_data_got::Got_entry::write): Likewise, pass to
+		tls_offset_for_local/global calls.
+		(Output_data_got::do_write): Adjust to suit.
+		* s390.cc (Target_s390::do_tls_offset_for_local): Likewise.
+		(Target_s390::do_tls_offset_for_global): Likewise.
+		* powerpc.cc (enum Got_type): Extend with small types, move from
+		class Target_powerpc.
+		(Target_powerpc::biggot_): New.
+		(Traget_powerpc::do_tls_offset_for_local, do_tls_offset_for_global,
+		got_size, got_section, got_base_offset): Handle biggot_.
+		(Target_powerpc::do_define_standard_symbols): Adjust.
+		(Target_powerpc::make_plt_section, do_finalize_sections): Likewise.
+		(Output_data_got_powerpc::Output_data_got_powerpc): Only make
+		64-bit header for small got section.
+		(Output_data_got_powerpc::g_o_t): Only return a result for small
+		got section.
+		(Output_data_got_powerpc::write): Only write small got section
+		header.
+		(Target_powerpc::Scan::local, global): Select small/big Got_type
+		and section to suit reloc.
+		(Target_powerpc::Relocate::relocate): Similarly.
+		(Sort_toc_sections): Rewrite.
+
+2021-10-14  Alan Modra  <amodra@gmail.com>
+
+	[GOLD] PowerPC64: Don't pretend to support multi-toc
+	Code in powerpc.cc is pretending to support a per-object toc pointer
+	value, but powerpc gold has no real support for multi-toc.  This patch
+	removes the pretense, tidying quite a lot in preparation for a
+	followup patch.  If multi-toc is ever to be supported, don't revert
+	this patch but start by adding object parameter to toc_pointer() and
+	an object to Branch_stub_key.
+
+		* powerpc.cc (Powerpc_relobj::toc_base_offset): Delete.
+		(Target_powerpc::toc_pointer): New function.  Use throughout.
+		(Target_powerpc::got_base_offset): New function.  Use throughout..
+		(Output_data_got_powerpc::got_base_offset): ..in place of
+		this.  Delete.
+		(Output_data_got_powerpc::Output_data_got_powerpc): Init
+		header_index_ to -1u for 64-bit, and make header here.
+		(Output_data_got_powerpc::set_final_data_size, reserve_ent): Don't
+		make 64-bit header here.
+		(Output_data_got_powerpc::g_o_t): Return toc pointer offset in
+		section for 64-bit.  Use throughout.
+		(Stub_table): Remove toc_base_off_ from Branch_stub_key, and
+		object param on add_long_branch_entry and find_long_branch_entry.
+		Adjust all uses.
+
+2021-10-14  Alan Modra  <amodra@gmail.com>
+
+	Re: s12z/disassembler: call memory_error_func when appropriate
+	Adjust for commit ba7c18a48457.
+
+		* testsuite/gas/s12z/truncated.d: Update expected output.
+
+2021-10-14  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-13  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/exp] Improve <error reading variable> message
+	When printing a variable x in a subroutine foo:
+	...
+	subroutine foo (x)
+	  integer(4) :: x (*)
+	  x(3) = 1
+	end subroutine foo
+	...
+	where x is an array with unknown bounds, we get:
+	...
+	$ gdb -q -batch outputs/gdb.fortran/array-no-bounds/array-no-bounds \
+	  -ex "break foo" \
+	  -ex run \
+	  -ex "print x"
+	Breakpoint 1 at 0x4005cf: file array-no-bounds.f90, line 18.
+
+	Breakpoint 1, foo (x=...) at array-no-bounds.f90:18
+	18        x(3) = 1
+	$1 = <error reading variable>
+	...
+
+	Improve the error message by printing the details of the error, such that we
+	have instead:
+	...
+	$1 = <error reading variable: failed to get range bounds>
+	...
+
+	This is a change in gdb/valprint.c, and grepping through the sources reveals
+	that this is a common pattern.
+
+	Tested on x86_64-linux.
+
+2021-10-13  Carl Love  <cel@us.ibm.com>
+
+	PPC fix for stfiwx instruction (and additional stores with primary opcode of 31)
+	[gdb] Fix address being recorded in rs6000-tdep.c, ppc_process_record_op31.
+
+	The GDB record function was recording the variable addr that was passed in
+	rather than the calculated effective address (ea) by the
+	ppc_process_record_op31 function.
+
+2021-10-13  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: improve error reporting from the disassembler
+	If the libopcodes disassembler returns a negative value then this
+	indicates that the disassembly failed for some reason.  In disas.c, in
+	the function gdb_disassembler::print_insn we can see how this is
+	handled; when we get a negative value back, we call the memory_error
+	function, which throws an exception.
+
+	The problem here is that the address used in the memory_error call is
+	gdb_disassembler::m_err_memaddr, which is set in
+	gdb_disassembler::dis_asm_memory_error, which is called from within
+	the libopcodes disassembler through the
+	disassembler_info::memory_error_func callback.
+
+	However, for this to work correctly, every time the libopcodes
+	disassembler returns a negative value, the libopcodes disassembler
+	must have first called the memory_error_func callback.
+
+	My first plan was to make m_err_memaddr a gdb::optional, and assert
+	that it always had a value prior to calling memory_error, however, a
+	quick look in opcodes/*-dis.c shows that there _are_ cases where a
+	negative value is returned without first calling the memory_error_func
+	callback, for example in arc-dis.c and cris-dis.c.
+
+	Now, I think that a good argument can be made that these disassemblers
+	must therefore be broken, except for the case where we can't read
+	memory, we should always be able to disassemble the memory contents to
+	_something_, even if it's just '.word 0x....'.  However, I certainly
+	don't plan to go and fix all of the disassemblers.
+
+	What I do propose to do then, is make m_err_memaddr a gdb::optional,
+	but now, instead of always calling memory_error, I add a new path
+	which just calls error complaining about an unknown error.  This new
+	path is only used if m_err_memaddr doesn't have a value (indicating
+	that the memory_error_func callback was not called).
+
+	To test this I just augmented one of the disassemblers to always
+	return -1, before this patch I see this:
+
+	  Dump of assembler code for function main:
+	     0x000101aa <+0>:	Cannot access memory at address 0x0
+
+	And after this commit I now see:
+
+	  Dump of assembler code for function main:
+	     0x000101aa <+0>:	unknown disassembler error (error = -1)
+
+	This doesn't really help much, but that's because there's no way to
+	report non memory errors out of the disasembler, because, it was not
+	expected that the disassembler would ever report non memory errors.
+
+2021-10-13  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.fortran/call-no-debug.exp with native-gdbserver
+	When running test-case gdb.fortran/call-no-debug.exp with target board
+	native-gdbserver, I run into:
+	...
+	(gdb) PASS: gdb.fortran/call-no-debug.exp: print string_func_ (&'abcdefg', 3)
+	call (integer) string_func_ (&'abcdefg', 3)^M
+	$2 = 0^M
+	(gdb) FAIL: gdb.fortran/call-no-debug.exp: call (integer) string_func_ (&'abcdefg', 3)
+	...
+
+	The problem is that gdb_test is used to match inferior output.
+
+	Fix this by using gdb_test_stdio.
+
+	Tested on x86_64-linux.
+
+2021-10-13  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Require use_gdb_stub == 0 where appropriate
+	When running with target board native-gdbserver, we run into a number of FAILs
+	due to use of the start command (and similar), which is not supported when
+	use_gdb_stub == 1.
+
+	Fix this by:
+	- requiring use_gdb_stub == 0 for the entire test-case, or
+	- guarding some tests in the test-case with use_gdb_stub == 0.
+
+	Tested on x86_64-linux.
+
+2021-10-13  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix test name in gdb.python/python.exp
+	When running test-case gdb.python/python.exp, we have:
+	...
+	PASS: gdb.python/python.exp: starti via gdb.execute, not from tty
+	PASS: gdb.python/python.exp: starti via interactive input
+	...
+
+	The two tests are instances of the same test, with different values for
+	starti command argument from_tty, so it's strange that the test names are so
+	different.
+
+	This is due to using a gdb_test nested in a gdb_test_multiple, with the inner
+	one using a different test name than the outer one.  [ That could still make
+	sense if both produced passes, but that's not the case here. ]
+
+	Fix this by using $gdb_test_name, such that we have:
+	...
+	PASS: gdb.python/python.exp: starti via gdb.execute, not from tty
+	PASS: gdb.python/python.exp: starti via gdb.execute, from tty
+	...
+
+	Also make this more readable by using variables.
+
+	Tested on x86_64-linux.
+
+2021-10-13  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.base/batch-exit-status.exp with native-gdbserver
+	When running test-case gdb.base/batch-exit-status.exp with target board
+	native-gdbserver, I run into (added missing double quotes for clarity):
+	...
+	builtin_spawn $build/gdb/testsuite/../../gdb/gdb -nw -nx \
+	  -data-directory $build/gdb/testsuite/../data-directory \
+	  -iex "set height 0" -iex "set width 0" \
+	  -ex "set auto-connect-native-target off" \
+	  -iex "set sysroot" -batch ""^M
+	: No such file or directory.^M
+	PASS: gdb.base/batch-exit-status.exp: 1x: \
+	  No such file or directory: [lindex $result 2] == 0
+	FAIL: gdb.base/batch-exit-status.exp: 1x: \
+	  No such file or directory: [lindex $result 3] == $expect_status
+	...
+
+	As in commit a02a90c114c "[gdb/testsuite] Set sysroot earlier in
+	local-board.exp", the problem is the use of -ex for
+	"set auto-connect-native-target off", which makes that the last command to
+	be executed, and consequently determines the return status.
+
+	Fix this by using -iex instead.
+
+	Tested on x86_64-linux.
+
+2021-10-13  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Remove quit in gdb.arch/i386-mpx.exp
+	When running test-case gdb.arch/i386-mpx.exp with target board
+	native-gdbserver, I run into:
+	...
+	(gdb) PASS: gdb.arch/i386-mpx.exp: verify size for bnd0
+	Remote debugging from host ::1, port 42328^M
+	quit^M
+	A debugging session is active.^M
+	^M
+	        Inferior 1 [process 19679] will be killed.^M
+	^M
+	Quit anyway? (y or n) monitor exit^M
+	Please answer y or n.^M
+	A debugging session is active.^M
+	^M
+	        Inferior 1 [process 19679] will be killed.^M
+	^M
+	Quit anyway? (y or n) WARNING: Timed out waiting for EOF in server after monitor exit
+	...
+
+	The problem is that the test-case sends a quit at the end (without verifying
+	the result of this in any way):
+	...
+	send_gdb "quit\n"
+	...
+
+	Fix this by removing the quit.
+
+	Tested on x86_64-linux.
+
+2021-10-13  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-12  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-11  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>
+
+	[ARM] Add support for M-profile MVE extension
+	This patch adds support for the M-profile MVE extension, which includes the
+	following:
+
+	- New M-profile XML feature m-profile-mve
+	- MVE vector predication status and control register (VPR)
+	- p0 pseudo register (contained in the VPR)
+	- q0 ~ q7 pseudo vector registers
+	- New feature bits
+	- Documentation update
+
+	Pseudo register p0 is the least significant bits of vpr and can be accessed
+	as $p0 or displayed through $vpr.  For more information about the register
+	layout, please refer to [1].
+
+	The q0 ~ q7 registers map back to the d0 ~ d15 registers, two d registers
+	per q register.
+
+	The register dump looks like this:
+
+	(gdb) info reg all
+	r0             0x0                 0
+	r1             0x0                 0
+	r2             0x0                 0
+	r3             0x0                 0
+	r4             0x0                 0
+	r5             0x0                 0
+	r6             0x0                 0
+	r7             0x0                 0
+	r8             0x0                 0
+	r9             0x0                 0
+	r10            0x0                 0
+	r11            0x0                 0
+	r12            0x0                 0
+	sp             0x0                 0x0 <__Vectors>
+	lr             0xffffffff          -1
+	pc             0xd0c               0xd0c <Reset_Handler>
+	xpsr           0x1000000           16777216
+	d0             0                   (raw 0x0000000000000000)
+	d1             0                   (raw 0x0000000000000000)
+	d2             0                   (raw 0x0000000000000000)
+	d3             0                   (raw 0x0000000000000000)
+	d4             0                   (raw 0x0000000000000000)
+	d5             0                   (raw 0x0000000000000000)
+	d6             0                   (raw 0x0000000000000000)
+	d7             0                   (raw 0x0000000000000000)
+	d8             0                   (raw 0x0000000000000000)
+	d9             0                   (raw 0x0000000000000000)
+	d10            0                   (raw 0x0000000000000000)
+	d11            0                   (raw 0x0000000000000000)
+	d12            0                   (raw 0x0000000000000000)
+	d13            0                   (raw 0x0000000000000000)
+	d14            0                   (raw 0x0000000000000000)
+	d15            0                   (raw 0x0000000000000000)
+	fpscr          0x0                 0
+	vpr            0x0                 [ P0=0 MASK01=0 MASK23=0 ]
+	s0             0                   (raw 0x00000000)
+	s1             0                   (raw 0x00000000)
+	s2             0                   (raw 0x00000000)
+	s3             0                   (raw 0x00000000)
+	s4             0                   (raw 0x00000000)
+	s5             0                   (raw 0x00000000)
+	s6             0                   (raw 0x00000000)
+	s7             0                   (raw 0x00000000)
+	s8             0                   (raw 0x00000000)
+	s9             0                   (raw 0x00000000)
+	s10            0                   (raw 0x00000000)
+	s11            0                   (raw 0x00000000)
+	s12            0                   (raw 0x00000000)
+	s13            0                   (raw 0x00000000)
+	s14            0                   (raw 0x00000000)
+	s15            0                   (raw 0x00000000)
+	s16            0                   (raw 0x00000000)
+	s17            0                   (raw 0x00000000)
+	s18            0                   (raw 0x00000000)
+	s19            0                   (raw 0x00000000)
+	s20            0                   (raw 0x00000000)
+	s21            0                   (raw 0x00000000)
+	s22            0                   (raw 0x00000000)
+	s23            0                   (raw 0x00000000)
+	s24            0                   (raw 0x00000000)
+	s25            0                   (raw 0x00000000)
+	s26            0                   (raw 0x00000000)
+	s27            0                   (raw 0x00000000)
+	s28            0                   (raw 0x00000000)
+	s29            0                   (raw 0x00000000)
+	s30            0                   (raw 0x00000000)
+	s31            0                   (raw 0x00000000)
+	q0             {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
+	q1             {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
+	q2             {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
+	q3             {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
+	q4             {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
+	q5             {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
+	q6             {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
+	q7             {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
+	p0             0x0                 0
+
+	Built and regtested with a simulator.
+
+	[1] https://developer.arm.com/documentation/ddi0553/bn
+
+	Co-Authored-By: Luis Machado <luis.machado@linaro.org>
+
+2021-10-11  Luis Machado  <luis.machado@linaro.org>
+
+	[ARM] Refactor pseudo register numbering
+	The pseudo register handling for ARM uses some hardcoded constants to
+	determine types and names.  In preparation to the upcoming MVE support
+	patch (that will add another pseudo register), this patch refactors and
+	reorganizes things in order to simplify handling of future pseudo registers.
+
+	We keep track of the first pseudo register number in a group and the number of
+	pseudo registers in that group.
+
+	Right now we only have the S and Q pseudo registers.
+
+2021-10-11  Luis Machado  <luis.machado@linaro.org>
+
+	[ARM] Small refactoring of arm gdbarch initialization
+	This is in preparation to MVE support, where we will define another
+	pseudo register. We need to define the pseudo register numbers *after*
+	accounting for all the registers in the XML description, so move
+	the call to tdesc_use_registers up.
+
+	If we don't do it, GDB's register count won't consider registers contained
+	in the XML but ignored by GDB, throwing the register numbering off.
+
+2021-10-11  Luis Machado  <luis.machado@linaro.org>
+
+	[ARM] Refactor some constants
+	In preparation for the MVE extension patch, this one refactors some of
+	the register-related constants we have for ARM.
+
+	Basically I'm separating counting constants from numbering constants.
+
+	For example, ARM_A1_REGNUM is a numbering constant, whereas ARM_NUM_ARG_REGS
+	is a counting constant.
+
+2021-10-11  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix FAIL in gdb.mi/mi-var-child-f.exp
+	When running test-case gdb.mi/mi-var-child-f.exp on openSUSE Tumbleweed
+	(with glibc 2.34) I run into:
+	...
+	(gdb) ^M
+	PASS: gdb.mi/mi-var-child-f.exp: mi runto prog_array
+	Expecting: ^(-var-create array \* array[^M
+	]+)?(\^done,name="array",numchild="[0-9]+",value=".*",type=.*,has_more="0"[^M
+	]+[(]gdb[)] ^M
+	[ ]*)
+	-var-create array * array^M
+	&"Attempt to use a type name as an expression.\n"^M
+	^error,msg="-var-create: unable to create variable object"^M
+	(gdb) ^M
+	FAIL: gdb.mi/mi-var-child-f.exp: create local variable array (unexpected output)
+	...
+
+	The problem is that the name array is used both:
+	- as the name for a local variable
+	- as the name of a type in glibc, in file malloc/dynarray-skeleton.c, as included
+	  by nss/nss_files/files-hosts.c.
+
+	Fix this by ignoring the shared lib symbols.
+
+	Likewise in a couple of other fortran tests.
+
+	Tested on x86_64-linux.
+
+2021-10-11  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	z80/disassembler: call memory_error_func when appropriate
+	If a call to the read_memory_func fails then we should call the
+	memory_error_func to notify the user of the disassembler of the
+	address that was a problem.
+
+	Without this GDB will report all memory errors as being at address
+	0x0.
+
+	opcodes/ChangeLog:
+
+		* z80-dis.c (fetch_data): Call memory_error_func if the
+		read_memory_func call fails.
+
+2021-10-11  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	s12z/disassembler: call memory_error_func when appropriate
+	If a call to the read_memory_func fails then we should call the
+	memory_error_func to notify the user of the disassembler of the
+	address that was a problem.
+
+	Without this GDB will report all memory errors as being at address
+	0x0.
+
+	opcodes/ChangeLog:
+
+		* s12z-disc.c (abstract_read_memory): Call memory_error_func if
+		the read_memory_func call fails.
+
+2021-10-11  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix double debug info in gdb.dwarf2/dw2-ref-missing-frame.exp
+	A mistake slipped in in commit a5ea23036d8 "[gdb/testsuite] Use function_range
+	in gdb.dwarf2/dw2-ref-missing-frame.exp".
+
+	Before the commit the main file was compiled with debug info, and the two
+	others not:
+	...
+	if {[prepare_for_testing_full "failed to prepare" \
+	        [list $testfile {} $srcfile {} $srcfuncfile {} \
+	             $srcmainfile debug]]} {
+	...
+
+	After the commit, all were compiled with debug info, and consequently, there
+	are two versions of debug info for $srcfuncfile.  This shows up as a FAIL when
+	running the test-case with target boards readnow and cc-with-debug-names.
+
+	Fix this by using prepare_for_testing_full, as before.
+
+	Tested on x86_64-linux.
+
+	Fixes: a5ea23036d8 ("[gdb/testsuite] Use function_range in
+	       gdb.dwarf2/dw2-ref-missing-frame.exp")
+
+2021-10-11  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Use require for ensure_gdb_index
+	Replace:
+	...
+	if { [ensure_gdb_index $binfile] == -1 } {
+	    return -1
+	}
+	...
+	with:
+	...
+	require {ensure_gdb_index $binfile} != -1
+	...
+	and consequently, add a missing UNTESTED message.
+
+	Tested on x86_64-linux, both with native and target board readnow.
+
+2021-10-11  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Handle readnow in ensure_gdb_index
+	When running test-case gdb.base/with-mf.exp with target board readnow, I run
+	into:
+	...
+	FAIL: gdb.base/with-mf.exp: check if index present
+	...
+	This is since commit 6010fb0c49e "[gdb/testsuite] Fix full buffer in
+	gdb.rust/dwindex.exp".
+
+	Before that commit, the proc ensure_gdb_index would treat the line:
+	...
+	.gdb_index: faked for "readnow"^M
+	...
+	as proof that an index is already present (which is incorrect).
+
+	Now, instead it generates aforementioned FAIL and continues to generate an
+	index.
+
+	Fix this by explicitly handling the readnow case in proc ensure_gdb_index,
+	such that we bail out instead.
+
+	Tested on x86_64-linux.
+
+2021-10-11  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.dwarf2/gdb-add-index-symlink.exp
+	The test-case gdb.dwarf2/gdb-add-index-symlink.exp interpretes a failure to
+	add an index as a failure to add an index for a symlink:
+	...
+	if { [ensure_gdb_index $symlink] == -1 } {
+	    fail "Unable to call gdb-add-index with a symlink to a symfile"
+	    return -1
+	}
+	...
+
+	However, it's possible that the gdb-add-index also fails with a regular
+	file.  Add a check for that situation.
+
+	Tested on x86_64-linux.
+
+2021-10-11  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Add proc require in lib/gdb.exp
+	Add a new proc require in lib/gdb.exp, and use it to shorten:
+	...
+	if { [gdb_skip_xml_test] } {
+	    # Valgrind gdbserver requires gdb with xml support.
+	    untested "missing xml support"
+	    return 0
+	}
+	...
+	into:
+	...
+	require gdb_skip_xml_test 0
+	...
+
+	Tested on x86_64-linux, both with and without a trigger patch that forces
+	gdb_skip_xml_test to return 1.
+
+2021-10-11  Michael Forney  <mforney@mforney.org>
+
+	bfd: Remove use of void pointer arithmetic
+	This is not valid in ISO C. Instead, use a pointer to bfd_byte.
+
+		* peicode.h (pe_bfd_object_p): Remove use of void pointer
+		arithmetic.
+
+2021-10-11  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-10  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-09  Tom de Vries  <tdevries@suse.de>
+
+	[gdb] Make execute_command_to_string return string on throw
+	The pattern for using execute_command_to_string is:
+	...
+	  std::string output;
+	  output = execute_fn_to_string (fn, term_out);
+	...
+
+	This results in a problem when using it in a try/catch:
+	...
+	  try
+	    {
+	      output = execute_fn_to_string (fn, term_out)
+	    }
+	  catch (const gdb_exception &e)
+	    {
+	      /* Use output.  */
+	    }
+	...
+
+	If an expection was thrown during execute_fn_to_string, then the output
+	remains unassigned, while it could be worthwhile to known what output was
+	generated by gdb before the expection was thrown.
+
+	Fix this by returning the string using a parameter instead:
+	...
+	  execute_fn_to_string (output, fn, term_out)
+	...
+
+	Also add a variant without string parameter, to support places where the
+	function is used while ignoring the result:
+	...
+	  execute_fn_to_string (fn, term_out)
+	...
+
+	Tested on x86_64-linux.
+
+2021-10-09  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Add check-readmore
+	Consider the gdb output:
+	...
+	27        return SYSCALL_CANCEL (nanosleep, requested_time, remaining);^M
+	(gdb) ^M
+	Thread 2 "run-attach-whil" stopped.^M
+	...
+
+	When trying to match the gdb prompt using gdb_test which uses '$gdb_prompt $',
+	it may pass or fail.
+
+	This sort of thing needs to be fixed (see commit b0e2f96b56b), but there's
+	currently no way to reliably find this type of FAILs.
+
+	We have check-read1, but that one actually make the test pass reliably.
+
+	We need something like the opposite of check-read1: something that makes
+	expect read a bit slower, or more exhaustively.
+
+	Add a new test target check-readmore that implements this.
+
+	There are two methods of implementing this in read1.c:
+	- the first method waits a bit before doing a read
+	- the second method does a read and then decides whether to
+	  return or to wait a bit and do another read, and so on.
+
+	The second method is potentially faster, has less risc of timeout and could
+	potentially detect more problems.  The first method has a simpler
+	implementation.
+
+	The second method is enabled by default.  The default waiting period is 10
+	miliseconds.
+
+	The first method can be enabled using:
+	...
+	$ export READMORE_METHOD=1
+	...
+	and the waiting period can be specified in miliseconds using:
+	...
+	$ export READMORE_SLEEP=9
+	...
+
+	Also a log file can be specified using:
+	...
+	$ export READMORE_LOG=$(pwd -P)/LOG
+	...
+
+	Tested on x86_64-linux.
+
+	Testing with check-readmore showed these regressions:
+	...
+	FAIL: gdb.base/bp-cmds-continue-ctrl-c.exp: run: stop with control-c (continue)
+	FAIL: gdb.base/bp-cmds-continue-ctrl-c.exp: attach: stop with control-c (continue)
+	...
+
+	I have not been able to find a problem in the test-case, and I think it's the
+	nature of both the test-case and readmore that makes it run longer.  Make
+	these pass by increasing the alarm timeout from 60 to 120 seconds.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27957
+
+2021-10-09  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix fortran module tests with stressed cpu
+	When running these test-cases:
+	- gdb.fortran/info-modules.exp
+	- gdb.fortran/module.exp
+	- gdb.mi/mi-fortran-modules.exp
+	in conjunction with:
+	...
+	$ stress -c $(($(cat /proc/cpuinfo | grep -c "^processor") + 1))
+	...
+	I run into timeouts.
+
+	Fix this by using:
+	- "set auto-solib-add off" to avoid symbols of shared libs
+	  (which doesn't work for libc, now that libpthread_name_p has been
+	  updated to  match libc)
+	- "nosharedlibrary" to avoid symbols of libc
+
+	Tested on x86_64-linux.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28133
+
+2021-10-09  Guillermo E. Martinez  <guillermo.e.martinez@oracle.com>
+
+	PR28415, invalid read in xtensa_read_table_entries
+		PR 28415
+		PR 28416
+		* elf32-xtensa.c (xtensa_read_table_entries): Handle error
+		return from retrieve_contents.
+
+2021-10-09  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-08  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.base/info-types-c++.exp with stressed cpu
+	When running test-case gdb.base/info-types-c++.exp in conjunction with:
+	...
+	$ stress -c $(($(cat /proc/cpuinfo | grep -c "^processor") + 1))
+	...
+	we get:
+	...
+	FAIL: gdb.base/info-types-c++.exp: info types (timeout)
+	...
+
+	Fix this by setting auto-solib-add to off.
+
+	Tested on x86_64-linux.
+
+2021-10-08  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.base/info_sources_2.exp with check-read1
+	When running test-case gdb.base/info_sources_2.exp with check-read1, I run
+	into:
+	...
+	FAIL: gdb.base/info_sources_2.exp: args: : info sources  (timeout)
+	...
+
+	Fix this by consuming a "$src1, $src2, ..., $srcn: line bit by bit rather than
+	as one whole line.
+
+	Also add the missing handling of "Objfile has no debug information".
+
+	Tested on x86_64-linux.
+
+2021-10-08  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.mi/gdb2549.exp with check-read1
+	When running test-case gdb.mi/gdb2549.exp with check-read1, I run into:
+	...
+	FAIL: gdb.mi/gdb2549.exp: register values x (timeout)
+	...
+
+	Fix this by applying the same fix as for "register values t" in commit
+	478e490a4df "[gdb/testsuite] Fix gdb.mi/gdb2549.exp with check-read1".
+
+	Tested on x86_64-linux.
+
+2021-10-08  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.base/bt-on-error-and-warning.exp with check-read1
+	When running test-case gdb.base/bt-on-error-and-warning.exp with check-read1,
+	I run into:
+	...
+	(gdb) maint internal-error foobar^M
+	src/gdb/maint.c:82: internal-error: foobar^M
+	A problem internal to GDB has been detectedFAIL: \
+	  gdb.base/bt-on-error-and-warning.exp: problem=internal-error, mode=on: \
+	  scan for backtrace (GDB internal error)
+	Resyncing due to internal error.
+	,^M
+	...
+
+	The corresponding gdb_test_multiple in the test-case contains:
+	...
+	           -early -re "^A problem internal to GDB has been detected,\r\n" {
+	               incr header_lines
+	               exp_continue
+	           }
+	...
+	but instead this one triggers in gdb_test_multiple:
+	...
+	        -re ".*A problem internal to GDB has been detected" {
+	            fail "$message (GDB internal error)"
+	            gdb_internal_error_resync
+	            set result -1
+	        }
+	...
+
+	Fix this by likewise shortening the regexp to before the comma.
+
+	Tested on x86_64-linux.
+
+2021-10-08  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Add nopie in two test-cases
+	When running test-case gdb.dwarf2/dw2-restrict.exp on openSUSE Leap 15.2 with
+	gcc-PIE installed (switching compiler default to -fPIE/-pie), I get:
+	...
+	gdb compile failed, ld: outputs/gdb.dwarf2/dw2-restrict/dw2-restrict0.o: \
+	  warning: relocation in read-only section `.text'
+	ld: warning: creating DT_TEXTREL in a PIE
+	UNTESTED: gdb.dwarf2/dw2-restrict.exp: failed to prepare
+	...
+
+	This is due to using a hardcoded .S file that was generated with -fno-PIE.
+
+	Fix this by adding the missing nopie.
+
+	Likewise in gdb.arch/amd64-tailcall-noret.exp.
+
+	Tested on x86_64-linux.
+
+2021-10-08  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-07  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.threads/check-libthread-db.exp with glibc 2.34
+	When running test-case gdb.threads/check-libthread-db.exp on openSUSE
+	Tumbleweed (with glibc 2.34) I get:
+	...
+	(gdb) continue^M
+	Continuing.^M
+	[Thread debugging using libthread_db enabled]^M
+	Using host libthread_db library "/lib64/libthread_db.so.1".^M
+	Stopped due to shared library event:^M
+	  Inferior loaded /lib64/libm.so.6^M
+	    /lib64/libc.so.6^M
+	(gdb) FAIL: gdb.threads/check-libthread-db.exp: user-initiated check: continue
+	...
+
+	The check expect the inferior to load libpthread, but since glibc 2.34
+	libpthread has been integrated into glibc, and consequently it's no longer
+	a dependency:
+	...
+	$ ldd outputs/gdb.threads/check-libthread-db/check-libthread-db
+	        linux-vdso.so.1 (0x00007ffe4cae4000)
+	        libm.so.6 => /lib64/libm.so.6 (0x00007f167c77c000)
+	        libc.so.6 => /lib64/libc.so.6 (0x00007f167c572000)
+	        /lib64/ld-linux-x86-64.so.2 (0x00007f167c86e000)
+	...
+
+	Fix this by updating the regexp to expect libpthread or libc.
+
+	Tested on x86_64-linux.
+
+2021-10-07  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.guile/scm-type.exp with gcc 4.8
+	With gcc 7.5.0, I get:
+	...
+	(gdb) guile (print (type-range (field-type (type-field (value-type \
+	  (value-dereference f)) "items"))))^M
+	= (0 0)^M
+	(gdb) PASS: gdb.guile/scm-type.exp: lang_cpp: test_range: \
+	  on flexible array member: $cmd
+	...
+	but with gcc 4.8.5, I get instead:
+	...
+	(gdb) guile (print (type-range (field-type (type-field (value-type \
+	  (value-dereference f)) "items"))))^M
+	= (0 -1)^M
+	(gdb) FAIL: gdb.guile/scm-type.exp: lang_cpp: test_range: \
+	  on flexible array member: $cmd
+	...
+
+	There's a difference in debug info.  With gcc 4.8.5, we have:
+	...
+	 <2><224>: Abbrev Number: 15 (DW_TAG_member)
+	    <225>   DW_AT_name        : items
+	    <22b>   DW_AT_type        : <0x231>
+	 <1><231>: Abbrev Number: 4 (DW_TAG_array_type)
+	    <232>   DW_AT_type        : <0x105>
+	 <2><23a>: Abbrev Number: 16 (DW_TAG_subrange_type)
+	    <23b>   DW_AT_type        : <0x11a>
+	    <23f>   DW_AT_upper_bound : 0xffffffffffffffff
+	...
+	and with gcc 7.5.0, we have instead:
+	...
+	 <2><89f>: Abbrev Number: 12 (DW_TAG_member)
+	    <8a0>   DW_AT_name        : items
+	    <8a6>   DW_AT_type        : <0x8ac>
+	 <1><8ac>: Abbrev Number: 17 (DW_TAG_array_type)
+	    <8ad>   DW_AT_type        : <0x29d>
+	 <2><8b5>: Abbrev Number: 41 (DW_TAG_subrange_type)
+	 <2><8b6>: Abbrev Number: 0
+	...
+
+	As mentioned in commit 858c8f2c1b9 "gdb/testsuite: adjust
+	gdb.python/flexible-array-member.exp expected pattern":
+	...
+	Ideally, GDB would present a consistent and documented value for an
+	array member declared with size 0, regardless of how the debug info
+	looks like.
+	...
+
+	As in gdb.python/flexible-array-member.exp, change the test to accept the two
+	values.
+
+	Tested on x86_64-linux.
+
+2021-10-07  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: add accessors for field (and call site) location
+	Add accessors for the various location values in struct field.  This
+	lets us assert that when we get a location value of a certain kind (say,
+	bitpos), the field's location indeed contains a value of that kind.
+
+	Remove the SET_FIELD_* macros, instead use the new setters directly.
+	Update the FIELD_* macros used to access field locations to go through
+	the getters.  They will be removed in a subsequent patch.
+
+	There are places where the FIELD_* macros are used on call_site_target
+	structures, because it contains members of the same name (loc_kind and
+	loc).  For now, I have replicated the getters/setters in
+	call_site_target.  But we could perhaps eventually factor them in a
+	"location" structure that can be used at both places.
+
+	Note that the field structure, being zero-initialized, defaults to a
+	bitpos location with value 0.  While writing this patch, I tried to make
+	it default to an "unset" location, to catch places where we would miss
+	setting a field's location.  However, I found that some places relied on
+	the default being "bitpos 0", so I left it as-is.  This change could
+	always be done as follow-up work, making these places explicitly set the
+	"bitpos 0" location.
+
+	I found two issues to fix:
+
+	 - I got some failures in the gdb.base/infcall-nested-structs-c++.exp
+	   test.  They were caused by two functions in amd64-tdep.c using
+	   TYPE_FIELD_BITPOS before checking if the location is of the bitpos
+	   kind, which they do indirectly through `field_is_static`.  Simply
+	   move getting the bitpos below the field_is_static call.
+
+	 - I got a failure in gdb.xml/tdesc-regs.exp.  It turns out that in
+	   make_gdb_type_enum, we set enum field values using SET_FIELD_BITPOS,
+	   and later access them through FIELD_ENUMVAL.  Fix that by using
+	   set_loc_enumval to set the value.
+
+	Change-Id: I53d3734916c46457576ba11dd77df4049d2fc1e8
+
+2021-10-07  Philipp Tomsich  <philipp.tomsich@vrull.eu>
+
+	RISC-V: Support aliases for Zbs instructions
+	Add aliases for the non-immediate mnemonics of b{set,clr,inv,ext} to
+	yencode the respective immediate insn b{set,clr,inv,ext}i when the
+	second source operand is an immediate.
+
+	2021-01-11  Philipp Tomsich  <philipp.tomsich@vrull.eu>
+
+	    gas/
+		* testsuite/gas/riscv/b-ext.d: Add tests.
+		* testsuite/gas/riscv/b-ext.s: Likewise.
+		* testsuite/gas/riscv/b-ext-64.d: Likewise.
+		* testsuite/gas/riscv/b-ext-64.s: Likewise.
+	    opcodes/
+	        * riscv-opc.c (riscv_opcodes): Add aliases for Zbs.
+
+	Suggested-by: Jan Beulich <jbeulich@suse.com>
+
+2021-10-07  Philipp Tomsich  <philipp.tomsich@vrull.eu>
+
+	RISC-V: Add support for Zbs instructions
+	This change adds the Zbs instructions from the Zbs 1.0.0 specification.
+	See
+	  https://github.com/riscv/riscv-bitmanip/releases/tag/1.0.0
+	for the frozen specification.
+
+	2021-01-09  Philipp Tomsich  <philipp.tomsich@vrull.eu>
+
+	    bfd/
+		* elfxx-riscv.c (riscv_supported_std_z_ext): Added zbs.
+	    gas/
+		* config/tc-riscv.c (riscv_multi_subset_supports): Handle INSN_CLASS_ZBS.
+		* testsuite/gas/riscv/b-ext.d: Test Zbs instructions.
+		* testsuite/gas/riscv/b-ext.s: Likewise.
+		* testsuite/gas/riscv/b-ext-64.d: Likewise.
+		* testsuite/gas/riscv/b-ext-64.s: Likewise.
+	    include/
+		* opcode/riscv-opc.h: Added MASK/MATCH/DECLARE_INSN for Zbs.
+		* opcode/riscv.h (riscv_insn_class): Added INSN_CLASS_ZBS.
+	    opcodes/
+		* riscv-opc.c (riscv_supported_std_z_ext): Add zbs.
+
+2021-10-07  Philipp Tomsich  <philipp.tomsich@vrull.eu>
+
+	RISC-V: Update extension version for Zb[abc] to 1.0.0
+	2021-10-06  Philipp Tomsich  <philipp.tomsich@vrull.eu>
+
+	    bfd/
+		* elfxx-riscv.c (riscv_supported_std_z_ext): Update the version
+		number for zba, zbb and zbc to 1.0.0
+
+
+	Version-changes: 3
+	- Updated version numbers for zba, zbb and zbc to 1.0.0
+
+2021-10-07  Philipp Tomsich  <philipp.tomsich@vrull.eu>
+
+	RISC-V: Split Zb[abc] into commented sections
+	The Zb[abc] opcodes are bundled just below the Privileged opcodes in
+	riscv_opcodes, possibly giving the appearance that they are part of
+	the Privileged spec for an uninitiated reader.  This separates them
+	out and adds comments above each section to clearly identify them as
+	Zba, Zbb or Zbc opcodes.
+
+	2021-10-04  Philipp Tomsich  <philipp.tomsich@vrull.eu>
+
+	    opcodes/
+		* riscv-opc.c: Split of Zb[abc] instructions and add comments.
+
+2021-10-07  Alan Modra  <amodra@gmail.com>
+
+	PR28423, use-after-free in objdump
+	XCOFF archives use a bi-directional linked list for file members.  So
+	one member points to both the previous member and the next member.
+	Members may not be sequentially ordered in the file.  This of course
+	is over-engineered nonsense and an attractive target for fuzzers.
+	(There is even a free list of members!)  The testcase in PR28423 is an
+	XCOFF archive with one member pointing to itself, which results in
+	lots of bad behaviour.  For example, "ar t" never terminates.
+
+	The use-after-free with "objdump -r" happens like this:  The first
+	archive element is opened, its symbols are read and "canonicalized"
+	for objdump, then relocations are read and printed.  Those relocations
+	use the canonicalized symbols, and also happen to be cached by the
+	coff bfd backend support.  objdump frees the symbols.  The next
+	archive element is then opened.  This must be done before the first
+	element is closed, because finding the next element uses data held in
+	the currect element.  Unfortunately the next element happens to be the
+	original, so we aren't opening, we're reopening a bfd which has cached
+	data.  When the relocations are printed they use the cached copy
+	containing references to the freed canonical symbols.
+
+	This patch adds a little sanity checking to the XCOFF "open next
+	archive file" support, so that it rejects archive members pointing at
+	themselves.  That is sufficient to cure this problem.  Anything more
+	is overkill.  If someone deliberately fuzzes an XCOFF archive with an
+	element loop then reports an "ar" bug when it runs forever, they will
+	find their bug report closed WONTFIX.
+
+		PR 28423
+		* coff-rs6000.c (_bfd_xcoff_read_ar_hdr): Save size occupied
+		by member name in areltdata.extra_size.
+		(_bfd_xcoff_openr_next_archived_file): Sanity check nextoff.
+		* coff64-rs6000.c (xcoff64_openr_next_archived_file): Call
+		_bfd_xcoff_openr_next_archived_file.
+
+2021-10-07  Alan Modra  <amodra@gmail.com>
+
+	PR28422, build_id use-after-free
+	This fixes a bug in commit 5d9bbb73c1df.  All fields preserved from a
+	bfd in struct bfd_preserve need to be cleared in bfd_reinit.
+
+		PR 28422
+		* format.c (bfd_reinit): Clear build_id.
+
+2021-10-07  Alan Modra  <amodra@gmail.com>
+
+	Change ridiculous section size error
+	Rather than reporting "memory exhausted", report "file truncated".
+	You can hit this error on small fuzzed object files, or on files that
+	are actually truncated.  In either case sizes can be such that an out
+	of memory error is a little confusing.
+
+		* compress.c (bfd_get_full_section_contents): Set
+		bfd_error_file_truncated rather than bfd_error_no_memory when
+		section size exceeds file size.
+
+2021-10-07  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix FAIL in gdb.base/annota1.exp
+	On openSUSE tumbleweed I run into:
+	...
+	FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout)
+	...
+	due to a message related to libthread_db:
+	...
+	^Z^Zstarting^M
+	[Thread debugging using libthread_db enabled]^M
+	Using host libthread_db library "/lib64/libthread_db.so.1".^M
+	^M
+	^Z^Zframes-invalid^M
+	...
+	which is not matched by the regexp.
+
+	Fix this by updating the regexp.
+
+	Tested on x86_64-linux.
+
+2021-10-07  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Refactor regexp in gdb.base/annota1.exp
+	Refactor regexp in gdb.base/annota1.exp to reduce indentation and repetition.
+
+	Tested on x86_64-linux.
+
+2021-10-07  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-06  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb/doc: improve 'show print elements' description
+	The documentation for 'show print elements' contains the line:
+
+	  If the number is 0, then the printing is unlimited.
+
+	However, this line is now out of date as can be seen by this GDB
+	session:
+
+	  (gdb) set print elements 0
+	  (gdb) show print elements
+	  Limit on string chars or array elements to print is unlimited.
+
+	The value 0 does indeed mean unlimited, and this is described in the
+	'set print elements' section, however, for 'show print elements' the
+	user will never see the value 0, so lets just remove that bit from the
+	docs.
+
+2021-10-06  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix FAIL in gdb.tui/corefile-run.exp
+	When running test-case gdb.tui/corefile-run.exp on openSUSE Tumbleweed,
+	I run into:
+	...
+	PASS: gdb.tui/corefile-run.exp: load corefile
+	FAIL: gdb.tui/corefile-run.exp: run until the end
+	...
+
+	What's going on is easier to see when also doing dump_screen if
+	check_contents passes, and inspecting state at the preceding PASS:
+	...
+	 +-------------------------------------------------------------------------+
+	 exec No process In:                                           L??   PC: ??
+	 [New LWP 16629]
+	 [Thread debugging using libthread_db enabled]
+	 Using host libthread_db library "/lib64/libthread_db.so.1".
+	 Core was generated by `/data/gdb_versions/devel/build/gdb/testsuite/output
+	 s/gdb.tui/corefile-run/corefi'.
+	 Program terminated with signal SIGTRAP, Trace/breakpoint trap.
+	 #0  main ()
+	 --Type <RET> for more, q to quit, c to continue without paging--
+	...
+
+	The problem is that we're getting a pagination prompt, and the subsequent run
+	command is interpreted as an answer to that prompt.
+
+	Fix this by:
+	- detecting the gdb prompt in response to "load corefile", such that
+	  we detect the failure earlier, and
+	- doing a "set pagination off" in Term::clean_restart.
+
+	Tested on x86_64-linux.
+
+2021-10-06  Alan Modra  <amodra@gmail.com>
+
+	PR28420, ecoff fuzzing failures
+		PR 28420
+		* coff-mips.c (mips_adjust_reloc_in): Replace abort with error
+		message and return.
+		* ecoff.c (ecoff_slurp_reloc_table): Remove assertion and aborts,
+		instead handle errors gracefully.
+
+2021-10-06  Alan Modra  <amodra@gmail.com>
+
+	PR28402, fail to allocate line number array
+	This fixes a situation where the COFF code allocated memory for
+	internal representaion arrays before reading the external file data.
+	That meant the allocation didn't have any sanity check against file
+	size.
+
+		PR 28402
+		* coffcode.h (buy_and_read): Malloc rather than alloc memory.
+		(coff_slurp_line_table): Read native line number info before
+		allocating memory for internal line number array.  Adjust error
+		paths to suit.  Remove now unnecessary line number count check.
+		(coff_slurp_reloc_table): Adjust to suit buy_and_read change.
+
+2021-10-06  Alan Modra  <amodra@gmail.com>
+
+	PR28403, null pointer dereference in disassemble_bytes
+	Indexing of symbol and howto arrays wasn't checked in aout targets.
+
+		PR 28403
+		* aout-ns32k.c (MY (reloc_howto)): Sanity check howto_table index.
+		Make r_index unsigned.
+		(MY_swap_std_reloc_in): Make r_index unsigned.
+		* aoutx.h (MOVE_ADDRESS): Sanity check symbol r_index.
+		(aout_link_input_section_std): Make r_index unsigned.
+		(aout_link_input_section_ext): Likewise.
+		* i386lynx.c (MOVE_ADDRESS): Sanity check symbol r_index.
+		(swap_ext_reloc_in, swap_std_reloc_in): Make r_index unsigned.
+		* pdp11.c (MOVE_ADDRESS): Sanity check symbol r_index.
+
+2021-10-06  Alan Modra  <amodra@gmail.com>
+
+	PR28401, invalid section name lookup
+	The PR28401 testcase has a section named "", ie. an empty string.
+	This results in some silly behaviour in load_debug_section, and
+	dump_dwarf_section.  Fix that.  Note that this patch doesn't correct
+	the main complaint in PR28401, "failed to allocate", since malloc
+	failures on sections having huge bogus sizes are to be expected.  We
+	can't safely catch all such cases by comparing with file size, for
+	example, where sections contain compressed data.
+
+		PR 28401
+		* objdump.c (load_debug_section): Don't attempt to retrieve
+		empty name sections.
+		(dump_dwarf_section): Likewise.
+
+2021-10-06  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-06  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Make tui testing less verbose
+	Currently, tui testing is rather verbose.  When using these RUNTESTFLAGS to
+	pick up all tui tests (17 in total):
+	...
+	rtf=$(echo $(cd src/gdb/testsuite/; find gdb.* -type f -name *.exp* \
+	  | xargs grep -l tuiterm_env) )
+	...
+	we have:
+	...
+	$ wc -l gdb.log
+	120592 gdb.log
+	...
+
+	Most of the output is related to controlling the tui screen, but that does
+	not give a top-level sense of how the test-case progresses.
+
+	Put differently: a lot of bandwith is used to describe how we arrive at a
+	certain tui screen state.  But we don't actually always show the state we
+	arrive at, unless there's a FAIL.
+
+	And if there's say, a PASS that should actually be FAILing, it's hard to
+	detect.
+
+	Fix this by:
+	- dropping the -log on the call to verbose in _log.  We still can get the
+	  same info back using runtest -v.
+	- dumping the screen or box that we're checking, also when the test passes.
+
+	Brings down verbosity to something more reasonable:
+	...
+	$ wc -l gdb.log
+	3221 gdb.log
+	...
+
+	Tested on x86_64-linux.
+
+2021-10-06  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Add Term::dump_box in lib/tuiterm.exp
+	Factor out new proc Term::get_region and use it to implement a
+	new proc Term::dump_box, similar to Term::dump_screen.
+
+	Tested on x86_64-linux.
+
+2021-10-05  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb: Remove deprecated assertion in setting::get
+	The commit 702991711a91bd47b209289562843a11e7009396 (gdb: Have setter
+	and getter callbacks for settings) makes it possible for a setting not
+	to be backed by a memory buffer but use callback functions instead to
+	retrieve or set the setting's value.
+
+	An assertion was not properly updated to take into account that the
+	m_var member (which points to a memory buffer, if used) might be nullptr
+	if the setting uses callback functions.  If the setting is backed by a
+	memory buffer, the m_var has to be non nullptr, which is already checked
+	before the pointer is dereferenced.
+
+	This commit removes this assertion as it is not valid anymore.
+
+2021-10-05  Tom Tromey  <tromey@adacore.com>
+
+	Remove 'varsize-limit'
+	This makes the Ada-specific "varsize-limit" a synonym for
+	"max-value-size", and removes the Ada-specific checks of the limit.
+
+	I am not certain of the history here, but it seems to me that this
+	code is fully obsolete now.  And, removing this makes it possible to
+	index large Ada arrays without triggering an error.  A new test case
+	is included to demonstrate this.
+
+2021-10-05  Tom Tromey  <tromey@adacore.com>
+
+	Allow lazy 'zero' value
+	This changes value_zero to create a lazy value.  In many cases,
+	value_zero is called in expression evaluation to wrap a type in a
+	non-eval context.  It seems senseless to allocate a buffer in these
+	cases.
+
+	A new 'is_zero' flag is added so we can preserve the existing
+	assertions in value_fetch_lazy.
+
+	A subsequent patch will add a test where creating a zero value would
+	fail, due to the variable size check.  However, the contents of this
+	value are never needed, and so creating a lazy value avoids the error
+	case.
+
+2021-10-05  Tom Tromey  <tromey@adacore.com>
+
+	Add lval_funcs::is_optimized_out
+	This adds an is_optimized_out function pointer to lval_funcs, and
+	changes value_optimized_out to call it.  This new function lets gdb
+	determine if a value is optimized out without necessarily fetching the
+	value.  This is needed for a subsequent patch, where an attempt to
+	access a lazy value would fail due to the value size limit -- however,
+	the access was only needed to determine the optimized-out state.
+
+2021-10-05  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix FAIL in gdb.mi/mi-nsmoribund.exp
+	Since commit e36788d1354 "[gdb/testsuite] Fix handling of nr_args < 3 in
+	mi_gdb_test" we run into:
+	...
+	PASS: gdb.mi/mi-nsmoribund.exp: print done = 1
+	Expecting: ^(.*[^M
+	]+)?([^
+	]*^M
+	\*running,thread-id="[0-9]+"^M
+	\*running,thread-id="[0-9]+"^M
+	\*running,thread-id="[0-9]+"^M
+	\*running,thread-id="[0-9]+"^M
+	\*running,thread-id="[0-9]+"^M
+	\*running,thread-id="[0-9]+"^M
+	\*running,thread-id="[0-9]+"^M
+	\*running,thread-id="[0-9]+"^M
+	\*running,thread-id="[0-9]+"^M
+	\*running,thread-id="[0-9]+"[^M
+	]+[(]gdb[)] ^M
+	[ ]*)
+	103-exec-continue --all^M
+	=library-loaded,id="/lib64/libgcc_s.so.1",target-name="/lib64/libgcc_s.so.1",\
+	  host-name="/lib64/libgcc_s.so.1",symbols-loaded="0",thread-group="i1",\
+	  ranges=[{from="0x00007ffff22a5010",to="0x00007ffff22b6365"}]^M
+	103^running^M
+	*running,thread-id="5"^M
+	(gdb) ^M
+	FAIL: gdb.mi/mi-nsmoribund.exp: 103-exec-continue --all (unexpected output)
+	...
+
+	The regexp expect running messages for all threads, but we only get one for
+	thread 5.
+
+	The test-case uses non-stop mode, and when the exec-continue --all command is
+	issued, thread 5 is stopped and all other threads are running.  Consequently,
+	only thread 5 is resumed, and reported as running.
+
+	Fix this by updating the regexp.
+
+	Tested on x86_64-linux.
+
+2021-10-05  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb/python: fix memory leak in python inferior code
+	When a user creates a gdb.Inferior object for the first time a new
+	Python object is created.  This object is then cached within GDB's
+	inferior object using the registry mechanism (see
+	inferior_to_inferior_object in py-inferior.c, specifically the calls
+	to inferior_data and set_inferior_data).
+
+	The Python Reference to the gdb.Inferior object held within the real
+	inferior object ensures that the reference count on the Python
+	gdb.Inferior object never reaches zero while the GDB inferior object
+	continues to exist.
+
+	At the same time, the gdb.Inferior object maintains a C++ pointer back
+	to GDB's real inferior object.  We therefore end up with a system that
+	looks like this:
+
+	                   Python Reference
+	                         |
+	                         |
+	    .----------.         |          .--------------.
+	    |          |------------------->|              |
+	    | inferior |                    | gdb.Inferior |
+	    |          |<-------------------|              |
+	    '----------'         |          '--------------'
+	                         |
+	                         |
+	                    C++ Pointer
+
+	When GDB's inferior object is deleted (say the inferior exits) then
+	py_free_inferior is called (thanks to the registry system), this
+	function looks up the Python gdb.Inferior object and sets the C++
+	pointer to nullptr and finally reduces the reference count on the
+	Python gdb.Inferior object.
+
+	If at this point the user still holds a reference to the Python
+	gdb.Inferior object then nothing happens.  However, the gdb.Inferior
+	object is now in the non-valid state (see infpy_is_valid in
+	py-inferior.c), but otherwise, everything is fine.
+
+	However, if there are no further references to the Python gdb.Inferior
+	object, or, once the user has given up all their references to the
+	gdb.Inferior object, then infpy_dealloc is called.
+
+	This function currently checks to see if the inferior pointer within
+	the gdb.Inferior object is nullptr or not.  If the pointer is nullptr
+	then infpy_dealloc immediately returns.
+
+	Only when the inferior point in the gdb.Inferior is not nullptr do
+	we (a) set the gdb.Inferior reference inside GDB's inferior to
+	nullptr, and (b) call the underlying Python tp_free function.
+
+	There are a number things wrong here:
+
+	  1.  The Python gdb.Inferior reference within GDB's inferior object
+	  holds a reference count, thus, setting this reference to nullptr
+	  without first decrementing the reference count would leak a
+	  reference, however...
+
+	  2. As GDB's inferior holds a reference then infpy_dealloc will never
+	  be called until GDB's inferior object is deleted.  Deleting a GDB
+	  inferior ohject calls py_free_inferior, and so gives up the
+	  reference.  At this point there is no longer a need to call
+	  set_inferior_data to set the field back to NULL, that field must
+	  have been cleared in order to get the reference count to zero, which
+	  means...
+
+	  3. If we know that py_free_inferior must be called before
+	  infpy_dealloc, then we know that the inferior pointer in
+	  gdb.Inferior will always be nullptr when infpy_dealloc is called,
+	  this means that the call to the underlying tp_free function will
+	  always be skipped.  Skipping this call will cause Python to leak the
+	  memory associated with the gdb.Inferior object, which is what we
+	  currently always do.
+
+	Given all of the above, I assert that the C++ pointer within
+	gdb.Inferior will always be nullptr when infpy_dealloc is called.
+	That's what this patch does.
+
+	I wrote a test for this issue making use of Pythons tracemalloc
+	module, which allows us to spot this memory leak.
+
+2021-10-05  Bhuvanendra Kumar N  <Bhuvanendra.KumarN@amd.com>
+
+	[gdb/testsuite] Use function_range in gdb.dwarf2/dw2-ref-missing-frame.exp
+	Following 2 test points are failing with clang compiler
+
+	(gdb) FAIL: gdb.dwarf2/dw2-ref-missing-frame.exp: func_nofb print
+	(gdb) FAIL: gdb.dwarf2/dw2-ref-missing-frame.exp: func_loopfb print
+
+	As in commit f677852bbda "[gdb/testsuite] Use function_range in
+	gdb.dwarf2/dw2-abs-hi-pc.exp", the problem is that the CU and functions
+	have an empty address range, due to using asm labels in global scope,
+	which is a known source of problems, as explained in the comment of proc
+	function_range in gdb/testsuite/lib/dwarf.exp.  Hence fix this also by
+	using function_range.
+
+	Tested on x86_64-linux with gcc and clang.
+
+2021-10-05  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb/python: add a new gdb_exiting event
+	Add a new event, gdb.events.gdb_exiting, which is called once GDB
+	decides it is going to exit.
+
+	This event is not triggered in the case that GDB performs a hard
+	abort, for example, when handling an internal error and the user
+	decides to quit the debug session, or if GDB hits an unexpected,
+	fatal, signal.
+
+	This event is triggered if the user just types 'quit' at the command
+	prompt, or if GDB is run with '-batch' and has processed all of the
+	required commands.
+
+	The new event type is gdb.GdbExitingEvent, and it has a single
+	attribute exit_code, which is the value that GDB is about to exit
+	with.
+
+	The event is triggered before GDB starts dismantling any of its own
+	internal state, so, my expectation is that most Python calls should
+	work just fine at this point.
+
+	When considering this functionality I wondered about using the
+	'atexit' Python module.  However, this is triggered when the Python
+	environment is shut down, which is done from a final cleanup.  At
+	this point we don't know for sure what other GDB state has already
+	been cleaned up.
+
+2021-10-05  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb/python: update events test to handle missing exit_code
+	The test gdb.python/py-events.exp sets up a handler for the gdb.exited
+	event.  Unfortunately the handler is slightly broken, it assumes that
+	the exit_code attribute will always be present.  This is not always
+	the case.
+
+	In a later commit I am going to add more tests to py-events.exp test
+	script, and in so doing I expose the bug in our handling of gdb.exited
+	events.
+
+	Just to be clear, GDB itself is fine, it is the test that is not
+	written correctly according to the Python Events API.
+
+	So, in this commit I fix the Python code in the test, and extend the
+	test case to exercise more paths through the Python code.
+
+	Additionally, I noticed that the gdb.exited event is used as an
+	example in the documentation for how to write an event handler.
+	Unfortunately the same bug that we had in our test was also present in
+	the example code in the manual.
+
+	So I've fixed that too.
+
+	After this commit there is no functional change to GDB.
+
+2021-10-05  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-04  Tom Tromey  <tromey@adacore.com>
+
+	Use unique_xmalloc_ptr<char> when demangling
+	I noticed that some methods in language_defn could use
+	unique_xmalloc_ptr<char> rather than a plain 'char *'.  This patch
+	implements this change, fixing up the fallout and changing
+	gdb_demangle to also return this type.  In one spot, std::string is
+	used to simplify some related code, and in another, an auto_obstack is
+	used to avoid manual management.
+
+	Regression tested on x86-64 Fedora 34.
+
+2021-10-04  Tom Tromey  <tromey@adacore.com>
+
+	Minor boolean fix in windows-nat.c
+	I noticed a spot in windows-nat.c that used '1' rather than the more
+	appropriate 'true'.  This patch fixes it.
+
+2021-10-04  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/build] Add CXX_DIALECT to CXX
+	Say we use a gcc version that (while supporting c++11) does not support c++11
+	by default, and needs an -std setting to enable it.
+
+	If gdb would use the default AX_CXX_COMPILE_STDCXX from autoconf-archive, then
+	we'd have:
+	...
+	CXX="g++ -std=gnu++11"
+	...
+
+	That mechanism however has the following problem (quoting from commit
+	0bcda685399):
+	...
+	the top level Makefile passes CXX down to subdirs, and that overrides whatever
+	gdb/Makefile may set CXX to.  The result would be that a make invocation from
+	the build/gdb/ directory would use "g++ -std=gnu++11" as expected, while a
+	make invocation at the top level would not.
+	...
+
+	Commit 0bcda685399 fixes this by using a custom AX_CXX_COMPILE_STDCXX which
+	does:
+	...
+	CXX=g++
+	CXX_DIALECT=-std=gnu++11
+	...
+
+	The problem reported in PR28318 is that using the custom instead of the
+	default AX_CXX_COMPILE_STDCXX makes the configure test for std::thread
+	support fail.
+
+	We could simply add $CXX_DIALECT to the test for std::thread support, but
+	that would have to be repeated for each added c++ support test.
+
+	Instead, fix this by doing:
+	...
+	CXX="g++ -std=gnu++11"
+	CXX_DIALECT=-std=gnu++11
+	...
+
+	This is somewhat awkward, since it results in -std=gnu++11 occuring twice in
+	some situations:
+	...
+	$ touch src/gdb/dwarf2/read.c
+	$ ( cd build/gdb; make V=1 dwarf2/read.o )
+	g++-4.8 -std=gnu++11 -x c++ -std=gnu++11 ...
+	...
+
+	However, both settings are needed:
+	 - the switch in CXX for the std::thread tests (and other tests)
+	 - the switch in CXX_DIALECT so it can be appended in Makefiles, to
+	   counteract the fact that the top-level Makefile overrides CXX
+
+	The code added in gdb/ax_cxx_compile_stdcxx.m4 is copied from the default
+	AX_CXX_COMPILE_STDCXX from autoconf-archive.
+
+	Tested on x86_64-linux.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28318
+
+2021-10-04  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	[gdb/symtab] Use unrelocated addresses in call_site
+	Consider test-case gdb.trace/entry-values.exp with target board
+	unix/-fPIE/-pie.
+
+	Using this command we have an abbreviated version, and can see the correct
+	@entry values for foo:
+	...
+	$ gdb -q -batch outputs/gdb.trace/entry-values/entry-values \
+	  -ex start \
+	  -ex "break foo" \
+	  -ex "set print entry-values both" \
+	  -ex continue
+	Temporary breakpoint 1 at 0x679
+
+	Temporary breakpoint 1, 0x0000555555554679 in main ()
+	Breakpoint 2 at 0x55555555463e
+
+	Breakpoint 2, 0x000055555555463e in foo (i=0, i@entry=2, j=2, j@entry=3)
+	...
+
+	Now, let's try the same again, but run directly to foo rather than stopping at
+	main:
+	...
+	$ gdb -q -batch outputs/gdb.trace/entry-values/entry-values \
+	  -ex "break foo" \
+	  -ex "set print entry-values both" \
+	  -ex run
+	Breakpoint 1 at 0x63e
+
+	Breakpoint 1, 0x000055555555463e in foo (i=0, i@entry=<optimized out>, \
+	  j=2, j@entry=<optimized out>)
+	...
+
+	So, what explains the difference?  Noteworthy, this is a dwarf assembly
+	test-case, with debug info for foo and bar, but not for main.
+
+	In the first case:
+	- we run to main
+	- this does not trigger expanding debug info, because there's none for main
+	- we set a breakpoint at foo
+	- this triggers expanding debug info.  Relocated addresses are used in
+	  call_site info (because the exec is started)
+	- we continue to foo, and manage to find the call_site info
+
+	In the second case:
+	- we set a breakpoint at foo
+	- this triggers expanding debug info.  Unrelocated addresses are used in
+	  call_site info (because the exec is not started)
+	- we run to foo
+	- this triggers objfile_relocate1, but it doesn't update the call_site
+	  info addresses
+	- we don't manage to find the call_site info
+
+	We could fix this by adding the missing call_site relocation in
+	objfile_relocate1.
+
+	This solution however is counter-trend in the sense that we're trying to
+	work towards the situation where when starting two instances of an executable,
+	we need only one instance of debug information, implying the use of
+	unrelocated addresses.
+
+	So, fix this instead by using unrelocated addresses in call_site info.
+
+	Tested on x86_64-linux.
+
+	This fixes all remaining unix/-fno-PIE/-no-pie vs unix/-fPIE/-pie
+	regressions, like f.i. PR24892.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24892
+
+	Co-Authored-By: Tom de Vries <tdevries@suse.de>
+
+2021-10-04  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	[gdb/symtab] C++-ify call_site
+	- add constructor
+	- add member function call_site::pc ()
+
+	Tested on x86_64-linux.
+
+	Co-Authored-By: Tom de Vries <tdevries@suse.de>
+
+2021-10-04  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/symtab] Add call_site_eq and call_site_hash
+	In commit b4c919f7525 "[gdb/symtab] Fix htab_find_slot call in
+	read_call_site_scope" , I removed the comment:
+	...
+	It must be the first field as we overload core_addr_hash and core_addr_eq for
+	it.
+	...
+	for field pc of struct call_site.
+
+	However, this was not tested, and when indeed moving field pc to the second
+	location, we run into a testsuite failure in gdb.trace/entry-values.exp.
+
+	This is caused by core_addr_eq (the eq_f function for the htab) being
+	called with a pointer to the pc field (as passed into htab_find_slot) and a
+	pointer to a hash table element.  Now that pc is no longer the first field,
+	the pointer to hash table element no longer points to the pc field.
+
+	This could be fixed by simply reinstating the comment, but we're trying to
+	get rid of this kind of tricks that make refactoring more difficult.
+
+	Instead, fix this by:
+	- reverting commit b4c919f7525, apart from the comment removal, such that
+	  we're passing a pointer to element to htab_find_slot
+	- updating the htab_find_slot call in compunit_symtab::find_call_site
+	  in a similar manner
+	- adding a call_site_eq and call_site_hash, and using these in the hash table
+	  instead of core_addr_eq and core_addr_hash.
+
+	Tested on x86_64-linux, both with and without a trigger patch that moves pc to
+	the second location in struct call_site.
+
+2021-10-04  Tom Tromey  <tromey@adacore.com>
+
+	Fix remote-sim.c compilation
+	The change "make string-like set show commands use std::string
+	variable" caused remote-sim.c to fail to build.  The issue is that the
+	code does:
+
+	  const std::string &sysroot = gdb_sysroot;
+	  if (is_target_filename (sysroot))
+	    sysroot += strlen (TARGET_SYSROOT_PREFIX);
+
+	... which isn't valid.
+
+	This patch changes this code to use a 'const char *' again, fixing the
+	build.
+
+2021-10-04  Bruno Larsen  <blarsen@redhat.com>
+
+	[gdb/testsuite] update analyze-racy-logs.py to python3
+	Since python 2 is no longer supported on most distributions, update the
+	script to run under python while while still being runnable under
+	python2.
+
+2021-10-04  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdbsupport: remove attempt to define TARGET_WORD_SIZE
+	In the gdbsupport configure.ac file, there is an attempt to define
+	TARGET_WORD_SIZE.  This is done by running grep on the file
+	../bfd/bfd-in3.h.
+
+	The problem with this is, the file bfd-in3.h is generated into the bfd
+	build directory when bfd is configured, and there is no dependency
+	between the gdbsupport module and the bfd module, so, for example, if
+	I do:
+
+	  $ ../src/configure
+	  $ make all-gdbsupport
+
+	Then bfd will neither be configured, or built.  In this case
+	TARGET_WORD_SIZE ends up being defined, but with no value because the
+	grep on bfd-in3.h fails.
+
+	However, it turns out that this doesn't matter; we don't actually use
+	TARGET_WORD_SIZE anywhere.
+
+	My proposal in this commit is to just remove the definition of
+	TARGET_WORD_SIZE, the alternative would be to add a dependency between
+	configure-gdbsupport and configure-bfd into Makefile.def, but adding a
+	dependency for something we don't need seems pretty pointless.
+
+2021-10-04  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: add --info-target for listing supported BFD targets
+	It can be difficult to guess the exact bfd name, so add an option to
+	list all the targets that the current build supports.  This aligns with
+	other simulator options like --info-architecture.
+
+2021-10-04  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-03  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb: Setting setter return a bool to tell if the value changed
+	GDB can notify observers when a parameter is changed.
+
+	To do that, do_set_command (in gdb/cli/cli-setshow.c) compares the new
+	value against the old one before updating it, and based on that notifies
+	observers.  This looks like something like:
+
+	    int valuechanged = 0;
+	    switch (cmd->var.type ())
+	    {
+	    case var_integer:
+	      {
+	        LONGEST new_val = parse_and_eval_long (arg)
+	        if (new_val != cmd->var.get<int> ())
+	        {
+	          cmd->var.get<int> (new_val);
+	          value_changes = 1;
+	        }
+	      }
+	    case var_uinteger:
+	    case var_zuinteger:
+	      {
+	        unsigned int val
+	          = parse_cli_var_uinteger (c->var->type (), &arg, true);
+	        if (c->var->get<unsigned int> () != val)
+	          {
+	            c->var->set<unsigned int> (val);
+	            option_changed = true;
+	          }
+	      }
+	    case...
+	      /* And so on for all possible var_types.  */
+	    }
+
+	This comparison is done for each possible var_type, which leads to
+	unnecessary logic duplication.
+
+	In this patch I propose to move all those checks in one place within the
+	setting setter method.  This limits the code duplication and simplifies
+	the do_set_command implementation.
+
+	This patch also changes slightly the way a value change is detected.
+	Instead of comparing the user provided value against the current value
+	of the setting, we compare the value of the setting before and after the
+	set operation.  This is meant to handle edge cases where trying to set
+	an unrecognized value would be equivalent to a noop (the actual value
+	remains unchanged).  Doing this requires that the original value needs
+	to be copied before the update, which can be non trivial for
+	std::string.
+
+	There should be no user visible change introduced by this commit.
+
+	Tested on x86_64 GNU/Linux.
+
+	[1] https://review.lttng.org/c/binutils-gdb/+/5831/41
+
+	Change-Id: If064b9cede3eb56275aacd2b286f74eceb1aed11
+
+2021-10-03  Lancelot SIX  <lsix@lancelotsix.com>
+	    Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: Have setter and getter callbacks for settings
+	The main motivation behind this improvement is to help the
+	implementation of a patch Simon Marchi is preparing to fix a bug when
+	MI or Python try to access parameters that are inferior dependent (see
+	PR/28085).
+
+	This commit extends the previous ones, which introduces the setting
+	object to represent a static variable whose value can be set or shown
+	with the appropriate commands.  This patch proposes that a setting can
+	either contain a pointer to a static variable holding a setting, or
+	pointers to a pair of setter and getter callback functions.
+
+	The callbacks functions can be used to retrieve or change the value with
+	custom logic.  This is useful when the source of truth for a given
+	setting is not contained in the variable pointed to by the setting
+	instance.
+
+	Given that the callback function call is hidden within the setting
+	abstraction introduced earlier, none of the sites accessing the setting
+	needs to be updated.  The registered getter or setter is used whatever
+	the way to access it is (through MI, Python, Guile, the "with" command
+	and the $_gdb_setting / $_gdb_setting_str convenience functions).
+
+	All the add_setshow_*_cmd are given a new overload that will accept the
+	pair of function pointers (set / get functions) instead of the pointer
+	to a global variable.
+
+	Tested on GNU/Linux x86_64 with no regression observed.
+
+	Change-Id: Ieb81fef57550632ff66e6aa85f637372a226be8c
+
+2021-10-03  Simon Marchi  <simon.marchi@efficios.com>
+	    Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb: make string-like set show commands use std::string variable
+	String-like settings (var_string, var_filename, var_optional_filename,
+	var_string_noescape) currently take a pointer to a `char *` storage
+	variable (typically global) that holds the setting's value.  I'd like to
+	"mordernize" this by changing them to use an std::string for storage.
+
+	An obvious reason is that string operations on std::string are often
+	easier to write than with C strings.  And they avoid having to do any
+	manual memory management.
+
+	Another interesting reason is that, with `char *`, nullptr and an empty
+	string often both have the same meaning of "no value".  String settings
+	are initially nullptr (unless initialized otherwise).  But when doing
+	"set foo" (where `foo` is a string setting), the setting now points to
+	an empty string.  For example, solib_search_path is nullptr at startup,
+	but points to an empty string after doing "set solib-search-path".  This
+	leads to some code that needs to check for both to check for "no value".
+	Or some code that converts back and forth between NULL and "" when
+	getting or setting the value.  I find this very error-prone, because it
+	is very easy to forget one or the other.  With std::string, we at least
+	know that the variable is not "NULL".  There is only one way of
+	representing an empty string setting, that is with an empty string.
+
+	I was wondering whether the distinction between NULL and "" would be
+	important for some setting, but it doesn't seem so.  If that ever
+	happens, it would be more C++-y and self-descriptive to use
+	optional<string> anyway.
+
+	Actually, there's one spot where this distinction mattered, it's in
+	init_history, for the test gdb.base/gdbinit-history.exp.  init_history
+	sets the history filename to the default ".gdb_history" if it sees that
+	the setting was never set - if history_filename is nullptr.  If
+	history_filename is an empty string, it means the setting was explicitly
+	cleared, so it leaves it as-is.  With the change to std::string, this
+	distinction doesn't exist anymore.  This can be fixed by moving the code
+	that chooses a good default value for history_filename to
+	_initialize_top.  This is ran before -ex commands are processed, so an
+	-ex command can then clear that value if needed (what
+	gdb.base/gdbinit-history.exp tests).
+
+	Another small improvement, in my opinion is that we can now easily
+	give string parameters initial values, by simply initializing the global
+	variables, instead of xstrdup-ing it in the _initialize function.
+
+	In Python and Guile, when registering a string-like parameter, we
+	allocate (with new) an std::string that is owned by the param_smob (in
+	Guile) and the parmpy_object (in Python) objects.
+
+	This patch started by changing all relevant add_setshow_* commands to
+	take an `std::string *` instead of a `char **` and fixing everything
+	that failed to build.  That includes of course all string setting
+	variable and their uses.
+
+	string_option_def now uses an std::string also, because there's a
+	connection between options and settings (see
+	add_setshow_cmds_for_options).
+
+	The add_path function in source.c is really complex and twisted, I'd
+	rather not try to change it to work on an std::string right now.
+	Instead, I added an overload that copies the std:string to a `char *`
+	and back.  This means more copying, but this is not used in a hot path
+	at all, so I think it is acceptable.
+
+	Change-Id: I92c50a1bdd8307141cdbacb388248e4e4fc08c93
+
+2021-10-03  Lancelot SIX  <lsix@lancelotsix.com>
+	    Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: Introduce setting construct within cmd_list_element
+	cmd_list_element can contain a pointer to data that can be set and / or
+	shown.  This is achieved with the void* VAR member which points to the
+	data that can be accessed, while the VAR_TYPE member (of type enum
+	var_types) indicates how to interpret the data pointed to.
+
+	With this pattern, the user of the cmd_list_element needs to know what
+	is the storage type associated with a given VAR_TYPES in order to do
+	the proper casting.  No automatic safeguard is available to prevent
+	miss-use of the pointer.  Client code typically looks something like:
+
+		switch (c->var_type)
+		{
+		  case var_zuinteger:
+		    unsigned int v = *(unsigned int*) c->var;
+		    ...
+		    break;
+		  case var_boolean:
+		    bool v = *(bool *) c->var;
+		    ...
+		    break;
+		  ...
+		}
+
+	This patch proposes to add an abstraction around the var_types and void*
+	pointer pair.  The abstraction is meant to prevent the user from having
+	to handle the cast and verify that the data is read or written as a type
+	that is coherent with the setting's var_type.  This is achieved by
+	introducing the struct setting which exposes a set of templated get /
+	set member functions.  The template parameter is the type of the
+	variable that holds the referred variable.
+
+	Using those accessors allows runtime checks to be inserted in order to
+	ensure that the data pointed to has the expected type.  For example,
+	instantiating the member functions with bool will yield something
+	similar to:
+
+		const bool &get<bool> () const
+		{
+		  gdb_assert (m_var_type == var_boolean);
+		  gdb_assert (m_var != nullptr);
+		  return *static_cast<bool *> (m_var);
+		}
+		void set<bool> (const bool &var)
+		{
+		  gdb_assert (m_var_type == var_boolean);
+		  gdb_assert (m_var != nullptr);
+		  *static_cast<bool *> (m_var) = var;
+		}
+
+	Using the new abstraction, our initial example becomes:
+
+		switch (c->var_type)
+		{
+		  case var_zuinteger:
+		    unsigned int v = c->var->get<unsigned int> ();
+		    ...
+		    break;
+		  case var_boolean:
+		    bool v = c->var->get<bool> ();
+		    ...
+		    break;
+		  ...
+		}
+
+	While the call site is still similar, the introduction of runtime checks
+	help ensure correct usage of the data.
+
+	In order to avoid turning the bulk of add_setshow_cmd_full into a
+	templated function, and following a suggestion from Pedro Alves, a
+	setting can be constructed from a pre validated type erased reference to
+	a variable.  This is what setting::erased_args is used for.
+
+	Introducing an opaque abstraction to describe a setting will also make
+	it possible to use callbacks to retrieve or set the value of the setting
+	on the fly instead of pointing to a static chunk of memory.  This will
+	be done added in a later commit.
+
+	Given that a cmd_list_element may or may not reference a setting, the
+	VAR and VAR_TYPES members of the struct are replaced with a
+	gdb::optional<setting> named VAR.
+
+	Few internal function signatures have been modified to take into account
+	this new abstraction:
+
+	-The functions value_from_setting, str_value_from_setting and
+	 get_setshow_command_value_string used to have a 'cmd_list_element *'
+	 parameter but only used it for the VAR and VAR_TYPE member. They now
+	 take a 'const setting &' parameter instead.
+	- Similarly, the 'void *' and a 'enum var_types' parameters of
+	  pascm_param_value and gdbpy_parameter_value have been replaced with a
+	  'const setting &' parameter.
+
+	No user visible change is expected after this patch.
+
+	Tested on GNU/Linux x86_64, with no regression noticed.
+
+	Change-Id: Ie1d08c3ceb8b30b3d7bf1efe036eb8acffcd2f34
+
+2021-10-03  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: filter out SIGSTKSZ [PR sim/28302]
+	We map target signals to host signals so we can propagate signals
+	between the host & simulated worlds.  That means we need to know
+	the symbolic names & values of all signals that might be sent.
+
+	The tools that generate that list use signal.h and include all
+	symbols that start with "SIG" so as to automatically include any
+	new symbols that the C library might add.  Unfortunately, this
+	also picks up "SIGSTKSZ" which is not actually a signal itself,
+	but a signal related setting -- it's the size of the stack when
+	a signal is handled.
+
+	By itself this doesn't super matter as we will never see a signal
+	with that same value (since the range of valid signals tend to be
+	way less than 1024, and the size of the default signal stack will
+	never be that small).  But with recent glibc changes that make this
+	into a dynamic value instead of a compile-time constant, some users
+	see build failures when building the sim.
+
+	As suggested by Adam Sampson, update our scripts to ignore this
+	symbol to simplify everything and avoid the build failure.
+
+	Bug: https://sourceware.org/PR28302
+
+2021-10-03  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: ppc: fallback when ln is not available [PR sim/18864]
+	Not all systems have easy access to hard links or symlinks, so add
+	fallback logic to the run->psim build code to handle those.
+
+	Bug: https://sourceware.org/PR18864
+
+2021-10-03  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb: Fix comment in riscv_scan_prologue
+	I found an inaccurate comment in riscv_scan_prologue.  This commit fixes
+	it.
+
+2021-10-03  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb: Support the c.mv insn in the riscv prologue scanner.
+	While working on other problems, I encountered situations where GDB
+	fails to properly unwind the stack because some functions use the C.MV
+	instruction in the prologue.  The prologue scanner stops when it hits
+	this instruction assuming its job is done at this point.  Unfortunately
+	the prologue is not necessarily finished yet, preventing GDB to properly
+	unwind.
+
+	This commit adds support for handling such instruction in
+	riscv_scan_prologue.
+
+	Note that C.MV is part of the compressed instruction set.  The MV
+	counterpart from the base ISA is a pseudo instruction that expands to
+	'ADDI RD,RS1,0' which is already supported.
+
+	Tested on riscv64-linux-gnu.
+
+	All feedback are welcome.
+
+2021-10-03  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-02  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	[gdb/symtab] Remove COMPUNIT_CALL_SITE_HTAB
+	Remove macro COMPUNIT_CALL_SITE_HTAB, and provide access to the htab using
+	member functions:
+	- compunit_symtab::find_call_site
+	- compunit_symtab::set_call_site_htab
+
+	Tested on x86_64-linux.
+
+	Co-Authored-By: Tom de Vries <tdevries@suse.de>
+
+2021-10-02  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/python: fix a few flake8 warnings
+	Fix these rather obvious warnings reported by flake8:
+
+	    ./lib/gdb/FrameIterator.py:16:1: F401 'gdb' imported but unused
+	    ./lib/gdb/FrameIterator.py:17:1: F401 'itertools' imported but unused
+	    ./lib/gdb/command/prompt.py:55:26: E712 comparison to False should be 'if cond is False:' or 'if not cond:'
+	    ./lib/gdb/command/explore.py:526:9: F841 local variable 'has_explorable_fields' is assigned to but never used
+	    ./lib/gdb/command/explore.py:697:56: E712 comparison to False should be 'if cond is False:' or 'if not cond:'
+	    ./lib/gdb/command/explore.py:736:62: E712 comparison to False should be 'if cond is False:' or 'if not cond:'
+	    ./lib/gdb/command/explore.py:767:61: E712 comparison to False should be 'if cond is False:' or 'if not cond:'
+	    ./lib/gdb/command/frame_filters.py:21:1: F401 'copy' imported but unused
+	    ./lib/gdb/command/frame_filters.py:22:1: F401 'gdb.FrameIterator.FrameIterator' imported but unused
+	    ./lib/gdb/command/frame_filters.py:23:1: F401 'gdb.FrameDecorator.FrameDecorator' imported but unused
+	    ./lib/gdb/command/frame_filters.py:25:1: F401 'itertools' imported but unused
+	    ./lib/gdb/command/frame_filters.py:179:17: E712 comparison to True should be 'if cond is True:' or 'if cond:'
+
+	Change-Id: I4f49c0cb430359ee872222600c61d9c5283b09ab
+
+2021-10-02  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-10-01  Luis Machado  <luis.machado@linaro.org>
+
+	Fix build failure for 32-bit targets
+	When building master GDB, I ran into the following:
+
+	binutils-gdb/gdb/bt-utils.c: In function 'int libbacktrace_print(void*, uintptr_t, const char*, int, const char*)':
+	binutils-gdb/gdb/bt-utils.c:93:44: error: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'uintptr_t {aka unsigned int}' [-Werror=format=]
+	   snprintf (buf, sizeof (buf), "0x%lx ", pc);
+
+	Fix this by using %PRIxPTR as opposed to %lx.
+
+2021-10-01  Nick Clifton  <nickc@redhat.com>
+
+	Fix mistake in RX assembler documentation (special section names)
+
+2021-10-01  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	[gdb/symtab] Fix htab_find_slot call in read_call_site_scope
+	In read_call_site_scope we have:
+	...
+	  call_site_local.pc = pc;
+	  slot = htab_find_slot (cu->call_site_htab, &call_site_local, INSERT);
+	...
+
+	The call passes a call_site pointer as element.  OTOH, the hashtab is created
+	using hash_f == core_addr_hash and eq_f == core_addr_eq, so the element
+	will be accessed through a CORE_ADDR pointer.
+
+	This is not wrong (at least in C), given that pc is the first field in
+	call_site.
+
+	Nevertheless, as in call_site_for_pc, make the htab_find_slot call match the
+	used hash_f and eq_f by using &pc instead:
+	...
+	  slot = htab_find_slot (cu->call_site_htab, &pc, INSERT);
+	...
+
+	Tested on x86_64-linux.
+
+	Co-Authored-By: Tom de Vries <tdevries@suse.de>
+
+2021-10-01  Andrea Corallo  <andrea.corallo@arm.com>
+
+	PATCH bfd: Fix linker warning for recently introduced arm attributes
+	2021-09-27  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* elf-bfd.h (NUM_KNOWN_OBJ_ATTRIBUTES): Update value to cover
+		'Tag_BTI_use' and 'Tag_PACRET_use'.
+
+2021-10-01  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/testsuite/dwarf: use options for rnglists/loclists procs
+	Change how rnglists and loclists procs to align them with how procs for
+	aranges (and other things in the DWARF assembler) work.  Instead of
+	using "args" (variable number of parameters in TCL) and command-line
+	style option arguments, use one leading "option" parameters, used as a
+	kind of key/value dictionary of options parsed using `parse_options`.
+
+	Change-Id: I63e60d17ae16a020ce4d6de44baf3d152ea42a1a
+
+2021-10-01  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/testsuite/dwarf: don't define nested procs for rnglists/loclists
+	When I wrote support for rnglists and loclists in the testsuite's DWARF
+	assembler, I made it with nested procs, for example proc "table" inside
+	proc "rnglists".  The intention was that this proc "table" could only be
+	used by the user while inside proc "rnglists"'s body.  I had chosen very
+	simple names, thinking there was no chance of name clashes.  I recently
+	learned that this is not how TCL works.  This ends up defining a proc
+	"table" in the current namespace ("Dwarf" in this case).
+
+	Things still work if you generate rnglists and loclists in the same
+	file, as each redefines its own procedures when executing.  But if a
+	user of the assembler happened to define a convenience "table" or
+	"start_end" procedure, for example, it would get overriden.
+
+	I'd like to change how this works to reduce the chances of a name clash.
+
+	 - Move the procs out of each other, so they are not defined in a nested
+	   fashion.
+	 - Prefix them with "_rnglists_" or "_loclists_".
+	 - While calling $body in the various procs, temporarily make the procs
+	   available under their "short" name.  For example, while in rngllists'
+	   body, make _rnglists_table available as just "table".  This allows
+	   existing code to keep working and keeps it not too verbose.
+	 - Modify with_override to allow the overriden proc to not exist.  In
+	   that case, the temporary proc is deleted on exit.
+
+	Note the non-conforming indentation when calling with_override in
+	_loclists_list.  This is on purpose: as we implement more loclists (and
+	rnglists) entry types, the indentation would otherwise get larger and
+	larger without much value for readability.  So I think it's reasonable
+	here to put them on the same level.
+
+	Change-Id: I7bb48d26fcb0dba1ae4dada05c0c837212424328
+
+2021-10-01  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove TYPE_FIELD_NAME and FIELD_NAME macros
+	Remove the `TYPE_FIELD_NAME` and `FIELD_NAME` macros, changing all the
+	call sites to use field::name directly.
+
+	Change-Id: I6900ae4e1ffab1396e24fb3298e94bf123826ca6
+
+2021-10-01  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: add field::name / field::set_name
+	Add the `name` and `set_name` methods on `struct field`, in order to
+	remove `FIELD_NAME` and `TYPE_FIELD_NAME` macros.  In this patch, the
+	macros are changed to use `field::name`, so all the call sites that are
+	used to set the field's name are changed to use `field::set_name`.
+	The next patch will remove the macros completely.
+
+	Note that because of the name clash between the existing field named
+	`name` and the new method, I renamed the field `m_name`.  It is not
+	private per-se, because we can't make `struct field` a non-POD yet, but
+	it should be considered private anyway (not accessed outside `struct
+	field`).
+
+	Change-Id: If16ddbca4e0c39d0ff9da420bb5cdebe5b9b0896
+
+2021-10-01  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-30  Sergio Durigan Junior  <sergiodj@sergiodj.net>
+
+	[PR gdb/28369] Use get_shell on gdb/ser-pipe.c
+	PR gdb/28369 reports that gdb/ser-pipe.c has an 'execl' function call
+	with a hard-coded "/bin/sh" as its argument.  We've had 'get_shell'
+	for a while now, which is conscious about the SHELL environment and a
+	better alternative to always calling "/bin/sh".
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28369
+
+2021-09-30  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Add untested for missing xml support in gdb.base/valgrind*.exp
+	Add untested in case missing xml support is detected in test-cases
+	gdb.base/valgrind*.exp.
+
+	Tested on x86_64-linux.
+
+2021-09-30  Przemyslaw Wirkus  <przemyslaw.wirkus@arm.com>
+
+	arm: enable Cortex-R52+ CPU
+	Patch is adding Cortex-R52+ as 'cortex-r52plus' command line
+	flag for -mcpu option.
+
+	bfd/
+
+		* cpu-arm.c: New Cortex-R52+ CPU.
+
+	gas/
+
+		* NEWS: Update docs.
+		* config/tc-arm.c: New Cortex-R52+ CPU.
+		* doc/c-arm.texi: Update docs.
+		* testsuite/gas/arm/cpu-cortex-r52plus.d: New test.
+
+2021-09-30  Przemyslaw Wirkus  <przemyslaw.wirkus@arm.com>
+
+	aarch64: Enable Cortex-X2 CPU
+	This patch is adding support for Cortex-X2 CPU.
+
+	gas:
+
+		* NEWS: Update docs.
+		* config/tc-aarch64.c: Add Cortex-X2.
+		* doc/c-aarch64.texi: Update docs.
+
+2021-09-30  Przemyslaw Wirkus  <przemyslaw.wirkus@arm.com>
+
+	aarch64: Enable Cortex-A710 CPU
+	This patch is adding support for Cortex-A710 CPU.
+
+	gas/
+
+	        * NEWS: Update docs.
+	        * config/tc-aarch64.c: Add Cortex-A710.
+	        * doc/c-aarch64.texi: Update docs.
+
+2021-09-30  Przemyslaw Wirkus  <przemyslaw.wirkus@arm.com>
+
+	aarch64: Enable Cortex-A510 CPU
+	This patch is adding support for Cortex-A510 CPU.
+
+	gas/
+
+		* NEWS: Update docs.
+		* config/tc-aarch64.c: Add Cortex-A510.
+		* doc/c-aarch64.texi: Update docs.
+
+2021-09-30  Przemyslaw Wirkus  <przemyslaw.wirkus@arm.com>
+
+	aarch64: Update AArch64 features command line options docs 2/2
+	Patch is only sorting by 'Extension` column 'Architecture Extension'
+	table.
+
+	gas/
+
+		* doc/c-aarch64.texi: Update docs.
+
+2021-09-30  Przemyslaw Wirkus  <przemyslaw.wirkus@arm.com>
+
+	aarch64: Update AArch64 features command line options docs 1/2
+	Patch is improving entries in "Architecture extensions" table in GAS
+	documentation.
+
+	gas/
+
+		* doc/c-aarch64.texi: Update docs.
+
+2021-09-30  Przemyslaw Wirkus  <przemyslaw.wirkus@arm.com>
+
+	aarch64: add armv9-a architecture to -march
+	Patch is adding new 'armv9-a` command line flag to -march for AArch64.
+
+	gas/
+
+		* config/tc-aarch64.c: Add 'armv9-a' command line flag.
+		* docs/c-aarch64.text: Update docs.
+		* NEWS: Update docs.
+
+	include/
+
+		* opcode/aarch64.h (AARCH64_FEATURE_V9): New define.
+		(AARCH64_ARCH_V9): New define.
+
+2021-09-30  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/testsuite: make runto_main not pass no-message to runto
+	As follow-up to this discussion:
+
+	  https://sourceware.org/pipermail/gdb-patches/2020-August/171385.html
+
+	... make runto_main not pass no-message to runto.  This means that if we
+	fail to run to main, for some reason, we'll emit a FAIL.  This is the
+	behavior we want the majority of (if not all) the time.
+
+	Without this, we rely on tests logging a failure if runto_main fails,
+	otherwise.  They do so in a very inconsisteny mannet, sometimes using
+	"fail", "unsupported" or "untested".  The messages also vary widly.
+	This patch removes all these messages as well.
+
+	Also, remove a few "fail" where we call runto (and not runto_main).  by
+	default (without an explicit no-message argument), runto prints a
+	failure already.  In two places, gdb.multi/multi-re-run.exp and
+	gdb.python/py-pp-registration.exp, remove "message" passed to runto.
+	This removes a few PASSes that we don't care about (but FAILs will still
+	be printed if we fail to run to where we want to).  This aligns their
+	behavior with the rest of the testsuite.
+
+	Change-Id: Ib763c98c5f4fb6898886b635210d7c34bd4b9023
+
+2021-09-30  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdbsupport: make gdb_mkostemp_cloexec return a scoped_fd
+	This encourages the callers to use automatic file descriptor management.
+
+	Change-Id: I137a81df6f3607b457e28c35aafde8ed6f3a3344
+
+2021-09-30  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdbsupport: make gdb_open_cloexec return scoped_fd
+	Make gdb_open_cloexec return a scoped_fd, to encourage using automatic
+	management of the file descriptor closing.  Except in the most trivial
+	cases, I changed the callers to just release the fd, which retains their
+	existing behavior.  That will allow the transition to using scoped_fd
+	more to go gradually, one caller at a time.
+
+	Change-Id: Ife022b403f96e71d5ebb4f1056ef6251b30fe554
+
+2021-09-30  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdbsupport: move gdb_file_up to its own file
+	The following patches wants to change gdb_fopen_cloexec and
+	gdb_mkostemp_cloexec to return a scoped_fd.  Doing this causes a cyclic
+	include between scoped_fd.h and filestuff.h, that both want to include
+	each other.  scoped_fd.h includes filestuff.h because of the
+	scoped_fd::to_file method's return value.  filestuff.h would then
+	include scoped_fd.h for gdb_fopen_cloexec's and gdb_mkostemp_cloexec's
+	return values.
+
+	To fix that, move gdb_file_up to its own file, gdb_file.h.
+
+	Change-Id: Ic82a48914b2aacee8f14af535b7469245f88b93d
+
+2021-09-30  Dimitar Dimitrov  <dimitar@dinux.eu>
+
+	ld: pru: Fix resource_table output section alignment
+	My commit 261980de18b added alignment for the resource table symbol.
+	But it is wrong.  The Linux remoteproc driver loads and interprets the
+	contents of the .resource_table ELF section, not of a table symbol.
+
+	Without this patch, if the linker happens to output padding for symbol
+	alignment, then the resource table contents as viewed by the kernel
+	loader would "shift" and look corrupted.
+
+	ld/ChangeLog:
+
+		* scripttempl/pru.sc  (.resource_table): Align the output
+		section, not the first symbol.
+
+2021-09-30  Tom Tromey  <tromey@adacore.com>
+
+	Fix Windows crash from stop_pc change
+	The "make thread_suspend_state::stop_pc optional" patch caused a
+	regression on Windows when using shared libraries.  I tracked this
+	down to an unguarded use of stop_pc() in the TARGET_WAITKIND_LOADED
+	case of handle_inferior_event.  This patch fixes the bug by ensuring
+	that the stop PC is set at this point.
+
+2021-09-30  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Use untested in gdb.debuginfod/fetch_src_and_symbols.exp
+	With running test-case gdb.debuginfod/fetch_src_and_symbols.exp with target
+	board unix/-bad, I get:
+	...
+	gcc: error: unrecognized command line option '-bad'^M
+	compiler exited with status 1
+	gdb compile failed, gcc: error: unrecognized command line option '-bad'
+	FAIL: gdb.debuginfod/fetch_src_and_symbols.exp: compile
+	...
+
+	Replace the FAIL with the usual:
+	...
+	UNTESTED: gdb.debuginfod/fetch_src_and_symbols.exp: failed to compile
+	...
+
+	Tested on x86_64-linux.
+
+2021-09-30  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Remove redundant FAIL in gdb.base/info-os.exp
+	When running test-case gdb.base/info-os.exp with target board unix/-bad, I run
+	into:
+	...
+	gdb compile failed, gcc: error: unrecognized command line option '-bad'
+	UNTESTED: gdb.base/info-os.exp: failed to prepare
+	FAIL: gdb.base/info-os.exp: cannot compile test program
+	...
+
+	Remove the redundant FAIL.
+
+	Tested on x86_64-linux.
+
+2021-09-30  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix DUPLICATE in gdb.base/info-os.exp
+	When running test-case gdb.base/info-os.exp, I run into:
+	...
+	PASS: gdb.base/info-os.exp: get threads
+	PASS: gdb.base/info-os.exp: get threads
+	DUPLICATE: gdb.base/info-os.exp: get threads
+	...
+
+	Fix this not doing pass followed by exp_continue in gdb_test_multiple.
+
+	Tested on x86_64-linux.
+
+2021-09-30  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Check compilation result in gdb.dwarf2/dw2-opt-structptr.exp
+	When running test-case gdb.dwarf2/dw2-opt-structptr.exp with target board
+	unix/-bad, I get:
+	...
+	gdb compile failed, gcc: error: unrecognized command line option '-bad'
+	UNTESTED: gdb.dwarf2/dw2-opt-structptr.exp: dw2-opt-structptr.exp
+	UNTESTED: gdb.dwarf2/dw2-opt-structptr.exp: failed to compile
+	ERROR: (dw2-opt-structptr) No such file or directory
+	UNRESOLVED: gdb.dwarf2/dw2-opt-structptr.exp: console: set print object on
+	...
+
+	Merge the two UNTESTEDs.
+
+	Fix the UNRESOLVED by checking result of compilation.
+
+	Tested on x86_64-linux.
+
+2021-09-30  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Check compilation result in gdb.base/structs.exp
+	When running test-case gdb.base/structs.exp with target board unix/-bad, I
+	get:
+	...
+	gdb compile failed, gcc: error: unrecognized command line option '-bad'
+	UNTESTED: gdb.base/structs.exp: failed to prepare
+	ERROR: tcl error sourcing src/gdb/testsuite/gdb.base/structs.exp.
+	ERROR: can't read "use_gdb_stub": no such variable
+	...
+
+	Fix this by checking the compilation result.
+
+	Fix the resulting DUPLICATEs using with_test_prefix.
+
+	Tested on x86_64-linux.
+
+2021-09-30  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Prepare nodebug exec in gdb.base/cvexpr.exp
+	When running test-case gdb.base/cvexpr.exp with target board unix/-bad, I get:
+	...
+	gdb compile failed, gcc: error: unrecognized command line option '-bad'
+	ERROR: tcl error sourcing src/gdb/testsuite/gdb.base/cvexpr.exp.
+	ERROR: can't read "use_gdb_stub": no such variable
+	...
+
+	This is triggered in a part of the test that claims to require no debug
+	information, but uses the exec containing either dwarf or ctf.
+
+	Fix this by preparing another executable compiled with nodebug, and using
+	that one instead.
+
+	Also use with_test_prefix to mark the nodebug part, such that we have:
+	...
+	gdb compile failed, gcc: error: unrecognized command line option '-bad'
+	UNTESTED: gdb.base/cvexpr.exp: dwarf: failed to prepare
+	gdb compile failed, gcc: error: unrecognized command line option '-bad'
+	UNTESTED: gdb.base/cvexpr.exp: nodebug: failed to prepare
+	...
+
+	Tested on x86_64-linux.
+
+2021-09-30  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix DUPLICATE in gdb.base/cvexpr.exp
+	Fix:
+	...
+	DUPLICATE: gdb.base/cvexpr.exp: ptype int * restrict
+	...
+	using with_test_prefix.
+
+	Tested on x86_64-linux.
+
+2021-09-30  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Check compilation result in gdb.base/call-sc.exp
+	When running test-case gdb.base/call-sc.exp with target board unix/-bad, I
+	get:
+	...
+	gdb compile failed, gcc: error: unrecognized command line option '-bad'
+	UNTESTED: gdb.base/call-sc.exp: failed to prepare
+	ERROR: tcl error sourcing src/gdb/testsuite/gdb.base/call-sc.exp.
+	ERROR: can't read "use_gdb_stub": no such variable
+	...
+
+	Fix this by checking the compilation result.
+
+	Fix the resulting DUPLICATE:
+	...
+	DUPLICATE: gdb.base/call-sc.exp: failed to prepare
+	...
+	using with_test_prefix.
+
+	Tested on x86_64-linux.
+
+2021-09-30  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix untested messages in gdb.mi/*.exp
+	The effect of:
+	...
+	untested "y.exp"
+	...
+	in a gdb.x/y.exp is:
+	...
+	UNTESTED: gdb.x/y.exp: y.exp
+	...
+	which is a bit pointless.
+
+	Replace these untested messages in gdb.mi/*.exp with the usual "failed to
+	compile".
+
+	Likewise for an:
+	...
+	untested $testname
+	...
+	where the variable is undefined.
+
+	Tested on x86_64-linux.
+
+2021-09-30  Nick Clifton  <nickc@redhat.com>
+
+	make objcopy fail if it is asked to redefine symbols in an object file containing LTO information.
+		* objcopy.c (filter_symbols): Fail if attempting to dredefine
+		symbols in an LTO object file.
+
+2021-09-30  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix full buffer in gdb.rust/dwindex.exp
+	On ubuntu 18.04.5, I run into:
+	...
+	(gdb) mt print objfiles dwindex^M
+	^M
+	Object file build/gdb/testsuite/outputs/gdb.rust/dwindex/dwindex:  \
+	  Objfile at 0x55dab0b87a50, bfd at 0x55dab0b0cfa0, 1095 minsyms^M
+	^M
+	Psymtabs:^M
+	vendor/compiler_builtins/src/int/specialized_div_rem/mod.rs at 0x55dab0db0720^M
+	  ...
+	library/std/src/sys/unix/stdio.rs at 0x55dab0d96320^M
+	ERROR: internal buffer is full.
+	UNRESOLVED: gdb.rust/dwindex.exp: check if index present
+	...
+
+	Fix this by using -lbl in proc ensure_gdb_index.
+
+	Tested on x86_64-linux.
+
+2021-09-30  Libor Bukata  <libor.bukata@oracle.com>
+
+	Add Solaris specific ELF note processing
+	Add elfcore_grok_solaris_note function that enables to
+	obtain process status, register values, and program info
+	from Solaris's core files.
+
+	bfd/
+		* elf.c (elfcore_grok_solaris_note): Solaris specific ELF
+		note parser. Better GDB's coredump analysis on Solaris...
+		(elfcore_grok_solaris_note_impl): New function.
+		(elfcore_grok_solaris_prstatus): New function.
+		(elfcore_grok_solaris_info): New function.
+		(elfcore_grok_solaris_lwpstatus): New function.
+		(elf_parse_notes): Added "CORE" groker element.
+	include/
+		* elf/common.h: Add note segment constants for core files on
+		Solaris systems.
+
+2021-09-30  Frederic Cambus  <fred@statdns.com>
+
+	Add support to readelf for reading OpenBSD ELF core notes.
+		* readelf.c (get_openbsd_elfcore_note_type): New function.
+		(process_note): Add support for OpenBSD core notes.
+
+2021-09-30  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-29  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.base/break-interp.exp for ld.so without debug
+	When running test-case gdb.base/break-interp.exp on openSUSE Leap 42.3, I get:
+	...
+	(gdb) info addr dl_main^M
+	Symbol "dl_main" is at 0x1750 in a file compiled without debugging.^M
+	(gdb) FAIL: gdb.base/break-interp.exp: info addr dl_main
+	...
+	while the regexp expects "Symbol \"dl_main\" is a function at address $hex\\."
+
+	Fix this by also accepting this variant.
+
+	Tested on x86_64-linux.
+
+2021-09-29  H.J. Lu  <hjl.tools@gmail.com>
+
+	Add a testcase for PR binutils/27202
+		PR binutils/27202
+		* testsuite/gas/elf/dwarf-5-loc0.d: New file.
+		* testsuite/gas/elf/dwarf-5-loc0.s: Likewise.
+		* testsuite/gas/elf/elf.exp: Run dwarf-5-loc0.
+
+2021-09-29  Pedro Alves  <pedro@palves.net>
+
+	Fix gdb.multi/multi-term-settings.exp race
+	The gdb.multi/multi-term-settings.exp testcase sometimes fails like so:
+
+	 Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.multi/multi-term-settings.exp ...
+	 FAIL: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: stop with control-c (SIGINT)
+
+	It's easier to reproduce if you stress the machine at the same time, like e.g.:
+
+	  $ stress -c 24
+
+	Looking at gdb.log, we see:
+
+	 (gdb) attach 60422
+	 Attaching to program: build/gdb/testsuite/outputs/gdb.multi/multi-term-settings/multi-term-settings, process 60422
+	 [New Thread 60422.60422]
+	 Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
+	 Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.31.so...
+	 Reading symbols from /lib64/ld-linux-x86-64.so.2...
+	 (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
+	 0x00007f2fc2485334 in __GI___clock_nanosleep (clock_id=<optimized out>, clock_id@entry <mailto:clock_id@entry>=0, flags=flags@entry <mailto:flags@entry>=0, req=req@entry <mailto:req@entry>=0x7ffe23126940, rem=rem@entry <mailto:rem@entry>=0x0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78
+	 78	../sysdeps/unix/sysv/linux/clock_nanosleep.c: No such file or directory.
+	 (gdb) PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: inf2: attach
+	 set schedule-multiple on
+	 (gdb) PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: set schedule-multiple on
+	 info inferiors
+	   Num  Description       Connection                         Executable
+	   1    process 60404     1 (extended-remote localhost:2349) build/gdb/testsuite/outputs/gdb.multi/multi-term-settings/multi-term-settings
+	 * 2    process 60422     1 (extended-remote localhost:2349) build/gdb/testsuite/outputs/gdb.multi/multi-term-settings/multi-term-settings
+	 (gdb) PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: info inferiors
+	 pid=60422, count=46
+	 pid=60422, count=47
+	 pid=60422, count=48
+	 pid=60422, count=49
+	 pid=60422, count=50
+	 pid=60422, count=51
+	 pid=60422, count=52
+	 pid=60422, count=53
+	 pid=60422, count=54
+	 pid=60422, count=55
+	 pid=60422, count=56
+	 pid=60422, count=57
+	 pid=60422, count=58
+	 pid=60422, count=59
+	 pid=60422, count=60
+	 pid=60422, count=61
+	 pid=60422, count=62
+	 pid=60422, count=63
+	 pid=60422, count=64
+	 pid=60422, count=65
+	 pid=60422, count=66
+	 pid=60422, count=67
+	 pid=60422, count=68
+	 pid=60422, count=69
+	 pid=60404, count=54
+	 pid=60404, count=55
+	 pid=60404, count=56
+	 pid=60404, count=57
+	 pid=60404, count=58
+	 PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: continue
+	 Quit
+	 (gdb) FAIL: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: stop with control-c (SIGINT)
+
+	If you look at the testcase's sources, you'll see that the intention
+	is to resumes the program with "continue", wait to see a few of those
+	"pid=..., count=..." lines, and then interrupt the program with
+	Ctrl-C.  But somehow, that resulted in GDB printing "Quit", instead of
+	the Ctrl-C stopping the program with SIGINT.
+
+	Here's what is happening:
+
+	 #1 - those "pid=..., count=..." lines we see above weren't actually
+	      output by the inferior after it has been continued (see #1).
+	      Note that "inf1_how" and "inf2_how" are "attach".  What happened
+	      is that those "pid=..., count=..." lines were output by the
+	      inferiors _before_ they were attached to.  We see them at that
+	      point instead of earlier, because that's where the testcase
+	      reads from the inferiors' spawn_ids.
+
+	 #2 - The testcase mistakenly thinks those "pid=..., count=..." lines
+	      happened after the continue was processed by GDB, meaning it has
+	      waited enough, and so sends the Ctrl-C.  GDB hasn't yet passed
+	      the terminal to the inferior, so the Ctrl-C results in that
+	      Quit.
+
+	The fix here is twofold:
+
+	 #1 - flush inferior output right after attaching
+
+	 #2 - consume the "Continuing" printed by "continue", indicating the
+	      inferior has the terminal.  This is the same as done throughout
+	      the testsuite to handle this exact problem of sending Ctrl-C too
+	      soon.
+
+	gdb/testsuite/ChangeLog:
+	yyyy-mm-dd  Pedro Alves  <pedro@palves.net <mailto:pedro@palves.net>>
+
+		* gdb.multi/multi-term-settings.exp (create_inferior): Flush
+		inferior output.
+		(coretest): Use $gdb_test_name.  After issuing "continue", wait
+		for "Continuing".
+
+	Change-Id: Iba7671dfe1eee6b98d29cfdb05a1b9aa2f9defb9
+
+2021-09-29  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Disable vgdb tests if xml not supported
+	I build gdb without xml support using --without-expat, and ran into:
+	...
+	(gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=22032^M
+	Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=22032^M
+	relaying data between gdb and process 22032^M
+	warning: Can not parse XML target description; XML support was disabled at \
+	  compile time^M
+	  ...
+	(gdb) PASS: gdb.base/valgrind-infcall.exp: continue #1
+	p gdb_test_infcall ()^M
+	Remote 'g' packet reply is too long (expected 560 bytes, got 800 bytes): ...^M
+	(gdb) FAIL: gdb.base/valgrind-infcall.exp: p gdb_test_infcall ()
+	...
+
+	After googling the error message with context valgrind gdbserver, I found
+	indications that the Remote 'g' packet reply error is due to missing xml
+	support.
+
+	And here ( https://www.valgrind.org/docs/manual/manual-core-adv.html ) I
+	found:
+	...
+	GDB version needed for ARM and PPC32/64.
+
+	You must use a GDB version which is able to read XML target description sent
+	by a gdbserver.  This is the standard setup if GDB was configured and built
+	with the "expat" library.  If your GDB was not configured with XML support, it
+	will report an error message when using the "target" command.  Debugging will
+	not work because GDB will then not be able to fetch the registers from the
+	Valgrind gdbserver.
+	...
+
+	So I guess I'm running into the same problem for x86_64.
+
+	Fix this by skipping all gdb.base/valgrind-*.exp tests if xml support is not
+	available.  Although only the gdb.base/valgrind-infcall*.exp produce fails,
+	the Remote 'g' packet reply error occurs in all tests, so it seems prudent to
+	disable them all.
+
+	Tested on x86_64-linux.
+
+2021-09-29  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.python/py-breakpoint.exp with python 2
+	With a gdb build using python 2.7, I run into:
+	...
+	(gdb) python \
+	  gdb.events.breakpoint_modified.connect(lambda bp: print(bp.enabled))^M
+	  File "<string>", line 1^M
+	    gdb.events.breakpoint_modified.connect(lambda bp: print(bp.enabled))^M
+	                                                          ^^M
+	SyntaxError: invalid syntax^M
+	Error while executing Python code.^M
+	(gdb) FAIL: gdb.python/py-breakpoint.exp: test_bkpt_auto_disable: \
+	  trap breakpoint_modified event
+	...
+
+	This is caused by the following:
+	- a lambda function body needs to be an expression
+	- in python 2, print is a statement, while in python 3 it's a function
+	- a function call is an expression, and a statement is not.
+
+	Fix this by defining a function print_bp_enabled:
+	...
+	def print_bp_enabled (bp):
+	    print (bp.enabled)
+	end
+	...
+	and using that instead.
+
+	Tested on x86_64-linux.
+
+2021-09-29  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix breakpoint detection in gdb.gdb/python-helper.exp
+	With a gdb configured to be somewhat minimal, while still supporting python:
+	...
+	$ gdb --configuration
+	This GDB was configured as follows:
+	   configure --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
+	             --with-auto-load-dir=$debugdir:$datadir/auto-load
+	             --with-auto-load-safe-path=$debugdir:$datadir/auto-load
+	             --without-expat
+	             --with-gdb-datadir=$install/share/gdb (relocatable)
+	             --with-jit-reader-dir=$install/lib64/gdb (relocatable)
+	             --without-libunwind-ia64
+	             --without-lzma
+	             --without-babeltrace
+	             --without-intel-pt
+	             --with-mpfr
+	             --without-xxhash
+	             --with-python=/usr
+	             --with-python-libdir=/usr/lib
+	             --with-debuginfod
+	             --without-guile
+	             --disable-source-highlight
+	             --with-separate-debug-dir=/usr/lib/debug
+	             --with-system-gdbinit=$devel/system-gdbinit
+	...
+	and using gcc 4.8 to build gdb (causing std::thread not to be used due to
+	PR28318) I ran into:
+	...
+	(gdb) PASS: gdb.gdb/python-helper.exp: start inner gdb
+	print 1^M
+	^M
+	Breakpoint 2, value_print () at src/gdb/valprint.c:1174^M
+	1174      scoped_value_mark free_values;^M
+	(xgdb) FAIL: gdb.gdb/python-helper.exp: hit breakpoint in inner gdb (timeout)
+	...
+
+	The problem is that the regexp expects "hit Breakpoint $decimal".  The "hit"
+	part is missing.
+
+	The "hit" is printed by maybe_print_thread_hit_breakpoint, when
+	show_thread_that_caused_stop returns true:
+	...
+	int
+	show_thread_that_caused_stop (void)
+	{
+	  return highest_thread_num > 1;
+	}
+	...
+	Apparently, that's not the case.
+
+	Fix this by removing "hit" from the regexp, making the regexp more similar to
+	what is used in say, continue_to_breakpoint.
+
+	Tested on x86_64-linux.
+
+2021-09-29  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: fix build when libbacktrace and execinfo backtrace are not available
+	In this commit:
+
+	  commit abbbd4a3e0ca51132e7fb31a43f896d29894dae0
+	  Date:   Wed Aug 11 13:24:33 2021 +0100
+
+	      gdb: use libbacktrace to create a better backtrace for fatal signals
+
+	The build of GDB was broken iff, the execinfo backtrace API is not
+	available, and, libbacktrace is either disabled, or not usable.  In
+	this case you'll see build errors like this:
+
+	      CXX    bt-utils.o
+	    /home/username/src/binutils-gdb/gdb/bt-utils.c: In function 'void gdb_internal_backtrace()':
+	    /home/username/src/binutils-gdb/gdb/bt-utils.c:165:5: error: 'gdb_internal_backtrace_1' was not declared in this scope
+	         gdb_internal_backtrace_1 ();
+	         ^~~~~~~~~~~~~~~~~~~~~~~~
+
+	This commit fixes the issue by guarding the call to
+	gdb_internal_backtrace_1 with '#ifdef GDB_PRINT_INTERNAL_BACKTRACE',
+	which is only defined when one of the backtrace libraries are
+	available.
+
+2021-09-29  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb/doc: use 'standard error stream' instead of 'stderr' in some places
+	With this commit:
+
+	  commit 91f2597bd24d171c1337a4629f8237aa47c59082
+	  Date:   Thu Aug 12 18:24:59 2021 +0100
+
+	      gdb: print backtrace for internal error/warning
+
+	I included some references to 'stderr', which, it was pointed out,
+	would be better written as 'standard error stream'.  See:
+
+	  https://sourceware.org/pipermail/gdb-patches/2021-September/182225.html
+
+	This commit replaces the two instances of 'stderr' that I introduced.
+
+2021-09-29  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: fix manor -> manner typo in some comments
+	In a recent commit I used 'manor' in some comments rather than
+	'manner'.  This commit fixes those two mistakes.
+
+	I also looked through the gdb/ tree and found one additional instance
+	of this mistake that this commit also fixes.
+
+2021-09-29  Alan Modra  <amodra@gmail.com>
+
+	PR27202, readelf -wL doesn't work on ".loc 0"
+	For DWARF revision 4 and earlier, display_debug_lines_decoded
+	populates the file_table array with entries read from .debug_line
+	after the directory table.  file_table[0] contains the first entry.
+	DWARF rev 4 line number programs index this entry as file number one.
+	DWARF revision 5 changes .debug_line format quite extensively, and in
+	particular gives file number zero a meaning.
+
+		PR 27202
+		* dwarf.c (display_debug_lines_decoded): Correct indexing used
+		for DWARF5 files.
+
+2021-09-29  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: enable target_async around stop_all_threads call in process_initial_stop_replies
+	The following scenario hangs:
+
+	 - maint set target-non-stop on
+	 - `gdbserver --attach`
+	 - a multi-threaded program
+
+	For example:
+
+	Terminal 1:
+
+	    $ gnome-calculator&
+	    [1] 495731
+	    $ ../gdbserver/gdbserver --once --attach :1234 495731
+	    Attached; pid = 495731
+	    Listening on port 1234
+
+	Terminal 2:
+
+	    $ ./gdb -nx -q --data-directory=data-directory /usr/bin/gnome-calculator -ex "maint set target-non-stop on" -ex "tar rem :1234"
+	    Reading symbols from /usr/bin/gnome-calculator...
+	    (No debugging symbols found in /usr/bin/gnome-calculator)
+	    Remote debugging using :1234
+	    * hangs *
+
+	What happens is:
+
+	 - The protocol between gdb and gdbserver is in non-stop mode, but the
+	   user-visible behavior is all-stop
+	 - On connect, gdbserver sends one stop reply for one thread that is
+	   stops, the others stay running
+	 - In process_initial_stop_replies, gdb calls stop_all_threads to stop
+	   these other threads, because we are using the all-stop user-visible
+	   mode
+	 - stop_all_threads sends a stop request for all the running threads and
+	   then waits for resulting events
+	 - At this point, the remote target is in target_async(0) mode, which
+	   makes stop_all_threads not consider it for events
+	 - stop_all_threads loops indefinitely (it does not even block
+	   indefinitely, it is in an infinite busy loop) because there are no
+	   event sources.  wait_one_event returns a TARGET_WAITKIND_NO_RESUMED
+	   wait status.
+
+	Fix that by making the remote target async around the stop_all_threads
+	call.
+
+	I haven't implemented it because I'm not sure how to do it, but I think
+	it would be a good idea to have, in stop_all_threads / wait_one /
+	handle_one, an assert to check that if we are expecting one or more
+	event, then there are some targets that are in a state where they can
+	supply some events.  Otherwise, we'll necessarily be stuck in this
+	infinite loop, and it's probably due to a bug in GDB.  I'm not too sure
+	where to put this or how to express it though.  Perhaps in
+	stop_all_threads, here:
+
+		  for (int i = 0; i < waits_needed; i++)
+		    {
+		      wait_one_event event = wait_one ();
+		      *here*
+		      if (handle_one (event))
+			break;
+		    }
+
+	If at that point, the returned event is TARGET_WAITKIND_NO_RESUMED,
+	there's a problem.  We expect some event, because we've asked some
+	threads to stop, but all targets are answering that they won't have any
+	events for us.  That's a contradiction, and a sign that something has
+	gone wrong.  It could perhaps event be:
+
+	    gdb_assert (event.ws.kind != TARGET_WAITKIND_NO_RESUMED);
+
+	in handle_one, as the idea is the same in prepare_for_detach.
+
+	A bit more sophisticated would be: we know which targets we are
+	expecting waits from, since we know which threads we have asked to
+	stop.  So if any of these targets returns TARGET_WAITKIND_NO_RESUMED,
+	something is fishy.
+
+	Add a test that tests attaching with gdbserver's --attach flag to a
+	multi-threaded program, and then connecting to it.  Without the fix, the
+	test reproduces the hang.
+
+	Change-Id: If6f6690a4887ca66693ef1af64791dda4c65f24f
+
+2021-09-29  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-29  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: fix darwin-nat build (again)
+	I made a mistake in the previous patch.  Adjust the format string to
+	match the arguments.
+
+	Change-Id: I4d45e0e0adb78eb3b5a06ba1a5287155940056ba
+
+2021-09-29  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: fix darwin-nat build
+	There are two errors of this kind:
+
+	      CXX    darwin-nat.o
+	    /Users/smarchi/src/binutils-gdb/gdb/darwin-nat.c:1175:19: error: format specifies type 'unsigned long' but the argument has type 'ULONGEST' (aka 'unsigned long long') [-Werror,-Wformat]
+		 ptid.pid (), ptid.tid ());
+			      ^~~~~~~~~~~
+
+	Fix them by using ptid_t's to_string method.
+
+	Change-Id: I52087d5f7ee0fc01ac8b3f87d4db0217cb0d7cc7
+
+2021-09-29  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb.base/foll-fork.exp: accept "info breakpoints" output in any order
+	The test currently requires the "inf 1" breakpoint to be before the "inf
+	2" breakpoint.  This is not always the case:
+
+	    info breakpoints 2
+	    Num     Type           Disp Enb Address            What
+	    2       breakpoint     keep y   <MULTIPLE>
+	    2.1                         y   0x0000555555554730 in callee at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:9 inf 2
+	    2.2                         y   0x0000555555554730 in callee at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:9 inf 1
+	    (gdb) FAIL: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: info breakpoints
+
+	Since add_location_to_breakpoint uses only the address as a criterion to
+	sort locations, the order of locations at the same address is not
+	stable: it will depend on the insertion order.  Here, the insertion
+	order comes from the order of SALs when creating the breakpoint, which
+	can vary from machine to machine.  While it would be more user-friendly
+	to have a more stable order for printed breakpoint locations, it doesn't
+	really matter for this test, and it would be hard to define an order
+	that will be the same everywhere, all the time.
+
+	So, loosen the regexp to accept "inf 1" and "inf 2" in any order.
+
+	Co-Authored-By: Pedro Alves <pedro@palves.net>
+	Change-Id: I5ada2e0c6ad0669e0d161bfb6b767229c0970d16
+
+2021-09-28  Cooper Qu  <cooper.qu@linux.alibaba.com>
+
+	RISC-V: Fix wrong version number when arch contains 'p'.
+	When specify a default version for p extension in
+	riscv_supported_std_ext[](elfxx-riscv.c) and assembling with
+	-march=rv32imacp, the c extension's version in attribute will become
+	0p0, the expectation is 2p0.
+
+	TODO: Remember to add testcase when we have supported standrad p in
+	the future.
+
+	bfd/
+		PR gas/28372
+		* elfxx-riscv.c (riscv_parsing_subset_version): Break if p
+		represent the 'p' extension.
+
+	Change-Id: Ia4e0cf26f3d7d07acaee8cefd86707ecac663a59
+
+2021-09-28  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: Allow to add numbers in the prefixed extension names.
+	We need to allow adding numbers in the prefixed extension names, since
+	the zve<32,64><d,f,x> extensions are included in the forzen rvv v1.0 spec
+	recently.  But there are two restrictions as follows,
+
+	* The extension name ends with <number>p is invalid, since this may
+	be confused with extension with <number>.0 version.  We report errors
+	for this case.
+
+	Invalid format: [z|h|s|zvm|x][0-9a-z]+[0-9]+p
+
+	* The extension name ends with numbers is valid, but the numbers will
+	be parsed as major version, so try to avoid naming extensions like this.
+
+	bfd/
+		* elfxx-riscv.c (riscv_recognized_prefixed_ext): Renamed from
+		riscv_valid_prefixed_ext/
+		(riscv_parsing_subset_version): The extensions end with <number>p
+		is forbidden, we already report the detailed errors in the
+		riscv_parse_prefixed_ext, so clean the code and unused parameters.
+		(riscv_parse_std_ext): Updated.
+		(riscv_parse_prefixed_ext): Rewrite the parser to allow numbers
+		in the prefixed extension names.
+	gas/
+		* testsuite/gas/riscv/march-fail-invalid-x-01.d: New testcases.
+		* testsuite/gas/riscv/march-fail-invalid-x-02.d: Likewise.
+		* testsuite/gas/riscv/march-fail-invalid-z-01.d: Likewise.
+		* testsuite/gas/riscv/march-fail-invalid-z-02.d: Likewise.
+		* testsuite/gas/riscv/march-fail-invalid.l: Likewise.
+		* testsuite/gas/riscv/march-fail-version-x.d: Removed.
+		* testsuite/gas/riscv/march-fail-version-z.d: Likewise.
+		* testsuite/gas/riscv/march-fail-version.l: Likewise.
+
+2021-09-28  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: print backtrace for internal error/warning
+	This commit builds on previous work to allow GDB to print a backtrace
+	of itself when GDB encounters an internal-error or internal-warning.
+	This fixes PR gdb/26377.
+
+	There's not many places where we call internal_warning, and I guess in
+	most cases the user would probably continue their debug session.  And
+	so, in order to avoid cluttering up the output, by default, printing
+	of a backtrace is off for internal-warnings.
+
+	In contrast, printing of a backtrace is on by default for
+	internal-errors, as I figure that in most cases hitting an
+	internal-error is going to be the end of the debug session.
+
+	Whether a backtrace is printed or not can be controlled with the new
+	settings:
+
+	  maintenance set internal-error backtrace on|off
+	  maintenance show internal-error backtrace
+
+	  maintenance set internal-warning backtrace on|off
+	  maintenance show internal-warning backtrace
+
+	Here is an example of what an internal-error now looks like with the
+	backtrace included:
+
+	  (gdb) maintenance internal-error blah
+	  ../../src.dev-3/gdb/maint.c:82: internal-error: blah
+	  A problem internal to GDB has been detected,
+	  further debugging may prove unreliable.
+	  ----- Backtrace -----
+	  0x5c61ca gdb_internal_backtrace_1
+	  	../../src.dev-3/gdb/bt-utils.c:123
+	  0x5c626d _Z22gdb_internal_backtracev
+	  	../../src.dev-3/gdb/bt-utils.c:165
+	  0xe33237 internal_vproblem
+	  	../../src.dev-3/gdb/utils.c:393
+	  0xe33539 _Z15internal_verrorPKciS0_P13__va_list_tag
+	  	../../src.dev-3/gdb/utils.c:470
+	  0x1549652 _Z14internal_errorPKciS0_z
+	  	../../src.dev-3/gdbsupport/errors.cc:55
+	  0x9c7982 maintenance_internal_error
+	  	../../src.dev-3/gdb/maint.c:82
+	  0x636f57 do_simple_func
+	  	../../src.dev-3/gdb/cli/cli-decode.c:97
+	   .... snip, lots more backtrace lines ....
+	  ---------------------
+	  ../../src.dev-3/gdb/maint.c:82: internal-error: blah
+	  A problem internal to GDB has been detected,
+	  further debugging may prove unreliable.
+	  Quit this debugging session? (y or n) y
+
+	  This is a bug, please report it.  For instructions, see:
+	  <https://www.gnu.org/software/gdb/bugs/>.
+
+	  ../../src.dev-3/gdb/maint.c:82: internal-error: blah
+	  A problem internal to GDB has been detected,
+	  further debugging may prove unreliable.
+	  Create a core file of GDB? (y or n) n
+
+	My hope is that this backtrace might make it slightly easier to
+	diagnose GDB issues if all that is provided is the console output, I
+	find that we frequently get reports of an assert being hit that is
+	located in pretty generic code (frame.c, value.c, etc) and it is not
+	always obvious how we might have arrived at the assert.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26377
+
+2021-09-28  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: use libbacktrace to create a better backtrace for fatal signals
+	GDB recently gained the ability to print a backtrace when a fatal
+	signal is encountered.  This backtrace is produced using the backtrace
+	and backtrace_symbols_fd API available in glibc.
+
+	However, in order for this API to actually map addresses to symbol
+	names it is required that the application (GDB) be compiled with
+	-rdynamic, which GDB is not by default.
+
+	As a result, the backtrace produced often looks like this:
+
+	  Fatal signal: Bus error
+	  ----- Backtrace -----
+	  ./gdb/gdb[0x80ec00]
+	  ./gdb/gdb[0x80ed56]
+	  /lib64/libc.so.6(+0x3c6b0)[0x7fc2ce1936b0]
+	  /lib64/libc.so.6(__poll+0x4f)[0x7fc2ce24da5f]
+	  ./gdb/gdb[0x15495ba]
+	  ./gdb/gdb[0x15489b8]
+	  ./gdb/gdb[0x9b794d]
+	  ./gdb/gdb[0x9b7a6d]
+	  ./gdb/gdb[0x9b943b]
+	  ./gdb/gdb[0x9b94a1]
+	  ./gdb/gdb[0x4175dd]
+	  /lib64/libc.so.6(__libc_start_main+0xf3)[0x7fc2ce17e1a3]
+	  ./gdb/gdb[0x4174de]
+	  ---------------------
+
+	This is OK if you have access to the exact same build of GDB, you can
+	manually map the addresses back to symbols, however, it is next to
+	useless if all you have is a backtrace copied into a bug report.
+
+	GCC uses libbacktrace for printing a backtrace when it encounters an
+	error.  In recent commits I added this library into the binutils-gdb
+	repository, and in this commit I allow this library to be used by
+	GDB.  Now (when GDB is compiled with debug information) the backtrace
+	looks like this:
+
+	  ----- Backtrace -----
+	  0x80ee08 gdb_internal_backtrace
+	  	../../src/gdb/event-top.c:989
+	  0x80ef0b handle_fatal_signal
+	  	../../src/gdb/event-top.c:1036
+	  0x7f24539dd6af ???
+	  0x7f2453a97a5f ???
+	  0x154976f gdb_wait_for_event
+	  	../../src/gdbsupport/event-loop.cc:613
+	  0x1548b6d _Z16gdb_do_one_eventv
+	  	../../src/gdbsupport/event-loop.cc:237
+	  0x9b7b02 start_event_loop
+	  	../../src/gdb/main.c:421
+	  0x9b7c22 captured_command_loop
+	  	../../src/gdb/main.c:481
+	  0x9b95f0 captured_main
+	  	../../src/gdb/main.c:1353
+	  0x9b9656 _Z8gdb_mainP18captured_main_args
+	  	../../src/gdb/main.c:1368
+	  0x4175ec main
+	  	../../src/gdb/gdb.c:32
+	  ---------------------
+
+	Which seems much more useful.
+
+	Use of libbacktrace is optional.  If GDB is configured with
+	--disable-libbacktrace then the libbacktrace directory will not be
+	built, and GDB will not try to use this library.  In this case GDB
+	would try to use the old backtrace and backtrace_symbols_fd API.
+
+	All of the functions related to writing the backtrace of GDB itself
+	have been moved into the new files gdb/by-utils.{c,h}.
+
+2021-09-28  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	src-release.sh: add libbacktrace to GDB_SUPPORT_DIRS
+	After the previous commit that imported libbacktrace from gcc, this
+	commit updates src-release.sh so that the libbacktrace directory is
+	included in the gdb release tar file.
+
+	ChangeLog:
+
+		* src-release.sh (GDB_SUPPPORT_DIRS): Add libbacktrace.
+
+2021-09-28  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	Copy in libbacktrace from gcc
+	This copies in libbacktrace from the gcc repository as it was in the
+	commit 62e420293a293608f383d9b9c7f2debd666e9fc9.  GDB is going to
+	start using this library soon.
+
+	A dependency between GDB and libbacktrace has already been added to
+	the top level Makefile, so, after this commit, when building GDB,
+	libbacktrace will be built first.  However, libbacktrace is not yet
+	linked into GDB, or used by GDB in any way.
+
+	It is possible to stop libbacktrace being built by configuring the
+	tree with --disable-libbacktrace.
+
+	This commit does NOT update src-release.sh, that will be done in the
+	next commit, this commit ONLY imports libbacktrace from gcc.  This
+	means that if you try to make a release of GDB from exactly this
+	commit then the release tar file will not include libbacktrace.
+	However, as libbacktrace is an optional dependency this is fine.
+
+2021-09-28  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: Add a dependency between gdb and libbacktrace
+	GDB is going to start using libbacktrace, so add a build dependency.
+
+	ChangeLog:
+
+		* Makefile.def: Add all-gdb dependency on all-libbacktrace.
+		* Makefile.in: Regenerate.
+
+2021-09-28  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	top-level configure: setup target_configdirs based on repository
+	The top-level configure script is shared between the gcc repository
+	and the binutils-gdb repository.
+
+	The target_configdirs variable in the configure.ac script, defines
+	sub-directories that contain components that should be built for the
+	target using the target tools.
+
+	Some components, e.g. zlib, are built as both host and target
+	libraries.
+
+	This causes problems for binutils-gdb.  If we run 'make all' in the
+	binutils-gdb repository we end up trying to build a target version of
+	the zlib library, which requires the target compiler be available.
+	Often the target compiler isn't immediately available, and so the
+	build fails.
+
+	The problem with zlib impacted a previous attempt to synchronise the
+	top-level configure scripts from gcc to binutils-gdb, see this thread:
+
+	  https://sourceware.org/pipermail/binutils/2019-May/107094.html
+
+	And I'm in the process of importing libbacktrace in to binutils-gdb,
+	which is also a host and target library, and triggers the same issues.
+
+	I believe that for binutils-gdb, at least at the moment, there are no
+	target libraries that we need to build.
+
+	In the configure script we build three lists of things we want to
+	build, $configdirs, $build_configdirs, and $target_configdirs, we also
+	build two lists of things we don't want to build, $skipdirs and
+	$noconfigdirs.  We then remove anything that is in the lists of things
+	not to build, from the list of things that should be built.
+
+	My proposal is to add everything in target_configdirs into skipdirs,
+	if the source tree doesn't contain a gcc/ sub-directory.  The result
+	is that for binutils-gdb no target tools or libraries will be built,
+	while for the gcc repository, nothing should change.
+
+	If a user builds a unified source tree, then the target tools and
+	libraries should still be built as the gcc/ directory will be present.
+
+	I've tested a build of gcc on x86-64, and the same set of target
+	libraries still seem to get built.  On binutils-gdb this change
+	resolves the issues with 'make all'.
+
+	ChangeLog:
+
+		* configure: Regenerate.
+		* configure.ac (skipdirs): Add the contents of target_configdirs if
+		we are not building gcc.
+
+2021-09-28  Gleb Fotengauer-Malinovskiy  <glebfm@altlinux.org>
+
+	PR28391, strip/objcopy --preserve-dates *.a: cannot set time
+	After commit 985e0264516 copy_archive function began to pass invalid
+	values to the utimensat(2) function when it tries to preserve
+	timestamps in ar archives.  This happens because the bfd_stat_arch_elt
+	implementation for ar archives fills only the st_mtim.tv_sec part of
+	the st_mtim timespec structure, but leaves the st_mtim.tv_nsec part
+	and the whole st_atim timespec untouched leaving them uninitialized
+
+		PR 28391
+		* ar.c (extract_file): Clear buf for preserve_dates.
+		* objcopy.c (copy_archive): Likewise.
+
+2021-09-28  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: drop weak func attrs on module inits
+	When I first wrote this, I was thinking we'd scan all source files
+	that existed and generate a complete init list.  That means for any
+	particular build, we'd probably have a few functions that didn't
+	exist, so weak attributes was necessary.  What I ended up scanning
+	though was only the source files that went into a particular build.
+
+	There was another concern too: a source file might be included, but
+	the build settings would cause all of its contents to be skipped
+	(via CPP defines).  So scanning via naive grep would pick up names
+	not actually available.  A check of the source tree shows that we
+	never do this, and it's pretty easy to institute a policy that we
+	don't start (by at the very least including a stub init func).
+
+	The use of weak symbols ends up causing a problem in practice: for
+	a few modules (like profiling), nothing else pulls it in, so the
+	linker omits it entirely, which leads to the profiling module never
+	being available.  So drop the weak markings since we know all these
+	funcs will be available.
+
+2021-09-28  Cui,Lili  <lili.cui@intel.com>
+
+	x86: Print {bad} on invalid broadcast in OP_E_memory
+	Don't print broadcast for scalar_mode, and print {bad} for invalid broadcast.
+
+	gas/
+
+		PR binutils/28381
+		* testsuite/gas/i386/bad-bcast.s: Add a new testcase.
+		* testsuite/gas/i386/bad-bcast.d: Likewise.
+		* testsuite/gas/i386/bad-bcast-intel.d: New.
+
+	opcodes/
+
+		PR binutils/28381
+		* i386-dis.c (static struct): Add no_broadcast.
+		(OP_E_memory): Mark invalid broadcast with no_broadcast=1 and Print "{bad}"for it.
+		(intel_operand_size): mark invalid broadcast with no_broadcast=1.
+		(OP_XMM): Mark scalar_mode with no_broadcast=1.
+
+2021-09-28  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: use intrusive_list for linux-nat lwp_list
+	Replace the manually maintained linked list of lwp_info objects with
+	intrusive_list.  Replace the ALL_LWPS macro with all_lwps, which returns
+	a range.  Add all_lwps_safe as well, for use in iterate_over_lwps, which
+	currently iterates in a safe manner.
+
+	Change-Id: I355313502510acc0103f5eaf2fbde80897d6376c
+
+2021-09-28  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: add destructor to lwp_info
+	Replace the lwp_free function with a destructor.  Make lwp_info
+	non-copyable, since there is now a destructor (we wouldn't want an
+	lwp_info object getting copied and this->arch_private getting deleted
+	twice).
+
+	Change-Id: I09fcbe967e362566d3a06fed2abca2a9955570fa
+
+2021-09-28  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: make lwp_info non-POD
+	Initialize all fields in the class declaration directly.  This opens the
+	door to using intrusive_list, done in the following patch.
+
+	Change-Id: I38bb27410cd9ebf511d310bb86fe2ea1872c3b05
+
+2021-09-28  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-27  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb: don't share aspace/pspace on fork with "detach-on-fork on" and "follow-fork-mode child"
+	We found that when handling forks, two inferiors can unexpectedly share
+	their program space and address space.  To reproduce:
+
+	 1. Using a test program that forks...
+	 2. "set follow-fork-mode child"
+	 3. "set detach-on-fork on" (the default)
+	 4. run to a breakpoint somewhere after the fork
+
+	Step 4 should have created a new inferior:
+
+	    (gdb) info inferiors
+	      Num  Description       Connection           Executable
+	      1    <null>                                 /home/smarchi/build/wt/amd/gdb/fork
+	    * 2    process 251425    1 (native)           /home/smarchi/build/wt/amd/gdb/fork
+
+	By inspecting the state of GDB, we can see that the two inferiors now
+	share one program space and one address space:
+
+	Inferior 1:
+
+	    (top-gdb) p inferior_list.m_front.num
+	    $2 = 1
+	    (top-gdb) p inferior_list.m_front.aspace
+	    $3 = (struct address_space *) 0x5595e2520400
+	    (top-gdb) p inferior_list.m_front.pspace
+	    $4 = (struct program_space *) 0x5595e2520440
+
+	Inferior 2:
+
+	    (top-gdb) p inferior_list.m_front.next.num
+	    $5 = 2
+	    (top-gdb) p inferior_list.m_front.next.aspace
+	    $6 = (struct address_space *) 0x5595e2520400
+	    (top-gdb) p inferior_list.m_front.next.pspace
+	    $7 = (struct program_space *) 0x5595e2520440
+
+	You can then run inferior 1 again and the two inferiors will still
+	erroneously share their spaces, but already at this point this is wrong.
+
+	The cause of the bad {a,p}space sharing is in follow_fork_inferior.
+	When following the child and detaching from the parent, we just re-use
+	the parent's spaces, rather than cloning them.  When we switch back to
+	inferior 1 and run again, we find ourselves with two unrelated inferiors
+	sharing spaces.
+
+	Fix that by creating new spaces for the parent after having moved them
+	to the child.  My initial implementation created new spaces for the
+	child instead.  Doing this breaks doing "next" over fork().  When "next"
+	start, we record the symtab of the starting location.  When the program
+	stops, we compare that symtab with the symtab the program has stopped
+	at.  If the symtab or the line number has changed, we conclude the
+	"next" is done.  If we create a new program space for the child and copy
+	the parent's program space to it with clone_program_space, it creates
+	new symtabs for the child as well.  When the child stop, but still on
+	the fork() line, GDB thinks the "next" is done because the symtab
+	pointers no longer match.  In reality they are two symtab instances that
+	represent the same file.  But moving the spaces to the child and
+	creating new spaces for the parent, we avoid this problem.
+
+	Note that the problem described above happens today with "detach-on-fork
+	off" and "follow-fork-mode child", because we create new spaces for the
+	child.  This will have to be addressed later.
+
+	Test-wise, improve gdb.base/foll-fork.exp to set a breakpoint that is
+	expected to have a location in each inferiors.  Without the fix, when
+	the two inferiors erroneously share a program space, GDB reports a
+	single location.
+
+	Change-Id: Ifea76e14f87b9f7321fc3a766217061190e71c6e
+
+2021-09-27  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb.base/foll-fork.exp: use foreach_with_prefix to handle prefixes
+	No behavior change in the test expected, other than in the test names.
+
+	Change-Id: I111137483858ab0f23138439f2930009779a2b3d
+
+2021-09-27  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb.base/foll-fork.exp: rename variables
+	Rename the variables / parameters used to match the corresponding GDB
+	setting name, I find that easier to follow.
+
+	Change-Id: Idcbddbbb369279fcf1e808b11a8c478f21b2a946
+
+2021-09-27  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb.base/foll-fork.exp: refactor to restart GDB between each portion of the test
+	This test is difficult to follow and modify because the state of GDB is
+	preserved some tests.  Add a setup proc, which starts a new GDB and runs
+	to main, and use it in all test procs.  Use proc_with_prefix to avoid
+	duplicates.
+
+	The check_fork_catchpoints proc also seems used to check for follow-fork
+	support by checking if catchpoints are supported.  If they are not, it
+	uses "return -code return", which makes its caller return.  I find this
+	unnecessary complex, versus just returning a boolean.  Modify it to do
+	so.
+
+	Change-Id: I23e62b204286c5e9c5c86d2727f7d33fb126ed08
+
+2021-09-27  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb.base/foll-fork.exp: remove gating based on target triplet
+	It looks like this test has some code to check at runtime the support of
+	fork handling of the target (see check_fork_catchpoints).  So, it seems
+	to me that the check based on target triplet at the beginning of the
+	test is not needed.  This kind of gating is generally not desirable,
+	because we wouldn't think of updating it when adding fork support to a
+	target.  For example, FreeBSD supports fork, but it wasn't listed here.
+
+	Change-Id: I6b55f2298edae6b37c3681fb8633d8ea1b5aabee
+
+2021-09-27  Simon Marchi  <simon.marchi@efficios.com>
+
+	gdb.base/foll-fork.exp: remove DUPLICATEs
+	Remove DUPLICATEs, and and at the same time replace two uses of
+	gdb_test_multiple with gdb_test.  I don't think using gdb_test_multiple
+	is necessary here.
+
+	Change-Id: I8dcf097c3364e92d4f0e11f0c0f05dbb88e86742
+
+2021-09-27  Nick Alcock  <nick.alcock@oracle.com>
+
+	libctf, lookup: fix bounds of pptrtab lookup
+	An off-by-one bug in the check for pptrtab lookup meant that we could
+	access the pptrtab past its bounds (*well* past its bounds),
+	particularly if we called ctf_lookup_by_name in a child dict with "*foo"
+	where "foo" is a type that exists in the parent but not the child and no
+	previous lookups by name have been carried out.  (Note that "*foo" is
+	not even a valid thing to call ctf_lookup_by_name with: foo * is.
+	Nonetheless, users sometimes do call ctf_lookup_by_name with invalid
+	content, and it should return ECTF_NOTYPE, not crash.)
+
+	ctf_pptrtab_len, as its name suggests (and as other tests of it in
+	ctf-lookup.c confirm), is one higher than the maximum valid permissible
+	index, so the comparison is wrong.
+
+	(Test added, which should fail pretty reliably in the presence of this
+	bug on any machine with 4KiB pages.)
+
+	libctf/ChangeLog
+	2021-09-27  Nick Alcock  <nick.alcock@oracle.com>
+
+		* ctf-lookup.c (ctf_lookup_by_name_internal): Fix pptrtab bounds.
+		* testsuite/libctf-writable/pptrtab-writable-page-deep-lookup.*:
+		New test.
+
+2021-09-27  Nick Alcock  <nick.alcock@oracle.com>
+
+	libctf, testsuite: fix various warnings in tests
+	These warnings are all off by default, but if they do fire you get
+	spurious ERRORs when running make check-libctf.
+
+	libctf/ChangeLog
+	2021-09-27  Nick Alcock  <nick.alcock@oracle.com>
+
+		* testsuite/libctf-lookup/enum-symbol.c: Remove unused label.
+		* testsuite/libctf-lookup/conflicting-type-syms.c: Remove unused
+		variables.
+		* testsuite/libctf-regression/pptrtab.c: Likewise.
+		* testsuite/libctf-regression/type-add-unnamed-struct.c: Likewise.
+		* testsuite/libctf-writable/pptrtab.c: Likewise.
+		* testsuite/libctf-writable/reserialize-strtab-corruption.c:
+		Likewise.
+		* testsuite/libctf-regression/nonstatic-var-section-ld-r.c: Fix
+		format string.
+		* testsuite/libctf-regression/nonstatic-var-section-ld.c:
+		Likewise.
+		* testsuite/libctf-regression/nonstatic-var-section-ld.lk: Adjust.
+		* testsuite/libctf-writable/symtypetab-nonlinker-writeout.c: Fix
+		initializer.
+
+2021-09-27  Nick Alcock  <nick.alcock@oracle.com>
+
+	libctf: fix handling of CTF symtypetab sections emitted by older GCC
+	Older (pre-upstreaming) GCC emits a function symtypetab section of a
+	format never read by any extant libctf.  We can detect such CTF dicts by
+	the lack of the CTF_F_NEWFUNCINFO flag in their header, and we do so
+	when reading in the symtypetab section -- but if the set of symbols with
+	types is sufficiently sparse, even an older GCC will emit a function
+	index section.
+
+	In NEWFUNCINFO-capable compilers, this section will always be the exact
+	same length as the corresponding function section (each is an array of
+	uint32_t, associated 1:1 with each other). But this is not true for the
+	older compiler, for which the sections are different lengths.  We check
+	to see if the function symtypetab section and its index are the same
+	length, but we fail to skip this check when this is not a NEWFUNCINFO
+	dict, and emit a spurious corruption error for a CTF dict we could
+	have perfectly well opened and used.
+
+	Fix trivial: check the flag (and fix the terrible grammar of the error
+	message at the same time).
+
+	libctf/ChangeLog
+	2021-09-27  Nick Alcock  <nick.alcock@oracle.com>
+
+		* ctf-open.c (ctf_bufopen_internal): Don't complain about corrupt
+		function index symtypetab sections if this is an old-format
+		function symtypetab section (which should be ignored in any case).
+		Fix bad grammar.
+
+2021-09-27  Nick Alcock  <nick.alcock@oracle.com>
+
+	configure: regenerate in all projects that use libtool.m4
+	(including sim/, which has no changelog.)
+
+	bfd/ChangeLog
+	2021-09-27  Nick Alcock  <nick.alcock@oracle.com>
+
+		* configure: Regenerate.
+
+	binutils/ChangeLog
+	2021-09-27  Nick Alcock  <nick.alcock@oracle.com>
+
+		* configure: Regenerate.
+
+	gas/ChangeLog
+	2021-09-27  Nick Alcock  <nick.alcock@oracle.com>
+
+		* configure: Regenerate.
+
+	gprof/ChangeLog
+	2021-09-27  Nick Alcock  <nick.alcock@oracle.com>
+
+		* configure: Regenerate.
+
+	ld/ChangeLog
+	2021-09-27  Nick Alcock  <nick.alcock@oracle.com>
+
+		* configure: Regenerate.
+
+	libctf/ChangeLog
+	2021-09-27  Nick Alcock  <nick.alcock@oracle.com>
+
+		* configure: Regenerate.
+		* Makefile.in: Regenerate.
+
+	opcodes/ChangeLog
+	2021-09-27  Nick Alcock  <nick.alcock@oracle.com>
+
+		* configure: Regenerate.
+
+	zlib/ChangeLog
+	2021-09-27  Nick Alcock  <nick.alcock@oracle.com>
+
+		* configure: Regenerate.
+
+2021-09-27  Nick Alcock  <nick.alcock@oracle.com>
+
+	libctf: try several possibilities for linker versioning flags
+	Checking for linker versioning by just grepping ld --help output for
+	mentions of --version-script is inadequate now that Solaris 11.4
+	implements a --version-script with different semantics.  Try linking a
+	test program with a small wildcard-using version script with each
+	supported set of flags in turn, to make sure that linker versioning is
+	not only advertised but actually works.
+
+	The Solaris "GNU-compatible" linker versioning is not quite
+	GNU-compatible enough, but we can work around the differences by
+	generating a new version script that removes the comments from the
+	original (Solaris ld requires #-style comments), and making another
+	version script for libctf-nonbfd in particular which doesn't mention any
+	of the symbols that appear in libctf.la, to avoid Solaris ld introducing
+	corresponding new NOTYPE symbols to match the version script.
+
+	libctf/ChangeLog
+	2021-09-27  Nick Alcock  <nick.alcock@oracle.com>
+
+		PR libctf/27967
+		* configure.ac (VERSION_FLAGS): Replace with...
+		(ac_cv_libctf_version_script): ... this multiple test.
+		(VERSION_FLAGS_NOBFD): Substitute this too.
+		* Makefile.am (libctf_nobfd_la_LDFLAGS): Use it.  Split out...
+		(libctf_ldflags_nover): ... non-versioning flags here.
+		(libctf_la_LDFLAGS): Use it.
+		* libctf.ver: Give every symbol not in libctf-nobfd a comment on
+		the same line noting as much.
+
+2021-09-27  Nick Alcock  <nick.alcock@oracle.com>
+
+	libtool.m4: fix nm BSD flag detection
+	Libtool needs to get BSD-format (or MS-format) output out of the system
+	nm, so that it can scan generated object files for symbol names for
+	-export-symbols-regex support.  Some nms need specific flags to turn on
+	BSD-formatted output, so libtool checks for this in its AC_PATH_NM.
+	Unfortunately the code to do this has a pair of interlocking flaws:
+
+	 - it runs the test by doing an nm of /dev/null.  Some platforms
+	   reasonably refuse to do an nm on a device file, but before now this
+	   has only been worked around by assuming that the error message has a
+	   specific textual form emitted by Tru64 nm, and that getting this
+	   error means this is Tru64 nm and that nm -B would work to produce
+	   BSD-format output, even though the test never actually got anything
+	   but an error message out of nm -B.  This is fixable by nm'ing *nm
+	   itself* (since we necessarily have a path to it).
+
+	 - the test is entirely skipped if NM is set in the environment, on the
+	   grounds that the user has overridden the test: but the user cannot
+	   reasonably be expected to know that libtool wants not only nm but
+	   also flags forcing BSD-format output.  Worse yet, one such "user" is
+	   the top-level Cygnus configure script, which neither tests for
+	   nor specifies any BSD-format flags.  So platforms needing BSD-format
+	   flags always fail to set them when run in a Cygnus tree, breaking
+	   -export-symbols-regex on such platforms.  Libtool also needs to
+	   augment $LD on some platforms, but this is done unconditionally,
+	   augmenting whatever the user specified: the nm check should do the
+	   same.
+
+	   One wrinkle: if the user has overridden $NM, a path might have been
+	   provided: so we use the user-specified path if there was one, and
+	   otherwise do the path search as usual.  (If the nm specified doesn't
+	   work, this might lead to a few extra pointless path searches -- but
+	   the test is going to fail anyway, so that's not a problem.)
+
+	(Tested with NM unset, and set to nm, /usr/bin/nm, my-nm where my-nm is a
+	symlink to /usr/bin/nm on the PATH, and /not-on-the-path/my-nm where
+	*that* is a symlink to /usr/bin/nm.)
+
+	ChangeLog
+	2021-09-27  Nick Alcock  <nick.alcock@oracle.com>
+
+		PR libctf/27967
+		* libtool.m4 (LT_PATH_NM): Try BSDization flags with a user-provided
+		NM, if there is one.  Run nm on itself, not on /dev/null, to avoid
+		errors from nms that refuse to work on non-regular files.  Remove
+		other workarounds for this problem.  Strip out blank lines from the
+		nm output.
+
+2021-09-27  Nick Alcock  <nick.alcock@oracle.com>
+
+	libtool.m4: augment symcode for Solaris 11
+	This reports common symbols like GNU nm, via a type code of 'C'.
+
+	ChangeLog
+	2021-09-27  Nick Alcock  <nick.alcock@oracle.com>
+
+		PR libctf/27967
+		* libtool.m4 (lt_cv_sys_global_symbol_pipe): Augment symcode for
+		Solaris 11.
+
+2021-09-27  Nick Alcock  <nick.alcock@oracle.com>
+
+	libctf: link against libiberty before linking in libbfd or libctf-nobfd
+	This ensures that the CTF_LIBADD, which always contains at least this
+	when doing a shared link:
+
+	-L`pwd`/../libiberty/pic -liberty
+
+	appears in the link line before any requirements pulled in by libbfd.la,
+	which include -liberty but because it is install-time do not include the
+	-L`pwd`/../libiberty/pic portion (in an indirect dep like this, the path
+	comes from the libbfd.la file, and is an install path).  libiberty also
+	appears after libbfd in the link line by virtue of libctf-nobfd.la,
+	because libctf-nobfd has to follow libbfd in the link line, and that
+	needs symbols from libiberty too.
+
+	Without this, an installed liberty might well be pulled in by libbfd,
+	and if --enable-install-libiberty is not specified this libiberty might
+	be completely incompatible with what is being installed and break either
+	or boht of libbfd and libctf. (The specific problem observed here is
+	that bsearch_r was not present, but other problems might easily be
+	observed in future too.)
+
+	Because ld links against libctf, this has a tendency to break the system
+	linker at install time too, if installing with --prefix=/usr.  That's
+	quite unpleasant to recover from.
+
+	libctf/ChangeLog
+	2021-09-27  Nick Alcock  <nick.alcock@oracle.com>
+
+		PR libctf/27360
+		* Makefile.am (libctf_la_LIBADD): Link against libiberty
+		before pulling in libbfd.la or pulling in libctf-nobfd.la.
+		* Makefile.in: Regenerate.
+
+2021-09-27  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/build] Fix build with g++-4.8
+	When building g++-4.8, we run into:
+	...
+	src/gdb/dwarf2/read.c:919:5: error: multiple fields in union \
+	  'partial_die_info::<anonymous union>' initialized
+	...
+
+	This is due to:
+	...
+	    union
+	    {
+	      struct
+	      {
+	       CORE_ADDR lowpc = 0;
+	       CORE_ADDR highpc = 0;
+	      };
+	      ULONGEST ranges_offset;
+	    };
+	...
+
+	The error looks incorrect, given that only one union member is initialized,
+	and does not reproduce with newer g++.
+
+	Nevertheless, work around this by moving the initialization to a constructor.
+
+	[ I considered just removing the initialization, with the idea that access
+	should be guarded by has_pc_info, but I ran into one failure in the testsuite,
+	for gdb.base/check-psymtab.exp due to add_partial_symbol using lowpc without
+	checking has_pc_info. ]
+
+	Tested on x86_64-linux.
+
+2021-09-27  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: add setting to disable reading source code files
+	In some situations it is possible that a user might not want GDB to
+	try and access source code files, for example, the source code might
+	be stored on a slow to access network file system.
+
+	It is almost certainly possible that using some combination of 'set
+	directories' and/or 'set substitute-path' a user can trick GDB into
+	being unable to find the source files, but this feels like a rather
+	crude way to solve the problem.
+
+	In this commit a new option is add that stops GDB from opening and
+	reading the source files.  A user can run with source code reading
+	disabled if this is required, then re-enable later if they decide
+	that they now want to view the source code.
+
+2021-09-27  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: remove duplicate cmd_list_element declarations
+	For some reason we have two locations where cmd_list_elements are
+	declared, cli/cli-cmds.h and gdbcmd.h.  Worse still there is
+	duplication between these two locations.
+
+	In this commit I have moved all of the cmd_list_element declarations
+	from gdbcmd.h into cli/cli-cmds.h and removed the duplicates.
+
+	There should be no user visible changes after this commit.
+
+2021-09-27  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: prevent an assertion when computing the frame_id for an inline frame
+	I ran into this assertion while GDB was trying to unwind the stack:
+
+	  gdb/inline-frame.c:173: internal-error: void inline_frame_this_id(frame_info*, void**, frame_id*): Assertion `frame_id_p (*this_id)' failed.
+
+	That is, when building the frame_id for an inline frame, GDB asks for
+	the frame_id of the previous frame.  Unfortunately, no valid frame_id
+	was returned for the previous frame, and so the assertion triggers.
+
+	What is happening is this, I had a stack that looked something like
+	this (the arrows '->' point from caller to callee):
+
+	  normal_frame -> inline_frame
+
+	However, for whatever reason (e.g. broken debug information, or
+	corrupted stack contents in the inferior), when GDB tries to unwind
+	"normal_frame", it ends up getting back effectively the same frame,
+	thus the call stack looks like this to GDB:
+
+	  .-> normal_frame -> inline_frame
+	  |     |
+	  '-----'
+
+	Given such a situation we would expect GDB to terminate the stack with
+	an error like this:
+
+	  Backtrace stopped: previous frame identical to this frame (corrupt stack?)
+
+	However, the inline_frame causes a problem, and here's why:
+
+	When unwinding we start from the sentinel frame and call
+	get_prev_frame.  We eventually end up in get_prev_frame_if_no_cycle,
+	in here we create a raw frame, and as this is frame #0 we immediately
+	return.
+
+	However, eventually we will try to unwind the stack further.  When we
+	do this we inevitably needing to know the frame_id for frame #0, and
+	so, eventually, we end up in compute_frame_id.
+
+	In compute_frame_id we first find the right unwinder for this frame,
+	in our case (i.e. for inline_frame) the $pc is within the function
+	normal_frame, but also within a block associated with the inlined
+	function inline_frame, as such the inline frame unwinder claims this
+	frame.
+
+	Back in compute_frame_id we next compute the frame_id, for our
+	inline_frame this means a call to inline_frame_this_id.
+
+	The ID of an inline frame is based on the id of the previous frame, so
+	from inline_frame_this_id we call get_prev_frame_always, this
+	eventually calls get_prev_frame_if_no_cycle again, which creates
+	another raw frame and calls compute_frame_id (for frames other than
+	frame 0 we immediately compute the frame_id).
+
+	In compute_frame_id we again identify the correct unwinder for this
+	frame.  Our $pc is unchanged, however, the fact that the next frame is
+	of type INLINE_FRAME prevents the inline frame unwinder from claiming
+	this frame again, and so, the standard DWARF frame unwinder claims
+	normal_frame.
+
+	We return to compute_frame_id and call the standard DWARF function to
+	build the frame_id for normal_frame.
+
+	With the frame_id of normal_frame figured out we return to
+	compute_frame_id, and then to get_prev_frame_if_no_cycle, where we add
+	the ID for normal_frame into the frame_id cache, and return the frame
+	back to inline_frame_this_id.
+
+	From inline_frame_this_id we build a frame_id for inline_frame and
+	return to compute_frame_id, and then to get_prev_frame_if_no_cycle,
+	which adds the frame_id for inline_frame into the frame_id cache.
+
+	So far, so good.
+
+	However, as we are trying to unwind the complete stack, we eventually
+	ask for the previous frame of normal_frame, remember, at this point
+	GDB doesn't know the stack is corrupted (with a cycle), GDB still
+	needs to figure that out.
+
+	So, we eventually end up in get_prev_frame_if_no_cycle where we create
+	a raw frame and call compute_frame_id, remember, this is for the frame
+	before normal_frame.
+
+	The first task for compute_frame_id is to find the unwinder for this
+	frame, so all of the frame sniffers are tried in order, this includes
+	the inline frame sniffer.
+
+	The inline frame sniffer asks for the $pc, this request is sent up the
+	stack to normal_frame, which, due to its cyclic behaviour, tells GDB
+	that the $pc in the previous frame was the same as the $pc in
+	normal_frame.
+
+	GDB spots that this $pc corresponds to both the function normal_frame
+	and also the inline function inline_frame.  As the next frame is not
+	an INLINE_FRAME then GDB figures that we have not yet built a frame to
+	cover inline_frame, and so the inline sniffer claims this new frame.
+	Our stack is now looking like this:
+
+	  inline_frame -> normal_frame -> inline_frame
+
+	But, we have not yet computed the frame id for the outer most (on the
+	left) inline_frame.  After the frame sniffer has claimed the inline
+	frame GDB returns to compute_frame_id and calls inline_frame_this_id.
+
+	In here GDB calls get_prev_frame_always, which eventually ends up
+	in get_prev_frame_if_no_cycle again, where we create a raw frame and
+	call compute_frame_id.
+
+	Just like before, compute_frame_id tries to find an unwinder for this
+	new frame, it sees that the $pc is within both normal_frame and
+	inline_frame, but the next frame is, again, an INLINE_FRAME, so, just
+	like before the standard DWARF unwinder claims this frame.  Back in
+	compute_frame_id we again call the standard DWARF function to build
+	the frame_id for this new copy of normal_frame.
+
+	At this point the stack looks like this:
+
+	  normal_frame -> inline_frame -> normal_frame -> inline_frame
+
+	After compute_frame_id we return to get_prev_frame_if_no_cycle, where
+	we try to add the frame_id for the new normal_frame into the frame_id
+	cache, however, unlike before, we fail to add this frame_id as it is
+	a duplicate of the previous normal_frame frame_id.  Having found a
+	duplicate get_prev_frame_if_no_cycle unlinks the new frame from the
+	stack, and returns nullptr, the stack now looks like this:
+
+	  inline_frame -> normal_frame -> inline_frame
+
+	The nullptr result from get_prev_frame_if_no_cycle is fed back to
+	inline_frame_this_id, which forwards this to get_frame_id, which
+	immediately returns null_frame_id.  As null_frame_id is not considered
+	a valid frame_id, this is what triggers the assertion.
+
+	In summary then:
+
+	 - inline_frame_this_id currently assumes that as the inline frame
+	   exists, we will always get a valid frame back from
+	   get_prev_frame_always,
+
+	 - get_prev_frame_if_no_cycle currently assumes that it is safe to
+	   return nullptr when it sees a cycle.
+
+	Notice that in frame.c:compute_frame_id, this code:
+
+	  fi->this_id.value = outer_frame_id;
+	  fi->unwind->this_id (fi, &fi->prologue_cache, &fi->this_id.value);
+	  gdb_assert (frame_id_p (fi->this_id.value));
+
+	The assertion makes it clear that the this_id function must always
+	return a valid frame_id (e.g. null_frame_id is not a valid return
+	value), and similarly in inline_frame.c:inline_frame_this_id this
+	code:
+
+	  *this_id = get_frame_id (get_prev_frame_always (this_frame));
+	  /* snip comment */
+	  gdb_assert (frame_id_p (*this_id));
+
+	Makes it clear that every inline frame expects to be able to get a
+	previous frame, which will have a valid frame_id.
+
+	As I have discussed above, these assumptions don't currently hold in
+	all cases.
+
+	One possibility would be to move the call to get_prev_frame_always
+	forward from inline_frame_this_id to inline_frame_sniffer, however,
+	this falls foul of (in frame.c:frame_cleanup_after_sniffer) this
+	assertion:
+
+	  /* No sniffer should extend the frame chain; sniff based on what is
+	     already certain.  */
+	  gdb_assert (!frame->prev_p);
+
+	This assert prohibits any sniffer from trying to get the previous
+	frame, as getting the previous frame is likely to depend on the next
+	frame, I can understand why this assertion is a good thing, and I'm in
+	no rush to alter this rule.
+
+	The solution proposed here takes onboard feedback from both Pedro, and
+	Simon (see the links below).  The get_prev_frame_if_no_cycle function
+	is renamed to get_prev_frame_maybe_check_cycle, and will now not do
+	cycle detection for inline frames, even when we spot a duplicate frame
+	it is still returned.  This is fine, as, if the normal frame has a
+	duplicate frame-id then the inline frame will also have a duplicate
+	frame-id.  And so, when we reject the inline frame, the duplicate
+	normal frame, which is previous to the inline frame, will also be
+	rejected.
+
+	In inline-frame.c the call to get_prev_frame_always is no longer
+	nested inside the call to get_frame_id.  There are reasons why
+	get_prev_frame_always can return nullptr, for example, if there is a
+	memory error while trying to get the previous frame, if this should
+	happen then we now give a more informative error message.
+
+	Historical Links:
+
+	 Patch v2: https://sourceware.org/pipermail/gdb-patches/2021-June/180208.html
+	 Feedback: https://sourceware.org/pipermail/gdb-patches/2021-July/180651.html
+	           https://sourceware.org/pipermail/gdb-patches/2021-July/180663.html
+
+	 Patch v3: https://sourceware.org/pipermail/gdb-patches/2021-July/181029.html
+	 Feedback: https://sourceware.org/pipermail/gdb-patches/2021-July/181035.html
+
+	 Additional input: https://sourceware.org/pipermail/gdb-patches/2021-September/182040.html
+
+2021-09-27  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.base/dcache-flush.exp
+	When running test-case gdb.base/dcache-flush.exp on ubuntu 18.04.5, I run into:
+	...
+	(gdb) PASS: gdb.base/dcache-flush.exp: p var2
+	info dcache^M
+	Dcache 4096 lines of 64 bytes each.^M
+	Contains data for Thread 0x7ffff7fc6b80 (LWP 3551)^M
+	Line 0: address 0x7fffffffd4c0 [47 hits]^M
+	Line 1: address 0x7fffffffd500 [31 hits]^M
+	Line 2: address 0x7fffffffd5c0 [7 hits]^M
+	Cache state: 3 active lines, 85 hits^M
+	(gdb) FAIL: gdb.base/dcache-flush.exp: check dcache before flushing
+	...
+	The regexp expects "Contains data for process $decimal".
+
+	This is another case of thread_db_target::pid_to_str being used.
+
+	Fix this by updating the regexp.
+
+	Tested on x86_64-linux.
+
+2021-09-27  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Test sw watchpoint in gdb.threads/process-dies-while-detaching.exp
+	The test-case gdb.threads/process-dies-while-detaching.exp takes about 20s
+	when using hw watchpoints, but when forcing sw watchpoints (using the patch
+	mentioned in PR28375#c0), the test-case takes instead 3m14s.
+
+	Also, it show a FAIL:
+	...
+	(gdb) continue^M
+	Continuing.^M
+	Cannot find user-level thread for LWP 10324: generic error^M
+	(gdb) FAIL: gdb.threads/process-dies-while-detaching.exp: single-process:
+	continue: watchpoint: continue
+	...
+	for which PR28375 was filed.
+
+	Modify the test-case to:
+	- add the hw/sw axis to the watchpoint testing, to ensure that we
+	  observe the sw watchpoint behaviour also on can-use-hw-watchpoints
+	  architectures.
+	- skip the hw breakpoint testing if not supported
+	- set the sw watchpoint later to avoid making the test
+	  too slow.  This still triggers the same PR, but now takes just 24s.
+
+	This patch adds a KFAIL for PR28375.
+
+	Tested on x86_64-linux.
+
+2021-09-27  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: fix indentation in gdbtypes.c
+	Change-Id: I7bfbb9d349a1f474256800c45e28fe3b1de08771
+
+2021-09-27  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-26  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-26  Peter Bergner  <bergner@linux.ibm.com>
+
+	PowerPC: Enable mfppr mfppr32, mtppr and mtppr32 extended mnemonics on POWER5
+	SPR 896 and the mfppr mfppr32, mtppr and mtppr32 extended mnemonics were added
+	in ISA 2.03, so enable them on POWER5 and later.
+
+	opcodes/
+		* ppc-opc.c (powerpc_opcodes) <mfppr, mfppr32, mtppr, mtppr32>: Enable
+		on POWER5 and later.
+
+	gas/
+		* testsuite/gas/ppc/power5.s: New test.
+		* testsuite/gas/ppc/power5.d: Likewise.
+		* testsuite/gas/ppc/ppc.exp: Run it.
+		* testsuite/gas/ppc/power7.s: Remove tests for mfppr, mfppr32, mtppr
+		and mtppr32.
+		* testsuite/gas/ppc/power7.d: Likewise.
+
+2021-09-25  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Minimize gdb restarts
+	Minimize gdb restarts, applying the following rules:
+	- don't use prepare_for_testing unless necessary
+	- don't use clean_restart unless necessary
+
+	Also, if possible, replace build_for_executable + clean_restart
+	with prepare_for_testing for brevity.
+
+	Touches 68 test-cases.
+
+	Tested on x86_64-linux.
+
+2021-09-25  Alan Modra  <amodra@gmail.com>
+
+	PR28346, segfault attempting to disassemble raw binary
+	Don't attempt to access elf_section_data for non-ELF sections.
+
+		PR 28346
+		* elf32-xtensa.c (xtensa_read_table_entries): Return zero entries
+		for non-ELF.
+
+2021-09-25  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-24  Hans-Peter Nilsson  <hp@axis.com>
+
+	gas/testsuite/ld-elf/dwarf2-21.d: Pass -W
+	Required for the expected "CU:" to be emitted for long
+	source-paths.  See binutils/dwarf.c:
+
+	 if (do_wide || strlen (directory) < 76)
+	   printf (_("CU: %s/%s:\n"), directory, file_table[0].name);
+	 else
+	   printf ("%s:\n", file_table[0].name);
+
+	See also commit 5f410aa50ce2c, "testsuite/ld-elf/pr26936.d:
+	Pass -W."
+
+	gas/ChangeLog:
+		* testsuite/ld-elf/dwarf2-21.d: Pass -W.
+
+2021-09-24  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: change thread_info::name to unique_xmalloc_ptr, add helper function
+	This started out as changing thread_info::name to a unique_xmalloc_ptr.
+	That showed that almost all users of that field had the same logic to
+	get a thread's name: use thread_info::name if non-nullptr, else ask the
+	target.  Factor out this logic in a new thread_name free function.  Make
+	the field private (rename to m_name) and add some accessors.
+
+	Change-Id: Iebdd95f4cd21fbefc505249bd1d05befc466a2fc
+
+2021-09-24  Tom Tromey  <tom@tromey.com>
+
+	Move value_true to value.h
+	I noticed that value_true is declared in language.h and defined in
+	language.c.  However, as part of the value API, I think it would be
+	better in one of those files.  And, because it is very short, I
+	changed it to be an inline function in value.h.  I've also removed a
+	comment from the implementation, on the basis that it seems obsolete
+	-- if the change it suggests was needed, it probably would have been
+	done by now; and if it is needed in the future, odds are it would be
+	done differently anyway.
+
+	Finally, this patch also changes value_true and value_logical_not to
+	return a bool, and updates some uses.
+
+2021-09-24  Pedro Alves  <pedro@palves.net>
+
+	Make dcache multi-target-safe
+	By inspection, I noticed that this code in dcache.c is not
+	multi-target-aware:
+
+	  /* If this is a different inferior from what we've recorded,
+	     flush the cache.  */
+
+	  if (inferior_ptid != dcache->ptid)
+
+	This doesn't take into account that threads of different targets may
+	have the same ptid.
+
+	Fixed by also storing/comparing the process_stratum_target.
+
+	Tested on x86-64-linux-gnu, native and gdbserver.
+
+	Change-Id: I4d9d74052c696b72d28cb1c77b697b911725c8d3
+
+2021-09-24  Pedro Alves  <pedro@palves.net>
+
+	Fix 'FAIL: gdb.perf/disassemble.exp: python Disassemble().run()'
+	We currently have one FAIL while running "make check-perf":
+
+	  PerfTest::assemble, run ...
+	  python Disassemble().run()
+	  Traceback (most recent call last):
+	    File "<string>", line 1, in <module>
+	    File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/perftest.py", line 64, in run
+	      self.warm_up()
+	    File "<string>", line 25, in warm_up
+	  gdb.error: No symbol "ada_evaluate_subexp" in current context.
+	  Error while executing Python code.
+	  (gdb) FAIL: gdb.perf/disassemble.exp: python Disassemble().run()
+	  ...
+
+	The gdb.perf/disassemble.exp testcase debugs GDB with itself, runs to
+	main, and then disassembles a few GDB functions.  The problem is that
+	most(!) functions it is trying to disassemble are now gone...
+
+	This commit fixes the issue by simply picking some other functions to
+	disassemble.
+
+	It would perhaps be better to come up with some test program to
+	disassemble, one that would stay the same throughout the years,
+	instead of disassembling GDB itself.  I don't know why that wasn't
+	done to begin with.  I'll have to leave that for another rainy day,
+	though.
+
+	gdb/testsuite/
+	yyyy-mm-dd  Pedro Alves  <pedro@palves.net>
+
+		* gdb.perf/disassemble.py (Disassemble::warm_up): Disassemble
+		evaluate_subexp_do_call instead of ada_evaluate_subexp.
+		(Disassemble::warm_up): Disassemble "captured_main",
+		"run_inferior_call" and "update_global_location_list" instead of
+		"evaluate_subexp_standard" and "c_parse_internal".
+
+	Change-Id: I89d1cca89ce2e495dea5096e439685739cc0d3df
+
+2021-09-24  Pedro Alves  <pedro@palves.net>
+
+	Fix all PATH problems in testsuite/gdb.perf/
+	Currently "make check-perf" triggers ~40 PATH messages in gdb.sum:
+
+	  ...
+	  PATH: gdb.perf/backtrace.exp: python sys.path.insert(0, os.path.abspath("/home/pedro/rocm/gdb/build/gdb/../../src/gdb/testsuite/gdb.perf/lib"))
+	  PATH: gdb.perf/backtrace.exp: python exec (open ('/home/pedro/rocm/gdb/build/gdb/testsuite/outputs/gdb.perf/backtrace/backtrace.py').read ())
+	  ...
+
+	This commit fixes them.  E.g. before/after gdb.sum diff:
+
+	 -PASS: gdb.perf/backtrace.exp: python import os, sys
+	 -PASS: gdb.perf/backtrace.exp: python sys.path.insert(0, os.path.abspath("/home/pedro/rocm/gdb/build-master/gdb/../../src/gdb/testsuite/gdb.perf/lib"))
+	 -PATH: gdb.perf/backtrace.exp: python sys.path.insert(0, os.path.abspath("/home/pedro/rocm/gdb/build-master/gdb/../../src/gdb/testsuite/gdb.perf/lib"))
+	 -PASS: gdb.perf/backtrace.exp: python exec (open ('/home/pedro/rocm/gdb/build-master/gdb/testsuite/outputs/gdb.perf/backtrace/backtrace.py').read ())
+	 -PATH: gdb.perf/backtrace.exp: python exec (open ('/home/pedro/rocm/gdb/build-master/gdb/testsuite/outputs/gdb.perf/backtrace/backtrace.py').read ())
+	 +PASS: gdb.perf/backtrace.exp: setup perftest: python import os, sys
+	 +PASS: gdb.perf/backtrace.exp: setup perftest: python sys.path.insert(0, os.path.abspath("${srcdir}/gdb.perf/lib"))
+	 +PASS: gdb.perf/backtrace.exp: setup perftest: python exec (open ('${srcdir}/gdb.perf/backtrace.py').read ())
+
+	gdb/testsuite/
+	yyyy-mm-dd  Pedro Alves  <pedro@palves.net>
+
+		* lib/perftest.exp (PerfTest::_setup_perftest): Use
+		with_test_prefix.  Add explicit test names to python invocations,
+		with "$srcdir" not expanded.
+
+	Change-Id: I50a31b04b7abdea754139509e4a34ae9263118a4
+
+2021-09-24  Pedro Alves  <pedro@palves.net>
+
+	Fix all DUPLICATE problems in testsuite/gdb.perf/
+	Currently running "make check-perf" shows:
+
+	 ...
+	 # of duplicate test names       6008
+	 ...
+
+	All those duplicate test names come from gdb.perf/skip-command.exp.
+	This commit fixes them, using with_test_prefix.
+
+	gdb/testsuite/
+	yyyy-mm-dd  Pedro Alves  <pedro@palves.net>
+
+		* gdb.perf/skip-command.exp (run_skip_bench): Wrap each for
+		iteration in with_test_prefix.
+
+	Change-Id: I38501cf70bc6b60306ee7228996ee7bcd858dc1b
+
+2021-09-24  Tom Tromey  <tromey@adacore.com>
+
+	Fix handling of DW_AT_data_bit_offset
+	A newer version of GCC will now emit member locations using just
+	DW_AT_data_bit_offset, like:
+
+	 <3><14fe>: Abbrev Number: 1 (DW_TAG_member)
+	    <14ff>   DW_AT_name        : (indirect string, offset: 0x215e): nb_bytes
+	    <1503>   DW_AT_decl_file   : 1
+	    <1503>   DW_AT_decl_line   : 10
+	    <1504>   DW_AT_decl_column : 7
+	    <1505>   DW_AT_type        : <0x150b>
+	    <1509>   DW_AT_bit_size    : 31
+	    <150a>   DW_AT_data_bit_offset: 64
+
+	whereas earlier versions would emit something like:
+
+	 <3><164f>: Abbrev Number: 7 (DW_TAG_member)
+	    <1650>   DW_AT_name        : (indirect string, offset: 0x218d): nb_bytes
+	    <1654>   DW_AT_decl_file   : 1
+	    <1655>   DW_AT_decl_line   : 10
+	    <1656>   DW_AT_decl_column : 7
+	    <1657>   DW_AT_type        : <0x165f>
+	    <165b>   DW_AT_byte_size   : 4
+	    <165c>   DW_AT_bit_size    : 31
+	    <165d>   DW_AT_bit_offset  : 1
+	    <165e>   DW_AT_data_member_location: 8
+
+	That is, DW_AT_data_member_location is not emitted any more.  This is
+	a change due to the switch to DWARF 5 by default.
+
+	This change pointed out an existing bug in gdb, namely that the
+	attr_to_dynamic_prop depends on the presence of
+	DW_AT_data_member_location.  This patch moves the handling of
+	DW_AT_data_bit_offset into handle_data_member_location, and updates
+	attr_to_dynamic_prop to handle this new case.
+
+	A new test case is included.  This test fails with GCC 11, but passes
+	with an earlier version of GCC.
+
+2021-09-24  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Don't leave gdb instance running after function_range
+	A typical dwarf assembly test-case start like this:
+	...
+	standard_testfile .c -debug.S
+
+	set asm_file [standard_output_file $srcfile2]
+	Dwarf::assemble $asm_file {
+	  ...
+	}
+
+	if { [prepare_for_testing "failed to prepare" ${testfile} \
+		  [list $srcfile $asm_file] {nodebug}] } {
+	    return -1
+	}
+	...
+
+	When accidentally using build_for_executable instead of
+	prepare_for_testing (or intentionally using it but forgetting to add
+	clean_restart $binfile or some such) the mistake may not be caught, because
+	another gdb instance is still running, and we may silently end up testing
+	compiler-generated DWARF.
+
+	This can be caused by something relatively obvious, like an earlier
+	prepare_for_testing or clean_restart, but also by something more obscure like
+	function_range, which may even be triggered by dwarf assembly like this:
+	...
+	  {MACRO_AT_func {main}}
+	...
+
+	Fix this by calling gdb_exit at the end of function_range.
+
+	Also fix the fallout of that in test-case gdb.dwarf2/dw2-bad-elf.exp, where a
+	get_sizeof call used the gdb instance left lingering by function_range.
+
+	[ A better and more complete fix would add a new proc get_exec_info, that would
+	be called at the start of the dwarf assembly body:
+	...
+	Dwarf::assemble $asm_file {
+	  get_exec_info {main foo} {int void*}
+	...
+	that would:
+	- do a prepare_for_testing with $srcfile (roughtly equivalent to what
+	  MACRO_AT_func does,
+	- call function_range for all functions main and foo, without starting a
+	  new gdb instance
+	- set corresponding variables at the call-site: main_start, main_len,
+	  main_end, foo_start, foo_len, foo_end.
+	- get size for types int and void*
+	- set corresponding variables at the call-site: int_size, void_ptr_size.
+	- do a gdb_exit. ]
+
+	Tested on x86_64-linux.
+
+2021-09-24  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Use pie instead of -fpie/-pie
+	I noticed two test-cases where -fpie is used.  Using the canonical pie option
+	will usually get one -fPIE instead.
+
+	That choice is justified here in gdb_compile:
+	...
+	  # For safety, use fPIE rather than fpie. On AArch64, m68k, PowerPC
+	  # and SPARC, fpie can cause compile errors due to the GOT exceeding
+	  # a maximum size.  On other architectures the two flags are
+	  # identical (see the GCC manual). Note Debian9 and Ubuntu16.10
+	  # onwards default GCC to using fPIE.  If you do require fpie, then
+	  # it can be set using the pie_flag.
+	  set flag "additional_flags=-fPIE"
+	...
+
+	There is no indication that using -fpie rather than -fPIE is on purpose, so
+	use pie instead.
+
+	Tested on x86_64-linux.
+
+2021-09-24  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Factor out dump_info in gdb.testsuite/dump-system-info.exp
+	Factor out new proc dump_info in test-case gdb.testsuite/dump-system-info.exp,
+	and in the process:
+	- fix a few typos
+	- remove unnecessary "test -r /proc/cpuinfo"
+
+	Tested on x86_64-linux.
+
+	Co-Authored-By: Pedro Alves <pedro@palves.net>
+
+2021-09-24  Pedro Alves  <pedro@palves.net>
+
+	gdb/testsuite: Make it possible to use TCL variables in DWARF assembler loclists
+	It is currently not possible to use variables in locations lists.  For
+	example, with:
+
+	  diff --git a/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp b/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp
+	  index 6b4f5c8cbb8..cdbf948619f 100644
+	  --- a/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp
+	  +++ b/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp
+	  @@ -30,6 +30,8 @@ if {![dwarf2_support]} {
+	       return 0
+	   }
+
+	  +set myconst 0x123456
+	  +
+	   # Test with 32-bit and 64-bit DWARF.
+	   foreach_with_prefix is_64 {false true} {
+	       if { $is_64 } {
+	  @@ -49,6 +51,7 @@ foreach_with_prefix is_64 {false true} {
+		  global func1_addr func1_len
+		  global func2_addr func2_len
+		  global is_64
+	  +       global myconst
+
+		  # The CU uses the DW_FORM_loclistx form to refer to the .debug_loclists
+		  # section.
+	  @@ -107,7 +110,7 @@ foreach_with_prefix is_64 {false true} {
+			  list_ {
+			      # When in func1.
+			      start_length $func1_addr $func1_len {
+	  -                       DW_OP_constu 0x123456
+	  +                       DW_OP_constu $myconst
+				  DW_OP_stack_value
+			      }
+
+	we get:
+
+	  $ make check TESTS="*/loclists-multiple-cus.exp"
+	  ...
+	  gdb compile failed, build/gdb/testsuite/outputs/gdb.dwarf2/loclists-multiple-cus/loclists-multiple-cus-dw32.S: Assembler messages:
+	  build/gdb/testsuite/outputs/gdb.dwarf2/loclists-multiple-cus/loclists-multiple-cus-dw32.S:78: Error: leb128 operand is an undefined symbol: $myconst
+	  ...
+
+	That means $myconst was copied literally to the generated assembly
+	file.
+
+	This patch fixes it, by running subst on the location list body, in
+	the context of the caller.  The fix is applied to both
+	Dwarf::loclists::table::list_::start_length and
+	Dwarf::loclists::table::list_::start_end.
+
+	Reported-by: Zoran Zaric <Zoran.Zaric@amd.com>
+
+	Change-Id: I615a64431857242d9f477d5699e3732df1b31322
+
+2021-09-24  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix DUPLICATEs in gdb.dwarf2/implptr-64bit.exp
+	When running test-case gdb.dwarf2/implptr-64bit.exp with target board
+	unix/-m32, I noticed:
+	...
+	DUPLICATE: gdb.dwarf2/implptr-64bit.exp: failed to prepare
+	...
+
+	Fix this by using with_test_prefix.
+
+	Tested on x86_64-linux.
+
+2021-09-24  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix DUPLICATEs gdb.dwarf2/dw2-is-stmt.exp
+	Fix these DUPLICATEs by using with_test_prefix:
+	...
+	DUPLICATE: gdb.dwarf2/dw2-is-stmt.exp: ensure we saw a valid line pattern, 1
+	DUPLICATE: gdb.dwarf2/dw2-is-stmt.exp: ensure we saw a valid line pattern, 2
+	...
+
+	Tested on x86_64-linux.
+
+2021-09-24  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix set $var val in gdb.dwarf2/dw2-is-stmt.exp
+	When doing a testrun with:
+	...
+	$ make check RUNTESTFLAGS=$(cd $src/gdb/testsuite/; echo gdb.dwarf2/*.exp)
+	...
+	I ran into:
+	...
+	ERROR: tcl error sourcing gdb.dwarf2/dw2-is-stmt.exp.
+	ERROR: expected integer but got "dw2-abs-hi-pc-world.c"
+	    while executing
+	"incr i"
+	...
+
+	The variable i is set in gdb.dwarf2/dw2-abs-hi-pc.exp, and leaks to
+	gdb.dwarf2/dw2-is-stmt.exp.  It's not removed by gdb_cleanup_globals because i
+	is set as global variable by runtest.exp, which does:
+	...
+	for { set i 0 } { $i < $argc } { incr i } {
+	...
+	at toplevel but forgets to unset the variable.
+
+	Fix this by removing '$' in front of the variable name when doing set:
+	...
+	-set $i 0
+	+set i 0
+	...
+
+	Tested on x86_64-linux.
+
+2021-09-24  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix DUPLICATE in gdb.base/load-command.exp
+	Fix this duplicate:
+	...
+	DUPLICATE: gdb.base/load-command.exp: check initial value of the_variable
+	...
+	by using with_test_prefix.
+
+	Tested on x86_64-linux.
+
+2021-09-24  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Use pie/nopie instead of ldflags=-pie/-no-pie
+	I noticed two test-case that use ldflags=-pie and ldflags-no-pie, instead of
+	the canonical pie and nopie options, which would typically also add
+	additional_flags=-fPIE respectively additional_flags=-fno-pie.
+
+	There is no indication that this is on purpose, so replace these with pie and
+	nopie.
+
+	Tested on x86_64-linux.
+
+2021-09-24  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Add gdb.testsuite/dump-system-info.exp
+	When interpreting the testsuite results, it's often relevant what kind of
+	machine the testsuite ran on.  On a local machine one can just do
+	/proc/cpuinfo, but in case of running tests using a remote system
+	that distributes test runs to other remote systems that are not directly
+	accessible, that's not possible.
+
+	Fix this by dumping /proc/cpuinfo into the gdb.log, as well as lsb_release -a
+	and uname -a.
+
+	We could do this at the start of each test run, by putting it into unix.exp
+	or some such.  However, this might be too verbose, so we choose to put it into
+	its own test-case, such that it get triggered in a full testrun, but not when
+	running one or a subset of tests.
+
+	We put the test-case into the gdb.testsuite directory, which is currently the
+	only place in the testsuite where we do not test gdb.   [ Though perhaps this
+	could be put into a new gdb.info directory, since the test-case doesn't
+	actually test the testsuite. ]
+
+	Tested on x86_64-linux.
+
+2021-09-24  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-23  Tom Tromey  <tom@tromey.com>
+
+	Change pointer_type to a method of struct type
+	I noticed that pointer_type is declared in language.h and defined in
+	language.c.  However, it really has to do with types, so it should
+	have been in gdbtypes.h all along.
+
+	This patch changes it to be a method on struct type.  And, I went
+	through uses of TYPE_IS_REFERENCE and updated many spots to use the
+	new method as well.  (I didn't update ones that were in arch-specific
+	code, as I couldn't readily test that.)
+
+2021-09-23  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Support -fPIE/-fno-PIE/-pie/-no-pie in gdb_compile_rust
+	When running gdb.rust/*.exp test-cases with target board unix/-fPIE/-pie, I
+	run into:
+	...
+	builtin_spawn -ignore SIGHUP rustc --color never gdb.rust/watch.rs \
+	  -g -lm -fPIE -pie -o outputs/gdb.rust/watch/watch^M
+	error: Unrecognized option: 'f'^M
+	^M
+	compiler exited with status 1
+	...
+
+	The problem is that -fPIE and -fpie are gcc options, but for rust we use
+	rustc, which has different compilation options.
+
+	Fix this by translating the gcc options to rustc options in gdb_compile_rust,
+	similar to how that is done for ada in target_compile_ada_from_dir.
+
+	Likewise for unix/-fno-PIE/-no-pie.
+
+	Tested on x86_64-linux, with:
+	- native
+	- unix/-fPIE/-pie
+	- unix/-fno-PIE/-no-pie
+	specifically, on openSUSE Leap 15.2 both with package gcc-PIE:
+	- installed (making gcc default to PIE)
+	- uninstalled (making gcc default to non-PIE).
+	and rustc 1.52.1.
+
+2021-09-23  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Use pie instead of -fPIE -pie
+	Replace {additional_flags=-fPIE ldflags=-pie} with {pie}.
+
+	This makes sure that the test-cases properly error out when using target board
+	unix/-fno-PIE/-no-pie.
+
+	Tested on x86_64-linux.
+
+2021-09-23  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix probe test in gdb.base/break-interp.exp
+	When running test-case gdb.base/break-interp.exp on ubuntu 18.04.5, we have:
+	...
+	 (gdb) bt^M
+	 #0  0x00007eff7ad5ae12 in ?? () from break-interp-LDprelinkNOdebugNO^M
+	 #1  0x00007eff7ad71f50 in ?? () from break-interp-LDprelinkNOdebugNO^M
+	 #2  0x00007eff7ad59128 in ?? () from break-interp-LDprelinkNOdebugNO^M
+	 #3  0x00007eff7ad58098 in ?? () from break-interp-LDprelinkNOdebugNO^M
+	 #4  0x0000000000000002 in ?? ()^M
+	 #5  0x00007fff505d7a32 in ?? ()^M
+	 #6  0x00007fff505d7a94 in ?? ()^M
+	 #7  0x0000000000000000 in ?? ()^M
+	 (gdb) FAIL: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: \
+	         first backtrace: dl bt
+	...
+
+	Using the backtrace, the test-case tries to establish that we're stopped in
+	dl_main.
+
+	However, the backtrace only shows an address, because:
+	- the dynamic linker contains no minimal symbols and no debug info, and
+	- gdb is build without --with-separate-debug-dir so it can't find the
+	  corresponding .debug file, which does contain the mimimal symbols and
+	  debug info.
+
+	As in "[gdb/testsuite] Improve probe detection in gdb.base/break-probes.exp",
+	fix this by doing info probes and grepping for the address.
+
+	Tested on x86_64-linux.
+
+2021-09-23  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Improve probe detection in gdb.base/break-probes.exp
+	When running test-case gdb.base/break-probes.exp on ubuntu 18.04.5, we have:
+	...
+	 (gdb) run^M
+	 Starting program: break-probes^M
+	 Stopped due to shared library event (no libraries added or removed)^M
+	 (gdb) bt^M
+	 #0  0x00007ffff7dd6e12 in ?? () from /lib64/ld-linux-x86-64.so.2^M
+	 #1  0x00007ffff7dedf50 in ?? () from /lib64/ld-linux-x86-64.so.2^M
+	 #2  0x00007ffff7dd5128 in ?? () from /lib64/ld-linux-x86-64.so.2^M
+	 #3  0x00007ffff7dd4098 in ?? () from /lib64/ld-linux-x86-64.so.2^M
+	 #4  0x0000000000000001 in ?? ()^M
+	 #5  0x00007fffffffdaac in ?? ()^M
+	 #6  0x0000000000000000 in ?? ()^M
+	 (gdb) UNSUPPORTED: gdb.base/break-probes.exp: probes not present on this system
+	...
+
+	Using the backtrace, the test-case tries to establish that we're stopped in
+	dl_main, which is used as proof that we're using probes.
+
+	However, the backtrace only shows an address, because:
+	- the dynamic linker contains no minimal symbols and no debug info, and
+	- gdb is build without --with-separate-debug-dir so it can't find the
+	  corresponding .debug file, which does contain the mimimal symbols and
+	  debug info.
+
+	Fix this by instead printing the pc and grepping for the value in the
+	info probes output:
+	...
+	(gdb) p /x $pc^M
+	$1 = 0x7ffff7dd6e12^M
+	(gdb) info probes^M
+	Type Provider Name           Where              Object                      ^M
+	  ...
+	stap rtld     init_start     0x00007ffff7dd6e12 /lib64/ld-linux-x86-64.so.2 ^M
+	  ...
+	(gdb)
+	...
+
+	Tested on x86_64-linux.
+
+2021-09-23  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Handle failing probe detection in gdb.base/break-probes.exp
+	When running test-case gdb.base/break-probes.exp on ubuntu 18.04.5, we have:
+	...
+	 (gdb) bt^M
+	 #0  0x00007ffff7dd6e12 in ?? () from /lib64/ld-linux-x86-64.so.2^M
+	 #1  0x00007ffff7dedf50 in ?? () from /lib64/ld-linux-x86-64.so.2^M
+	 #2  0x00007ffff7dd5128 in ?? () from /lib64/ld-linux-x86-64.so.2^M
+	 #3  0x00007ffff7dd4098 in ?? () from /lib64/ld-linux-x86-64.so.2^M
+	 #4  0x0000000000000001 in ?? ()^M
+	 #5  0x00007fffffffdaac in ?? ()^M
+	 #6  0x0000000000000000 in ?? ()^M
+	 (gdb) FAIL: gdb.base/break-probes.exp: ensure using probes
+	...
+
+	The test-case intends to emit an UNTESTED in this case, but fails to do so
+	because it tries to do it in a regexp clause in a gdb_test_multiple, which
+	doesn't trigger.  Instead, a default clause triggers which produces the FAIL.
+
+	Also the use of UNTESTED is not appropriate, and we should use UNSUPPORTED
+	instead.
+
+	Fix this by silencing the FAIL, and emitting an UNSUPPORTED after the
+	gdb_test_multiple:
+	...
+	 if { ! $using_probes } {
+	+    unsupported "probes not present on this system"
+	     return -1
+	 }
+	...
+
+	Tested on x86_64-linux.
+
+2021-09-23  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Use early-out style in gdb.base/break-probes.exp
+	Reduce indentation and improve readability in test-case
+	gdb.base/break-probes.exp by replacing:
+	...
+	if { <cond> } {
+	  <lots-of-code>
+	}
+	...
+	with:
+	...
+	if { ! <cond> } {
+	  return -1
+	}
+	<lots-of-code>
+	...
+
+	Tested on x86_64-linux.
+
+2021-09-23  Pedro Alves  <pedro@palves.net>
+
+	Test that frame info/IDs are stable/consistent
+	This adds a testcase that tests that the unwinder produces consistent
+	frame info and frame IDs by making sure that "info frame" shows the
+	same result when stopped at a function (level == 0), compared to when
+	we find the same frame in the stack at a level > 0.
+
+	E.g., on x86-64, right after running to main, we see:
+
+	  (gdb) info frame
+	  Stack level 0, frame at 0x7fffffffd340:
+	   rip = 0x555555555168 in main (gdb.base/backtrace.c:41); saved rip = 0x7ffff7dd90b3
+	   source language c.
+	   Arglist at 0x7fffffffd330, args:
+	   Locals at 0x7fffffffd330, Previous frame's sp is 0x7fffffffd340
+	   Saved registers:
+	    rbp at 0x7fffffffd330, rip at 0x7fffffffd338
+	  (gdb)
+
+	and then after continuing to a function called by main, and selecting
+	the "main" frame again, we see:
+
+	  (gdb) info frame
+	  Stack level 3, frame at 0x7fffffffd340:
+	   rip = 0x555555555172 in main (gdb.base/backtrace.c:41); saved rip = 0x7ffff7dd90b3
+	   caller of frame at 0x7fffffffd330
+	   source language c.
+	   Arglist at 0x7fffffffd330, args:
+	   Locals at 0x7fffffffd330, Previous frame's sp is 0x7fffffffd340
+	   Saved registers:
+	    rbp at 0x7fffffffd330, rip at 0x7fffffffd338
+	  (gdb)
+
+	The only differences should be in the stack level, the 'rip = '
+	address, and the presence of the "caller of frame at" info.  All the
+	rest should be the same.  If it isn't, it probably means that the
+	frame base, the frame ID, etc. aren't stable & consistent.
+
+	The testcase exercises both the DWARF and the heuristic unwinders,
+	using "maint set dwarf unwinder on/off".
+
+	Tested on {x86-64 -m64, x86-64 -m32, Aarch64, Power8} GNU/Linux.
+
+	Change-Id: I795001c82cc70d543d197415e3f80ce5dc7f3452
+
+2021-09-23  Tom Tromey  <tromey@adacore.com>
+
+	Change get_ada_task_ptid parameter type
+	get_ada_task_ptid currently takes a 'long' as its 'thread' parameter
+	type.  However, on some platforms this is actually a pointer, and
+	using 'long' can sometimes end up with the value being sign-extended.
+	This sign extension can cause problems later, if the tid is then later
+	used as an address again.
+
+	This patch changes the parameter type to ULONGEST and updates all the
+	uses.  This approach preserves sign extension on the targets where it
+	is apparently intended, while avoiding it on others.
+
+	Co-Authored-By: John Baldwin <jhb@FreeBSD.org>
+
+2021-09-23  Tom Tromey  <tromey@adacore.com>
+
+	Change ptid_t::tid to ULONGEST
+	The ptid_t 'tid' member is normally used as an address in gdb -- both
+	bsd-uthread and ravenscar-thread use it this way.  However, because
+	the type is 'long', this can cause problems with sign extension.
+
+	This patch changes the type to ULONGEST to ensure that sign extension
+	does not occur.
+
+2021-09-23  Tom Tromey  <tromey@adacore.com>
+
+	Remove defaulted 'tid' parameter to ptid_t constructor
+	I wanted to find, and potentially modify, all the spots where the
+	'tid' parameter to the ptid_t constructor was used.  So, I temporarily
+	removed this parameter and then rebuilt.
+
+	In order to make it simpler to search through the "real" (nonzero)
+	uses of this parameter, something I knew I'd have to do multiple
+	times, I removed any ", 0" from constructor calls.
+
+	Co-Authored-By: John Baldwin <jhb@FreeBSD.org>
+
+2021-09-23  Tom Tromey  <tom@tromey.com>
+
+	Style the "XXX" text in ptype/o
+	This patch changes gdb to use the 'highlight' style on the "XXX" text
+	in the output of ptype/o.
+
+2021-09-23  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-22  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.python/py-events.exp
+	With test-case gdb.python/py-events.exp on ubuntu 18.04.5 we run into:
+	...
+	(gdb) info threads^M
+	  Id   Target Id                                     Frame ^M
+	* 1    Thread 0x7ffff7fc3740 (LWP 31467) "py-events" do_nothing () at \
+	         src/gdb/testsuite/gdb.python/py-events-shlib.c:19^M
+	(gdb) FAIL: gdb.python/py-events.exp: get current thread
+	...
+
+	The info thread commands uses "Thread" instead of "process" because
+	libpthread is already loaded:
+	...
+	new objfile name: /lib/x86_64-linux-gnu/libdl.so.2^M
+	[Thread debugging using libthread_db enabled]^M
+	Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".^M
+	event type: new_objfile^M
+	new objfile name: /lib/x86_64-linux-gnu/libpthread.so.0^M
+	...
+	and consequently thread_db_target::pid_to_str is used.
+
+	Fix this by parsing the "Thread" expression.
+
+	Tested on x86_64-linux.
+
+2021-09-22  Tom de Vries  <tdevries@suse.de>
+
+	[gdb] Add maint selftest -verbose option
+	The print_one_insn selftest in gdb/disasm-selftests.c contains:
+	...
+	  /* If you want to see the disassembled instruction printed to gdb_stdout,
+	     set verbose to true.  */
+	  static const bool verbose = false;
+	...
+
+	Make this parameter available in the maint selftest command using a new option
+	-verbose, such that we can do:
+	...
+	(gdb) maint selftest -verbose print_one_insn
+	...
+
+	Tested on x86_64-linux.
+
+2021-09-22  Alan Modra  <amodra@gmail.com>
+
+	dwarf2 sub-section test
+	This is a testcase for the bug fixed by commit 5b4846283c3d.  When
+	running the testcase on ia64 targets I found timeouts along with lots
+	of memory being consumed, due to ia64 gas not tracking text
+	sub-sections.  Trying to add nops for ".nop 16" in ".text 1" resulting
+	in them being added to subsegment 0, with no increase to subsegment 1
+	size.  This patch also fixes that problem.
+
+	Note that the testcase fails on ft32-elf, mn10200-elf, score-elf,
+	tic5x-elf, and xtensa-elf.  The first two are relocation errors, the
+	last three appear to be the .nop directive failing to emit the right
+	number of nops.  I didn't XFAIL any of them.
+
+		* config/tc-ia64.c (md): Add last_text_subseg.
+		(ia64_flush_insns, dot_endp): Use last_text_subseg.
+		(ia64_frob_label, md_assemble): Set last_text_subseg.
+		* testsuite/gas/elf/dwarf2-21.d,
+		* testsuite/gas/elf/dwarf2-21.s: New test.
+		* testsuite/gas/elf/elf.exp: Run it.
+
+2021-09-22  Alan Modra  <amodra@gmail.com>
+
+	Fix x86 "FAIL: TLS -fno-pic -shared"
+	Fix a typo in commit 5d0869d9872a
+
+		* testsuite/ld-i386/tlsnopic.rd: Typo fix.
+
+2021-09-22  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-21  Nick Clifton  <nickc@redhat.com>
+
+	Change the linker's heuristic for computing the entry point for binaries so that shared libraries default to an entry point of 0.
+		* ldlang.c (lang_end): When computing the entry point, only
+		try the start address of the entry section when creating an
+		executable.
+		* ld.texi (Entry point): Update description of heuristic used to
+		choose the entry point.
+		testsuite/ld-alpha/tlspic.rd: Update expected entry point address.
+		testsuite/ld-arm/tls-gdesc-got.d: Likewise.
+		testsuite/ld-i386/tlsnopic.rd: Likewise.
+		testsuite/ld-ia64/tlspic.rd: Likewise.
+		testsuite/ld-sparc/gotop32.rd: Likewise.
+		testsuite/ld-sparc/gotop64.rd: Likewise.
+		testsuite/ld-sparc/tlssunnopic32.rd: Likewise.
+		testsuite/ld-sparc/tlssunnopic64.rd: Likewise.
+		testsuite/ld-sparc/tlssunpic32.rd: Likewise.
+		testsuite/ld-sparc/tlssunpic64.rd: Likewise.
+		testsuite/ld-tic6x/shlib-1.rd: Likewise.
+		testsuite/ld-tic6x/shlib-1b.rd: Likewise.
+		testsuite/ld-tic6x/shlib-1r.rd: Likewise.
+		testsuite/ld-tic6x/shlib-1rb.rd: Likewise.
+		testsuite/ld-tic6x/shlib-noindex.rd: Likewise.
+		testsuite/ld-x86-64/pr14207.d: Likewise.
+		testsuite/ld-x86-64/tlsdesc.rd: Likewise.
+		testsuite/ld-x86-64/tlspic.rd: Likewise.
+		testsuite/ld-x86-64/tlspic2.rd: Likewise.
+
+2021-09-21  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Handle supports_memtag in gdb.base/gdb-caching-proc.exp
+	In test-case gdb.base/gdb-caching-proc.exp, we run all procs declared with
+	gdb_caching_proc.  Some of these require a gdb instance, some not.
+
+	We could just do a clean_restart every time, but that would amount to 44 gdb
+	restarts.  We try to minimize this by doing this only for the few procs that
+	need it, and hardcoding those in the test-case.
+
+	For those procs, we do a clean_restart, execute the proc, and then do a
+	gdb_exit, to make sure the gdb instance doesn't linger such that we detect
+	procs that need a gdb instance but are not listed in the test-case.
+
+	However, that doesn't work in the case of gnat_runtime_has_debug_info.  This
+	proc doesn't require a gdb instance because it starts its own.  But it doesn't
+	clean up the gdb instance, and since it's not listed, the test-case
+	doesn't clean up the gdb instance eiter.  Consequently, the proc
+	supports_memtag (which should be listed, but isn't) uses the gdb instance
+	started by gnat_runtime_has_debug_info rather than throwing an error.  Well,
+	unless gnat_runtime_has_debug_info fails before starting a gdb instance, in
+	which case we do run into the error.
+
+	Fix this by:
+	- doing gdb_exit unconditionally
+	- fixing the resulting error by adding supports_memtag in the test-case to
+	  the "needing gdb instance" list
+
+	Tested on x86_64-linux.
+
+2021-09-21  Felix Willgerodt  <felix.willgerodt@intel.com>
+
+	gdb, doc: Add ieee_half and bfloat16 to list of predefined target types.
+	For some reason these two weren't added to the list when they were orginally
+	added to GDB.
+
+	gdb/doc/ChangeLog:
+	2021-09-21  Felix Willgerodt  <felix.willgerodt@intel.com>
+
+		* gdb.texinfo (Predefined Target Types): Mention ieee_half and bfloat16.
+
+2021-09-21  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-20  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.ada/interface.exp with gcc-9
+	When running test-case gdb.ada/interface.exp with gcc-9, we run into:
+	...
+	(gdb) info locals^M
+	s = (x => 1, y => 2, w => 3, h => 4)^M
+	r = (x => 1, y => 2, w => 3, h => 4)^M
+	(gdb) FAIL: gdb.ada/interface.exp: info locals
+	...
+
+	The failure is caused by the regexp expecting variable r followed by
+	variable s.
+
+	Fix this by allowing variable s followed by variable r as well.
+
+	Tested on x86_64-linux.
+
+2021-09-20  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.ada/mi_prot.exp
+	When running test-case gdb.ada/mi_prot.exp with gcc 8.5.0, we run into:
+	...
+	(gdb) ^M
+	Expecting: ^(-stack-list-arguments --no-frame-filters 1[^M
+	]+)?(\^done,stack=.*[^M
+	]+[(]gdb[)] ^M
+	[ ]*)
+	-stack-list-arguments --no-frame-filters 1^M
+	^done,stack-args=[frame={level="0",args=[{name="<_object>",value="(ceiling_priority =\
+	> 97, local => 0)"},{name="v",value="5"},{name="<_objectO>",value="true"}]},frame={le\
+	vel="1",args=[{name="v",value="5"},{name="<_objectO>",value="true"}]},frame={level="2\
+	",args=[]}]^M
+	(gdb) ^M
+	FAIL: gdb.ada/mi_prot.exp: -stack-list-arguments --no-frame-filters 1 (unexpected out\
+	put)
+	...
+
+	Fix this by updating the regexp to expect "^done,stack-args=" instead of
+	"^done,stack=".
+
+	Tested on x86_64-linux.
+
+2021-09-20  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Register test for each arch separately in register_test_foreach_arch
+	In gdb/disasm-selftests.c we have:
+	...
+	  selftests::register_test_foreach_arch ("print_one_insn",
+	                                         selftests::print_one_insn_test);
+	...
+	and we get:
+	...
+	$ gdb -q -batch -ex "maint selftest print_one_insn" 2>&1 \
+	  | grep ^Running
+	Running selftest print_one_insn.
+	$
+	...
+
+	Change the semantics register_test_foreach_arch such that a version of
+	print_one_insn is registered for each architecture, such that we have:
+	...
+	$ gdb -q -batch -ex "maint selftest print_one_insn" 2>&1 \
+	  | grep ^Running
+	Running selftest print_one_insn::A6.
+	Running selftest print_one_insn::A7.
+	Running selftest print_one_insn::ARC600.
+	  ...
+	$
+	...
+
+	This makes it f.i. possible to do:
+	...
+	$ gdb -q -batch a.out -ex "maint selftest print_one_insn::armv8.1-m.main"
+	Running selftest print_one_insn::armv8.1-m.main.
+	Self test failed: self-test failed at src/gdb/disasm-selftests.c:165
+	Ran 1 unit tests, 1 failed
+	...
+
+	Tested on x86_64-linux with an --enable-targets=all build.
+
+2021-09-20  Tom de Vries  <tdevries@suse.de>
+
+	[gdb] Change register_test to use std::function arg
+	Change register_test to use std::function arg, such that we can do:
+	...
+	  register_test (test_name, [=] () { SELF_CHECK (...); });
+	...
+
+	Tested on x86_64-linux.
+
+2021-09-20  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.ada/big_packed_array.exp xfail for -m32
+	With test-case gdb.ada/big_packed_array.exp and target board unix/-m32 I run
+	into:
+	...
+	(gdb) print bad^M
+	$2 = (0 => 0 <repeats 24 times>, 160)^M
+	(gdb) FAIL: gdb.ada/big_packed_array.exp: scenario=minimal: print bad
+	...
+
+	The problem is that while the variable is an array of 196 bits (== 24.5 bytes),
+	the debug information describes it as 25 unsigned char.  This is PR
+	gcc/101643, and the test-case contains an xfail for this, which catches only:
+	...
+	(gdb) print bad^M
+	$2 = (0 => 0 <repeats 25 times>)^M
+	...
+
+	Fix this by updating the xfail pattern.
+
+	Tested on x86_64-linux.
+
+2021-09-20  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdbsupport/gdb_proc_service.h: use decltype instead of typeof
+	Bug 28341 shows that GDB fails to compile when built with -std=c++11.
+	I don't know much about the use case, but according to the author of the
+	bug:
+
+	    I encountered the scenario where CXX is set to "g++ -std=c++11" when
+	    I try to compile binutils under GCC as part of the GCC 3-stage
+	    compilation, which is common for building a cross-compiler.
+
+	The author of the bug suggests using __typeof__ instead of typeof.  But
+	since we're using C++, we might as well use decltype, which is standard.
+	This is what this patch does.
+
+	The failure (and fix) can be observed by configuring GDB with CXX="g++
+	-std=c++11":
+
+	      CXX    linux-low.o
+	    In file included from /home/simark/src/binutils-gdb/gdbserver/gdb_proc_service.h:22,
+			     from /home/simark/src/binutils-gdb/gdbserver/linux-low.h:27,
+			     from /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:20:
+	    /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/gdb_proc_service.h:177:50: error: expected constructor, destructor, or type conversion before (token
+	      177 |   __attribute__((visibility ("default"))) typeof (SYM) SYM
+		  |                                                  ^
+	    /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/gdb_proc_service.h:179:1: note: in expansion of macro PS_EXPORT
+	      179 | PS_EXPORT (ps_get_thread_area);
+		  | ^~~~~~~~~
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28341
+	Change-Id: I84fbaae938209d8d935ca08dec9b7e6a0dd1bda0
+
+2021-09-20  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	riscv: print .2byte or .4byte before an unknown instruction encoding
+	When the RISC-V disassembler encounters an unknown instruction, it
+	currently just prints the value of the bytes, like this:
+
+	  Dump of assembler code for function custom_insn:
+	     0x00010132 <+0>:	addi	sp,sp,-16
+	     0x00010134 <+2>:	sw	s0,12(sp)
+	     0x00010136 <+4>:	addi	s0,sp,16
+	     0x00010138 <+6>:	0x52018b
+	     0x0001013c <+10>:	0x9c45
+
+	My proposal, in this patch, is to change the behaviour to this:
+
+	  Dump of assembler code for function custom_insn:
+	     0x00010132 <+0>:	addi	sp,sp,-16
+	     0x00010134 <+2>:	sw	s0,12(sp)
+	     0x00010136 <+4>:	addi	s0,sp,16
+	     0x00010138 <+6>:	.4byte	0x52018b
+	     0x0001013c <+10>:	.2byte	0x9c45
+
+	Adding the .4byte and .2byte opcodes.  The benefit that I see here is
+	that in the patched version of the tools, the disassembler output can
+	be fed back into the assembler and it should assemble to the same
+	binary format.  Before the patch, the disassembler output is invalid
+	assembly.
+
+	I've started a RISC-V specific test file under binutils so that I can
+	add a test for this change.
+
+	binutils/ChangeLog:
+
+		* testsuite/binutils-all/riscv/riscv.exp: New file.
+		* testsuite/binutils-all/riscv/unknown.d: New file.
+		* testsuite/binutils-all/riscv/unknown.s: New file.
+
+	opcodes/ChangeLog:
+
+		* riscv-dis.c (riscv_disassemble_insn): Print a .%dbyte opcode
+		before an unknown instruction, '%d' is replaced with the
+		instruction length.
+
+2021-09-20  Alan Modra  <amodra@gmail.com>
+
+	Fix allocate_filenum last dir/file checks
+		* dwarf2dbg.c (allocate_filenum) Correct use of last_used_dir_len.
+
+2021-09-20  Alan Modra  <amodra@gmail.com>
+
+	Re: PR28149, debug info with wrong file association
+	Fixes segfaults when building aarch64-linux kernel, due to only doing
+	part of the work necessary when allocating file numbers late.  I'd
+	missed looping over subsegments, which resulted in some u.filename
+	entries left around and later interpreted as u.view.
+
+		PR 28149
+		* dwarf2dbg.c (purge_generated_debug): Iterate over subsegs too.
+		(dwarf2_finish): Call do_allocate_filenum for all subsegs too,
+		in a separate loop before subsegs are chained.
+
+2021-09-20  Alan Modra  <amodra@gmail.com>
+
+	Move eelf_mipsel_haiki.c to ALL_64_EMULATION_SOURCES
+	--enable-targets=all on a 32-bit host results in a link failure with
+	undefined references due to elfxx-mips.c not being compiled.  This
+	patch fixes that by putting eelf_mipsel_haiki.c in the correct
+	EMULATION_SOURCES Makefile variable.  I've also added a bunch of
+	missing file dependencies and sorted a few things so that it's easier
+	to verify dependencies are present.
+
+		* Makfile.am: Add missing haiku dependencies, sort.
+		(ALL_EMULATION_SOURCES): Sort.  Move eelf_mipsel_haiku.c to..
+		(ALL_64_EMULATION_SOURCES): ..here.  Sort.
+		* Makfile.in: Regenerate.
+
+2021-09-20  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-19  H.J. Lu  <hjl.tools@gmail.com>
+
+	elf: Don't set version info on unversioned symbols
+	Don't set version info on unversioned symbols when seeing a hidden
+	versioned symbol after an unversioned definition and the default
+	versioned symbol.
+
+	bfd/
+
+		PR ld/28348
+		* elflink.c (elf_link_add_object_symbols): Don't set version info
+		on unversioned symbols.
+
+	ld/
+
+		PR ld/28348
+		* testsuite/ld-elf/pr28348.rd: New file.
+		* testsuite/ld-elf/pr28348.t: Likewise.
+		* testsuite/ld-elf/pr28348a.c: Likewise.
+		* testsuite/ld-elf/pr28348b.c: Likewise.
+		* testsuite/ld-elf/pr28348c.c: Likewise.
+		* testsuite/ld-elf/shared.exp: Run PR ld/28348 tests.
+
+2021-09-19  Mike Frysinger  <vapier@gentoo.org>
+
+	gdb: manual: update @inforef to @xref
+	The @inforef command is deprecated, and @xref does the samething.
+	Also had to update the text capitalization to match current manual.
+	Verified that info & HTML links work.
+
+2021-09-19  Weimin Pan  <weimin.pan@oracle.com>
+
+	CTF: multi-CU and archive support
+	Now gdb is capable of debugging executable, which consists of multiple
+	compilation units (CUs) with the CTF debug info. An executable could
+	potentially have one or more archives, which, in CTF context, contain
+	conflicting types.
+
+	all changes were made in ctfread.c in which elfctf_build_psymtabs was
+	modified to handle archives, via the ctf archive iterator and its callback
+	build_ctf_archive_member and scan_partial_symbols was modified to scan
+	archives, which are treated as subfiles, to build the psymtabs.
+
+	Also changes were made to handle CTF's data object section and function
+	info section which now share the same format of their contents - an array
+	of type IDs. New functions ctf_psymtab_add_stt_entries, which is called by
+	ctf_psymtab_add_stt_obj and ctf_psymtab_add_stt_func, and add_stt_entries,
+	which is called by add_stt_obj and add_stt_func when setting up psymtabs
+	and full symtab, respectively.
+
+2021-09-19  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-18  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.server/server-kill.exp with -m32
+	When running test-case gdb.server/server-kill.exp with target board unix/-m32,
+	I run into:
+	...
+	0xf7fd6b20 in _start () from /lib/ld-linux.so.2^M
+	(gdb) Executing on target: kill -9 13082    (timeout = 300)
+	builtin_spawn -ignore SIGHUP kill -9 13082^M
+	bt^M
+	(gdb) FAIL: gdb.server/server-kill.exp: kill_pid_of=server: test_unwind_syms: bt
+	...
+
+	The test-case expects the backtrace command to trigger remote communication,
+	which then should result in a "Remote connection closed" or similar.
+
+	However, no remote communication is triggered, because we hit the "Check that
+	this frame is unwindable" case in get_prev_frame_always_1.
+
+	We don't hit this problem in the kill_pid_of=inferior case, because there we
+	run to main before doing the backtrace.
+
+	Fix this by doing the same in the kill_pid_of=server case.
+
+	Tested on x86_64-linux.
+
+2021-09-18  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/ada] Handle artificial local symbols
+	With current master and gcc 7.5.0/8.5.0, we have this timeout:
+	...
+	(gdb) print s^M
+	Multiple matches for s^M
+	[0] cancel^M
+	[1] s at src/gdb/testsuite/gdb.ada/interface/foo.adb:20^M
+	[2] s at src/gdb/testsuite/gdb.ada/interface/foo.adb:?^M
+	> FAIL: gdb.ada/interface.exp: print s (timeout)
+	...
+
+	[ The FAIL doesn't reproduce with gcc 9.3.1.  This difference in
+	behaviour bisects to gcc commit d70ba0c10de.
+
+	The FAIL with earlier gcc bisects to gdb commit ba8694b650b. ]
+
+	The FAIL is caused by gcc generating this debug info describing a named
+	artificial variable:
+	...
+	 <2><1204>: Abbrev Number: 31 (DW_TAG_variable)
+	    <1205>   DW_AT_name        : s.14
+	    <1209>   DW_AT_type        : <0x1213>
+	    <120d>   DW_AT_artificial  : 1
+	    <120d>   DW_AT_location    : 5 byte block: 91 e0 7d 23 18   \
+	      (DW_OP_fbreg: -288; DW_OP_plus_uconst: 24)
+	...
+
+	An easy way to fix this would be to simply not put named artificial variables
+	into the symbol table.  However, that causes regressions for Ada.  It relies
+	on being able to get the value from such variables, using a named reference.
+
+	Fix this instead by marking the symbol as artificial, and:
+	- ignoring such symbols in ada_resolve_variable, which fixes the FAIL
+	- ignoring such ada symbols in do_print_variable_and_value, which prevents
+	  them from showing up in "info locals"
+
+	Note that a fix for the latter was submitted here (
+	https://sourceware.org/pipermail/gdb-patches/2008-January/054994.html ), and
+	this patch borrows from it.
+
+	Tested on x86_64-linux.
+
+	Co-Authored-By: Joel Brobecker  <brobecker@adacore.com>
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28180
+
+2021-09-18  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-17  Alan Modra  <amodra@gmail.com>
+
+	PR28149 part 2, purge generated line info
+	Mixing compiler generated line info with gas generated line info is
+	generally just confusing.  Also .loc directives with non-zero view
+	fields might reference a previous .loc.  It becomes a little more
+	tricky to locate that previous .loc if there might be gas generated
+	line info present too.  Mind you, we turn off gas generation of line
+	info on seeing compiler generated line info, so any reference back
+	won't hit gas generated line info.  At least, if the view info is
+	sane.  Unfortunately, gas needs to handle mangled source.
+
+		PR 28149
+		* dwarf2dbg.c (purge_generated_debug): New function.
+		(dwarf2_directive_filename): Call the above.
+		(out_debug_line): Don't segfault after purging.
+		* testsuite/gas/i386/dwarf2-line-4.d: Update expected output.
+		* testsuite/gas/i386/dwarf4-line-1.d: Likewise.
+		* testsuite/gas/i386/dwarf5-line-1.d: Likewise.
+		* testsuite/gas/i386/dwarf5-line-2.d: Likewise.
+
+2021-09-17  Alan Modra  <amodra@gmail.com>
+
+	PR28149, debug info with wrong file association
+	gcc-11 and gcc-12 pass -gdwarf-5 to gas, in order to prime gas for
+	DWARF 5 level debug info.  Unfortunately it seems there are cases
+	where the compiler does not emit a .file or .loc dwarf debug directive
+	before any machine instructions.  (Note that the .file directive
+	typically emitted as the first line of assembly output doesn't count as
+	a dwarf debug directive.  The dwarf .file has a file number before the
+	file name string.)
+
+	This patch delays allocation of file numbers for gas generated line
+	debug info until the end of assembly, thus avoiding any clashes with
+	compiler generated file numbers.  Two fixes for test case source are
+	necessary;  A .loc can't use a file number that hasn't already been
+	specified with .file.
+
+	A followup patch will remove all the gas generated line info on
+	seeing a .file directive.
+
+		PR 28149
+		* dwarf2dbg.c (num_of_auto_assigned): Delete.
+		(current): Update initialisation.
+		(set_or_check_view): Replace all accesses to view with u.view.
+		(dwarf2_consume_line_info): Likewise.
+		(dwarf2_directive_loc): Likewise.  Assert that we aren't generating
+		line info.
+		(dwarf2_gen_line_info_1): Don't call set_or_check_view on
+		gas generated line entries.
+		(dwarf2_gen_line_info): Set and track filenames for gas generated
+		line entries.  Simplify generation of labels.
+		(get_directory_table_entry): Use filename_cmp when comparing dirs.
+		(do_allocate_filenum): New function.
+		(dwarf2_where): Set u.filename and filenum to -1 for gas generated
+		line entries.
+		(dwarf2_directive_filename): Remove num_of_auto_assigned handling.
+		(process_entries): Update view field access.  Call
+		do_allocate_filenum.
+		* dwarf2dbg.h (struct dwarf2_line_info): Add filename field in
+		union aliasing view.
+		* testsuite/gas/i386/dwarf2-line-3.s: Add .file directive.
+		* testsuite/gas/i386/dwarf2-line-4.s: Likewise.
+		* testsuite/gas/i386/dwarf2-line-4.d: Update expected output.
+		* testsuite/gas/i386/dwarf4-line-1.d: Likewise.
+		* testsuite/gas/i386/dwarf5-line-1.d: Likewise.
+		* testsuite/gas/i386/dwarf5-line-2.d: Likewise.
+
+2021-09-17  Alan Modra  <amodra@gmail.com>
+
+	[GOLD] PowerPC64 support for sym+addend GOT entries
+	Pass addends to all the GOT handling functions, plus remove some
+	extraneous asserts.
+
+		PR 28192
+		* powerpc.cc (Output_data_got_powerpc): Add addend parameter to
+		all methods creating got entries.
+		(Target_powerpc::Scan::local): Pass reloc addend to got handling
+		functions, and when creating dynamic got relocations.
+		(Target_powerpc::Scan::global): Likewise.
+		(Target_powerpc::Relocate::relocate): Likewise.  Remove extraneous
+		assertions.
+
+2021-09-17  Alan Modra  <amodra@gmail.com>
+
+	[GOLD] Got_entry::write addends
+	This takes care of writing out GOT entries with addends.  The local
+	symbol case was already largely handled, except for passing the addend
+	to tls_offset_for_local which might need the addend in a
+	local_got_offset call.  That's needed also in tls_offset_for_global.
+
+	I'm assuming here that GOT entries for function symbols won't ever
+	have addends, and in particular that a GOT entry referencing PLT call
+	stub code won't want an offset into the code.
+
+		PR 28192
+		* output.cc (Output_data_got::Got_entry::write): Include addend
+		in global symbol value.  Pass addend to tls_offset_for_*.
+		* powerpc.cc (Target_powerpc::do_tls_offset_for_local): Handle addend.
+		(Target_powerpc::do_tls_offset_for_global): Likewise.
+		* s390.cc (Target_s390::do_tls_offset_for_local): Likewise.
+		(Target_s390::do_tls_offset_for_global): Likewise.
+		* target.h (Target::tls_offset_for_local): Add addend param.
+		(Target::tls_offset_for_global): Likewise.
+		(Target::do_tls_offset_for_local): Likewise.
+		(Target::do_tls_offset_for_global): Likewise.
+
+2021-09-17  Alan Modra  <amodra@gmail.com>
+
+	[GOLD] Output_data_got create entry method addends
+	This patch makes all the Output_data_got methods that create new
+	entries accept an optional addend.
+
+		PR 28192
+		* output.h (Output_data_got::add_global): Add optional addend
+		parameter.  Update comment.  Delete overload without addend.
+		(Output_data_got::add_global_plt): Likewise.
+		(Output_data_got::add_global_tls): Likewise.
+		(Output_data_got::add_global_with_rel): Likewise.
+		(Output_data_got::add_global_pair_with_rel): Likewise.
+		(Output_data_got::add_local_plt): Likewise.
+		(Output_data_got::add_local_tls): Likewise.
+		(Output_data_got::add_local_tls_pair): Likewise.
+		(Output_data_got::reserve_local): Likewise.
+		(Output_data_got::reserve_global): Likewise.
+		(Output_data_got::Got_entry): Include addend in global sym
+		constructor.  Delete local sym constructor without addend.
+		* output.cc (Output_data_got::add_global): Add addend param,
+		pass to got handling methods.
+		(Output_data_got::add_global_plt): Likewise.
+		(Output_data_got::add_global_with_rel): Likewise.
+		(Output_data_got::add_global_pair_with_rel): Likewise.
+		(Output_data_got::add_local_plt): Likewise.
+		(Output_data_got::add_local_tls_pair): Likewise.
+		(Output_data_got::reserve_local): Likewise.
+		(Output_data_got::reserve_global): Likewise.
+
+2021-09-17  Alan Modra  <amodra@gmail.com>
+
+	[GOLD] Output_data_got tidy
+	Some Output_data_got methods already have support for addends, but
+	were implemented as separate methods.  This removes unnecessary code
+	duplication.
+
+	Relobj::local_has_got_offset and others there get a similar treatment.
+	Comments are removed since it should be obvious without a comment, and
+	the existing comments are not precisely what the code does.  For
+	example, a local_has_got_offset call without an addend does not return
+	whether the local symbol has *a* GOT offset of type GOT_TYPE, it
+	returns whether there is a GOT entry of type GOT_TYPE for the symbol
+	with addend of zero.
+
+		PR 28192
+		* output.h (Output_data_got::add_local): Make addend optional.
+		(Output_data_got::add_local_with_rel): Likewise.
+		(Output_data_got::add_local_pair_with_rel): Likewise.
+		* output.cc (Output_data_got::add_local): Delete overload
+		without addend.
+		(Output_data_got::add_local_with_rel): Likewise.
+		(Output_data_got::add_local_pair_with_rel): Likewise.
+		* object.h (Relobj::local_has_got_offset): Make addend optional.
+		Delete overload without addend later.  Update comment.
+		(Relobj::local_got_offset): Likewise.
+		(Relobj::set_local_got_offset): Likewise.
+
+2021-09-17  Alan Modra  <amodra@gmail.com>
+
+	[GOLD] Remove addend from Local_got_entry_key
+	This patch removes the addend from Local_got_entry_key, which is
+	unnecessary now that Got_offset_list has an addend.  Note that it
+	might be advantageous to keep the addend in Local_got_entry_key when
+	linking objects containing a large number of section_sym+addend@got
+	relocations.  I opted to save some memory by removing the field but
+	left the class there in case we might need to restore {sym,addend}
+	lookup.  That's also why this change is split out from the
+	Got_offset_list change.
+
+		PR 28192
+		* object.h (Local_got_entry_key): Delete addend_ field.
+		Adjust constructor and methods to suit.
+		* object.cc (Sized_relobj::do_for_all_local_got_entries):
+		Update key.
+
+2021-09-17  Alan Modra  <amodra@gmail.com>
+
+	[GOLD] Got_offset_list: addend field
+	This is the first in a series of patches aimed at supporting GOT
+	entries against symbol plus addend generally for PowerPC64 rather than
+	just section symbol plus addend as gold has currently.
+
+	This patch adds an addend field to Got_offset_list, so that both local
+	and global symbols can have GOT entries with addend.
+
+		PR 28192
+		* object.h (Got_offset_list): Add addend_ field, init in both
+		constructors.  Adjust all accessors to suit.
+		(Sized_relobj::do_local_has_got_offset): Adjust to suit.
+		(Sized_relobj::do_local_got_offset): Likewise.
+		(Sized_relobj::do_set_local_got_offset): Likewise.
+		* symtab.h (Symbol::has_got_offset): Add optional addend param.
+		(Symbol::got_offset, Symbol::set_got_offset): Likewise.
+		* incremental.cc (Local_got_offset_visitor::visit): Add unused
+		uint64_t parameter with FIXME.
+		(Global_got_offset_visitor::visit): Add unused uint64_t parameter.
+
+2021-09-17  Henry Castro  <hcvcastro@gmail.com>
+
+	Fix segfault when running ia16-elf-gdb
+	"A problem internal to GDB has been detected,
+	further debugging may prove unreliable."
+
+	Segmentation fault
+
+2021-09-17  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: Merged extension string tables and their version tables into one.
+	There are two main reasons for this patch,
+
+	* In the past we had two extension tables, one is used to record all
+	supported extensions in bfd/elfxx-riscv.c, another is used to get the
+	default extension versions in gas/config/tc-riscv.c.  It is hard to
+	maintain lots of tables in different files, but in fact we can merge
+	them into just one table.  Therefore, we now define many riscv_supported_std*
+	tables, which record names and versions for all supported extensions.
+	We not only use these tables to initialize the riscv_ext_order, but
+	also use them to get the default versions of extensions, and decide if
+	the extensions should be enbaled by default.
+
+	* We add a new filed `default_enable' for the riscv_supported_std* tables,
+	to decide if the extension should be enabled by default.  For now if the
+	`default_enable' field of the extension is set to EXT_DEFAULT, then we
+	should enable the extension when the -march and elf architecture attributes
+	are not set.  In the future, I suppose the `default_enable' can be set
+	to lots of EXT_<VENDOR>, each vendor can decide to open which extensions,
+	when the target triple of vendor is chosen.
+
+	The elf/linux regression tests of riscv-gnu-toolchain are passed.
+
+	bfd/
+		* elfnn-riscv.c (cpu-riscv.h): Removed sine it is included in
+		bfd/elfxx-riscv.h.
+		(riscv_merge_std_ext): Updated since the field of rpe is changed.
+		* elfxx-riscv.c (cpu-riscv.h): Removed.
+		(riscv_implicit_subsets): Added implicit extensions for g.
+		(struct riscv_supported_ext): Used to be riscv_ext_version.  Moved
+		from gas/config/tc-riscv.c, and added new field `default_enable' to
+		decide if the extension should be enabled by default.
+		(EXT_DEFAULT): Defined for `default_enable' field.
+		(riscv_supported_std_ext): It used to return the supported standard
+		architecture string, but now we move ext_version_table from
+		gas/config/tc-riscv.c to here, and rename it to riscv_supported_std_ext.
+		Currently we not only use the table to initialize riscv_ext_order, but
+		also get the default versions of extensions, and decide if the extensions
+		should be enbaled by default.
+		(riscv_supported_std_z_ext): Likewise, but is used for z* extensions.
+		(riscv_supported_std_s_ext): Likewise, but is used for s* extensions.
+		(riscv_supported_std_h_ext): Likewise, but is used for h* extensions.
+		(riscv_supported_std_zxm_ext): Likewise, but is used for zxm* extensions.
+		(riscv_all_supported_ext): Includes all supported extension tables.
+		(riscv_known_prefixed_ext): Updated.
+		(riscv_valid_prefixed_ext): Updated.
+		(riscv_init_ext_order): Init the riscv_ext_order table according to
+		riscv_supported_std_ext.
+		(riscv_get_default_ext_version): Moved from gas/config/tc-riscv.c.
+		Get the versions of extensions from riscv_supported_std* tables.
+		(riscv_parse_add_subset): Updated.
+		(riscv_parse_std_ext): Updated.
+		(riscv_set_default_arch): Set the default subset list according to
+		the default_enable field of riscv_supported_*ext tables.
+		(riscv_parse_subset): If the input ARCH is NULL, then we call
+		riscv_set_default_arch to set the default subset list.
+		* elfxx-riscv.h (cpu-riscv.h): Included.
+		(riscv_parse_subset_t): Removed get_default_version field, and added
+		isa_spec field to replace it.
+		(extern riscv_supported_std_ext): Removed.
+	gas/
+		* (bfd/cpu-riscv.h): Removed.
+		(struct riscv_ext_version): Renamed and moved to bfd/elfxx-riscv.c.
+		(ext_version_table): Likewise.
+		(riscv_get_default_ext_version): Likewise.
+		(ext_version_hash): Removed.
+		(init_ext_version_hash): Removed.
+		(riscv_set_arch): Updated since the field of rps is changed.  Besides,
+		report error when the architecture string is empty.
+		(riscv_after_parse_args): Updated.
+
+2021-09-17  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-16  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix interrupted sleep in multi-threaded test-cases
+	When running test-case gdb.threads/continue-pending-status.exp with native, I
+	have:
+	...
+	(gdb) continue^M
+	Continuing.^M
+	PASS: gdb.threads/continue-pending-status.exp: attempt 0: continue for ctrl-c
+	^C^M
+	Thread 1 "continue-pendin" received signal SIGINT, Interrupt.^M
+	[Switching to Thread 0x7ffff7fc4740 (LWP 1276)]^M
+	0x00007ffff758e4c0 in __GI___nanosleep () at nanosleep.c:27^M
+	27        return SYSCALL_CANCEL (nanosleep, requested_time, remaining);^M
+	(gdb) PASS: gdb.threads/continue-pending-status.exp: attempt 0: caught interrupt
+	...
+	but with target board unix/-m32, I run into:
+	...
+	(gdb) continue^M
+	Continuing.^M
+	PASS: gdb.threads/continue-pending-status.exp: attempt 0: continue for ctrl-c
+	[Thread 0xf74aeb40 (LWP 31957) exited]^M
+	[Thread 0xf7cafb40 (LWP 31956) exited]^M
+	[Inferior 1 (process 31952) exited normally]^M
+	(gdb) Quit^M
+	...
+
+	The problem is that the sleep (300) call at the end of main is interrupted,
+	which causes the inferior to exit before the ctrl-c can be send.
+
+	This problem is described at "Interrupted System Calls" in the docs, and the
+	suggested solution (using a sleep loop) indeed fixes the problem.
+
+	Fix this instead using the more prevalent:
+	...
+	  alarm (300);
+	  ...
+	  while (1) sleep (1);
+	...
+	which is roughly equivalent because the sleep is called at the end of main,
+	but slightly better because it guards against hangs from the start rather than
+	from the end of main.
+
+	Likewise in gdb.base/watch_thread_num.exp.
+
+	Likewise in gdb.btrace/enable-running.exp, but use the sleep loop there,
+	because the sleep is not called at the end of main.
+
+	Tested on x86_64-linux.
+
+2021-09-16  Mike Frysinger  <vapier@gentoo.org>
+
+	gdb: manual: fix werrors typo
+
+2021-09-16  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-15  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Use function_range in gdb.dwarf2/dw2-abs-hi-pc.exp
+	When I run test-case gdb.dwarf2/dw2-abs-hi-pc.exp with gcc, we have:
+	...
+	(gdb) break hello^M
+	Breakpoint 1 at 0x4004c0: file dw2-abs-hi-pc-hello.c, line 24.^M
+	(gdb) PASS: gdb.dwarf2/dw2-abs-hi-pc.exp: break hello
+	...
+	but with clang, I run into:
+	...
+	(gdb) break hello^M
+	Breakpoint 1 at 0x4004e4^M
+	(gdb) FAIL: gdb.dwarf2/dw2-abs-hi-pc.exp: break hello
+	...
+
+	The problem is that the CU and function both have an empty address range:
+	...
+	 <0><d2>: Abbrev Number: 1 (DW_TAG_compile_unit)
+	    <108>   DW_AT_name        : dw2-abs-hi-pc-hello.c
+	    <123>   DW_AT_low_pc      : 0x4004e0
+	    <127>   DW_AT_high_pc     : 0x4004e0
+	 <1><12f>: Abbrev Number: 2 (DW_TAG_subprogram)
+	    <131>   DW_AT_name        : hello
+	    <13a>   DW_AT_low_pc      : 0x4004e0
+	    <13e>   DW_AT_high_pc     : 0x4004e0
+	...
+
+	The address ranges are set like this in dw2-abs-hi-pc-hello-dbg.S:
+	...
+	        .4byte  .hello_start    /* DW_AT_low_pc */
+	        .4byte  .hello_end      /* DW_AT_high_pc */
+	...
+	where the labels refer to dw2-abs-hi-pc-hello.c:
+	...
+	extern int v;
+
+	asm (".hello_start: .globl .hello_start\n");
+	void
+	hello (void)
+	{
+	asm (".hello0: .globl .hello0\n");
+	  v++;
+	asm (".hello1: .globl .hello1\n");
+	}
+	asm (".hello_end: .globl .hello_end\n");
+	...
+
+	Using asm labels in global scope is a known source of problems, as explained
+	in the comment of proc function_range in gdb/testsuite/lib/dwarf.exp.
+
+	Fix this by using function_range instead.
+
+	Tested on x86_64-linux with gcc and clang-7 and clang-12.
+
+2021-09-15  Claudiu Zissulescu  <claziss@synopsys.com>
+
+	arc: Fix got-weak linker test
+	Use regular expressions to fix the got-weak linker test.
+
+	ld/
+		* testsuite/got-weak.d: Update test.
+
+2021-09-15  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	bfd: fix incorrect type used in sizeof
+	Noticed in passing that we used 'sizeof (char **)' when calculating
+	the size of a list of 'char *' pointers.  Of course, this isn't really
+	going to make a difference anywhere, but we may as well be correct.
+
+	There should be no user visible changes after this commit.
+
+	bfd/ChangeLog:
+
+		* archures.c (bfd_arch_list): Use 'char *' instead of 'char **'
+		when calculating space for a string list.
+
+2021-09-15  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/doc] Fix typo in maint selftest entry
+	Fix typo "will by" -> "will be".
+
+2021-09-15  Tom de Vries  <tdevries@suse.de>
+
+	[bfd] Ensure unique printable names for bfd archs
+	Remove duplicate entry in bfd_ft32_arch and bfd_rx_arch.
+
+	Fix printable name for bfd_mach_n1: "nh1" -> "n1".
+
+		PR 28336
+		* cpu-ft32.c (arch_info_struct): Remove "ft32" entry.
+		* cpu-rx.c (arch_info_struct): Remove "rx" entry.
+		* cpu-nds32.c (bfd_nds32_arch): Fix printable name for bfd_mach_n1
+		entry.
+
+2021-09-15  Alan Modra  <amodra@gmail.com>
+
+	PR28328, dlltool ice
+		PR 28328
+		* archive.c (bfd_ar_hdr_from_filesystem): Don't use bfd_set_input_error
+		here, our caller will do that.
+
+2021-09-15  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-14  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb_load_no_complaints with gnu-debuglink
+	When running test-case gdb.dwarf2/dw2-ranges-psym-warning.exp with target
+	board gnu-debuglink I run into:
+	...
+	(gdb) file dw2-ranges-psym-warning^M
+	Reading symbols from dw2-ranges-psym-warning...^M
+	Reading symbols from .debug/dw2-ranges-psym-warning.debug...^M
+	(gdb) FAIL: gdb.dwarf2/dw2-ranges-psym-warning.exp: No complaints
+	...
+
+	Fix this by updating the regexp in gdb_load_no_complaints.
+
+	Tested on x86_64-linux.
+
+2021-09-14  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/symtab] Fix function range handling in psymtabs
+	Consider the test-case from this patch.
+
+	We run into:
+	...
+	(gdb) PASS: gdb.dwarf2/dw2-ranges-psym-warning.exp: continue
+	bt^M
+	warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in symtab.)^M
+	^M
+	warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in symtab.)^M
+	^M
+	warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in symtab.)^M
+	^M
+	warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in symtab.)^M
+	^M
+	warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in symtab.)^M
+	^M
+	warning: (Internal error: pc 0x4004b6 in read in psymtab, but not in symtab.)^M
+	^M
+	  read in psymtab, but not in symtab.)^M
+	^M
+	)^M
+	(gdb) FAIL: gdb.dwarf2/dw2-ranges-psym-warning.exp: bt
+	...
+
+	This happens as follows.
+
+	The function foo:
+	...
+	 <1><31>: Abbrev Number: 4 (DW_TAG_subprogram)
+	    <33>   DW_AT_name        : foo
+	    <37>   DW_AT_ranges      : 0x0
+	...
+	has these ranges:
+	...
+	    00000000 00000000004004c1 00000000004004d2
+	    00000000 00000000004004ae 00000000004004af
+	    00000000 <End of list>
+	...
+	which have a hole at at [0x4004af,0x4004c1).
+
+	However, the address map of the partial symtabs incorrectly maps addresses
+	in the hole (such as 0x4004b6 in the backtrace) to the foo CU.
+
+	The address map of the full symbol table of the foo CU however does not
+	contain the addresses in the hole, which is what the warning / internal error
+	complains about.
+
+	Fix this by making sure that ranges of functions are read correctly.
+
+	The patch adds a bit to struct partial_die_info, in this hole (shown for
+	x86_64-linux):
+	...
+	/*   11: 7   |     4 */    unsigned int canonical_name : 1;
+	/* XXX  4-byte hole  */
+	/*   16      |     8 */    const char *raw_name;
+	...
+	So there's no increase in size for 64-bit, but AFAIU there will be an increase
+	for 32-bit.
+
+	Tested on x86_64-linux.
+
+	gdb/ChangeLog:
+
+	2021-08-10  Tom de Vries  <tdevries@suse.de>
+
+		PR symtab/28200
+		* dwarf2/read.c (struct partial_die_info): Add has_range_info and
+		range_offset field.
+		(add_partial_subprogram): Handle pdi->has_range_info.
+		(partial_die_info::read): Set pdi->has_range_info.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-08-10  Tom de Vries  <tdevries@suse.de>
+
+		PR symtab/28200
+		* gdb.dwarf2/dw2-ranges-psym-warning-main.c: New test.
+		* gdb.dwarf2/dw2-ranges-psym-warning.c: New test.
+		* gdb.dwarf2/dw2-ranges-psym-warning.exp: New file.
+
+2021-09-14  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/symtab] Fix CU list in .debug_names for dummy CUs
+	With current trunk and target board cc-with-debug-names we have:
+	...
+	(gdb) file dw2-ranges-psym^M
+	Reading symbols from dw2-ranges-psym...^M
+	warning: Section .debug_names in dw2-ranges-psym has abbreviation_table of \
+	  size 1 vs. written as 28, ignoring .debug_names.^M
+	(gdb) set complaints 0^M
+	(gdb) FAIL: gdb.dwarf2/dw2-ranges-psym.exp: No complaints
+	...
+
+	The executable has 8 compilation units:
+	...
+	$ readelf -wi dw2-ranges-psym | grep @
+	  Compilation Unit @ offset 0x0:
+	  Compilation Unit @ offset 0x2e:
+	  Compilation Unit @ offset 0xa5:
+	  Compilation Unit @ offset 0xc7:
+	  Compilation Unit @ offset 0xd2:
+	  Compilation Unit @ offset 0x145:
+	  Compilation Unit @ offset 0x150:
+	  Compilation Unit @ offset 0x308:
+	...
+	of which the ones at 0xc7 and 0x145 are dummy CUs (that is, they do not
+	contain a single DIE), which were added by recent commit 5ef670d81fd
+	"[gdb/testsuite] Add dummy start and end CUs in dwarf assembly".
+
+	The .debug_names section contains this CU table:
+	...
+	[  0] 0x0
+	[  1] 0x2e
+	[  2] 0xa5
+	[  3] 0xd2
+	[  4] 0x150
+	[  5] 0x308
+	[  6] 0x1
+	[  7] 0x0
+	...
+	The last two entries are incorrect, and the entries for the dummy CUs are
+	missing.
+
+	The last two entries are incorrect because here in write_debug_names we write
+	the dimension of the CU list as 8:
+	...
+	  /* comp_unit_count - The number of CUs in the CU list.  */
+	  header.append_uint (4, dwarf5_byte_order,
+	                     per_objfile->per_bfd->all_comp_units.size ()
+	                     - per_objfile->per_bfd->tu_stats.nr_tus);
+	...
+	while the actual dimension of the CU list is 6.
+
+	The discrepancy is caused by this code which skips the dummy CUs:
+	...
+	  for (int i = 0; i < per_objfile->per_bfd->all_comp_units.size (); ++i)
+	    {
+	      ...
+	      /* CU of a shared file from 'dwz -m' may be unused by this main
+	        file.  It may be referenced from a local scope but in such
+	        case it does not need to be present in .debug_names.  */
+	      if (psymtab == NULL)
+	       continue;
+	...
+	because they have a null partial symtab.
+
+	We can fix this by writing the actual dimension of the CU list, but that still
+	leaves the dummy CUs out of the CU list.  The purpose of having these is to
+	delimit the end of preceding CUs.
+
+	So, fix this by:
+	- removing the code that skips the dummy CUs (note that the same change
+	  was done for .gdb_index in commit efba5c2319d '[gdb/symtab] Handle PU
+	  without import in "save gdb-index"'.
+	- verifying that all units are represented in the CU/TU lists
+	- using the actual CU list size when writing the dimension of the CU list
+	  (and likewise for the TU list).
+
+	Tested on x86_64-linux with native and target board cc-with-debug-names.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28261
+
+2021-09-14  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Generate .debug_aranges in gdb.dwarf2/locexpr-data-member-location.exp
+	When running test-case gdb.dwarf2/locexpr-data-member-location.exp with target
+	board cc-with-debug-names, all tests pass but we run into PR28261:
+	...
+	(gdb) run ^M
+	Starting program: locexpr-data-member-location ^M
+	warning: Section .debug_names in locexpr-data-member-location-lib.so has \
+	  abbreviation_table of size 1 vs. written as 37, ignoring .debug_names.^M
+	...
+
+	Using a patch that fixes PR28261, the warning is gone, but we run into:
+	...
+	FAIL: gdb.dwarf2/locexpr-data-member-location.exp: step into foo
+	...
+
+	This is due a missing .debug_aranges contribution for the CU declared in
+	gdb.dwarf2/locexpr-data-member-location.exp.
+
+	Fix this by adding the missing .debug_aranges contribution.
+
+	Tested on x86_64-linux.
+
+2021-09-14  Claudiu Zissulescu  <claziss@synopsys.com>
+
+	arc: Fix potential invalid pointer access when fixing got symbols.
+	When statically linking, it can arrive to an undefined weak symbol of
+	which its value cannot be determined. However, we are having pieces of
+	code which doesn't take this situation into account, leading to access
+	a structure which may not be initialized. Fix this situation and add a
+	test.
+
+	bfd/
+	xxxx-xx-xx  Cupertino Miranda  <cmiranda@synopsys.com>
+	            Claudiu Zissulescu  <claziss@synopsys.com>
+
+		* arc-got.h (arc_static_sym_data): New structure.
+		(get_static_sym_data): New function.
+		(relocate_fix_got_relocs_for_got_info): Move the computation fo
+		symbol value and section to above introduced function, and use
+		this new function.
+
+	ld/testsuite/
+	xxxx-xx-xx  Claudiu Zissulescu  <claziss@synopsys.com>
+
+		* ld-arc/got-weak.d: New file.
+		* ld-arc/got-weak.s: Likewise.
+
+
+	fix
+
+2021-09-14  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: bfin: add support for SDL2
+	This probably should have been ported long ago, but better late than
+	never.  We keep support for both versions for now since both projects
+	tend to have long lifetimes.  Maybe consider dropping SDL1 in another
+	ten years.
+
+2021-09-14  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-14  Tom Tromey  <tom@tromey.com>
+
+	Remove use of __CYGNUSCLIB__
+	I found a check of __CYGNUSCLIB__ in dbxread.c.  I think this is dead
+	code.  This patch removes it.
+
+2021-09-13  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Check for valid test name
+	When running gdb.base/batch-exit-status.exp I noticed that the test name
+	contains a newline:
+	...
+	PASS: gdb.base/batch-exit-status.exp: : No such file or directory\.^M
+	: No such file or directory\.: [lindex $result 2] == 0
+	...
+
+	Check for this in ::CheckTestNames::check, such that we have a warning:
+	...
+	PASS: gdb.base/batch-exit-status.exp: : No such file or directory\.^M
+	: No such file or directory\.: [lindex $result 2] == 0
+	WARNING: Newline in test name
+	...
+
+	Tested on x86_64-linux.
+
+2021-09-13  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/tdep] Fix exec check in gdb_print_insn_arm
+	With a gdb build with --enable-targets=all we run into a KFAIL:
+	...
+	KFAIL: gdb.gdb/unittest.exp: executable loaded: maintenance selftest, \
+	  failed none (PRMS: gdb/27891)
+	...
+	due to:
+	...
+	Running selftest print_one_insn.^M
+	Self test failed: arch armv8.1-m.main: self-test failed at \
+	  disasm-selftests.c:165^M
+	...
+
+	The test fails because we expect disassembling of one arm insn to consume 4
+	bytes and produce (using verbose = true in disasm-selftests.c):
+	...
+	arm mov r0, #0
+	...
+	but instead the disassembler uses thumb mode and only consumes 2
+	bytes and produces:
+	...
+	arm movs        r0, r0
+	...
+
+	The failure does not show up in the "no executable loaded" variant because
+	this code in gdb_print_insn_arm isn't triggered:
+	...
+	  if (current_program_space->exec_bfd () != NULL)
+	    info->flags |= USER_SPECIFIED_MACHINE_TYPE;
+	...
+	and consequently we do this in print_insn:
+	...
+	      if ((info->flags & USER_SPECIFIED_MACHINE_TYPE) == 0)
+	        info->mach = bfd_mach_arm_unknown;
+	...
+	and don't set force_thumb to true in select_arm_features.
+
+	The code in gdb_print_insn_arm makes the assumption that the disassembly
+	architecture matches the exec architecture, which in this case is incorrect,
+	because the exec architecture is x86_64, and the disassembly architecture is
+	armv8.1-m.main.  Fix that by explicitly checking it:
+	...
+	  if (current_program_space->exec_bfd () != NULL
+	      && (current_program_space->exec_bfd ()->arch_info
+		  == gdbarch_bfd_arch_info (gdbarch)))
+	...
+
+	This fixes the print_one_insn failure, so remove the KFAIL.
+
+	Tested on x86_64-linux.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27891
+
+2021-09-13  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/tdep] Reset force_thumb in parse_arm_disassembler_options
+	With a gdb build with --enable-targets=all, we have 2 arch-specific failures
+	in selftest print_one_insn:
+	...
+	$ gdb -q -batch a.out -ex "maint selftest print_one_insn" 2>&1 \
+	  | grep "Self test failed: arch "
+	Self test failed: arch armv8.1-m.main: self-test failed at \
+	  disasm-selftests.c:165
+	Self test failed: arch arm_any: self-test failed at disasm-selftests.c:165
+	$
+	...
+
+	During the first failed test, force_thumb is set to true, and remains so until
+	and during the second test, which causes the second failure.
+
+	Fix this by resetting force_thumb to false in parse_arm_disassembler_options,
+	such that we get just one failure:
+	...
+	$ gdb -q -batch a.out -ex "maint selftest print_one_insn" 2>&1 \
+	  | grep "Self test failed: arch "
+	Self test failed: arch armv8.1-m.main: self-test failed at \
+	  disasm-selftests.c:165
+	$
+	...
+
+	Tested on x86_64-linux.
+
+2021-09-13  Tom Tromey  <tromey@adacore.com>
+
+	Fix no-Python build
+	A build without Python will currently fail, because
+	selftests::test_python uses gdb_python_initialized, which is only
+	conditionally defined.
+
+	This patch fixes the build by making test_python also be conditionally
+	defined.  I chose this approach because the selftest will fail if
+	Python is not enabled, so it didn't seem useful to leave it defined.
+
+2021-09-13  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: Update the assembler insn testcase.
+	Since the 0x57 is preserved for the vadd.vv instruction in the integration
+	branch, remove it to make sure the testcase can work.
+
+	gas/
+		* testsuite/gas/riscv/insn.d: Remove 0x57 since it is preserved
+		for vadd.vv instruction.
+		* testsuite/gas/riscv/insn.s: Likewise.
+
+2021-09-13  Jan Beulich  <jbeulich@suse.com>
+
+	MIPS: don't use get_symbol_name() for section parsing.  With s_change_section() later calling obj_elf_section(), it seems better to pre-parse the section name by the same function that will be used there. This way no differences in what is accepted will result.
+	gas	* config/tc-mips.c (s_change_section): Use obj_elf_section_name to
+		parse the section name.
+
+	ia64: don't use get_symbol_name() for section parsing.  With cross_section() later calling obj_elf_section(), it seems better to pre-parse the section name by the same function that will be used there. This way no differences in what is accepted will result.
+	gas	* config/tc-ia64.c (cross_section): Use obj_elf_section_name to
+		parse the section name.
+
+2021-09-13  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.gdb/selftest.exp
+	With a gdb build with CFLAGS "-O2 -g -flto=auto", I run into:
+	...
+	 #7  gdb_main (args=0x7fffffffd220) at src/gdb/main.c:1368^M
+	 #8  main (argc=<optimized out>, argv=<optimized out>) at src/gdb/gdb.c:32^M
+	 (gdb) FAIL: gdb.gdb/selftest.exp: backtrace through signal handler
+	...
+	which means that this regexp in proc test_with_self fails:
+	...
+	  -re "#0.*(read|poll).*in main \\(.*\\) at .*gdb\\.c.*$gdb_prompt $" {
+	...
+
+	The problem is that gdb_main has been inlined into main, and consequently the
+	backtrace uses:
+	...
+	 #x  <fn> ...
+	...
+	instead of
+	...
+	 #x  <address> in <fn> ...
+	...
+
+	Fix this by updating the regexp to not require "in" before " main".
+
+	Tested on x86_64-linux.
+
+2021-09-13  Alan Modra  <amodra@gmail.com>
+
+	Re: Deprecate a.out support for NetBSD targets
+		* config.bfd: Correct m68-*-*bsd* obsolete target match.
+
+2021-09-13  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix test name in gdb.base/batch-exit-status.exp
+	When running gdb.base/batch-exit-status.exp I noticed that the test name
+	contains a newline:
+	...
+	PASS: gdb.base/batch-exit-status.exp: : No such file or directory\.^M
+	: No such file or directory\.: [lindex $result 2] == 0
+	...
+
+	The mistake is that I passed an output regexp argument to a parameter
+	interpreted as testname prefix.  Fix this by passing a testname prefix
+	instead.
+
+	Add support for checking output, to be able to handle the output regexp
+	argument.
+
+	Tested on x86_64-linux.
+
+2021-09-13  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-12  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Set sysroot earlier in local-board.exp
+	When running test-case gdb.base/batch-exit-status.exp for native, it passes.
+	But with target board cc-with-debug-names, we run into (added missing double
+	quotes for clarity):
+	...
+	builtin_spawn $build/gdb/testsuite/../../gdb/gdb -nw -nx \
+	  -data-directory $build/gdb/testsuite/../data-directory \
+	  -iex "set height 0" -iex "set width 0" -ex "set sysroot" -batch ""^M
+	: No such file or directory.^M
+	PASS: gdb.base/batch-exit-status.exp: \
+	  : No such file or directory\.: [lindex $result 2] == 0
+	FAIL: gdb.base/batch-exit-status.exp: \
+	  : No such file or directory\.: [lindex $result 3] == $expect_status
+	...
+
+	The difference between the passing and failing case is that with native we
+	have (leaving out set height/width for brevity):
+	...
+	$ gdb -batch ""; echo $?
+	: No such file or directory.
+	1
+	...
+	and with target board cc-with-debug-names:
+	...
+	$ gdb -ex "set sysroot" -batch ""; echo $?
+	: No such file or directory.
+	0
+	...
+
+	The difference is expected.  GDB returns the exit status of the last executed
+	command.  In the former case that's 'file ""', which fails.  In the latter case,
+	that's 'set sysroot', which succeeds.
+
+	Fix this by setting sysroot using -iex instead of -ex in local-board.exp, such
+	that we have the expected:
+	...
+	$ gdb -iex "set sysroot" -batch ""; echo $?
+	: No such file or directory.
+	1
+	...
+
+	Tested on x86_64-linux.
+
+2021-09-12  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-11  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: run: change help short option to -h
+	It's unclear why -H was picked over the more standard -h, but since
+	-h is still not used, just change -H to -h to match pretty much every
+	other tool in the sourceware tree.
+
+2021-09-11  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-10  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Reimplement gdb.gdb/python-selftest.exp as unittest
+	The test-case gdb.gdb/python-selftest.exp:
+	- patches the gdb_python_initialized variable in gdb to 0
+	- checks that the output of a python command is "Python not initialized"
+
+	Reimplement gdb.gdb/python-selftest.exp as unittest, using:
+	- execute_command_to_string to capture the output
+	- try/catch to catch the "Python not initialized" exception.
+
+	Tested on x86_64-linux.
+
+2021-09-10  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix DUPLICATE in gdb.base/global-var-nested-by-dso.exp
+	Fix DUPLICATE in gdb.base/global-var-nested-by-dso.exp by naming commands more
+	uniquely.
+
+2021-09-10  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix DUPLICATE in gdb.base/skip-solib.exp
+	Fix DUPLICATE in gdb.base/skip-solib.exp by using with_test_prefix.
+
+	Also fix indentation style and long lines, remove outdated question/answer
+	bits, and use multi_line.
+
+2021-09-10  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix handling of nr_args < 3 in mi_gdb_test
+	The documentation of mi_gdb_test states that the command, pattern and message
+	arguments are mandatory:
+	...
+	 # mi_gdb_test COMMAND PATTERN MESSAGE [IPATTERN] -- send a command to gdb;
+	 #   test the result.
+	...
+
+	However, this is not checked, and when mi_gdb_test is called with less than 3
+	arguments, it passes or fails silently.
+
+	Fix this by using the following semantics:
+	- if there are 1 or 2 arguments, use the command as the message.
+	- if there is 1 argument, use ".*" as the pattern.
+	- if there are no or too much arguments, error out.
+
+	Fix a PATH issue in gdb.mi/mi-logging.exp, introduced by using the command as
+	message.  Fix a few other trivial-looking FAILs.
+
+	There are 11 less trivial-looking FAILs left in gdb.mi in test-cases:
+	- mi-nsmoribund.exp
+	- mi-breakpoint-changed.exp
+	- mi-break.exp.
+
+	Tested on x86_64-linux.
+
+2021-09-10  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Add string_list_to_regexp
+	A regexp pattern with escapes like this is hard to read:
+	...
+	set re "~\"\[$\]$decimal = 1\\\\n\"\r\n\\^done"
+	...
+
+	We can make it more readable by spacing out parts (which allows us to also use
+	the curly braces where that's convenient):
+	...
+	set re [list "~" {"} {[$]} $decimal " = 1" "\\\\" "n" {"} "\r\n" "\\^" "done"]
+	set re [join $re ""]
+	...
+	or by using string_to_regexp:
+	...
+	set re [list \
+	            [string_to_regexp {~"$}] \
+	            $decimal \
+	            [string_to_regexp " = 1\\n\"\r\n^done"]]
+	set re [join $re ""]
+	...
+	Note: we have to avoid applying string_to_list to decimal, which is already a
+	regexp.
+
+	Add a proc string_list_to_regexp to make it easy to do both:
+	...
+	set re [list \
+	            [string_list_to_regexp ~ {"} $] \
+	            $decimal \
+	            [string_list_to_regexp " = 1" \\ n {"} \r\n ^ done]]
+	...
+
+	Also add a test-case gdb.testsuite/string_to_regexp.exp.
+
+2021-09-10  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Handle unrecognized command line option in gdb_compile_test
+	When running the gdb testsuite with gnatmake-4.8, I get many fails of the
+	following form:
+	...
+	gcc: error: unrecognized command line option '-fgnat-encodings=all'^M
+	gnatmake: "gdb.ada/O2_float_param/foo.adb" compilation error^M
+	compiler exited with status 1
+	compilation failed: gcc ... gdb.ada/O2_float_param/foo.adb
+	gcc: error: unrecognized command line option '-fgnat-encodings=all'
+	gnatmake: "gdb.ada/O2_float_param/foo.adb" compilation error
+	FAIL: gdb.ada/O2_float_param.exp: scenario=all: compilation foo.adb
+	...
+
+	Fix this by marking the test unsupported instead, such that we have:
+	...
+	UNSUPPORTED: gdb.ada/O2_float_param.exp: scenario=all: compilation foo.adb \
+	  (unsupported option '-fgnat-encodings=all')
+	...
+
+	Tested on x86_64-linux.
+
+2021-09-10  Alan Modra  <amodra@gmail.com>
+
+	PowerPC, sanity check r_offset in relocate_section
+	        * elf32-ppc.c (offset_in_range): New function.
+		(ppc_elf_vle_split16): Sanity check r_offset before accessing
+		section contents.  Return status.
+	        (ppc_elf_relocate_section): Sanity check r_offset before
+	        accessing section contents.  Don't segfault on NULL howto.
+
+	Re: gas: Use the directory name in .file 0
+		PR gas/28266
+		* testsuite/gas/elf/dwarf-5-file0-2.s: Use %object rather than
+		@object, .4byte instead of .long, and .asciz instead of .string.
+
+2021-09-10  Mike Frysinger  <vapier@gentoo.org>
+
+	etc: switch to automake
+	There's no content in here currently, so switching to automake is
+	pretty easy with a stub file.
+
+	etc: rename configure.in to configure.ac
+	The .in name has been deprecated for a long time in favor of .ac.
+
+2021-09-10  H.J. Lu  <hjl.tools@gmail.com>
+
+	gas: Use the directory name in .file 0
+	DWARF5 allows .file 0 to take an optional directory name.  Set the entry
+	0 of the directory table to the directory name in .file 0.
+
+		PR gas/28266
+		* dwarf2dbg.c (get_directory_table_entry): Add an argument for
+		the directory name in .file 0 and use it, instead of PWD.
+		(allocate_filenum): Pass NULL to get_directory_table_entry.
+		(allocate_filename_to_slot): Pass the incoming dirname to
+		get_directory_table_entry.
+		* testsuite/gas/elf/dwarf-5-file0-2.d: New file.
+		* testsuite/gas/elf/dwarf-5-file0-2.s: Likewise.
+		* testsuite/gas/elf/elf.exp: Run dwarf-5-file0-2.
+
+2021-09-10  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-09  Yoshinori Sato  <ysato@users.sourceforge.jp>
+
+	gdb: Enable target rx-*-*linux.
+	I added rx-*-linux in binutils few yaers ago.
+	But missing this changes,
+
+2021-09-09  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.base/coredump-filter-build-id.exp with older eu-unstrip
+	On openSUSE Leap 42.3 with eu-unstrip 0.158, we run into:
+	...
+	(gdb) PASS: gdb.base/coredump-filter-build-id.exp: save corefile
+	First line of eu-unstrip: \
+	  0x400000+0x202000 f4ae8502bd6a14770182382316bc595e9dc6f08b@0x400284 - - [exe]
+	FAIL: gdb.base/coredump-filter-build-id.exp: gcore dumped mapping with build-id
+	...
+
+	The test expects an actual file name instead of '[exe]', but that only got
+	introduced with eu-unstrip 0.161.  Before it printed '[exe]' or '[pie]'.
+
+	Fix this by updating the regexp.
+
+	Tested on x86_64-linux.
+
+2021-09-09  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix various issues in gdb.mi/mi-sym-info.exp
+	I noticed this failure in gdb.mi/mi-sym-info.exp with gcc-4.8:
+	...
+	FAIL: gdb.mi/mi-sym-info.exp: -symbol-info-functions --max-results 1 \
+	  (unexpected output)
+	...
+	due to function f2 instead of f3 being listed.
+
+	AFAICT, this is caused by a difference in debug info:
+	...
+	$ readelf -wi outputs/gdb.mi/mi-sym-info/mi-sym-info1.o \
+	  | egrep "DW_AT_name.*: f[1-3]"
+	    <72>   DW_AT_name        : f1
+	    <a1>   DW_AT_name        : f2
+	    <d0>   DW_AT_name        : f3
+	...
+	vs:
+	...
+	$ readelf -wi outputs/gdb.mi/mi-sym-info/mi-sym-info1.o \
+	  | egrep "DW_AT_name.*: f[1-3]"
+	    <f4>   DW_AT_name        : f3
+	    <123>   DW_AT_name        : f2
+	    <152>   DW_AT_name        : f1
+	...
+	and the command documentation does not mention an imposed order, so fix this
+	by allowing f2 as well.
+
+	Doing this fix, it made sense to do a refactoring of adding f2_re and f3_re
+	variables, in order to write (?:$f2_re|$f3_re), and I applied the same pattern
+	overall.
+
+	Furthermore, I found a silent FAIL due to calling mi_gdb_proc with 2 args, fix
+	by updating the regexp.
+
+	Then I ran with clang and found another FAIL, fix by updating the regexp.
+
+	Tested on x86_64-linux with gcc-4.8.5, gcc-7.5.0, gcc-11.2.1, clang-7.0.1 and
+	clang-12.0.1.
+
+2021-09-09  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Reimplement gdb.gdb/complaints.exp as unittest
+	When building gdb with "-Wall -O2 -g -flto=auto", I run into:
+	...
+	(gdb) call clear_complaints()^M
+	No symbol "clear_complaints" in current context.^M
+	(gdb) FAIL: gdb.gdb/complaints.exp: clear complaints
+	...
+
+	The problem is that lto has optimized away the clear_complaints function
+	and consequently the selftest doesn't work.
+
+	Fix this by reimplementing the selftest as a unit test.
+
+	Factor out two new functions:
+	- void
+	  execute_fn_to_ui_file (struct ui_file *file, std::function<void(void)> fn);
+	- std::string
+	  execute_fn_to_string (std::function<void(void)> fn, bool term_out);
+	and use the latter to capture the complaints output.
+
+	Tested on x86_64-linux.
+
+2021-09-09  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb/python: remove all uses of Py_TPFLAGS_HAVE_ITER
+	Python 2 has a bit flag Py_TPFLAGS_HAVE_ITER which can be passed as
+	part of the tp_flags field when defining a new object type.  This flag
+	is not defined in Python 3 and so we define it to 0 in
+	python-internal.h (when IS_PY3K is defined).
+
+	The meaning of this flag is that the object has the fields tp_iter and
+	tp_iternext.  Note the use of "has" here, the flag says nothing about
+	the values in those fields, just that the type object has the fields.
+
+	In early versions of Python 2 these fields were no part of the
+	PyTypeObject struct, they were added in version 2.2 (see
+	https://docs.python.org/release/2.3/api/type-structs.html).  And so,
+	there could be a some code compiled out there which has a PyTypeObject
+	structure within it that doesn't even have the tp_iter and tp_iternext
+	fields, attempting to access these fields would be undefined
+	behaviour.
+
+	And so Python added the Py_TPFLAGS_HAVE_ITER flag.  If the flag is
+	present then Python is free to access the tp_iter and tp_iternext
+	fields.
+
+	If we consider GDB then we always assume that the tp_iter and
+	tp_iternext fields are part of PyTypeObject.  If someone was crazy
+	enough to try and compile GDB against Python 2.1 then we'd get lots of
+	build errors saying that we were passing too many fields when
+	initializing PyTypeObject structures.  And so, I claim, we can be sure
+	that GDB will always be compiled with a version of Python that has the
+	tp_iter and tp_iternext fields in PyTypeObject.
+
+	Next we can look at the Py_TPFLAGS_DEFAULT flag.  In Python 2, each
+	time additional fields are added to PyTypeObject a new Py_TPFLAGS_*
+	flag would be defined to indicate whether those flags are present or
+	not.  And, those new flags would be added to Py_TPFLAGS_DEFAULT.  And
+	so, in the latest version of Python 2 the Py_TPFLAGS_DEFAULT flag
+	includes Py_TPFLAGS_HAVE_ITER (see
+	https://docs.python.org/2.7/c-api/typeobj.html).
+
+	In GDB we pass Py_TPFLAGS_DEFAULT as part of the tp_flags for all
+	objects we define.
+
+	And so, in this commit, I propose to remove all uses of
+	Py_TPFLAGS_HAVE_ITER from GDB, it's simply not needed.
+
+	There should be no user visible changes after this commit.
+
+2021-09-09  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: accept -EB/-EL short options
+	Many GNU tools accept -EB/-EL as short options for selecting big &
+	little endian modes.  While the sim has an -E option, it requires
+	spelling out "big" and "little".  Adding support for -EB & -EL is
+	thus quite trivial, so lets round it out to be less annoying.
+
+	sim: ppc: drop support for std-config.h overrides
+	Only the ppc arch supports this kind of source file override logic.
+	All the others expose knobs via configure flags, and for some of
+	these, the ppc code does as well.  For others, it doesn't make sense
+	to ever change them.  Since it's unlikely anyone is using this, drop
+	it all to simplify the code (and to get us a little closer to the
+	common sim code).
+
+	sim: ppc: enable use of gnulib
+	All other sim arches are using this now, so finish up the logic in
+	the ppc arch to enable gnulib usage here too.
+
+	sim: drop old O_NDELAY & FNBLOCK support
+	We use these older names inconsistently in the sim codebase, and time
+	has moved on long ago, so drop support for these non-standard names.
+	POSIX provides O_NONBLOCK for us, so use it everywhere.
+
+2021-09-09  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: dv-sockser: enable for mingw targets too
+	We have enough functionality from gnulib now to build sockser on
+	all platforms.
+
+	Non-blocking I/O is supported when F_GETFL/F_SETFL are unavailable,
+	but we can address that in a follow up commit.  This mirrors what
+	is done in other places in the sim already.
+
+2021-09-09  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: cgen: workaround Windows VOID define
+	The cgen framework provides a "VOID" type for code to use, but this
+	defines ends up conflicting with the standard Windows VOID define.
+	Since they actually define to the same thing ("void"), undef it here
+	to fix the Windows build.
+
+	We might want to reconsider the need for "VOID" in cgen, but that
+	will take larger discussion & coordination with the cgen project.
+
+2021-09-09  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: dv-sockser: move sim-main.h include after system includes
+	The sim-main.h header is a bit of a dumping ground.  Every arch can
+	(and many do) define all sorts of weird & common names that end up
+	conflicting with system headers.  So including it before the system
+	headers sets us up for pain.  v850 is a good example of this -- when
+	building for mingw, we see weird failures:
+
+	$ i686-w64-mingw32-gcc ... -c -o dv-sockser.o ../../../../sim/v850/../common/dv-sockser.c
+	In file included from ../../../../sim/v850/sim-main.h:11,
+	                 from ../../../../sim/v850/../common/dv-sockser.c:24:
+	../../../../sim/v850/../common/sim-base.h:97:32: error: expected ')' before '->' token
+	  97 | # define STATE_CPU(sd, n) ((sd)->cpu[0])
+	     |                                ^~
+
+	While gcc is unhelpful at first, running it through the preprocessor
+	by hand shows more details:
+
+	$ i686-w64-mingw32-gcc ... -E -dD -o dv-sockser.i ../../../../sim/v850/../common/dv-sockser.c
+	$ i686-w64-mingw32-gcc -c dv-sockser.i
+	In file included from /usr/i686-w64-mingw32/usr/include/minwindef.h:163,
+	                 from /usr/i686-w64-mingw32/usr/include/windef.h:9,
+	                 from /usr/i686-w64-mingw32/usr/include/windows.h:69,
+	                 from /usr/i686-w64-mingw32/usr/include/winsock2.h:23,
+	                 from ../../gnulib/import/sys/socket.h:684,
+	                 from ../../gnulib/import/netinet/in.h:43,
+	                 from ../../../../sim/v850/../common/dv-sockser.c:39:
+	/usr/i686-w64-mingw32/usr/include/winnt.h:4803:25: error: expected ')' before '->' token
+	 4803 |       DWORD State;
+	      |                         ^
+	      |                         )
+
+	This is because v850 sets up this common name:
+
+	All of this needs cleaning up someday, but since the dv-sockser code
+	definitely should be fixed in this way, lets do that now and unblock
+	the v850 code.
+
+2021-09-09  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: mips: delete unused PSIZE define
+	It's unclear what this define is for as it appears to be unused, and
+	has never been used in the history of the mips sim.  Delete it to tidy
+	up, and to fix build errors for Windows targets that have a standard
+	"PSIZE" struct in their system headers.  This doesn't show up yet as
+	most sim files don't include many system headers, but enabling sockser
+	code for mingw uncovers the conflict.
+
+	Unfortunately the error produced by gcc is inscrutable, but running
+	it through the preprocessor manually manages to provide a pointer to
+	the underlying issue.
+
+	$ i686-w64-mingw32-gcc ... -c -o dv-sockser.o ../../../../sim/mips/../common/dv-sockser.c
+	<command-line>: error: expected identifier or '(' before numeric constant
+	In file included from /usr/i686-w64-mingw32/usr/include/windows.h:71,
+	                 from /usr/i686-w64-mingw32/usr/include/winsock2.h:23,
+	                 from ../../gnulib/import/sys/socket.h:684,
+	                 from ../../gnulib/import/netinet/in.h:43,
+	                 from ../../../../sim/mips/../common/dv-sockser.c:39:
+	/usr/i686-w64-mingw32/usr/include/wingdi.h:2934:59: error: unknown type name 'LPSIZE'; did you mean 'LPSIZEL'?
+	 2934 |   WINGDIAPI WINBOOL WINAPI GetAspectRatioFilterEx(HDC hdc,LPSIZE lpsize);
+	      |                                                           ^~~~~~
+	      |                                                           LPSIZEL
+	...
+
+	$ i686-w64-mingw32-gcc ... -E -dD -o dv-sockser.i ../../../../sim/mips/../common/dv-sockser.c
+	$ i686-w64-mingw32-gcc -c dv-sockser.i
+	In file included from /usr/i686-w64-mingw32/usr/include/windows.h:69,
+	                 from /usr/i686-w64-mingw32/usr/include/winsock2.h:23,
+	                 from ../../gnulib/import/sys/socket.h:684,
+	                 from ../../gnulib/import/netinet/in.h:43,
+	                 from ../../../../sim/mips/../common/dv-sockser.c:39:
+	/usr/i686-w64-mingw32/usr/include/windef.h:104:9: error: expected identifier or '(' before numeric constant
+	  104 | } SIZE,*PSIZE,*LPSIZE;
+	      |         ^~
+
+2021-09-09  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: ppc: switch to common warning flags
+	Now that the ppc code has been cleaned up enough to use the same set
+	of warning flags as the common code, delete the ppc-specific configure
+	logic so we can leverage what the common code already defined for us.
+
+2021-09-09  Tom de Vries  <tdevries@suse.de>
+
+	sim: ppc: enable -Wpointer-sign warnings
+	When compiling with --enable-werror and CFLAGS="-O0 -g -Wall", we run into:
+	...
+	src/sim/ppc/hw_memory.c: In function 'hw_memory_init_address':
+	src/sim/ppc/hw_memory.c:204:7: error: pointer targets in passing argument 4 \
+	  of 'device_find_integer_array_property' differ in signedness \
+	  [-Werror=pointer-sign]
+	       &new_chunk->size);
+	       ^
+	...
+
+	Fix these by adding an explicit pointer cast.  It's a bit ugly to use APIs
+	based on signed integers to read out unsigned values, but in practice, this
+	is par for the course in the ppc code.
+
+	We already use signed APIs and assign the result to unsigned values a lot:
+	see how device_find_integer_property returns a signed integer (cell), but
+	then assign it to unsigned types.  The array APIs are not used that often
+	which is why we don't see many warnings, and we disable warnings when we
+	assign signed integers to unsigned integers in general.
+
+	The dtc/libfdt project (which is the standard in other projects) processes
+	the fdt blob as a series of bytes without any type information.  Typing is
+	left to the caller.  They have core APIs that read/write bytes, and a few
+	helper functions to cast/convert those bytes to the right value (e.g. u32).
+	In this ppc sim code, the core APIs use signed integers, and the callers
+	convert to unsigned, usually implicitly.
+
+	We could add some core APIs to the ppc sim that deal with raw bytes and then
+	add some helpers to convert to the right type, but that seems like a lot of
+	lifting for what boils down to a cast, and is effectively equivalent to all
+	the implicit assignments we use elsewhere.  Long term, a lot of the ppc code
+	should either get converted to existing sim common code, or we should stand
+	up proper APIs in the common code first, or use standard libraries to do all
+	the processing (e.g. libfdt).  Either way, this device.c code would all get
+	deleted, and callers (like these hw_*.c files) would get converted.  Which
+	is also why we go with a cast rather new (but largely unused) APIs.
+
+2021-09-09  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: ppc: enable -Wmissing-declarations & -Wmissing-prototypes
+	This aligns with common code which already uses this flag.  We have
+	to add another local prototype to fix the failure, and add another
+	local decl for the SIM_DESC type.  Unwinding these will require a
+	lot more work & conversions in the process, so going with the decl
+	for now unblocks the warning unification.
+
+2021-09-09  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: microblaze: replace custom basic types with common ones
+	The basic "byte" type conflicts with Windows headers, and we already
+	have common types that provide the right sizes.  So replace these with
+	the common ones to avoid issues.
+
+	  CC     dv-sockser.o
+	In file included from /usr/i686-w64-mingw32/usr/include/wtypes.h:8,
+	                 from /usr/i686-w64-mingw32/usr/include/winscard.h:10,
+	                 from /usr/i686-w64-mingw32/usr/include/windows.h:97,
+	                 from /usr/i686-w64-mingw32/usr/include/winsock2.h:23,
+	                 from ../../gnulib/import/sys/socket.h:684,
+	                 from ../../gnulib/import/netinet/in.h:43,
+	                 from .../build/sim/../../../sim/microblaze/../common/dv-sockser.c:39:
+	/usr/i686-w64-mingw32/usr/include/rpcndr.h:63:25: error: conflicting types for 'byte'; have 'unsigned char'
+	   63 |   typedef unsigned char byte;
+	      |                         ^~~~
+	In file included from .../buildsim/../../../sim/microblaze/sim-main.h:21,
+	                 from .../buildsim/../../../sim/microblaze/../common/dv-sockser.c:24:
+	.../buildsim/../../../sim/microblaze/microblaze.h:94:25: note: previous declaration of 'byte' with type 'byte' {aka 'char'}
+	   94 | typedef char            byte;
+	      |                         ^~~~
+	make: *** [Makefile:513: dv-sockser.o] Error 1
+
+2021-09-09  Jim Wilson  <jimw@sifive.com>
+
+	RISC-V: Pretty print values formed with lui and addiw.
+	The disassembler has support to pretty print values created by an lui/addi
+	pair, but there is no support for addiw.  There is also no support for
+	c.addi and c.addiw.  This patch extends the pretty printing support to
+	handle these 3 instructions in addition to addi.  Existing testcases serve
+	as tests for the new feature.
+
+		opcodes/
+		* riscv-dis.c (maybe_print_address): New arg wide.  Sign extend when
+		wide is true.
+		(print_insn_args): Fix calls to maybe_print_address.  Add checks for
+		c.addi, c.addiw, and addiw, and call maybe_print_address for them.
+
+		gas/
+		* testsuite/gas/riscv/insn.d: Update for disassembler change.
+		* testsuite/gas/li32.d, testsuite/gas/li64.d: Likwise.
+		* testsuite/gas/lla64.d: Likewise.
+
+2021-09-09  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: ppc: align format string settings with common code
+	This copies logic used in the common sim warning configure code to fix
+	build errors for mingw targets.  Turning format warnings on triggers
+	a failure in the debug.c file, so apply a minor fix at the same time.
+
+	sim: ppc: drop unnecessary config includes
+	This file is compiled for the --host & --build system which leads to
+	including the configure generated config.h in both environments.
+	This obviously doesn't work when the two targets don't look alike at
+	all and can cause build failures here (e.g. a mingw host & a linux
+	build).  Since we don't actually need any config settings in this
+	very simple file, drop the includes entirely.
+
+2021-09-09  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-08  Mike Frysinger  <vapier@gentoo.org>
+
+	gnulib: import various network functions
+	Some sim ports use these to provide networking functionality via the
+	dv-sockser module or via direct emulation for a few ports.
+
+	Gdb seems to build just fine still too.
+
+2021-09-08  Tom Tromey  <tromey@adacore.com>
+
+	Fix unit test build on Windows
+	Like Tom de Vries' earlier patch to fix the no-CXX_STD_THREAD case in
+	maint.c, this patch fixes a similar problem in
+	parallel-for-selftests.c.  This fixes a build failure on Windows.
+
+2021-09-08  Alan Modra  <amodra@gmail.com>
+
+	PowerPC64, sanity check r_offset in relocate_section
+	This hardens the powerpc64 linker code transformations.
+
+		* elf64-ppc.c (is_8byte_reloc, offset_in_range): New functions.
+		(ppc64_elf_relocate_section): Sanity check r_offset before
+		accessing section contents for various code transformations.
+
+2021-09-08  Alan Modra  <amodra@gmail.com>
+
+	PowerPC64: Avoid useless work on R_PPC64_TPREL34
+	_bfd_elf_ppc_at_tprel_transform doesn't handle prefix instructions,
+	and I'm not inclined to implement code editing for them.
+
+		* elf64-ppc.c (ppc64_elf_relocate_section): Don't attempt tprel
+		transform for R_PPC64_TPREL34.
+
+2021-09-08  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: make thread_suspend_state::stop_pc optional
+	Currently the stop_pc field of thread_suspect_state is a CORE_ADDR and
+	when we want to indicate that there is no stop_pc available we set
+	this field back to a special value.
+
+	There are actually two special values used, in post_create_inferior
+	the stop_pc is set to 0.  This is a little unfortunate, there are
+	plenty of embedded targets where 0 is a valid pc value.  The more
+	common special value for stop_pc though, is set in
+	thread_info::set_executing, where the value (~(CORE_ADDR) 0) is used.
+
+	This commit changes things so that the stop_pc is instead a
+	gdb::optional.  We can now explicitly reset the field to an
+	uninitialised state, we also have asserts that we don't read the
+	stop_pc when its in an uninitialised state (both in
+	gdbsupport/gdb_optional.h, when compiling with _GLIBCXX_DEBUG
+	defined, and in thread_info::stop_pc).
+
+	One situation where a thread will not have a stop_pc value is when the
+	thread is stopped as a consequence of GDB being in all stop mode, and
+	some other thread stopped at an interesting event.  When GDB brings
+	all the other threads to a stop those other threads will not have a
+	stop_pc set (thus avoiding an unnecessary read of the pc register).
+
+	Previously, when GDB passed through handle_one (in infrun.c) the
+	threads executing flag was set to false and the stop_pc field was left
+	unchanged, i.e. it would (previous) have been left as ~0.
+
+	Now, handle_one leaves the stop_pc with no value.
+
+	This caused a problem when we later try to set these threads running
+	again, in proceed() we compare the current pc with the cached stop_pc.
+	If the thread was stopped via handle_one then the stop_pc would have
+	been left as ~0, and the compare (in proceed) would (likely) fail.
+	Now however, this compare tries to read the stop_pc when it has no
+	value and this would trigger an assert.
+
+	To resolve this I've added thread_info::stop_pc_p() which returns true
+	if the thread has a cached stop_pc.  We should only ever call
+	thread_info::stop_pc() if we know that there is a cached stop_pc,
+	however, this doesn't mean that every call to thread_info::stop_pc()
+	needs to be guarded with a call to thread_info::stop_pc_p(), in most
+	cases we know that the thread we are looking at stopped due to some
+	interesting event in that thread, and so, we know that the stop_pc is
+	valid.
+
+	After running the testsuite I've seen no other situations where
+	stop_pc is read uninitialised.
+
+	There should be no user visible changes after this commit.
+
+2021-09-08  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/build] Fix build with undefined CXX_STD_THREAD
+	When building gdb on openSUSE Leap 42.3, we trigger the case that
+	CXX_STD_THREAD is undefined, and run into:
+	...
+	gdb/maint.c: In function 'void maintenance_show_worker_threads \
+	  (ui_file*, int, cmd_list_element*, const char*)':
+	gdb/maint.c:877:14: error: 'gdb::thread_pool' has not been declared
+	         gdb::thread_pool::g_thread_pool->thread_count ());
+	              ^
+	Makefile:1647: recipe for target 'maint.o' failed
+	make[1]: *** [maint.o] Error 1
+	...
+
+	Fix this by handling the undefined CXX_STD_THREAD case in
+	maintenance_show_worker_threads, such that we get:
+	...
+	$ gdb -q -batch -ex "maint show worker-thread"
+	The number of worker threads GDB can use is 0.
+	...
+
+	Tested on x86_64-linux.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28312
+
+2021-09-08  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: update configure target list
+	Fix sorting of the list, and update the globs to match the list used
+	in gdb's configure script.
+
+	gdb: cris: enable sim integration
+	The sim side is already ready to go for cris, so wire it up.
+
+	gdb: aarch64: enable sim integration
+	The sim side is already ready to go for aarch64, so wire it up.
+
+	gdb: sim: consolidate configure settings
+	Moving all the sim settings to one section makes it easier to track,
+	and makes it easier to keep it aligned with the sim target tests.
+	The gdb logic was duplicating this when handling different OS targets
+	instead of having a single cpu check.  Now it's more obvious that the
+	sim is tied to a cpu and not related to the OS.
+
+2021-09-08  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-07  Tom Tromey  <tromey@adacore.com>
+
+	Remove unused declaration from gdbserver/win32-low.h
+	I noticed that gdbserver/win32-low.h has an unused declaration.  This
+	code was changed a while ago, but this declaration slipped through.
+	This patch removes it.  Tested by rebuilding.
+
+2021-09-07  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: make use of std::string in utils.c
+	Replace some of the manual string management (malloc/free) with
+	std::string when creating commands in utils.c.
+
+	Things are a little bit messy as, creating the prefix commands (using
+	add_basic_prefix_cmd and add_show_prefix_cmd), doesn't copy the doc
+	string, while creating the actual set/show commands (using
+	add_setshow_enum_cmd) does copy the doc string.
+
+	As a result, I have retained the use of xstrprintf when creating the
+	prefix command doc strings, but switched to using std::string when
+	creating the actual set/show commands.
+
+	There should be no user visible changes after this commit.
+
+2021-09-07  Luis Machado  <luis.machado@linaro.org>
+
+	Revert: [AArch64] MTE corefile support
+	        bfd     * elf.c (elfcore_make_memtag_note_section): New function.
+	                (elfcore_grok_note): Handle NT_MEMTAG note types.
+
+	        binutils* readelf.c (get_note_type): Handle NT_MEMTAG note types.
+
+	        include * elf/common.h (NT_MEMTAG): New constant.
+	                (NT_MEMTAG_TYPE_AARCH_MTE): New constant.
+
+2021-09-07  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: use bool instead of int in struct internal_problem
+	Change struct internal_problem (gdb/utils.c) to use bool instead of
+	int, update the 3 static instances of this structure that we create to
+	use true/false instead of 1/0.
+
+	I've also updated the comments on struct internal_problem as the
+	existing comment doesn't seem to be referring to the structure, it
+	talks about returning something, which doesn't make sense in this
+	context.
+
+	There should be no user visible changes after this commit.
+
+2021-09-07  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: make thread_info::executing private
+	Rename thread_info::executing to thread_info::m_executing, and make it
+	private.  Add a new get/set member functions, and convert GDB to make
+	use of these.
+
+	The only real change of interest in this patch is in thread.c where I
+	have deleted the helper function set_executing_thread, and now just
+	use the new set function thread_info::set_executing.  However, the old
+	helper function set_executing_thread included some code to reset the
+	thread's stop_pc, so I moved this code into the new function
+	thread_info::set_executing.  However, I don't believe there is
+	anywhere that this results in a change of behaviour, previously the
+	executing flag was always set true through a call to
+	set_executing_thread anyway.
+
+2021-09-07  Nick Clifton  <nickc@redhat.com>
+
+	Fix an illegal memory access triggered by an atempt to disassemble a corrupt xtensa binary.
+		PR 28305
+		* elf32-xtensa.c (elf_xtensa_do_reloc): Add check for put of range
+		reloc.
+
+2021-09-07  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb/python: new function to add values into GDB's history
+	The guile API has (history-append! <value>) to add values into GDB's
+	history list.  There is currently no equivalent in the Python API.
+
+	This commit adds gdb.add_history(<value>) to the Python API, this
+	function takes <value> a gdb.Value (or anything that can be passed to
+	the constructor of gdb.Value), and adds the value it represents to
+	GDB's history list.  The index of the newly added value is returned.
+
+2021-09-07  Nick Clifton  <nickc@redhat.com>
+
+	Fix illegal memory access triggered by an attempt to disassemble a corrupt RISC-V binary.
+		PR 28303
+		* elfxx-riscv.c (riscv_elf_add_sub_reloc): Add check for out of
+		range relocs.
+
+2021-09-07  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Handle internal-error in gdb_unload
+	When reverting commit 5a20fadc841 and using gdb_unload instead of runto "bar"
+	to trigger the internal-error in test-case
+	gdb.dwarf2/locexpr-data-member-location.exp, we run into:
+	...
+	ERROR: couldn't unload file in $gdb (timeout).
+	...
+	and the test-case takes about 1 minute.
+
+	Fix this by handling internal-error in gdb_unload, such that we have:
+	...
+	ERROR: Couldn't unload file in $gdb (GDB internal error).
+	ERROR: Could not resync from internal error (eof)
+	...
+	within 2 seconds.
+
+	Tested on x86_64-linux.
+
+2021-09-07  Alan Modra  <amodra@gmail.com>
+
+	PR28307, segfault in ppc64_elf_toc64_reloc
+	Adds missing bfd_reloc_offset_in_range checks to various relocation
+	special_functions.
+
+		PR 28307
+		* elf32-ppc.c (ppc_elf_addr16_ha_reloc): Range check reloc offset.
+		* elf64-ppc.c (ppc64_elf_ha_reloc, ppc64_elf_brtaken_reloc): Likewise.
+		(ppc64_elf_toc64_reloc, ppc64_elf_prefix_reloc): Likewise.
+
+2021-09-07  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-07  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Handle internal-error in gdb_run_cmd
+	When reverting commit 5a20fadc841 the test-case
+	gdb.dwarf2/locexpr-data-member-location.exp fails like this:
+	...
+	FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \
+	  (GDB internal error)
+	ERROR: Could not resync from internal error (eof)
+	...
+	and takes 1 minute to run.
+
+	The long running time is caused by running into a timeout in gdb_run_cmd, at
+	this point:
+	...
+	(gdb) run ^M
+	The program being debugged has been started already.^M
+	Start it from the beginning? (y or n) y^M
+	/home/vries/gdb_versions/devel/src/gdb/gdbtypes.c:5583: internal-error: \
+	  Unexpected type field location kind: 4^M
+	A problem internal to GDB has been detected,^M
+	further debugging may prove unreliable.^M
+	Quit this debugging session? (y or n)
+	...
+
+	Fix this by detecting the internal-error in gdb_run_cmd.  We don't handle it
+	in gdb_run_cmd, but stash the gdb output back into the buffer using
+	-notransfer, and let the caller proc runto deal with it.
+
+	After the fix, the test-case just takes 2 seconds.
+
+	Tested on x86_64-linux.
+
+2021-09-06  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb: rename gdb/testsuite/gdb.arch/riscv64-unwind-prologue-with-ld-lw.c
+	A previous commit added the
+	gdb.arch/riscv64-unwind-prologue-with-ld-lw.exp testcase, but one of its
+	associated file was named after a previous version of the test.
+
+	This commit fixes this and makes sure that all the files linked to this
+	testcase share the same prefix in the name.
+
+	Tested on riscv64 GNU/Linux.
+
+2021-09-06  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Handle eof in gdb_internal_error_resync
+	Before commit 5a20fadc841 the test-case
+	gdb.dwarf2/locexpr-data-member-location.exp fails like this:
+	...
+	FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \
+	  (GDB internal error)
+	ERROR: : spawn id exp9 not open
+	    while executing
+	"expect {
+	-i exp9 -timeout 10
+	            -re "Quit this debugging session\\? \\(y or n\\) $" {
+	                send_gdb "n\n" answer
+	                incr count
+	            }
+	            -re "Create ..."
+	    ("uplevel" body line 1)
+	    invoked from within
+	"uplevel $body" NONE : spawn id exp9 not open
+	ERROR: Could not resync from internal error (timeout)
+	...
+
+	Fix the:
+	...
+	ERROR: : spawn id exp9 not open
+	...
+	by handling eof in gdb_internal_error_resync, such that we have instead:
+	...
+	FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \
+	  (GDB internal error)
+	ERROR: Could not resync from internal error (eof)
+	...
+
+	Tested on x86_64-linux.
+
+2021-09-06  Tom Tromey  <tom@tromey.com>
+
+	Remove some complaints.h includes
+	There are a few includes of complaints.h that aren't necessary.  This
+	patch removes them.  Tested by rebuilding.
+
+2021-09-06  Nick Clifton  <nickc@redhat.com>
+
+	Fix an illegal memory access triggered by disassembling corrupt s390x binaries.
+		PR 28304
+		* elfxx-score7.c (score_elf_gprel15_reloc): If there is no output bfd
+		treat the reloc as undefined.
+
+	Fix potential use on an uninitialised vairable in the MCore assembler.
+
+	Fix potential uninitialised variable in microblaze assembler code.
+
+2021-09-06  Yinjun Zhang  <yinjun.zhang@corigine.com>
+
+	Add a sanity check to the init_nfp6000_mecsr_sec() function in the NFP disassembler.
+
+2021-09-06  Alexandra Hájková  <ahajkova@redhat.com>
+
+	gdbtypes.c: Add the case for FIELD_LOC_KIND_DWARF_BLOCK
+	The case for FIELD_LOC_KIND_DWARF_BLOCK was missing for
+	switch TYPE_FIELD_LOC_KIND. Thas caused an internal-error
+	under some circumstances.
+
+	Fixes bug 28030.
+
+2021-09-06  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-05  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-04  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Check avx support in gdb.arch/amd64-disp-step-avx.exp
+	On a machine on Open Build Service I'm running into a SIGILL for test-case
+	gdb.arch/amd64-disp-step-avx.exp:
+	...
+	Program received signal SIGILL, Illegal instruction.^M
+	test_rip_vex2 () at gdb.arch/amd64-disp-step-avx.S:40^M
+	40              vmovsd ro_var(%rip),%xmm0^M
+	(gdb) FAIL: gdb.arch/amd64-disp-step-avx.exp: vex2: \
+	  continue to test_rip_vex2_end
+	...
+	The SIGILL happens when trying to execute the first avx instruction in the
+	executable.
+
+	I can't directly access the machine, but looking at the log for test-case
+	gdb.arch/i386-avx.exp, it seems that there's no avx support:
+	...
+	Breakpoint 1, main (argc=1, argv=0x7fffffffd6b8) at gdb.arch/i386-avx.c:68^M
+	68        if (have_avx ())^M
+	(gdb) print have_avx ()^M
+	$1 = 0^M
+	...
+
+	Fix this by:
+	- adding a gdb_caching_proc have_avx, similar to have_mpx, using the have_avx
+	  function from gdb.arch/i386-avx.c
+	- using proc have_avx in both gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp
+	  and gdb/testsuite/gdb.arch/i386-avx.exp.
+
+	Tested on my x86_64-linux laptop with avx support, where both test-cases pass.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-09-04  Tom de Vries  <tdevries@suse.de>
+
+		PR testsuite/26950
+		* gdb/testsuite/gdb.arch/i386-avx.c (main): Remove call to have_avx.
+		(have_avx): Move ...
+		* gdb/testsuite/lib/gdb.exp (have_avx): ... here.  New proc.
+		* gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp: Use have_avx.
+		* gdb/testsuite/gdb.arch/i386-avx.exp: Same.
+
+2021-09-04  Mike Frysinger  <vapier@gentoo.org>
+
+	gnulib: import sys_wait
+	A few sims use this to emulate process syscalls.
+	Gdb builds seem to still be fine.
+
+2021-09-04  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-03  Tom Tromey  <tromey@adacore.com>
+
+	Use CORE_ADDR as return type from x86_dr_low_get_addr
+	On a Windows build locally, watchpoints started failing.  I tracked
+	this down to x86_dr_low_get_addr returning an 'unsigned long'... in
+	this particular build, this is a 32-bit type, but the inferior is a
+	64-bit program.
+
+	This patch fixes the problem by changing the return type.  No other
+	change is required, because this matches the function pointer in
+	struct x86_dr_low_type.
+
+2021-09-03  Kevin Buettner  <kevinb@redhat.com>
+
+	Test case reproducing PR28030 bug
+	The original reproducer for PR28030 required use of a specific
+	compiler version - gcc-c++-11.1.1-3.fc34 is mentioned in the PR,
+	though it seems probable that other gcc versions might also be able to
+	reproduce the bug as well.  This commit introduces a test case which,
+	using the DWARF assembler, provides a reproducer which is independent
+	of the compiler version.  (Well, it'll work with whatever compilers
+	the DWARF assembler works with.)
+
+	To the best of my knowledge, it's also the first test case which uses
+	the DWARF assembler to provide debug info for a shared object.  That
+	being the case, I provided more than the usual commentary which should
+	allow this case to be used as a template when a combo shared
+	library / DWARF assembler test case is required in the future.
+
+	I provide some details regarding the bug in a comment near the
+	beginning of locexpr-dml.exp.
+
+	This problem was difficult to reproduce; I found myself constantly
+	referring to the backtrace while trying to figure out what (else) I
+	might be missing while trying to create a reproducer.  Below is a
+	partial backtrace which I include for posterity.
+
+	 #0  internal_error (
+	    file=0xc50110 "/ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/gdbtypes.c", line=5575,
+	    fmt=0xc520c0 "Unexpected type field location kind: %d")
+	    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdbsupport/errors.cc:51
+	 #1  0x00000000006ef0c5 in copy_type_recursive (objfile=0x1635930,
+	    type=0x274c260, copied_types=0x30bb290)
+	    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/gdbtypes.c:5575
+	 #2  0x00000000006ef382 in copy_type_recursive (objfile=0x1635930,
+	    type=0x274ca10, copied_types=0x30bb290)
+	    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/gdbtypes.c:5602
+	 #3  0x0000000000a7409a in preserve_one_value (value=0x24269f0,
+	    objfile=0x1635930, copied_types=0x30bb290)
+	    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/value.c:2529
+	 #4  0x000000000072012a in gdbscm_preserve_values (
+	    extlang=0xc55720 <extension_language_guile>, objfile=0x1635930,
+	    copied_types=0x30bb290)
+	    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/guile/scm-value.c:94
+	 #5  0x00000000006a3f82 in preserve_ext_lang_values (objfile=0x1635930,
+	    copied_types=0x30bb290)
+	    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/extension.c:568
+	 #6  0x0000000000a7428d in preserve_values (objfile=0x1635930)
+	    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/value.c:2579
+	 #7  0x000000000082d514 in objfile::~objfile (this=0x1635930,
+	    __in_chrg=<optimized out>)
+	    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/objfiles.c:549
+	 #8  0x0000000000831cc8 in std::_Sp_counted_ptr<objfile*, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x1654580)
+	    at /usr/include/c++/11/bits/shared_ptr_base.h:348
+	 #9  0x00000000004e6617 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x1654580) at /usr/include/c++/11/bits/shared_ptr_base.h:168
+	 #10 0x00000000004e1d2f in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x190bb88, __in_chrg=<optimized out>)
+	    at /usr/include/c++/11/bits/shared_ptr_base.h:705
+	 #11 0x000000000082feee in std::__shared_ptr<objfile, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x190bb80, __in_chrg=<optimized out>)
+	    at /usr/include/c++/11/bits/shared_ptr_base.h:1154
+	 #12 0x000000000082ff0a in std::shared_ptr<objfile>::~shared_ptr (
+	    this=0x190bb80, __in_chrg=<optimized out>)
+	    at /usr/include/c++/11/bits/shared_ptr.h:122
+	 #13 0x000000000085ed7e in __gnu_cxx::new_allocator<std::_List_node<std::shared_ptr<objfile> > >::destroy<std::shared_ptr<objfile> > (this=0x114bc00,
+	    __p=0x190bb80) at /usr/include/c++/11/ext/new_allocator.h:168
+	 #14 0x000000000085e88d in std::allocator_traits<std::allocator<std::_List_node<std::shared_ptr<objfile> > > >::destroy<std::shared_ptr<objfile> > (__a=...,
+	    __p=0x190bb80) at /usr/include/c++/11/bits/alloc_traits.h:531
+	 #15 0x000000000085e50c in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::_M_erase (this=0x114bc00, __position=
+	  std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x1635930})
+	    at /usr/include/c++/11/bits/stl_list.h:1925
+	 #16 0x000000000085df0e in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::erase (this=0x114bc00, __position=
+	  std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x1635930})
+	    at /usr/include/c++/11/bits/list.tcc:158
+	 #17 0x000000000085c748 in program_space::remove_objfile (this=0x114bbc0,
+	    objfile=0x1635930)
+	    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/progspace.c:210
+	 #18 0x000000000082d3ae in objfile::unlink (this=0x1635930)
+	    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/objfiles.c:487
+	 #19 0x000000000082e68c in objfile_purge_solibs ()
+	    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/objfiles.c:875
+	 #20 0x000000000092dd37 in no_shared_libraries (ignored=0x0, from_tty=1)
+	    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/solib.c:1236
+	 #21 0x00000000009a37fe in target_pre_inferior (from_tty=1)
+	    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/target.c:2496
+	 #22 0x00000000007454d6 in run_command_1 (args=0x0, from_tty=1,
+	    run_how=RUN_NORMAL)
+	    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/infcmd.c:437
+
+	I'll note a few points regarding this backtrace:
+
+	Frame #1 is where the internal error occurs.  It's caused by an
+	unhandled case for FIELD_LOC_KIND_DWARF_BLOCK.  The fix for this bug
+	adds support for this case.
+
+	Frame #22 - it's a partial backtrace - shows that GDB is attempting to
+	(re)run the program.  You can see the exact command sequence that was
+	used for reproducing this problem in the PR (at
+	https://sourceware.org/bugzilla/show_bug.cgi?id=28030), but in a
+	nutshell, after starting the program and advancing to the appropriate
+	source line, GDB was asked to step into libstdc++; a "finish" command
+	was issued, returning a value.  The fact that a value was returned is
+	very important.  GDB was then used to step back into libstdc++.  A
+	breakpoint was set on a source line in the library after which a "run"
+	command was issued.
+
+	Frame #19 shows a call to objfile_purge_solibs.  It's aptly named.
+
+	Frame #7 is a call to the destructor for one of the objfile solibs; it
+	turned out to be the one for libstdc++.
+
+	Frames #6 thru #3 show various value preservation frames.  If you look
+	at preserve_values() in gdb/value.c, the value history is preserved
+	first, followed by internal variables, followed by values for the
+	extension languages (python and guile).
+
+2021-09-03  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Add untested case in gdb.gdb/complaints.exp
+	When building gdb with "-Wall -O2 -g -flto=auto", I run into:
+	...
+	(gdb) call clear_complaints()^M
+	No symbol "clear_complaints" in current context.^M
+	(gdb) FAIL: gdb.gdb/complaints.exp: clear complaints
+	...
+
+	The problem is that lto has optimized away clear_complaints, and consequently
+	the selftests cannot run.
+
+	Fix this by:
+	- using info function to detect presence of clear_complaints
+	- handling the absence of clear_complaints by calling untested
+	...
+	(gdb) UNTESTED: gdb.gdb/complaints.exp: \
+	  Cannot find clear_complaints, skipping test
+	...
+
+	Tested on x86_64-linux.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-09-03  Tom de Vries  <tdevries@suse.de>
+
+		* gdb.gdb/complaints.exp: Use untested if clear_complaints cannot
+		be found.
+
+2021-09-03  Felix Willgerodt  <felix.willgerodt@intel.com>
+
+	gdb: Enable finish command and inferior calls for _Float16 on amd64 and i386.
+	Values of type _Float16 and _Float16 _Complex can now be used on CPUs with
+	AVX512-FP16 support. Return values of those types are located in XMM0.
+	Compiler support for gcc and clang is in progress, see e.g.:
+	https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574117.html
+
+	gdb/ChangeLog:
+	2021-07-21  Felix Willgerodt  <Felix.Willgerodt@intel.com>
+
+		* amd64-tdep.c (amd64_classify): Classify _Float16 and
+		_Float16 _Complex as AMD64_SSE.
+		* i386-tdep.c (i386_extract_return_value): Read _Float16 and
+		_Float16 _Complex from xmm0.
+
+	gdb/testsuite/ChangeLog:
+	2021-07-21  Felix Willgerodt  <Felix.Willgerodt@intel.com>
+
+		* gdb.arch/x86-avx512fp16-abi.c: New file.
+		* gdb.arch/x86-avx512fp16-abi.exp: New file.
+
+2021-09-03  Felix Willgerodt  <felix.willgerodt@intel.com>
+
+	Add half support for AVX512 register view.
+	This adds support for the half datatype, FP16, to the AVX512 register printing.
+
+	gdb/ChangeLog:
+	2020-07-21  Felix Willgerodt  <Felix.Willgerodt@intel.com>
+
+		* i386-tdep.c (i386_zmm_type) <v32_half>: New field.
+		(i386_ymm_type) <v16_half>: New field.
+		(i386_gdbarch_init): Add set_gdbarch_half_format.
+		* features/i386/64bit-avx512.xml: Add half type.
+		* features/i386/64bit-avx512.c: Regenerated.
+		* features/i386/64bit-sse.xml: Add half type.
+		* features/i386/64bit-sse.c: Regenerated.
+
+	gdb/testsuite/ChangeLog:
+	2021-07-21  Felix Willgerodt  <Felix.Willgerodt@intel.com>
+
+		* gdb.arch/x86-avx512fp16.c: New file.
+		* gdb.arch/x86-avx512fp16.exp: New file.
+		* lib/gdb.exp (skip_avx512fp16_tests): New function.
+
+2021-09-03  Felix Willgerodt  <felix.willgerodt@intel.com>
+
+	gdb, i386: Enable AVX512-bfloat16 for i386 targets.
+	Values of type bfloat16 can also be used on 32-bit targets, which was missed
+	in the original enablement.  This also adjusts the testcase to pass with
+	"unix/-m32", where only the lower 8 AVX registers are available.
+
+	gdb/ChangeLog:
+	2021-07-21  Felix Willgerodt  <Felix.Willgerodt@intel.com>
+
+		* features/i386/32bit-sse.xml: Add bfloat16 type.
+		* features/i386/32bit-sse.c: Regenerated.
+
+	gdb/testsuite/ChangeLog:
+	2021-07-21  Felix Willgerodt  <Felix.Willgerodt@intel.com>
+
+		* gdb.arch/x86-avx512bf16.exp: Only use x/z/ymm 0-7.
+
+2021-09-03  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Add untested case in selftest_setup
+	When building gdb with "-Wall -O2 -g -flto=auto", I run into:
+	...
+	FAIL: gdb.gdb/python-helper.exp: breakpoint in captured_main \
+	  (got interactive prompt)
+	FAIL: gdb.gdb/python-helper.exp: run until breakpoint at captured_main
+	WARNING: Couldn't test self
+	...
+	and similar in gdb.gdb/selftest.exp.
+
+	The first FAIL in more detail:
+	...
+	(gdb) break captured_main^M
+	Function "captured_main" not defined.^M
+	Make breakpoint pending on future shared library load? (y or [n]) n^M
+	(gdb) FAIL: gdb.gdb/python-helper.exp: breakpoint in captured_main \
+	  (got interactive prompt)
+	...
+
+	The problem is that lto has optimized away the captured_main function
+	and consequently the selftests dependent on that cannot run.
+
+	Fix this by:
+	- using gdb_breakpoint to detect failure to set the breakpoint
+	- handling the failure to set a breakpoint by calling untested
+	- not emitting the warning if we've already got untested
+	such that we have:
+	...
+	(gdb) UNTESTED: gdb.gdb/python-helper.exp: Cannot set breakpoint at \
+	  captured_main, skipping testcase.
+	...
+
+	gdb/testsuite/ChangeLog:
+
+	2021-09-02  Tom de Vries  <tdevries@suse.de>
+
+		* lib/selftest-support.exp: Emit untested when not being able to set
+		breakpoint.
+
+2021-09-03  Alan Modra  <amodra@gmail.com>
+
+	ld testsuite tidy
+	Fixes a few issues:
+	1) If you use "-fsanitize=address,undefined" in CFLAGS, the Makefile
+	attempt to trim off -fsanitize options left us with ",undefined".
+	2) ld_compile adds CFLAGS_FOR_TARGET itself, no need to pass it.
+	3) CFLAGS might be needed linking bootstrap test.
+
+		* Makefile.am (CFLAGS_FOR_TARGET, CXXFLAGS_FOR_TARGET): Trim off
+		all -fsanitize=*.
+		* Makefile.in: Regenerate.
+		* testsuite/ld-bootstrap/bootstrap.exp: Use CFLAGS when linking.
+		* testsuite/ld-cdtest/cdtest.exp: Use CFLAGS_FOR_TARGET when
+		linking.
+		* testsuite/ld-auto-import/auto-import.exp: Don't pass
+		CFLAGS_FOR_TARGET to ld_compile.
+		* testsuite/ld-cygwin/exe-export.exp: Likewise.
+		* testsuite/ld-elfvers/vers.exp: Likewise.
+		* testsuite/ld-elfvsb/elfvsb.exp: Likewise.
+		* testsuite/ld-elfweak/elfweak.exp: Likewise.
+		* testsuite/ld-gc/gc.exp: Likewise.
+		* testsuite/ld-pe/pe-compile.exp: Likewise.
+		* testsuite/ld-pe/pe-run.exp: Likewise.
+		* testsuite/ld-pe/pe-run2.exp: Likewise.
+		* testsuite/ld-plugin/plugin.exp: Likewise.
+		* testsuite/ld-shared/shared.exp: Likewise.
+		* testsuite/ld-elfcomm/elfcomm.exp: Likewise, and don't allow
+		nios2 testing to trash CFLAGS_FOR_TARGET.
+		* testsuite/ld-scripts/crossref.exp: Don't pass options in
+		CC_FOR_TARGET, do so in CFLAGS_FOR_TARGET instead.
+		* testsuite/ld-srec/srec.exp: Likewise, and for CXX.
+
+2021-09-03  Alan Modra  <amodra@gmail.com>
+
+	CC_FOR_TARGET et al
+	The top level Makefile, the ld Makefile and others, define
+	CC_FOR_TARGET to be a compiler for the binutils target machine.  This
+	is the compiler that should be used for almost all tests with C
+	source.  There are _FOR_TARGET versions of CFLAGS, CXX, and CXXFLAGS
+	too.  This was all supposed to work with the testsuite .exp files
+	using CC for the target compiler, and CC_FOR_HOST for the host
+	compiler, with the makefiles passing CC=$CC_FOR_TARGET and
+	CC_FOR_HOST=$CC to the runtest invocation.
+
+	One exception to the rule of using CC_FOR_TARGET is the native-only ld
+	bootstrap test, which uses the newly built ld to link a copy of
+	itself.  Since the files being linked were created with the host
+	compiler, the boostrap test should use CC and CFLAGS, in case some
+	host compiler option provides needed libraries automatically.
+	However, bootstrap.exp used CC where it should have used CC_FOR_HOST.
+	I set about fixing that problem, then decided that playing games in
+	the makefiles with CC was a bad idea.  Not only is it confusing, but
+	other dejagnu code knows about CC_FOR_TARGET.  See dejagnu/target.exp.
+
+	So this patch gets rid of the makefile variable renaming and changes
+	all the .exp files to use the correct _FOR_TARGET variables.
+	CC_FOR_HOST and CFLAGS_FOR_HOST disappear.  A followup patch will
+	correct bootstrap.exp to use CFLAGS, and a number of other things I
+	noticed.
+
+	binutils/
+		* testsuite/lib/binutils-common.exp (run_dump_test): Use
+		CC_FOR_TARGET and CFLAGS_FOR_TARGET rather than CC and CFLAGS.
+	ld/
+		* Makefile.am (check-DEJAGNU): Don't set CC to CC_FOR_TARGET
+		and similar.  Pass variables with unchanged names.  Don't set
+		CC_FOR_HOST or CFLAGS_FOR_HOST.
+		* Makefile.in: Regenerate.
+		* testsuite/config/default.exp: Update default CC and similar.
+		(compiler_supports, plug_opt): Use CC_FOR_TARGET.
+		* testsuite/ld-cdtest/cdtest.exp: Replace all uses of CC with
+		CC_FOR_TARGET, and similarly for CFLAGS, CXX and CXXFLAGS.
+		* testsuite/ld-auto-import/auto-import.exp: Likewise.
+		* testsuite/ld-cygwin/exe-export.exp: Likewise.
+		* testsuite/ld-elf/dwarf.exp: Likewise.
+		* testsuite/ld-elf/indirect.exp: Likewise.
+		* testsuite/ld-elf/shared.exp: Likewise.
+		* testsuite/ld-elfcomm/elfcomm.exp: Likewise.
+		* testsuite/ld-elfvers/vers.exp: Likewise.
+		* testsuite/ld-elfvsb/elfvsb.exp: Likewise.
+		* testsuite/ld-elfweak/elfweak.exp: Likewise.
+		* testsuite/ld-gc/gc.exp: Likewise.
+		* testsuite/ld-ifunc/ifunc.exp: Likewise.
+		* testsuite/ld-mn10300/mn10300.exp: Likewise.
+		* testsuite/ld-pe/pe-compile.exp: Likewise.
+		* testsuite/ld-pe/pe-run.exp: Likewise.
+		* testsuite/ld-pe/pe-run2.exp: Likewise.
+		* testsuite/ld-pie/pie.exp: Likewise.
+		* testsuite/ld-plugin/lto.exp: Likewise.
+		* testsuite/ld-plugin/plugin.exp: Likewise.
+		* testsuite/ld-scripts/crossref.exp: Likewise.
+		* testsuite/ld-selective/selective.exp: Likewise.
+		* testsuite/ld-sh/sh.exp: Likewise.
+		* testsuite/ld-shared/shared.exp: Likewise.
+		* testsuite/ld-srec/srec.exp: Likewise.
+		* testsuite/ld-undefined/undefined.exp: Likewise.
+		* testsuite/ld-unique/unique.exp: Likewise.
+		* testsuite/ld-x86-64/tls.exp: Likewise.
+		* testsuite/lib/ld-lib.exp: Likewise.
+	libctf/
+		* Makefile.am (check-DEJAGNU): Don't set CC to CC_FOR_TARGET.
+		Pass CC and CC_FOR_TARGET.  Don't set CC_FOR_HOST.
+		* Makefile.in: Regenerate.
+		* testsuite/config/default.exp: Update default CC and similar.
+		* testsuite/lib/ctf-lib.exp (run_native_host_cmd): Use CC rather
+		than CC_FOR_HOST.
+		(run_lookup_test): Use CC_FOR_TARGET and CFLAGS_FOR_TARGET.
+
+2021-09-03  Alan Modra  <amodra@gmail.com>
+
+	pj: asan: out of bounds, ubsan: left shift of negative
+		* pj-dis.c: Include libiberty.h.
+		(print_insn_pj): Don't index op->arg past array bound.  Don't
+		left shift negative int.
+
+	ubsan: alpha: member access within null pointer
+		* elf64-alpha.c (elf64_alpha_relax_with_lituse): Avoid UB.
+
+	ubsan: libctf: applying zero offset to null pointer
+		* ctf-open.c (init_symtab): Avoid ubsan error.
+
+2021-09-03  Alan Modra  <amodra@gmail.com>
+
+	haiku tidy
+	--enable-maintainer-mode showed a number of files needing to be
+	regenerated, and in the case of ld/Makefile.in that the file was
+	regenerated by hand.  Nothing to see here really.
+
+	ld/
+		* Makefile.am (ALL_64_EMULATION_SOURCES): Sort haiku entry.
+		* Makefile.in: Regenerate.
+		* po/BLD-POTFILES.in: Regenerate.
+	libctf/
+		* configure: Regenerate.
+	zlib/
+		* configure: Regenerate.
+
+2021-09-03  Fangrui Song  <maskray@google.com>
+
+	gold: --export-dynamic-symbol: don't imply -u
+	to match GNU ld.
+
+	gold/
+		* archive.cc (Library_base::should_include_member): Don't handle
+		--export-dynamic-symbol.
+		* symtab.cc (Symbol_table::do_add_undefined_symbols_from_command_line):
+		Likewise.
+
+2021-09-03  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-02  Alexander von Gluck IV  <kallisti5@unixzen.com>
+
+	Add support for the haiku operating system.  These are the os support patches we have been grooming and maintaining for quite a few years over on git.haiku-os.org.  All of these architectures are working and most have been stable for quite some time.
+
+2021-09-02  Nick Clifton  <nickc@redhat.com>
+
+	Fix the V850 assembler's generation of relocations for the st.b instruction.
+		PR 28292
+	gas	* config/tc-v850.c (handle_lo16): Also accept
+		BFD_RELOC_V850_LO16_SPLIT_OFFSET.
+		* testsuite/gas/v850/split-lo16.s: Add extra line.
+		* testsuite/gas/v850/split-lo16.d: Update expected disassembly.
+
+	opcodes	* v850-opc.c (D16): Use BFD_RELOC_V850_LO16_SPLIT_OFFSET in place
+		of BFD_RELOC_16.
+
+2021-09-02  Alan Modra  <amodra@gmail.com>
+
+	SHT_SYMTAB_SHNDX handling
+	.symtab_shndx section contents is an array, one entry for each symbol
+	in .symtab, present when the number of symbols exceeds a little less
+	than 64k.  Since the mapping is 1-1 with symbols there is no need to
+	keep both dest_index and destshndx_index in elf_sym_strtab.  Instead,
+	just make sure that the shndx pointers to the swap functions are kept
+	NULL when .symtab_shndx does not exist.  Also, strtabcount in the
+	linker's elf hash table is incremented in lock-step with the output
+	symcount, so that can disappear too.
+
+2021-09-02  Alan Modra  <amodra@gmail.com>
+
+	PTR_ADD and NPTR_ADD for bfd.h
+	This defines a couple of macros used to avoid ubsan complaints about
+	calculations involving NULL pointers.  PTR_ADD should be used in the
+	case where it is known that the offset is always zero with a NULL
+	pointer, and you'd like to know if a non-zero offset is ever used.
+	NPTR_ADD should be rarely used, but is defined for cases where a
+	non-zero offset is expected and should be ignored if the pointer is
+	NULL.
+
+	bfd/
+		* bfd-in.h (PTR_ADD, NPTR_ADD): Define.
+		* bfd-in2.h: Regenerate.
+		* elf-eh-frame.c (adjust_eh_frame_local_symbols): Avoid NULL
+		pointer calculations.
+		* elflink.c (_bfd_elf_strip_zero_sized_dynamic_sections): Likewise.
+		(bfd_elf_add_dt_needed_tag, elf_finalize_dynstr): Likewise.
+		(elf_link_add_object_symbols, elf_link_input_bfd): Likewise.
+		(bfd_elf_final_link, bfd_elf_gc_record_vtinherit): Likewise.
+	binutils/
+		* objdump.c (disassemble_section): Use PTR_ADD for rel_ppend.
+
+2021-09-02  Alan Modra  <amodra@gmail.com>
+
+	obstack.h __PTR_ALIGN vs. ubsan
+	Current ubsan complains on every use of __PTR_ALIGN (when ptrdiff_t is
+	as large as a pointer), due to making calculations relative to a NULL
+	pointer.  This patch avoids the problem by extracting out and
+	simplifying __BPTR_ALIGN for the usual case.  I've continued to use
+	ptrdiff_t here, where it might be better to throw away __BPTR_ALIGN
+	entirely and just assume uintptr_t exists.
+
+		* obstack.h (__PTR_ALIGN): Expand and simplify __BPTR_ALIGN
+		rather than calculating relative to a NULL pointer.
+
+2021-09-02  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-09-01  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix dwo path in fission-*.S
+	[ Using $build for /home/vries/gdb_versions/devel/build to make things a bit
+	more readable. ]
+
+	When using make check// to run test-case gdb.dwarf2/fission-base.exp:
+	...
+	( cd $build/gdb; make check//unix RUNTESTFLAGS="fission-base.exp" )
+	...
+	we run into:
+	...
+	(gdb) file \
+	  $build/gdb/testsuite.unix/outputs/gdb.dwarf2/fission-base/fission-base^M
+	Reading symbols from \
+	  $build/gdb/testsuite.unix/outputs/gdb.dwarf2/fission-base/fission-base...^M
+	warning: Could not find DWO CU \
+	  $build/gdb/testsuite.1/outputs/gdb.dwarf2/fission-base/fission-base.dwo \
+	  (0x807060504030201) referenced by CU at offset 0xc7 [in module \
+	  $build/gdb/testsuite.unix/outputs/gdb.dwarf2/fission-base/fission-base]^M
+	...
+
+	The problem is that the executable refers to the dwo file using path name
+	$build/gdb/testsuite.1/outputs/gdb.dwarf2/fission-base/fission-base.dwo,
+	while the actual dwo file is at
+	$build/gdb/testsuite.unix/outputs/gdb.dwarf2/fission-base/fission-base.dwo.
+
+	This is caused by this trick in fission-base.S:
+	...
+	 #define XSTR(s) STR(s)
+	 #define STR(s) #s
+	   ...
+	   .asciz XSTR(DWO)        # DW_AT_GNU_dwo_name
+	...
+	and:
+	...
+	$ echo | gcc -E -dD - | grep "define unix"
+	...
+
+	I used this trick to avoid doing additional_flags=-DDWO=\"$dwo\", since I was
+	concerned that there could be quoting issues.
+
+	However, I've found other uses of this pattern, f.i. in
+	gdb/testsuite/gdb.base/corefile-buildid.exp:
+	...
+	  additional_flags=-DSHLIB_NAME=\"$dlopen_lib\"]
+	...
+
+	So, fix this by:
+	- using additional_flags=-DDWO=\"$dwo\" and
+	- using plain DWO instead of XSTR(DWO)
+
+	Likewise in other gdb.dwarf2/fission*.exp test-cases.
+
+	Tested on x86_64-linux, using make check//unix.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-09-01  Tom de Vries  <tdevries@suse.de>
+
+		PR testsuite/28298
+		* gdb.dwarf2/fission-base.S: Use DWO instead of XSTR(DWO).
+		* gdb.dwarf2/fission-loclists-pie.S: Same.
+		* gdb.dwarf2/fission-loclists.S: Same.
+		* gdb.dwarf2/fission-reread.S: Same.
+		* gdb.dwarf2/fission-base.exp: Use additional_flags=-DDWO=\"$dwo\".
+		* gdb.dwarf2/fission-loclists-pie.exp: Same.
+		* gdb.dwarf2/fission-loclists.exp: Same.
+		* gdb.dwarf2/fission-reread.exp: Same.
+
+2021-09-01  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.fortran/call-no-debug.exp symbol search
+	On openSUSE Tumbleweed I ran into:
+	...
+	(gdb) ptype outstring_func.part^M
+	No symbol "outstring_func" in current context.^M
+	(gdb) FAIL: gdb.fortran/call-no-debug.exp: ptype outstring_func.part
+	...
+	while on openSUSE Leap 15.2 I have instead:
+	...
+	(gdb) ptype string_func_^M
+	type = <unknown return type> ()^M
+	(gdb) PASS: gdb.fortran/call-no-debug.exp: ptype string_func_
+	...
+
+	The difference is caused by the result for "info function string_func", which
+	is this for the latter:
+	...
+	(gdb) info function string_func^M
+	All functions matching regular expression "string_func":^M
+	^M
+	Non-debugging symbols:^M
+	0x000000000040089c  string_func_^M
+	...
+	but this for the former:
+	...
+	(gdb) info function string_func^M
+	All functions matching regular expression "string_func":^M
+	^M
+	Non-debugging symbols:^M
+	0x00000000004012bb  string_func_^M
+	0x00007ffff7bac5b0  outstring_func.part^M
+	0x00007ffff7bb1a00  outstring_func.part^M
+	...
+
+	The extra symbols are part of glibc:
+	...
+	$ nm /lib64/libc.so.6 | grep string_func
+	00000000000695b0 t outstring_func.part.0
+	000000000006ea00 t outstring_func.part.0
+	...
+
+	If glibc debug info is installed, we get instead:
+	...
+	(gdb) info function string_func^M
+	All functions matching regular expression "string_func":^M
+	^M
+	File /usr/src/debug/glibc-2.33-9.1.x86_64/stdio-common/vfprintf-internal.c:^M
+	236:    static int outstring_func(int, size_t, const unsigned int *, FILE *);^M
+	^M
+	File vfprintf-internal.c:^M
+	236:    static int outstring_func(int, size_t, const unsigned char *, FILE *);^M
+	^M
+	Non-debugging symbols:^M
+	0x00000000004012bb  string_func_^M
+	...
+	and the FAIL doesn't trigger.
+
+	Fix this by calling "info function string_func" before starting the exec, such
+	that only symbols of the exec are taken into account.
+
+	Tested on x86_64-linux.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-09-01  Tom de Vries  <tdevries@suse.de>
+
+		* gdb.fortran/call-no-debug.exp: Avoid shared lib symbols for
+		find_mangled_name calls.
+
+2021-09-01  Yinjun Zhang  <yinjun.zhang@corigine.com>
+
+	nfp: add validity check of island and me
+	AddressSanitizer detects heap-buffer-overflow when running
+	"objdump -D" for nfp .nffw files.
+
+		PR 27854
+		* nfp-dis.c (_NFP_ISLAND_MAX, _NFP_ME_MAX): Define.
+		(nfp_priv_data): ..and use here.
+		(_print_instrs): Sanity check island and menum.
+
+2021-09-01  Alan Modra  <amodra@gmail.com>
+
+	PR28250, Null pointer dereference in debug_class_type_samep
+	Typo fix, obviously should be m1->variants != NULL, not
+	m1->variants == NULL.
+
+		PR 28250
+		* debug.c (debug_class_type_samep): Correct m1->variants test.
+
+2021-09-01  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-31  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove breakpoint_find_if
+	Remove breakpoint_find_if, replace its sole usage with using
+	all_breakpoints directly instead.  At the same time, change return
+	types to use bool.
+
+	Change-Id: I9ec392236b4804b362d16ab563330b9c07311106
+
+2021-08-31  Nick Clifton  <nickc@redhat.com>
+
+	Update the how-to-make-a-release document so that a check for empty manual pages is included.  cf PR 28144
+
+2021-08-31  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: Extend .insn directive to support hardcode encoding.
+	The .insn directive can let users use their own instructions, or
+	some new instruction, which haven't supported in the old binutils.
+	For example, if users want to use sifive cache instruction, they
+	cannot just write "cflush.d1.l1" in the assembly code, they should
+	use ".insn i SYSTEM, 0, x0, x10, -0x40".  But the .insn directive
+	may not easy to use for some cases, and not so friendly to users.
+	Therefore, I believe most of the users will use ".word 0xfc050073",
+	to encode the instructions directly, rather than use .insn.  But
+	once we have supported the mapping symbols, the .word directives
+	are marked as data, so disassembler won't dump them as instructions
+	as usual.  I have discussed this with Kito many times, we all think
+	extend the .insn direcitve to support the hardcode encoding, is the
+	easiest way to resolve the problem.  Therefore, there are two more
+	.insn formats are proposed as follows,
+
+	(original) .insn <type>, <operand1>, <operand2>, ...
+	           .insn <insn-length>, <value>
+	           .insn <value>
+
+	The <type> is string, and the <insn-length> and <value> are constants.
+
+	gas/
+		* config/tc-riscv.c (riscv_ip_hardcode): Similar to riscv_ip,
+		but assembles an instruction according to the hardcode values
+		of .insn directive.
+		* doc/c-riscv.texi: Document two new .insn formats.
+		* testsuite/gas/riscv/insn-fail.d: New testcases.
+		* testsuite/gas/riscv/insn-fail.l: Likewise.
+		* testsuite/gas/riscv/insn-fail.s: Likewise.
+		* testsuite/gas/riscv/insn.d: Updated.
+		* testsuite/gas/riscv/insn.s: Likewise.
+
+2021-08-31  John Baldwin  <jhb@FreeBSD.org>
+
+	Use gdbfmt for vprintf_filtered.
+	gdbfmt was already used for printf_filtered, so using it for
+	vprintf_filtered is more consistent.
+
+	As a result, all callers of vfprintf_maybe_filtered now use gdbfmt, so
+	the function can be simplified to assume the gdbfmt case and remove
+	the associated bool argument.  Similary, vprintf_filtered is now a
+	simple wrapper around vfprintf_filtered.
+
+2021-08-31  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-30  John Baldwin  <jhb@FreeBSD.org>
+
+	fbsd-nat: Don't use '%jd' and '%ju' with printf_filtered.
+	The handler for 'info proc status' for native processes on FreeBSD
+	uses the 'j' size modifier along with uintmax_t / intmax_t casts to
+	output integer values for types such as off_t that are not aliases of
+	a basic C type such as 'int' or 'long'.  printf_filtered does not
+	support the 'j' modifer, so this resulted in runtime errors in
+	practice:
+
+	(gdb) info proc stat
+	process 8674
+	Name: ls
+	State: T (stopped)
+	Parent process: 8673
+	Process group: 8674
+	Session id: 2779
+	Unrecognized format specifier 'j' in printf
+
+	Instead, use plongest and pulongest to generate the output strings of
+	these integer values.
+
+2021-08-30  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: fix build error in unittests/parallel-for-selftests.c
+	We get this error when building GDB on some platforms.  I get it using
+	g++-10 on Ubuntu 20.04 (installed using the distro package).  It was
+	also reported by John Baldwin, using a clang that uses libc++.
+
+	      CXX    unittests/parallel-for-selftests.o
+	    cc1plus: warning: command line option '-Wmissing-prototypes' is valid for C/ObjC but not for C++
+	    /home/smarchi/src/binutils-gdb/gdb/unittests/parallel-for-selftests.c: In function 'void selftests::parallel_for::test(int)':
+	    /home/smarchi/src/binutils-gdb/gdb/unittests/parallel-for-selftests.c:53:30: error: use of deleted function 'std::atomic<int>::atomic(const std::atomic<int>&)'
+	       53 |   std::atomic<int> counter = 0;
+	          |                              ^
+	    In file included from /usr/include/c++/9/future:42,
+	                     from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/thread-pool.h:29,
+	                     from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/parallel-for.h:26,
+	                     from /home/smarchi/src/binutils-gdb/gdb/unittests/parallel-for-selftests.c:22:
+	    /usr/include/c++/9/atomic:755:7: note: declared here
+	      755 |       atomic(const atomic&) = delete;
+	          |       ^~~~~~
+	    /usr/include/c++/9/atomic:759:17: note:   after user-defined conversion: 'constexpr std::atomic<int>::atomic(std::atomic<int>::__integral_type)'
+	      759 |       constexpr atomic(__integral_type __i) noexcept : __base_type(__i) { }
+	          |                 ^~~~~~
+
+	I haven't dug to know why it does not happen everywhere, but this patch
+	fixes it by using the constructor to initialize the variable, rather
+	than the assignment operator.
+
+	Change-Id: I6b27958171bf6187f6a875657395fd10441db7e6
+
+2021-08-30  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: PR28291, Fix the gdb fails that PR27916 caused.
+	* According to PR28291, we get the following unexpected gdb behavior,
+
+	(gdb) disassemble 0x0,+4
+	Dump of assembler code from 0x0 to 0x4:
+	   0x0000000000000000:
+	   0x0000000000000001:
+	   0x0000000000000002:
+	   0x0000000000000003:
+	End of assembler dump.
+
+	* This patch should fix it to the right behavior,
+
+	(gdb) disassemble 0x0,+4
+	Dump of assembler code from 0x0 to 0x4:
+	   0x0000000000000000:  Cannot access memory at address 0x0
+
+	opcodes/
+	    pr 28291
+	    * riscv-dis.c (print_insn_riscv): Return STATUS if it is not zero.
+
+2021-08-30  Tom Tromey  <tom@tromey.com>
+
+	Add some parallel_for_each tests
+	Tom de Vries noticed that a patch in the DWARF scanner rewrite series
+	caused a regression in parallel_for_each -- it started crashing in the
+	case where the number of threads is 0 (there was an unchecked use of
+	"n-1" that was used to size an array).
+
+	He also pointed out that there were no tests of parallel_for_each.
+	This adds a few tests of parallel_for_each, primarily testing that
+	different settings for the number of threads will work.  This test
+	catches the bug that he found in that series.
+
+2021-08-30  Tom Tromey  <tom@tromey.com>
+
+	Add a show function for "maint show worker-threads"
+	I wanted to see how many threads gdb thought it was using, but
+	"maint show worker-threads" only reported "unlimited".  This patch
+	adds a show function so that it will now report the number of threads
+	gdb has started.
+
+	Regression tested on x86-64 Fedora 34.
+
+2021-08-30  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/cli] Don't assert on empty string for core-file
+	With current gdb we run into:
+	...
+	$ gdb -batch '' ''
+	: No such file or directory.
+	pathstuff.cc:132: internal-error: \
+	  gdb::unique_xmalloc_ptr<char> gdb_abspath(const char*): \
+	  Assertion `path != NULL && path[0] != '\0'' failed.
+	...
+
+	Fix this by skipping the call to gdb_abspath in core_target_open in the
+	empty-string case, such that we have instead:
+	...
+	$ gdb -batch '' ''
+	: No such file or directory.
+	: No such file or directory.
+	$
+	...
+
+	Tested on x86_64-linux.
+
+	gdb/ChangeLog:
+
+	2021-08-30  Tom de Vries  <tdevries@suse.de>
+
+		PR cli/28290
+		* gdb/corelow.c (core_target_open): Skip call to gdb_abspath in the
+		empty-string case.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-08-30  Tom de Vries  <tdevries@suse.de>
+
+		PR cli/28290
+		* gdb.base/batch-exit-status.exp: Add gdb '' and gdb '' '' tests.
+
+2021-08-30  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: PR27916, Support mapping symbols.
+	Similar to ARM/AARCH64, we add mapping symbols in the symbol table,
+	to mark the start addresses of data and instructions.  The $d means
+	data, and the $x means instruction.  Then the disassembler uses these
+	symbols to decide whether we should dump data or instruction.
+
+	Consider the mapping-04 test case,
+	$ cat tmp.s
+	  .text
+	  .option norelax
+	  .option norvc
+	  .fill 2, 4, 0x1001
+	  .byte 1
+	  .word 0
+	  .balign 8
+	  add a0, a0, a0
+	  .fill 5, 2, 0x2002
+	  add a1, a1, a1
+	  .data
+	  .word 0x1             # No need to add mapping symbols.
+	  .word 0x2
+
+	$ riscv64-unknown-elf-as tmp.s -o tmp.o
+	$ riscv64-unknown-elf-objdump -d tmp.o
+
+	Disassembly of section .text:
+
+	0000000000000000 <.text>:
+	   0:   00001001         .word   0x00001001  # Marked $d, .fill directive.
+	   4:   00001001         .word   0x00001001
+	   8:   00000001         .word   0x00000001  # .byte + part of .word.
+	   c:   00               .byte   0x00        # remaining .word.
+	   d:   00               .byte   0x00        # Marked $d, odd byte of alignment.
+	   e:   0001             nop                 # Marked $x, nops for alignment.
+	  10:   00a50533         add     a0,a0,a0
+	  14:   20022002         .word   0x20022002  # Marked $d, .fill directive.
+	  18:   20022002         .word   0x20022002
+	  1c:   2002             .short  0x2002
+	  1e:   00b585b3         add     a1,a1,a1    # Marked $x.
+	  22:   0001             nop                 # Section tail alignment.
+	  24:   00000013         nop
+
+	* Use $d and $x to mark the distribution of data and instructions.
+	  Alignments of code are recognized as instructions, since we usually
+	  fill nops for them.
+
+	* If the alignment have odd bytes, then we cannot just fill the nops
+	  into the spaces.  We always fill an odd byte 0x00 at the start of
+	  the spaces.  Therefore, add a $d mapping symbol for the odd byte,
+	  to tell disassembler that it isn't an instruction.  The behavior
+	  is same as Arm and Aarch64.
+
+	The elf/linux toolchain regressions all passed.  Besides, I also
+	disable the mapping symbols internally, but use the new objudmp, the
+	regressions passed, too.  Therefore, the new objudmp should dump
+	the objects corretly, even if they don't have any mapping symbols.
+
+	bfd/
+		pr 27916
+		* cpu-riscv.c (riscv_elf_is_mapping_symbols): Define mapping symbols.
+		* cpu-riscv.h: extern riscv_elf_is_mapping_symbols.
+		* elfnn-riscv.c (riscv_maybe_function_sym): Do not choose mapping
+		symbols as a function name.
+		(riscv_elf_is_target_special_symbol): Add mapping symbols.
+	binutils/
+		pr 27916
+		* testsuite/binutils-all/readelf.s: Updated.
+		* testsuite/binutils-all/readelf.s-64: Likewise.
+		* testsuite/binutils-all/readelf.s-64-unused: Likewise.
+		* testsuite/binutils-all/readelf.ss: Likewise.
+		* testsuite/binutils-all/readelf.ss-64: Likewise.
+		* testsuite/binutils-all/readelf.ss-64-unused: Likewise.
+	gas/
+		pr 27916
+		* config/tc-riscv.c (make_mapping_symbol): Create a new mapping symbol.
+		(riscv_mapping_state): Decide whether to create mapping symbol for
+		frag_now.  Only add the mapping symbols to text sections.
+		(riscv_add_odd_padding_symbol): Add the mapping symbols for the
+		riscv_handle_align, which have odd bytes spaces.
+		(riscv_check_mapping_symbols): Remove any excess mapping symbols.
+		(md_assemble): Marked as MAP_INSN.
+		(riscv_frag_align_code): Marked as MAP_INSN.
+		(riscv_init_frag): Add mapping symbols for frag, it usually called
+		by frag_var.  Marked as MAP_DATA for rs_align and rs_fill, and
+		marked as MAP_INSN for rs_align_code.
+		(s_riscv_insn): Marked as MAP_INSN.
+		(riscv_adjust_symtab): Call riscv_check_mapping_symbols.
+		* config/tc-riscv.h (md_cons_align): Defined to riscv_mapping_state
+		with MAP_DATA.
+		(TC_SEGMENT_INFO_TYPE): Record mapping state for each segment.
+		(TC_FRAG_TYPE): Record the first and last mapping symbols for the
+		fragments.  The first mapping symbol must be placed at the start
+		of the fragment.
+		(TC_FRAG_INIT): Defined to riscv_init_frag.
+		* testsuite/gas/riscv/mapping-01.s: New testcase.
+		* testsuite/gas/riscv/mapping-01a.d: Likewise.
+		* testsuite/gas/riscv/mapping-01b.d: Likewise.
+		* testsuite/gas/riscv/mapping-02.s: Likewise.
+		* testsuite/gas/riscv/mapping-02a.d: Likewise.
+		* testsuite/gas/riscv/mapping-02b.d: Likewise.
+		* testsuite/gas/riscv/mapping-03.s: Likewise.
+		* testsuite/gas/riscv/mapping-03a.d: Likewise.
+		* testsuite/gas/riscv/mapping-03b.d: Likewise.
+		* testsuite/gas/riscv/mapping-04.s: Likewise.
+		* testsuite/gas/riscv/mapping-04a.d: Likewise.
+		* testsuite/gas/riscv/mapping-04b.d: Likewise.
+		* testsuite/gas/riscv/mapping-norelax-04a.d: Likewise.
+		* testsuite/gas/riscv/mapping-norelax-04b.d: Likewise.
+		* testsuite/gas/riscv/no-relax-align.d: Updated.
+		* testsuite/gas/riscv/no-relax-align-2.d: Likewise.
+	include/
+		pr 27916
+		* opcode/riscv.h (enum riscv_seg_mstate): Added.
+
+	opcodes/
+		pr 27916
+		* riscv-dis.c (last_map_symbol, last_stop_offset, last_map_state):
+		Added to dump sections with mapping symbols.
+		(riscv_get_map_state): Get the mapping state from the symbol.
+		(riscv_search_mapping_symbol): Check the sorted symbol table, and
+		then find the suitable mapping symbol.
+		(riscv_data_length): Decide which data size we should print.
+		(riscv_disassemble_data): Dump the data contents.
+		(print_insn_riscv): Handle the mapping symbols.
+		(riscv_symbol_is_valid): Marked mapping symbols as invalid.
+
+2021-08-30  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Improve argument syntax of proc arange
+	The current syntax of proc arange is:
+	...
+	  proc arange { arange_start arange_length {comment ""} {seg_sel ""} } {
+	...
+	and a typical call looks like:
+	...
+	  arange $start $len
+	...
+
+	This style is somewhat annoying because if you want to specify the last
+	parameter, you need to give the default values of all the other optional ones
+	before as well:
+	...
+	  arange $start $len "" $seg_sel
+	...
+
+	Update the syntax to:
+	...
+	    proc arange { options arange_start arange_length } {
+	       parse_options {
+	           { comment "" }
+	           { seg_sel "" }
+	       }
+	...
+	such that a typical call looks like:
+	...
+	  arange {} $start $len
+	...
+	and a call using seg_sel looks like:
+	...
+	  arange {
+	    seg_sel $seg_sel
+	  } $start $len
+	...
+
+	Also update proc aranges, which already has an options argument, to use the
+	new proc parse_options.
+
+	Tested on x86_64-linux.
+
+	Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca>
+
+2021-08-30  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-29  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-28  H.J. Lu  <hjl.tools@gmail.com>
+
+	ld: Change indirect symbol from IR to undefined
+	bfd/
+
+		PR ld/28264
+		* elflink.c (_bfd_elf_merge_symbol): Change indirect symbol from
+		IR to undefined.
+
+	ld/
+
+		PR ld/28264
+		* testsuite/ld-plugin/lto.exp: Run PR ld/28264 test.
+		* testsuite/ld-plugin/pr28264-1.d: New file.
+		* testsuite/ld-plugin/pr28264-2.d: Likewise.
+		* testsuite/ld-plugin/pr28264-3.d: Likewise.
+		* testsuite/ld-plugin/pr28264-4.d: Likewise.
+		* testsuite/ld-plugin/pr28264.c: Likewise.
+		* testsuite/ld-plugin/pr28264.ver: Likewise.
+
+2021-08-28  Alan Modra  <amodra@gmail.com>
+
+	PR28264, ld.bfd crash on linking efivar with LTO
+		PR 28264
+		PR 26978
+		* linker.c (_bfd_generic_link_add_one_symbol <MIND>): Check
+		that string is non-NULL.
+
+2021-08-28  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-27  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/symtab] Don't write .gdb_index symbol table with empty entries
+	When comparing the sizes of the index files generated for shlib
+	outputs/gdb.dwarf2/dw2-zero-range/shr1.sl, I noticed a large difference
+	between .debug_names:
+	...
+	$ gdb -q -batch $shlib -ex "save gdb-index -dwarf-5 ."
+	$ du -b -h shr1.sl.debug_names shr1.sl.debug_str
+	61      shr1.sl.debug_names
+	0       shr1.sl.debug_str
+	...
+	and .gdb_index:
+	...
+	$ gdb -q -batch $shlib -ex "save gdb-index ."
+	$ du -b -h shr1.sl.gdb-index
+	8.2K    shr1.sl.gdb-index
+	...
+
+	The problem is that the .gdb_index contains a non-empty symbol table with only
+	empty entries.
+
+	Fix this by making the symbol table empty, such that we have instead:
+	...
+	$ du -b -h shr1.sl.gdb-index
+	184     shr1.sl.gdb-index
+	...
+
+	Tested on x86_64-linux.
+
+2021-08-27  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Generate .debug_aranges in gdb.dlang/watch-loc.exp
+	Before commit 5ef670d81fd "[gdb/testsuite] Add dummy start and end CUs in
+	dwarf assembly" we had in exec outputs/gdb.dlang/watch-loc/watch-loc a D
+	compilation unit at offset 0xc7:
+	...
+	  Compilation Unit @ offset 0xc7:
+	   Length:        0x4c (32-bit)
+	   Version:       4
+	   Abbrev Offset: 0x64
+	   Pointer Size:  8
+	 <0><d2>: Abbrev Number: 2 (DW_TAG_compile_unit)
+	    <d3>   DW_AT_language    : 19       (D)
+	...
+	with a corresponding .debug_aranges entry:
+	...
+	Offset into .debug_info:  0xc7
+	  Pointer Size:             4
+	  Segment Size:             0
+
+	    Address    Length
+	    004004a7 0000000b
+	    00000000 00000000
+	...
+
+	After that commit we have a dummy CU at offset 0xc7 and the D compilation unit
+	at offset 0xd2:
+	...
+	  Compilation Unit @ offset 0xc7:
+	   Length:        0x7 (32-bit)
+	   Version:       4
+	   Abbrev Offset: 0x64
+	   Pointer Size:  8
+	  Compilation Unit @ offset 0xd2:
+	   Length:        0x4c (32-bit)
+	   Version:       4
+	   Abbrev Offset: 0x65
+	   Pointer Size:  8
+	 <0><dd>: Abbrev Number: 2 (DW_TAG_compile_unit)
+	    <de>   DW_AT_language    : 19       (D)
+	...
+	while the .debug_aranges entry still points to 0xc7.
+
+	The problem is that the test-case uses a hack (quoting from
+	commit 75f06e9dc59):
+	...
+	[ Note: this is a non-trivial test-case.  The file watch-loc-dw.S contains a
+	.debug_info section, but not an .debug_aranges section or any actual code.
+	The file watch-loc.c contains code and a .debug_aranges section, but no other
+	debug section.  So, the intent for the .debug_aranges section in watch-loc.c
+	is to refer to a compilation unit in the .debug_info section in
+	watch-loc-dw.S. ]
+	...
+	and adding the dummy CU caused that hack to stop working.
+
+	Fix this by moving the generation of .debug_aranges from watch-loc.c to
+	watch-loc.exp, such that we have:
+	...
+	  Offset into .debug_info:  0xd2
+	  Pointer Size:             4
+	  Segment Size:             0
+
+	    Address    Length
+	    004004a7 0000000b
+	    00000000 00000000
+	...
+
+	Tested on x86_64-linux.
+
+2021-08-27  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Generate .debug_aranges entry for dummy CU
+	A best practise for DWARF [1] is to generate .debug_aranges entries for CUs
+	even if they have no address range.
+
+	Generate .debug_arange entries for the dummy CUs added by the DWARF assembler.
+
+	Tested on x86_64-linux.
+
+	[1] http://wiki.dwarfstd.org/index.php?title=Best_Practices
+
+2021-08-27  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Add .debug_aranges in more test-cases
+	A couple of test-cases fail when run with target board cc-with-debug-names due
+	to missing .debug_aranges entries for the CUs added by the dwarf assembler.
+
+	Add a .debug_aranges entry for those CUs.
+
+	Tested on x86_64-linux.
+
+2021-08-27  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Support .debug_aranges in dwarf assembly
+	Add a proc aranges such that we can generate .debug_aranges sections in dwarf
+	assembly using:
+	...
+	  cu { label cu_label } {
+	  ...
+	  }
+
+	  aranges {} cu_label {
+	    arange $addr $len [<comment>] [$segment_selector]
+	  }
+	...
+
+	Tested on x86_64-linux.
+
+2021-08-27  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Add label option to proc cu
+	We can use current dwarf assembly infrastructure to declare a label that marks
+	the start of the CU header:
+	...
+	  declare_labels header_start_cu_a
+	  _section ".debug_info"
+	  header_start_cu_a : cu {} {
+	  }
+	  _section ".debug_info"
+	  header_start_cu_b : cu {} {
+	  }
+	...
+	on the condition that we switch to the .debug_info section before, which makes
+	this style of use fragile.
+
+	Another way to achieve the same is to use the label as generated by the cu
+	proc itself:
+	...
+	  variable _cu_label
+	  cu {} {
+	  }
+	  set header_start_cu_a $_cu_label
+	  cu {} {
+	  }
+	  set header_start_cu_b $_cu_label
+	...
+	but again that seems fragile given that adding a new CU inbetween will
+	silently result in the wrong value for the label.
+
+	Add a label option to proc cu such that we can simply do:
+	...
+	  cu { label header_start_cu_a } {
+	  }
+	  cu { label header_start_cu_b } {
+	  }
+	...
+
+	Tested on x86_64-linux.
+
+2021-08-27  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-26  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: remove some stray newlines in debug output
+	I spotted a couple of stray newlines that were left at the end of
+	debug message during conversion to the new debug output scheme.  These
+	messages are part of the 'set debug lin-lwp 1' output.
+
+2021-08-26  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-25  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-24  Tom Tromey  <tom@tromey.com>
+
+	Fix two regressions caused by CU / TU merging
+	PR symtab/28160 and PR symtab/27893 concern GDB crashes in the test
+	suite when using the "fission" target board.  They are both caused by
+	the patches that merge the list of CUs with the list of TUs (and to a
+	lesser degree by the patches to share DWARF data across objfiles), and
+	the underlying issue is the same: it turns out that reading a DWO can
+	cause new type units to be created.  This means that the list of
+	dwarf2_per_cu_data objects depends on precisely which CUs have been
+	expanded.  However, because the type units can be created while
+	expanding a CU means that the vector of CUs can expand while it is
+	being iterated over -- a classic mistake.  Also, because a TU can be
+	added later, it means the resize_symtabs approach is incorrect.
+
+	This patch fixes resize_symtabs by removing it, and having set_symtab
+	resize the vector on demand.  It fixes the iteration problem by
+	introducing a safe (index-based) iterator and changing the relevant
+	spots to use it.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28160
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27893
+
+2021-08-24  Alan Modra  <amodra@gmail.com>
+
+	Real programmers don't configure gcc using --with-ld
+		* testsuite/lib/ld-lib.exp (run_host_cmd): Give a clue as to why
+		gcc -B doesn't pick up the ld under test.
+
+2021-08-24  Alan Modra  <amodra@gmail.com>
+
+	objdump -S test fail on mingw
+	FAIL: objdump -S
+	FAIL: objdump --source-comment
+	is seen on mingw for the simple reason that gcc adds a .exe suffix on
+	the output file if not already present.  Fix that, and tidy some objcopy
+	tests.
+
+		* testsuite/lib/binutils-common.exp (exeext): New proc.
+		* testsuite/binutils-all/objcopy.exp (exe, test_prog): Use it here.
+		(objcopy_remove_relocations_from_executable): Catch objcopy errors.
+		Only run on ELF targets.
+		* testsuite/binutils-all/objdump.exp (exe): Set variable.
+		(test_build_id_debuglink, test_objdump_S): Use exe file suffix.
+
+2021-08-24  James Bowman (FTDI-UK)  <james.bowman@ftdichip.com>
+
+	FT32: Remove recursion in ft32_opcode
+	The function ft32_opcode used recursion.  This could cause a stack
+	overflow.  Replaced with a pair of non-recursive functions.
+
+		PR 28169
+	        * ft32-dis.c: Formatting.
+		(ft32_opcode1): Split out from..
+		(ft32_opcode): ..here.
+
+2021-08-24  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-23  Tom Tromey  <tom@tromey.com>
+
+	Fix a latent bug in dw2-ranges-overlap.exp
+	dw2-ranges-overlap.exp creates a program where a psymtab has two
+	address ranges, and a function without debug info whose address is
+	between these two ranges.  Then it sets a breakpoint on this function
+	and runs to it, expecting that the language should remain "auto; c"
+	when stopped.
+
+	However, this test case also has a "main" function described (briefly)
+	in the DWARF, and this function is given language C++.  Also, a
+	breakpoint stop sets the current language to the language that was
+	used when setting the breakpoint.
+
+	My new DWARF scanner decides that this "main" is the main program and
+	sets the current language to C++ at startup, causing this test to
+	fail.
+
+	This patch fixes the test in a simple way, by introducing a new
+	function that takes the place of "main" in the DWARF.  I think this
+	still exercises the original problem, but also avoids problems with my
+	branch.
+
+	It seemed safe to me to submit this separately.
+
+2021-08-23  Tom de Vries  <tdevries@suse.de>
+
+	[gdb] Fix 'not in executable format' error message
+	With trying to load a non-executable file into gdb, we run into PR26880:
+	...
+	$ gdb -q -batch test.c
+	"0x7ffc87bfc8d0s": not in executable format: \
+	  file format not recognized
+	...
+
+	The problem is caused by using %ps in combination with the error function
+	(note that confusingly, it does work in combination with the warning
+	function).
+
+	Fix this by using plain "%s" instead.
+
+	Tested on x86_64-linux.
+
+	gdb/ChangeLog:
+
+	2021-08-22  Tom de Vries  <tdevries@suse.de>
+
+		PR gdb/26880
+		* gdb/exec.c (exec_file_attach): Use %s instead of %ps in call to
+		error function.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-08-22  Tom de Vries  <tdevries@suse.de>
+
+		PR gdb/26880
+		* gdb.base/non-executable.exp: New file.
+
+2021-08-23  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Use compiler-generated instead of gas-generated stabs
+	The test-case gdb.dwarf2/dw2-ranges.exp is the only one in the gdb testsuite
+	that uses gas-generated stabs.
+
+	While the use seems natural alongside the use of gas-generated dwarf in the
+	same test-case, there are a few known issues, filed on the gdb side as:
+	- PR symtab/12497 - "stabs: PIE relocation does not work"
+	- PR symtab/28221 - "[readnow, stabs] FAIL: gdb.dwarf2/dw2-ranges.exp: \
+	  info line func"
+	and on the gas side as:
+	- PR gas/28233 - "[gas, --gstabs] Generate stabs more similar to gcc"
+
+	The test-case contains a KFAIL for PR12497, but it's outdated and fails to
+	trigger.
+
+	The intention of the test-case is to test gas-generated dwarf, and using
+	gcc-generated stabs instead of gas-generated stabs works fine.
+
+	Supporting compiler-generated stabs is already a corner-case for gdb, and
+	there's no current commitment/incentive to support/workaround gas-generated
+	stabs, which can be considered a corner-case of a corner-case.
+
+	Work around these problem by using compiler-generated stabs in the test-case.
+
+	Tested on x86_64-linux.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-08-22  Tom de Vries  <tdevries@suse.de>
+
+		* gdb.dwarf2/dw2-ranges.exp: Use compiler-generated stabs.
+
+2021-08-23  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Add dummy start and end CUs in dwarf assembly
+	Say one compiles a hello.c:
+	...
+	$ gcc -g hello.c
+	...
+
+	On openSUSE Leap 15.2 and Tumbleweed, the CU for hello.c is typically not the
+	first in .debug_info, nor the last, due to presence of debug information in
+	objects for sources like:
+	- ../sysdeps/x86_64/start.S
+	- init.c
+	- ../sysdeps/x86_64/crti.S
+	- elf-init.c
+	- ../sysdeps/x86_64/crtn.S.
+
+	On other systems, say ubuntu 18.04.5, the CU for hello.c is typically the
+	first and the last in .debug_info.
+
+	This difference has caused me to find some errors in the dwarf assembly
+	using openSUSE, that didn't show up on other platforms.
+
+	Force the same situation on other platforms by adding a dummy start
+	and end CU.
+
+	Tested on x86_64-linux.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-08-22  Tom de Vries  <tdevries@suse.de>
+
+		PR testsuite/28235
+		* lib/dwarf.exp (Dwarf::dummy_cu): New proc.
+		(Dwarf::assemble): Add dummy start and end CU.
+
+2021-08-23  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix dw2-ranges-psym.exp with -readnow
+	When running test-case gdb.dwarf2/dw2-ranges-psym.exp with target board
+	-readnow, I run into:
+	...
+	(gdb) file dw2-ranges-psym^M
+	Reading symbols from dw2-ranges-psym...^M
+	Expanding full symbols from dw2-ranges-psym...^M
+	(gdb) set complaints 0^M
+	(gdb) FAIL: gdb.dwarf2/dw2-ranges-psym.exp: No complaints
+	...
+
+	The problem is that the regexp expects a gdb prompt immediately after the
+	"Reading symbols" line.
+
+	Fix this by updating the regexp.
+
+	Tested on x86_64-linux.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-08-22  Tom de Vries  <tdevries@suse.de>
+
+		* lib/gdb.exp (gdb_load_no_complaints): Update regexp to allow
+		"Expanding full symbols" Line.
+
+2021-08-23  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-22  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: m32r: add __linux__ hack for non-Linux hosts
+	The m32r Linux syscall emulation logic assumes the host environment
+	directly matches -- it's being run on 32-bit little endian Linux.
+	This breaks building for non-Linux systems, so put all the code in
+	__linux__ ifdef checks.  This code needs a lot of love to make it
+	work everywhere, but let's at least unbreak it for non-Linux hosts.
+
+2021-08-22  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-21  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-20  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: nltvals: switch output mode to a directory
+	In preparation for this script generating more files, change the output
+	argument to specify a directory.  This drops the stdout behavior, but
+	since no one really runs this tool directly, it's not a big deal.
+
+2021-08-20  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-19  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: use bool in notify_command_param_changed_p and do_set_command
+	Trivial patch to use bool instead of int.
+
+	Change-Id: I9e5f8ee4305272a6671cbaaaf2f0484eff0d1ea5
+
+2021-08-19  H.J. Lu  <hjl.tools@gmail.com>
+
+	x86: Put back 3 aborts in OP_E_memory
+	Put back 3 aborts where invalid lengths should have been filtered out.
+
+	gas/
+
+		PR binutils/28247
+		* testsuite/gas/i386/bad-bcast.s: Add a comment.
+
+	opcodes/
+
+		PR binutils/28247
+		* * i386-dis.c (OP_E_memory): Put back 3 aborts.
+
+2021-08-19  H.J. Lu  <hjl.tools@gmail.com>
+
+	x86: Avoid abort on invalid broadcast
+	Print "{bad}" on invalid broadcast instead of abort.
+
+	gas/
+
+		PR binutils/28247
+		* testsuite/gas/i386/bad-bcast.d: New file.
+		* testsuite/gas/i386/bad-bcast.s: Likewise.
+		* testsuite/gas/i386/i386.exp: Run bad-bcast.
+
+	opcodes/
+
+		PR binutils/28247
+		* i386-dis.c (OP_E_memory): Print "{bad}" on invalid broadcast
+		instead of abort.
+
+2021-08-19  Aaron Merey  <amerey@redhat.com>
+
+	gdb/solib: Refactor scan_dyntag
+	scan_dyntag is unnecessarily duplicated in solib-svr4.c and solib-dsbt.c.
+
+	Move this function to solib.c and rename it to gdb_bfd_scan_elf_dyntag.
+	Also add it to solib.h so it is included in both solib-svr4 and solib-dsbt.
+
+2021-08-19  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-18  Will Schmidt  <will_schmidt@vnet.ibm.com>
+
+	[gdb] [rs6000] Add ppc64_linux_gcc_target_options method.
+	Add a method to set the gcc target options for the ppc64 targets.
+	This change sets an empty value, which allows the gcc
+	default values (-mcmodel=medium) be used, instead of -mcmodel=large
+	which is set by the default_gcc_target_options hook.
+
+	[gdb] [rs6000] Add ppc64*_gnu_triplet_regexp methods.
+	Add methods to set the target triplet so we can
+	find the proper gcc when our gcc is named of
+	the form powerpc64{le}-<foo>-gcc or ppc64{le}-<foo>-gcc.
+
+2021-08-18  Alan Modra  <amodra@gmail.com>
+
+	Re: as: Replace the removed symbol with the versioned symbol
+	Some targets, typically embedded without shared libraries, replace the
+	relocation symbol with a section symbol (see tc_fix_adjustable).
+	Allow the test to pass for such targets.  Fixes the following.
+
+	avr-elf  +FAIL: symver symver16
+	d10v-elf  +FAIL: symver symver16
+	dlx-elf  +FAIL: symver symver16
+	ip2k-elf  +FAIL: symver symver16
+	m68k-elf  +FAIL: symver symver16
+	mcore-elf  +FAIL: symver symver16
+	pj-elf  +FAIL: symver symver16
+	s12z-elf  +FAIL: symver symver16
+	visium-elf  +FAIL: symver symver16
+	z80-elf  +FAIL: symver symver16
+
+		PR gas/28157
+		* testsuite/gas/symver/symver16.d: Relax reloc match.
+
+2021-08-18  Alan Modra  <amodra@gmail.com>
+
+	[GOLD] PowerPC64 relocation overflow for -Os register save/restore funcs
+	Fixes a silly mistake in calculating the address of -Os out-of-line
+	register save/restore function copies.  Copies of these linker defined
+	functions are added to stub sections when the original (in
+	target->savres_section) can't be reached.
+
+		* powerpc.cc (Target_powerpc::Relocate::relocate): Correct address
+		calculation of out-of-line save/restore function copies.
+
+2021-08-18  Alan Modra  <amodra@gmail.com>
+
+	Another ld script backtrack
+		* ldgram.y (length_spec): Throw away look-ahead NAME.
+
+2021-08-18  Mike Frysinger  <vapier@gentoo.org>
+
+	gdb: fix spacing on CCLD silent rules
+
+	sim: nltvals: localize TARGET_<ERRNO> defines
+	Code should not be using these directly, instead they should be
+	resolving these dynamically via cb_host_to_target_errno maps.
+	Fix the Blackfin code and remove the defines out of the header
+	so no new code can rely on them.
+
+2021-08-18  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: rename ChangeLog files to ChangeLog-2021
+	Now that ChangeLog entries are no longer used for sim patches,
+	this commit renames all relevant sim ChangeLog to ChangeLog-2021,
+	similar to what we would do in the context of the "Start of New
+	Year" procedure.
+
+	The purpose of this change is to avoid people merging ChangeLog
+	entries by mistake when applying existing commits that they are
+	currently working on.
+
+	Also throw in a .gitignore entry to keep people from adding new
+	ChangeLog files anywhere in the sim tree.
+
+2021-08-18  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-17  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: fix thread_step_over_chain_length
+	If I debug a single-thread program and look at the infrun debug logs, I
+	see:
+
+	    [infrun] start_step_over: stealing global queue of threads to step, length = 2
+
+	That makes no sense... turns out there's a buglet in
+	thread_step_over_chain_length, "num" should be initialized to 0.  I
+	think this bug is a leftover from an earlier version of the code (not
+	merged upstream) that manually walked the list, where the first item was
+	implicitly counted (hence the 1).
+
+	Change-Id: I0af03aa93509aed36528be5076894dc156a0b5ce
+
+2021-08-17  Shahab Vahedi  <shahab@synopsys.com>
+
+	opcodes: Fix the auxiliary register numbers for ARC HS
+	The numbers for the auxiliary registers "tlbindex" and
+	"tlbcommand" of ARCv2HS are incorrect.  This patch makes
+	the following changes to correct that error.
+
+	 ,------------.-----------------.---------------.
+	 | aux. reg.  | old (incorrect) | new (correct) |
+	 |------------+-----------------+---------------|
+	 | tlbindex   |      0x463      |     0x464     |
+	 | tlbcommand |      0x464      |     0x465     |
+	 `------------^-----------------^---------------'
+
+	opcodes/
+	2021-08-17  Shahab Vahedi <shahab@synopsys.com>
+
+		* arc-regs.h (DEF): Fix the register numbers.
+
+2021-08-17  H.J. Lu  <hjl.tools@gmail.com>
+
+	gdb: Don't assume r_ldsomap when r_version > 1 on Linux
+	The r_ldsomap field is specific to Solaris (part of librtld_db), and
+	should never be accessed for Linux.  glibc is planning to add a field
+	to support multiple namespaces.  But there will be no r_ldsomap when
+	r_version is bumped to 2.  Add linux_[ilp32|lp64]_fetch_link_map_offsets
+	to set r_ldsomap_offset to -1 and use them for Linux targets.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28236
+
+2021-08-17  H.J. Lu  <hjl.tools@gmail.com>
+
+	gdbserver: Check r_version < 1 for Linux debugger interface
+	Update gdbserver to check r_version < 1 instead of r_version != 1 so
+	that r_version can be bumped for a new field in the glibc debugger
+	interface to support multiple namespaces.  Since so far, the gdbserver
+	only reads fields defined for r_version == 1, it is compatible with
+	r_version >= 1.
+
+	All future glibc debugger interface changes will be backward compatible.
+	If there is ever the need for backward incompatible change to the glibc
+	debugger interface, a new DT_XXX element will be provided to access the
+	new incompatible interface.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11839
+
+2021-08-17  Andrea Corallo  <andrea.corallo@arm.com>
+
+	PATCH [4/4] arm: Add Tag_PACRET_use build attribute
+	bfd/
+	2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* elf32-arm.c (elf32_arm_merge_eabi_attributes): Add
+		'Tag_PACRET_use' case.
+
+	binutils/
+	2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* readelf.c (arm_attr_tag_PAC_extension): Declare.
+		(arm_attr_public_tags): Add 'PAC_extension' lookup.
+
+	elfcpp/
+	2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* arm.h: Define 'Tag_PACRET_use' enum.
+
+	gas/
+	2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* config/tc-arm.c (arm_convert_symbolic_attribute): Add
+		'Tag_PACRET_use' to the attribute_table.
+
+	include/
+	2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* elf/arm.h (elf_arm_reloc_type): Add 'Tag_PACRET_use'.
+
+2021-08-17  Andrea Corallo  <andrea.corallo@arm.com>
+
+	PATCH [3/4] arm: Add Tag_BTI_use build attribute
+	bfd/
+	2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* elf32-arm.c (elf32_arm_merge_eabi_attributes): Add
+		'Tag_BTI_use' case.
+
+	binutils/
+	2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* readelf.c (arm_attr_tag_PAC_extension): Declare.
+		(arm_attr_public_tags): Add 'PAC_extension' lookup.
+
+	elfcpp/
+	2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* arm.h: Define 'Tag_BTI_use' enum.
+
+	gas/
+	2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* config/tc-arm.c (arm_convert_symbolic_attribute): Add
+		'Tag_BTI_use' to the attribute_table.
+
+	include/
+	2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* elf/arm.h (elf_arm_reloc_type): Add 'Tag_BTI_use'.
+
+2021-08-17  Andrea Corallo  <andrea.corallo@arm.com>
+
+	PATCH [2/4] arm: Add Tag_BTI_extension build attribute
+	bfd/
+	2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* elf32-arm.c (elf32_arm_merge_eabi_attributes): Add
+		'Tag_BTI_extension' case.
+
+	binutils/
+	2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* readelf.c (arm_attr_tag_PAC_extension): Declare.
+		(arm_attr_public_tags): Add 'PAC_extension' lookup.
+
+	elfcpp/
+	2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* arm.h: Define 'Tag_BTI_extension' enum.
+
+	gas/
+	2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* config/tc-arm.c (arm_convert_symbolic_attribute): Add
+		'Tag_BTI_extension' to the attribute_table.
+
+	include/
+	2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* elf/arm.h (elf_arm_reloc_type): Add 'Tag_BTI_extension'.
+
+2021-08-17  Andrea Corallo  <andrea.corallo@arm.com>
+
+	PATCH [1/4] arm: Add Tag_PAC_extension build attribute
+	bfd/
+	2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* elf32-arm.c (elf32_arm_merge_eabi_attributes): Add
+		'Tag_PAC_extension' case.
+
+	binutils/
+	2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* readelf.c (arm_attr_tag_PAC_extension): Declare.
+		(arm_attr_public_tags): Add 'PAC_extension' lookup.
+
+	elfcpp/
+	2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* arm.h: Define 'Tag_PAC_extension' enum.
+
+	gas/
+	2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* config/tc-arm.c (arm_convert_symbolic_attribute): Add
+		'Tag_PAC_extension' to the attribute_table.
+
+	include/
+	2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* elf/arm.h (elf_arm_reloc_type): Add 'Tag_PAC_extension'.
+
+2021-08-17  H.J. Lu  <hjl.tools@gmail.com>
+
+	x86: Always run fp tests
+	Always run fp tests since the size of .tfloat, .ds.x, .dc.x and .dcb.x
+	directive outputs is always 10 bytes.  There is no need for fp-elf32 nor
+	fp-elf64.
+
+		PR gas/28230
+		* testsuite/gas/i386/fp-elf32.d: Removed.
+		* testsuite/gas/i386/fp-elf64.d: Likewise.
+		* testsuite/gas/i386/fp.s: Remove NO_TFLOAT_PADDING codes.
+		* testsuite/gas/i386/i386.exp: Don't run fp-elf32 nor fp-elf64.
+		Always run fp.
+
+2021-08-17  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-16  H.J. Lu  <hjl.tools@gmail.com>
+
+	x86: Don't pad .tfloat directive output
+	.tfloat output should always be 10 bytes without padding, independent
+	of psABIs.  In glibc, x86 assembly codes expect 10-byte .tfloat output.
+	This also reduces .ds.x output and .tfloat output with hex input from
+	12 bytes to 10 bytes to match .tfloat output.
+
+		PR gas/28230
+		* NEWS: Mention changes of .ds.x output and .tfloat output with
+		hex input.
+		* config/tc-i386.c (x86_tfloat_pad): Removed.
+		* config/tc-i386.h (X_PRECISION_PAD): Changed to 0.
+		(x86_tfloat_pad): Removed.
+		* testsuite/gas/i386/fp.s: If NO_TFLOAT_PADDING isn't defined,
+		add explicit paddings after .tfloat, .ds.x, .dc.x and .dcb.x
+		directives.
+		* testsuite/gas/i386/i386.exp (ASFLAGS): Append
+		"--defsym NO_TFLOAT_PADDING=1" when running the fp test.
+
+2021-08-16  Tom Tromey  <tromey@adacore.com>
+
+	Fix register regression in DWARF evaluator
+	On an internal test case, using an arm-elf target, commit ba5bc3e5a92
+	("Make DWARF evaluator return a single struct value") causes a
+	regression.  (It doesn't happen for any of the other cross targets
+	that I test when importing upstream gdb.)
+
+	I don't know if there's an upstream gdb test case showing the same
+	problem... I can only really run native tests with dejagnu AFAIK.
+
+	The failure manifests like this:
+
+	    Breakpoint 1, file_1.export_1 (param_1=<error reading variable: Unable to access DWARF register number 64>, str=...) at [...]/file_1.adb:5
+
+	Whereas when it works it looks like:
+
+	    Breakpoint 1, file_1.export_1 (param_1=99.0, str=...) at [...]/file_1.adb:5
+
+	The difference is that the new code uses the passed-in gdbarch,
+	whereas the old code used the frame's gdbarch, when handling
+	DWARF_VALUE_REGISTER.
+
+	This patch restores the use of the frame's arch.
+
+2021-08-16  Tom Tromey  <tromey@adacore.com>
+
+	Fix Ada regression due to DWARF expression series
+	Commit 0579205aec4 ("Simplify dwarf_expr_context class interface")
+	caused a regression in the internal AdaCore test suite.  I didn't try
+	to reproduce this with the GDB test suite, but the test is identical
+	to gdb.dwarf2/dynarr-ptr.exp.
+
+	The problem is that this change:
+
+	 	case DW_OP_push_object_address:
+	 	  /* Return the address of the object we are currently observing.  */
+	-	  if (this->data_view.data () == nullptr
+	-	      && this->obj_address == 0)
+	+	  if (this->m_addr_info == nullptr)
+
+	... slightly changes the logic here.  In particular, it's possible for
+	the caller to pass in a non-NULL m_addr_info, but one that looks like:
+
+	    (top) p *this.m_addr_info
+	    $15 = {
+	      type = 0x29b7a70,
+	      valaddr = {
+		m_array = 0x0,
+		m_size = 0
+	      },
+	      addr = 0,
+	      next = 0x0
+	    }
+
+	In this case, an additional check is needed.  With the current code,
+	what happens instead is that the computation computes an incorrect
+	address -- but one that does not fail in read_memory, due to the
+	precise memory map of the embedded target in question.
+
+	This patch restores the old logic.
+
+2021-08-16  Patrick Monnerat  <patrick@monnerat.net>
+
+	Notify observer of breakpoint auto-disabling
+	As breakpoint_modified observer is currently notified upon breakpoint stop
+	before handling auto-disabling when enable count is reached, the observer
+	is never notified of the disabling.
+
+	The problem affects:
+	- The MI interpreter enabled= value when reporting =breakpoint-modified
+	- A Python event handler for breakpoint_modified using the "enabled"
+	  member of its parameter
+	- insight: breakpoint GUI window is not properly updated upon auto-disable
+
+	This patch moves the observer notification after the auto-disabling
+	code and implements corresponding tests for the MI and Python cases.
+
+	Fixes https://sourceware.org/bugzilla/show_bug.cgi?id=23336
+
+	Change-Id: I0c50df4789334071e5390cb46b3ca0d4a7f83c61
+
+2021-08-16  H.J. Lu  <hjl.tools@gmail.com>
+
+	as: Replace the removed symbol with the versioned symbol
+	When a symbol removed by .symver is used in relocation and there is one
+	and only one versioned symbol, don't remove the symbol.  Instead, mark
+	it to be removed and replace the removed symbol used in relocation with
+	the versioned symbol before generating relocation.
+
+		PR gas/28157
+		* symbols.c (symbol_flags): Add removed.
+		(symbol_entry_find): Updated.
+		(symbol_mark_removed): New function.
+		(symbol_removed_p): Likewise.
+		* symbols.h (symbol_mark_removed): New prototype.
+		(symbol_removed_p): Likewise.
+		* write.c (write_relocs): Call obj_fixup_removed_symbol on
+		removed fixp->fx_addsy and fixp->fx_subsy if defined.
+		(set_symtab): Don't add a symbol if symbol_removed_p returns true.
+		* config/obj-elf.c (elf_frob_symbol):  Don't remove the symbol
+		if it is used on relocation.  Instead, mark it as to be removed
+		and issue an error if the symbol has more than one versioned name.
+		(elf_fixup_removed_symbol): New function.
+		* config/obj-elf.h (elf_fixup_removed_symbol): New prototype.
+		(obj_fixup_removed_symbol): New.
+		* testsuite/gas/symver/symver11.d: Updated expected error
+		message.
+		* testsuite/gas/symver/symver16.d: New file.
+		* testsuite/gas/symver/symver16.s: Likewise.
+
+2021-08-16  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-15  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-14  Alan Modra  <amodra@gmail.com>
+
+	ld script fill pattern expression
+	It turns out we do need to backtrack when parsing after all.  The
+	fill_opt component in the section rule swiches to EXPRESSION and back
+	to SCRIPT, and to find the end of an expression it is necessary to
+	look ahead one token.
+
+		* ldgram.y (section): Throw away lookahead NAME token.
+		(overlay_section): Likewise.
+		* testsuite/ld-elf/overlay.t: Add fill pattern on overlays.
+		Test fill pattern before stupidly named normal sections too,
+		and before /DISCARD/.
+
+2021-08-14  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-13  Alan Modra  <amodra@gmail.com>
+
+	ld lexer tidy, possibly break the world
+	This tidies the states in which ld lexer rules are enabled.
+	This change will quite likely trip over issues similar to those
+	mentioned in the new ldlex.l comments, so please test it out.
+
+		* ldgram.y (wildcard_name): Remove now unnecessary components.
+		* ldlex.l: Restrict many rules' states.  Remove -l expression
+		state rule.  Comment on lookahead state madness and need for
+		/DISCARD/ in expression state.
+
+2021-08-13  Alan Modra  <amodra@gmail.com>
+
+	ld script lower-case absolute and sizeof_headers
+	I think these happened by accident, so let's see what breaks if they
+	are removed.
+
+		* ldlex.l: Remove lower case "absolute" and "sizeof_headers"
+		in non-mri mode.
+		* ld.texi: Remove sizeof_headers index.
+		* testsuite/ld-mmix/mmohdr1.ld: Use SIZEOF_HEADERS.
+
+2021-08-13  Alan Modra  <amodra@gmail.com>
+
+	tidy mri script extern
+	MRI mode generally doesn't flip lexer states, so let's make MRI mode
+	"extern" not do so either.
+
+		* ldgram.y (extern_name_list): Don't change lex state here.
+		(ifile_p1): Change state here on EXTERN instead.
+
+2021-08-13  Alan Modra  <amodra@gmail.com>
+
+	Re: PR28217, Syntax error when memory region contains a hyphen
+	I discovered some more errors when tightening up the lexer rules.
+	Just because we INCLUDE a file doesn't mean we've switched states.
+
+		PR 28217
+		* ldgram.y (statement): Don't switch lexer state on INCLUDE.
+		(mri_script_command, ifile_p1, memory_spec, section): Likewise.
+
+2021-08-13  Lifang Xia  <lifang_xia@c-sky.com>
+
+	PR28168: [CSKY] Fix stack overflow in disassembler
+	PR 28168:
+	Stack overflow with a large float. %f is not a goot choice for this.
+	%f should be replaced with %.7g.
+
+	gas/
+		* testsuite/gas/csky/pr28168.d: New testcase for PR 28168.
+		* testsuite/gas/csky/pr28168.s: Likewise.
+		* testsuite/gas/csky/v2_float_part2.d: Following the new format.
+		* opcodes/csky-dis.c (csky_output_operand): %.7g replaces %f.
+
+2021-08-13  Alan Modra  <amodra@gmail.com>
+
+	PR28217, Syntax error when memory region contains a hyphen
+	The saga of commit 40726f16a8d7 continues.  This attacks the problem
+	of switching between SCRIPT and EXPRESSION state lexing by removing
+	the need to do so for phdrs like ":text".  Instead {WILDCHAR}*
+	matching, the reason why ":text" lexed as one token, is restricted to
+	within the braces of a section or overlay statement.  The new WILD
+	lexer state is switched at the non-optional brace tokens, so
+	ldlex_backup is no longer needed.  I've also removed the BOTH state,
+	which doesn't seem to be needed any more.  Besides rules involving
+	error reporting, there was just one place where SCRIPT appeared
+	without BOTH, the {WILDCHAR}* rule, three where BOTH appears without
+	SCRIPT for tokens that only need EXPRESSION state, and two where BOTH
+	appears alongside INPUT_LIST.  (Since I'm editing the wild and
+	filename rules, removing BOTH and adding WILD can also be seen as
+	renaming the old BOTH state to SCRIPT and renaming the old SCRIPT
+	state to WILD with a reduced scope.)
+
+	As a followup, I'll look at removing EXPRESSION state from some lexer
+	rules that no longer need it due to this cleanup.
+
+		PR 28217
+		* ldgram.y (exp <ORIGIN, LENGTH>): Use paren_script_name.
+		(section): Parse within braces of section in wild mode, and
+		after brace back in script mode.  Remove ldlex_backup call.
+		Similarly for OVERLAY.
+		(overlay_section): Similarly.
+		(script_file): Replace ldlex_both with ldlex_script.
+		* ldlex.h (ldlex_wild): Declare.
+		(ldlex_both): Delete.
+		* ldlex.l (BOTH): Delete.  Remove state from all rules.
+		(WILD): New state.  Enable many tokens in this state.
+		Enable filename match in SCRIPT mode.  Enable WILDCHAR match
+		in WILD state, disable in SCRIPT mode.
+		(ldlex_wild): New function.
+		* ldfile.c (ldfile_try_open_bfd): Replace ldlex_both call with
+		ldlex_script.
+
+2021-08-13  Alan Modra  <amodra@gmail.com>
+
+	ns32k configury
+	Since ns32k-netbsd is as yet not removed, just marked obsolete,
+	the target should still be accepted with --enable-obsolete.
+
+	I also enabled ns32k-openbsd in ld since there doesn't seem to be a
+	good reason why that target is not supported there but is elsewhere.
+
+	bfd/
+		* config.bfd: Allow ns32k-netbsd.
+	ld/
+		* configure.tgt: Allow ns32k-openbsd.
+
+2021-08-13  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-13  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb: riscv_scan_prologue: handle LD and LW instructions
+	While working on the testsuite, I ended up noticing that GDB fails to
+	produce a full backtrace from a thread waiting in pthread_join.  When
+	selecting the waiting thread and using the 'bt' command, the following
+	result can be observed:
+
+		(gdb) bt
+		#0  0x0000003ff7fccd20 in __futex_abstimed_wait_common64 () from /lib/riscv64-linux-gnu/libpthread.so.0
+		#1  0x0000003ff7fc43da in __pthread_clockjoin_ex () from /lib/riscv64-linux-gnu/libpthread.so.0
+		Backtrace stopped: frame did not save the PC
+
+	On my platform, I do not have debug symbols for glibc, so I need to rely
+	on prologue analysis in order to unwind stack.
+
+	Here is what the function prologue looks like:
+
+		(gdb) disassemble __pthread_clockjoin_ex
+		Dump of assembler code for function __pthread_clockjoin_ex:
+		   0x0000003ff7fc42de <+0>:     addi    sp,sp,-144
+		   0x0000003ff7fc42e0 <+2>:     sd      s5,88(sp)
+		   0x0000003ff7fc42e2 <+4>:     auipc   s5,0xd
+		   0x0000003ff7fc42e6 <+8>:     ld      s5,-2(s5) # 0x3ff7fd12e0
+		   0x0000003ff7fc42ea <+12>:    ld      a5,0(s5)
+		   0x0000003ff7fc42ee <+16>:    sd      ra,136(sp)
+		   0x0000003ff7fc42f0 <+18>:    sd      s0,128(sp)
+		   0x0000003ff7fc42f2 <+20>:    sd      s1,120(sp)
+		   0x0000003ff7fc42f4 <+22>:    sd      s2,112(sp)
+		   0x0000003ff7fc42f6 <+24>:    sd      s3,104(sp)
+		   0x0000003ff7fc42f8 <+26>:    sd      s4,96(sp)
+		   0x0000003ff7fc42fa <+28>:    sd      s6,80(sp)
+		   0x0000003ff7fc42fc <+30>:    sd      s7,72(sp)
+		   0x0000003ff7fc42fe <+32>:    sd      s8,64(sp)
+		   0x0000003ff7fc4300 <+34>:    sd      s9,56(sp)
+		   0x0000003ff7fc4302 <+36>:    sd      a5,40(sp)
+
+	As far as prologue analysis is concerned, the most interesting part is
+	done at address 0x0000003ff7fc42ee (<+16>): 'sd ra,136(sp)'. This stores
+	the RA (return address) register on the stack, which is the information
+	we are looking for in order to identify the caller.
+
+	In the current implementation of the prologue scanner, GDB stops when
+	hitting 0x0000003ff7fc42e6 (<+8>) because it does not know what to do
+	with the 'ld' instruction.  GDB thinks it reached the end of the
+	prologue but have not yet reached the important part, which explain
+	GDB's inability to unwind past this point.
+
+	The section of the prologue starting at <+4> until <+12> is used to load
+	the stack canary[1], which will then be placed on the stack at <+36> at
+	the end of the prologue.
+
+	In order to have the prologue properly handled, this commit proposes to
+	add support for the ld instruction in the RISC-V prologue scanner.
+	I guess riscv32 would use lw in such situation so this patch also adds
+	support for this instruction.
+
+	With this patch applied, gdb is now able to unwind past pthread_join:
+
+		(gdb) bt
+		#0  0x0000003ff7fccd20 in __futex_abstimed_wait_common64 () from /lib/riscv64-linux-gnu/libpthread.so.0
+		#1  0x0000003ff7fc43da in __pthread_clockjoin_ex () from /lib/riscv64-linux-gnu/libpthread.so.0
+		#2  0x0000002aaaaaa88e in bar() ()
+		#3  0x0000002aaaaaa8c4 in foo() ()
+		#4  0x0000002aaaaaa8da in main ()
+
+	I have had a look to see if I could reproduce this easily, but in my
+	simple testcases using '-fstack-protector-all', the canary is loaded
+	after the RA register is saved.  I do not have a reliable way of
+	generating a prologue similar to the problematic one so I forged one
+	instead.
+
+	The testsuite have been run on riscv64 ubuntu 21.01 with no regression
+	observed.
+
+	[1] https://en.wikipedia.org/wiki/Buffer_overflow_protection#Canaries
+
+2021-08-12  Tom Tromey  <tromey@adacore.com>
+
+	Update documentation to mention Pygments
+	Philippe Blain pointed out that the gdb documentation does not mention
+	that Pygments may be used for source highlighting.  This patch updates
+	the docs to reflect how highlighting is actually done.
+
+2021-08-12  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: make gdbarch_printable_names return a vector
+	I noticed that gdbarch_selftest::operator() leaked the value returned by
+	gdbarch_printable_names.  Make gdbarch_printable_names return an
+	std::vector and update callers.  That makes it easier for everyone
+	involved, less manual memory management.
+
+	Change-Id: Ia8fc028bdb91f787410cca34f10bf3c5a6da1498
+
+2021-08-12  Carl Love  <cel@us.ibm.com>
+
+	Improve forward progress test in python.exp
+	The test steps into func2 and than does an up to get back to the previous
+	frame. The test checks that the line number you are at after the up command
+	is greater than the line where the function was called from. The
+	assembly/codegen for the powerpc target includes a NOP after the
+	branch-link.
+
+	func2 (); /* Break at func2 call site. /
+	10000694: 59 00 00 48 bl 100006ec
+	10000698: 00 00 00 60 nop
+	return 0; / Break to end. */
+	1000069c: 00 00 20 39 li r9,0
+
+	The PC at the instruction following the branch-link is 0x10000698 which
+	GDB.find_pc_line() maps to the same line number as the bl instruction.
+	GDB did move past the branch-link location thus making forward progress.
+
+	The following proposed fix adds an additional PC check to see if forward
+	progress was made.  The line test is changed from greater than to greater
+	than or equal.
+
+2021-08-12  Jiangshuai Li  <jiangshuai_li@c-sky.com>
+
+	gdb:csky rm tdesc_has_registers in csky_register_name
+	As CSKY arch has not parsed target-description.xml in csky_gdbarch_init,
+	when a remote server, like csky-qemu or gdbserver, send a target-description.xml
+	to gdb, tdesc_has_registers will return ture, but tdesc_register_name (gdbarch, 0)
+	will return NULL, so a cmd "info registers r0" will not work.
+
+	Function of parsing target-description.xml will be add later for CSKY arch,
+	now it is temporarily removed to allow me to do other supported tests.
+
+	2021-07-15 Jiangshuai Li  <jiangshuai_li@c-sky.com>
+
+	            * csky-tdep.c : not using tdesc funtions in csky_register_name
+
+2021-08-12  Alan Modra  <amodra@gmail.com>
+
+	Re: gas: support NaN flavors
+	Fixes tic4x-coff FAIL: simple FP constants
+
+		* testsuite/gas/all/float.s: Make NaN tests conditional on hasnan.
+		* testsuite/gas/all/gas.exp: Define hasnan.
+
+2021-08-12  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-11  H.J. Lu  <hjl.tools@gmail.com>
+
+	ld: Update the pass and fail strings of PR ld/28138 test
+		PR ld/28138
+		* testsuite/ld-plugin/lto.exp: Update the pass and fail strings
+		of PR ld/28138 test to indicate which part of the test passed
+		and failed.
+
+2021-08-11  Darius Galis  <darius.galis@cyberthorstudios.com>
+
+	Fix a typo in the RX asse,bler.  The Double-precision floating-point exception handling control register name is DECNT not DCENT.
+		* config/rx-parse.y (DECNT): Fixed typo.
+		* testsuite/gas/rx/dpopm.sm (DECNT): Fixed typo.
+		* testsuite/gas/rx/dpushm.sm (DECNT): Fixed typo.
+		* testsuite/gas/rx/macros.inc (DECNT): Fixed typo.
+
+2021-08-11  Nick Clifton  <nickc@redhat.com>
+
+	Fix an internal error in the CSKY assembler when asked to resolve an overlarge constant.
+		PR 28215
+		* config/tc-csky.c (md_apply_fix): Correctly handle a fixup that
+		involves an overlarge constant.
+
+2021-08-11  Luis Machado  <luis.machado@linaro.org>
+
+	Add 3 new PAC-related ARM note types
+	The following patch synchronizes includes/objdump/readelf with the Linux
+	Kernel in terms of ARM regset notes.
+
+	We're currently missing 3 of them:
+
+	NT_ARM_PACA_KEYS
+	NT_ARM_PACG_KEYS
+	NT_ARM_PAC_ENABLED_KEYS
+
+	We don't need GDB to bother with this at the moment, so this doesn't update
+	bfd/elf.c. If needed, we can do it in the future.
+
+	binutils/
+
+		* readelf.c (get_note_type): Handle new ARM PAC notes.
+
+	include/elf/
+
+		* common.h (NT_ARM_PACA_KEYS, NT_ARM_PACG_KEYS)
+		(NT_ARM_PAC_ENABLED_KEYS): New constants.
+
+2021-08-11  Nick Clifton  <nickc@redhat.com>
+
+	Updated Portuguese translation for the binutils sub-directory.
+
+2021-08-11  John Ericson  <git@JohnEricson.me>
+
+	Deprecate a.out support for NetBSD targets.
+	As discussed previously, a.out support is now quite deprecated, and in
+	some cases removed, in both Binutils itself and NetBSD, so this legacy
+	default makes little sense. `netbsdelf*` and `netbsdaout*` still work
+	allowing the user to be explicit about there choice. Additionally, the
+	configure script warns about the change as Nick Clifton requested.
+
+	One possible concern was the status of NetBSD on NS32K, where only a.out
+	was supported. But per [1] NetBSD has removed support, and if it were to
+	come back, it would be with ELF. The binutils implementation is
+	therefore marked obsolete, per the instructions in the last message.
+
+	With that patch and this one applied, I have confirmed the following:
+
+	--target=i686-unknown-netbsd
+	--target=i686-unknown-netbsdelf
+	  builds completely
+
+	--target=i686-unknown-netbsdaout
+	  properly fails because target is deprecated.
+
+	--target=vax-unknown-netbsdaout builds completely except for gas, where
+	the target is deprecated.
+
+	[1]: https://mail-index.netbsd.org/tech-toolchain/2021/07/19/msg004025.html
+	---
+	 bfd/config.bfd                             | 43 +++++++++++++--------
+	 bfd/configure.ac                           |  5 +--
+	 binutils/testsuite/binutils-all/nm.exp     |  2 +-
+	 binutils/testsuite/lib/binutils-common.exp |  7 +---
+	 config/picflag.m4                          |  4 +-
+	 gas/configure.tgt                          |  9 +++--
+	 gas/testsuite/gas/arm/blx-bl-convert.d     |  2 +-
+	 gas/testsuite/gas/arm/blx-local-thumb.d    |  2 +-
+	 gas/testsuite/gas/sh/basic.exp             |  2 +-
+	 gdb/configure.host                         | 34 +++++++----------
+	 gdb/configure.tgt                          |  2 +-
+	 gdb/testsuite/gdb.asm/asm-source.exp       |  6 +--
+	 intl/configure                             |  2 +-
+	 ld/configure.tgt                           | 44 +++++++++++-----------
+	 ld/testsuite/ld-arm/arm-elf.exp            |  4 +-
+	 ld/testsuite/ld-elf/elf.exp                |  2 +-
+	 ld/testsuite/ld-elf/shared.exp             |  4 +-
+	 libiberty/configure                        |  4 +-
+
+2021-08-11  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: don't print backtrace when dumping core after an internal error
+	Currently, when GDB hits an internal error, and the user selects to
+	dump core, the recently added feature to write a backtrace to the
+	console will kick in, and print a backtrace as well as dumping the
+	core.
+
+	This was certainly not my intention when adding the backtrace on fatal
+	signal functionality, this feature was intended to produce a backtrace
+	when GDB crashes due to some fatal signal, internal errors should have
+	continued to behave as they did before, unchanged.
+
+	In this commit I set the signal disposition of SIGABRT back to SIG_DFL
+	just prior to the call to abort() that GDB uses to trigger the core
+	dump, this prevents GDB reaching the code that writes the backtrace to
+	the console.
+
+	I've also added a test that checks we don't see a backtrace on the
+	console after an internal error.
+
+2021-08-11  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: register SIGBUS, SIGFPE, and SIGABRT handlers
+	Register handlers for SIGBUS, SIGFPE, and SIGABRT.  All of these
+	signals are setup as fatal signals that will cause GDB to terminate.
+	However, by passing these signals through the handle_fatal_signal
+	function, a user can arrange to see a backtrace when GDB
+	terminates (see maint set backtrace-on-fatal-signal).
+
+	In normal use of GDB there should be no user visible changes after
+	this commit.  Only if GDB terminates with one of the above signals
+	will GDB change slightly, potentially printing a backtrace before
+	aborting.
+
+	I've added new tests for SIGFPE, SIGBUS, and SIGABRT.
+
+2021-08-11  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: print backtrace on fatal SIGSEGV
+	This commit adds a new maintenance feature, the ability to print
+	a (limited) backtrace if GDB dies due to a fatal signal.
+
+	The backtrace is produced using the backtrace and backtrace_symbols_fd
+	functions which are declared in the execinfo.h header, and both of
+	which are async signal safe.  A configure check has been added to
+	check for these features, if they are not available then the new code
+	is not compiled into GDB and the backtrace will not be printed.
+
+	The motivation for this new feature is to aid in debugging GDB in
+	situations where GDB has crashed at a users site, but the user is
+	reluctant to share core files, possibly due to concerns about what
+	might be in the memory image within the core file.  Such a user might
+	be happy to share a simple backtrace that was written to stderr.
+
+	The production of the backtrace is on by default, but can switched off
+	using the new commands:
+
+	  maintenance set backtrace-on-fatal-signal on|off
+	  maintenance show backtrace-on-fatal-signal
+
+	Right now, I have hooked this feature in to GDB's existing handling of
+	SIGSEGV only, but this will be extended to more signals in a later
+	commit.
+
+	One additional change I have made in this commit is that, when we
+	decide GDB should terminate due to the fatal signal, we now
+	raise the same fatal signal rather than raising SIGABRT.
+
+	Currently, this is only effecting our handling of SIGSEGV.  So,
+	previously, if GDB hit a SEGV then we would terminate GDB with a
+	SIGABRT.  After this commit we will terminate GDB with a SIGSEGV.
+
+	This feels like an improvement to me, we should still get a core dump,
+	but in many shells, the user will see a more specific message once GDB
+	exits, in bash for example "Segmentation fault" rather than "Aborted".
+
+	Finally then, here is an example of the output a user would see if GDB
+	should hit an internal SIGSEGV:
+
+	  Fatal signal: Segmentation fault
+	  ----- Backtrace -----
+	  ./gdb/gdb[0x8078e6]
+	  ./gdb/gdb[0x807b20]
+	  /lib64/libpthread.so.0(+0x14b20)[0x7f6648c92b20]
+	  /lib64/libc.so.6(__poll+0x4f)[0x7f66484d3a5f]
+	  ./gdb/gdb[0x1540f4c]
+	  ./gdb/gdb[0x154034a]
+	  ./gdb/gdb[0x9b002d]
+	  ./gdb/gdb[0x9b014d]
+	  ./gdb/gdb[0x9b1aa6]
+	  ./gdb/gdb[0x9b1b0c]
+	  ./gdb/gdb[0x41756d]
+	  /lib64/libc.so.6(__libc_start_main+0xf3)[0x7f66484041a3]
+	  ./gdb/gdb[0x41746e]
+	  ---------------------
+	  A fatal error internal to GDB has been detected, further
+	  debugging is not possible.  GDB will now terminate.
+
+	  This is a bug, please report it.  For instructions, see:
+	  <https://www.gnu.org/software/gdb/bugs/>.
+
+	  Segmentation fault (core dumped)
+
+	It is disappointing that backtrace_symbols_fd does not actually map
+	the addresses back to symbols, this appears, in part, to be due to GDB
+	not being built with -rdynamic as the manual page for
+	backtrace_symbols_fd suggests, however, even when I do add -rdynamic
+	to the build of GDB I only see symbols for some addresses.
+
+	We could potentially look at alternative libraries to provide the
+	backtrace (e.g. libunwind) however, the solution presented here, which
+	is available as part of glibc is probably a good baseline from which
+	we might improve things in future.
+
+2021-08-11  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: rename async_init_signals to gdb_init_signals
+	The async_init_signals has, for some time, dealt with async and sync
+	signals, so removing the async prefix makes sense I think.
+
+	Additionally, as pointed out by Pedro:
+
+	  .....
+
+	The comments relating to SIGTRAP and SIGQUIT within this function are
+	out of date.
+
+	The comments for SIGTRAP talk about the signal disposition (SIG_IGN)
+	being passed to the inferior, meaning the signal disposition being
+	inherited by GDB's fork children.  However, we now call
+	restore_original_signals_state prior to forking, so the comment on
+	SIGTRAP is redundant.
+
+	The comments for SIGQUIT are similarly out of date, further, the
+	comment on SIGQUIT talks about problems with BSD4.3 and vfork,
+	however, we have not supported BSD4.3 for several years now.
+
+	Given the above, it seems that changing the disposition of SIGTRAP is
+	no longer needed, so I've deleted the signal() call for SIGTRAP.
+
+	Finally, the header comment on the function now called
+	gdb_init_signals was getting quite out of date, so I've updated it
+	to (hopefully) better reflect reality.
+
+	There should be no user visible change after this commit.
+
+2021-08-11  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: register signal handler after setting up event token
+	This commit fixes the smallest of small possible bug related to signal
+	handling.  If we look in async_init_signals we see code like this:
+
+	  signal (SIGQUIT, handle_sigquit);
+	  sigquit_token =
+	    create_async_signal_handler (async_do_nothing, NULL, "sigquit");
+
+	Then if we look in handle_sigquit we see code like this:
+
+	  mark_async_signal_handler (sigquit_token);
+	  signal (sig, handle_sigquit);
+
+	Finally, in mark_async_signal_handler we have:
+
+	  async_handler_ptr->ready = 1;
+
+	Where async_handler_ptr will be sigquit_token.
+
+	What this means is that if a SIGQUIT arrive in async_init_signals
+	after handle_sigquit has been registered, but before sigquit_token has
+	been initialised, then GDB will most likely crash.
+
+	The chance of this happening is tiny, but fixing this is trivial, just
+	ensure we call create_async_signal_handler before calling signal, so
+	lets do that.
+
+	There are no tests for this.  Trying to land a signal in the right
+	spot is pretty hit and miss.  I did try changing the current HEAD GDB
+	like this:
+
+	  signal (SIGQUIT, handle_sigquit);
+	  raise (SIGQUIT);
+	  sigquit_token =
+	    create_async_signal_handler (async_do_nothing, NULL, "sigquit");
+
+	And confirmed that this did result in a crash, after my change I tried
+	this:
+
+	  sigquit_token =
+	    create_async_signal_handler (async_do_nothing, NULL, "sigquit");
+	  signal (SIGQUIT, handle_sigquit);
+	  raise (SIGQUIT);
+
+	And GDB now starts up just fine.
+
+	gdb/ChangeLog:
+
+		* event-top.c (async_init_signals): For each signal, call signal
+		only after calling create_async_signal_handler.
+
+2021-08-11  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: terminate upon receipt of SIGFPE
+	GDB's SIGFPE handling is broken, this is PR gdb/16505 and
+	PR gdb/17891.
+
+	We currently try to use an async event token to process SIGFPE.  So,
+	when a SIGFPE arrives the signal handler calls
+	mark_async_signal_handler then returns, effectively ignoring the
+	signal (for now).
+
+	The intention is that later the event loop will see that the async
+	token associated with SIGFPE has been marked and will call the async
+	handler, which just throws an error.
+
+	The problem is that SIGFPE is not safe to ignore.  Ignoring a
+	SIGFPE (unless it is generated artificially, e.g. by raise()) is
+	undefined behaviour, after ignoring the signal on many targets we
+	return to the instruction that caused the SIGFPE to be raised, which
+	immediately causes another SIGFPE to be raised, we get stuck in an
+	infinite loop.  The behaviour is certainly true on x86-64.
+
+	To view this behaviour I simply added some dummy code to GDB that
+	performed an integer divide by zero, compiled this on x86-64
+	GNU/Linux, ran GDB and saw GDB hang.
+
+	In this commit, I propose to remove all special handling of SIGFPE and
+	instead just let GDB make use of the default SIGFPE action, that is,
+	to terminate the process.
+
+	The only user visible change here should be:
+
+	  - If a user sends a SIGFPE to GDB using something like kill,
+	    previously GDB would just print an error and remain alive, now GDB
+	    will terminate.  This is inline with what happens if the user
+	    sends GDB a SIGSEGV from kill though, so I don't see this as an
+	    issue.
+
+	  - If a bug in GDB causes a real SIGFPE, previously the users GDB
+	    session would hang.  Now the GDB session will terminate.  Again,
+	    this is inline with what happens if GDB receives a SIGSEGV due to
+	    an internal bug.
+
+	In bug gdb/16505 there is mention that it would be nice if GDB did
+	more than just terminate when receiving a fatal signal.  I haven't
+	done that in this commit, but later commits will move in that
+	direction.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16505
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17891
+
+2021-08-11  Alan Modra  <amodra@gmail.com>
+
+	PR28198, Support # as linker script comment marker
+		PR 28198
+		* ldlex.l: Combine rules for handling newline, whitespace and
+		comments.  Extend # comment handling to all states.
+
+2021-08-11  Alan Modra  <amodra@gmail.com>
+
+	ldgram.y tidies
+	I've been tripped up before thinking the "end" rule was the "END"
+	token.  Let's use a better name.  The formatting changes are for
+	consistency within rules, and making it a little easier to visually
+	separate tokens from mid-rule actions.
+
+		* ldgram.y (separator): Rename from "end".  Update uses.
+		(statement): Formatting.  Move ';' match to beginning.
+		(paren_script_name): Formatting.  Simplify.
+		(must_be_exp, section): Formatting.
+
+2021-08-11  Alan Modra  <amodra@gmail.com>
+
+	Mention whitespace in script expressions
+	Inside an output section statement, ld's parser can't tell whether a
+	line
+	    .+=4;
+	is an assignment to dot or a file named ".+=4".
+
+		* ld.texi (expressions): Mention need for whitespace.
+
+2021-08-11  Matt Jacobson  <mhjacobson@me.com>
+
+	Add a -mno-dollar-line-separator command line option to the AVR assembler.
+	Some frontends, like the gcc Objective-C frontend, emit symbols with $
+	characters in them.  The AVR target code in gas treats $ as a line separator,
+	so the code doesn?t assemble correctly.
+
+	Provide a machine-specific option to disable treating $ as a line separator.
+
+		* config/tc-avr.c (enum options): Add option flag.
+		(struct option): Add option -mno-dollar-line-separator.
+		(md_parse_option): Adjust treatment of $ when option is present.
+		* config/tc-avr.h: Use avr_line_separator_chars.
+
+2021-08-11  Nick Clifton  <nickc@redhat.com>
+
+	Fix typo in previous delta
+
+2021-08-11  Jan Beulich  <jbeulich@suse.com>
+
+	gas: fold IEEE encoding of -Inf with that of +Inf
+	The respective results differ only by the sign bits - there's no need to
+	have basically identical (partially even arch-specific) logic twice.
+	Simply set the sign bit at the end of encoding the various formats.
+
+2021-08-11  Jan Beulich  <jbeulich@suse.com>
+
+	gas: support NaN flavors
+	Like for infinity, there isn't just a single NaN. The sign bit may be
+	of interest and, going beyond infinity, whether the value is quiet or
+	signalling may be even more relevant to be able to encode.
+
+	Note that an anomaly with x86'es double extended precision NaN values
+	gets taken care of at the same time: For all other formats a positive
+	value with all mantissa bits set was used, while here a negative value
+	with all non-significant mantissa bits clear was chose for an unknown
+	reason.
+
+	For m68k, since I don't know their X_PRECISION floating point value
+	layout, a warning gets issued if any of the new flavors was attempted
+	to be encoded that way. However likely it may be that, given that the
+	code lives in a source file supposedly implementing IEEE-compliant
+	formats, the bit patterns of the individual words match x86'es, I didn't
+	want to guess so. And my very, very old paper doc doesn't even mention
+	floating point formats other than single and double.
+
+2021-08-11  Jan Beulich  <jbeulich@suse.com>
+
+	Arm64: leave .bfloat16 processing to common code
+	With x86 support having been implemented by extending atof-ieee.c, avoid
+	unnecessary code duplication in md_atof(). This will then also allow to
+	take advantage of adjustments made there without needing to mirror them
+	here.
+
+	Arm32: leave more .bfloat16 processing to common code
+	With x86 support having been implemented by extending atof-ieee.c, avoid
+	unnecessary code duplication in md_atof(). This will then also allow to
+	take advantage of adjustments made there without needing to mirror them
+	here.
+
+	gas: make 2nd argument of .dcb.* consistently optional
+	Unlike the forms consuming/producing integer data, the floating point
+	ones so far required the 2nd argument to be present, contrary to
+	documentation. To avoid code duplication, split float_length() out of
+	hex_float() (taking the opportunity to adjust error message wording).
+
+2021-08-11  Jan Beulich  <jbeulich@suse.com>
+
+	x86: introduce .bfloat16 directive
+	This is to be able to generate data acted upon by AVX512-BF16 and
+	AMX-BF16 insns. While not part of the IEEE standard, the format is
+	sufficiently standardized to warrant handling in config/atof-ieee.c.
+	Arm, where custom handling was implemented, may want to leverage this as
+	well. To be able to also use the hex forms supported for other floating
+	point formats, a small addition to the generic hex_float() is needed.
+
+	Extend existing x86 testcases.
+
+2021-08-11  Jan Beulich  <jbeulich@suse.com>
+
+	x86: introduce .hfloat directive
+	This is to be able to generate data passed to {,V}CVTPH2PS and acted
+	upon by AVX512-FP16 insns. To be able to also use the hex forms
+	supported for other floating point formats, a small addition to the
+	generic hex_float() is needed.
+
+	Extend existing x86 testcases.
+
+2021-08-11  Jan Beulich  <jbeulich@suse.com>
+
+	x86/ELF: fix .tfloat output with hex input
+	The ELF psABI-s are quite clear here: On 32-bit the data type is 12
+	bytes long (with 2 bytes of trailing padding), while on 64-bit it is 16
+	bytes long (with 6 bytes of padding). Make hex_float() capable of
+	handling such padding.
+
+	Note that this brings the emitted data size of .dc.x / .dcb.x in line
+	also for non-ELF targets; so far they were different depending on input
+	format (dec vs hex).
+
+	Extend the existing x86 testcases.
+
+2021-08-11  Jan Beulich  <jbeulich@suse.com>
+
+	x86/ELF: fix .ds.x output
+	The ELF psABI-s are quite clear here: On 32-bit the underlying data type
+	is 12 bytes long (with 2 bytes of trailing padding), while on 64-bit it
+	is 16 bytes long (with 6 bytes of padding). Make s_space() capable of
+	handling 'x' (and 'p') type floating point being other than 12 bytes
+	wide (also adjusting documentation). This requires duplicating the
+	definition of X_PRECISION in the target speciifc header; the compiler
+	would complain if this was out of sync with config/atof-ieee.c.
+
+	Note that for now padding space doesn't get separated from actual
+	storage, which means that things will work correctly only for little-
+	endian cases, and which also means that by specifying large enough
+	numbers padding space can be set to non-zero. Since the logic is needed
+	for a single little-endian architecture only for now, I'm hoping that
+	this might be acceptable for the time being; otherwise the change will
+	become more intrusive.
+
+	Note also that this brings the emitted data size of .ds.x vs .tfloat in
+	line for non-ELF targets as well; the issue will be even more obvious
+	when further taking into account a subsequent patch fixing .dc.x/.dcb.x
+	(where output sizes currently differ depending on input format).
+
+	Extend existing x86 testcases.
+
+2021-08-11  Jan Beulich  <jbeulich@suse.com>
+
+	x86/ELF: fix .tfloat output
+	The ELF psABI-s are quite clear here: On 32-bit the data type is 12
+	bytes long (with 2 bytes of trailing padding), while on 64-bit it is 16
+	bytes long (with 6 bytes of padding). Make ieee_md_atof() capable of
+	handling such padding, and specify the needed padding for x86 (leaving
+	non-ELF targets alone for now). Split the existing x86 testcase.
+
+	x86: have non-PE/COFF BEOS be recognized as ELF
+	BEOS, unless explicitly requesting *-*-beospe* targets, uses standard
+	ELF. None of the newly enabled tests in the testsuite fail for me.
+
+2021-08-11  Alan Modra  <amodra@gmail.com>
+
+	PR28163, Segment fault in function rl78_special_reloc
+	Relocation offset checks were completely missing in the rl78 backend,
+	allowing a relocation to write over memory anywhere.  This was true
+	for rl78_special_reloc, a function primarily used when applying debug
+	relocations, and in rl78_elf_relocate_section used by the linker.
+
+	This patch fixes those problems by correcting inaccuracies in the
+	relocation howtos, then uses those howtos to sanity check relocation
+	offsets before applying relocations.  In addition, the patch
+	implements overflow checking using the howto information rather than
+	the ad-hoc scheme implemented in relocate_section.  I implemented the
+	overflow checking in rl78_special_reloc too.
+
+		* elf32-rl78.c (RL78REL, RL78_OP_REL): Add mask parameter.
+		(rl78_elf_howto_table): Set destination masks.  Correct size and
+		bitsize of DIR32_REV.  Correct complain_on_overflow for many relocs
+		as per tests in relocate_section.  Add RH_SFR.  Correct bitsize
+		for RH_SADDR.  Set size to 3 and bitsize to 0 for all OP relocs.
+		(check_overflow): New function.
+		(rl78_special_reloc): Check that reloc address is within section.
+		Apply relocations using reloc howto.  Check for overflow.
+		(RANGE): Delete.
+		(rl78_elf_relocate_section): Sanity check r_offset.  Perform
+		overflow checking using reloc howto.
+
+2021-08-11  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-10  Tom Tromey  <tom@tromey.com>
+
+	Ignore .debug_types when reading .debug_aranges
+	I noticed that the fission-reread.exp test case can cause a complaint
+	when run with --target_board=cc-with-debug-names:
+
+	warning: Section .debug_aranges in [...]/fission-reread has duplicate debug_info_offset 0x0, ignoring .debug_aranges.
+
+	The bug here is that this executable has both .debug_info and
+	.debug_types, and both have a CU at offset 0x0.  This triggers the
+	duplicate warning.
+
+	Because .debug_types doesn't provide any address ranges, these CUs can
+	be ignored.  That is, this bug turns out to be another regression from
+	the info/types merger patch.
+
+	This patch fixes the problem by having this loop igore type units.
+	fission-reread.exp is updated to test for the bug.
+
+2021-08-10  Tom Tromey  <tom@tromey.com>
+
+	Generalize addrmap dumping
+	While debugging another patch series, I wanted to dump an addrmap.  I
+	came up with this patch, which generalizes the addrmap-dumping code
+	from psymtab.c and moves it to addrmap.c.  psymtab.c is changed to use
+	the new code.
+
+2021-08-10  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: iterate only on vfork parent threads in handle_vfork_child_exec_or_exit
+	I spotted what I think is a buglet in proceed_after_vfork_done.  After a
+	vfork child exits or execs, we resume all the threads of the parent.  To
+	do so, we iterate on all threads using iterate_over_threads with the
+	proceed_after_vfork_done callback.  Each thread is resumed if the
+	following condition is true:
+
+	    if (thread->ptid.pid () == pid
+		&& thread->state == THREAD_RUNNING
+		&& !thread->executing
+		&& !thread->stop_requested
+		&& thread->stop_signal () == GDB_SIGNAL_0)
+
+	where `pid` is the pid of the vfork parent.  This is not multi-target
+	aware: since it only filters on pid, if there is an inferior with the
+	same pid in another target, we could end up resuming a thread of that
+	other inferior.  The chances of the stars aligning for this to happen
+	are tiny, but still.
+
+	Fix that by iterating only on the vfork parent's threads, instead of on
+	all threads.  This is more efficient, as we iterate on just the required
+	threads (inferiors have their own thread list), and we can drop the pid
+	check.  The resulting code is also more straightforward in my opinion,
+	so it's a win-win.
+
+	Change-Id: I14647da72e2bf65592e82fbe6efb77a413a4be3a
+
+2021-08-10  Nick Clifton  <nickc@redhat.com>
+
+	Updated Serbian and Russian translations for various sub-directories
+
+2021-08-10  George Barrett  <bob@bob131.so>
+
+	guile: fix smob exports
+	Before Guile v2.1 [1], calls to `scm_make_smob_type' implicitly added
+	the created class to the exports list of (oop goops); v2.1+ does not
+	implicitly create bindings in any modules. This means that the GDB
+	manual subsection documenting exported types is not quite right when GDB
+	is linked against Guile <v2.1 (types are exported from (oop goops))
+	instead of (gdb)) and incorrect when linked against Guile v2.1+ (types
+	are not bound to any variables at all!).
+
+	There is a range of cases in which it's necessary or convenient to be
+	able to refer to a GDB smob type, for instance:
+
+	 - Pattern matching based on the type of a value.
+	 - Defining GOOPS methods handling values from GDB (GOOPS methods
+	   typically use dynamic dispatch based on the types of the arguments).
+	 - Type-checking assertions when applying some defensive programming on
+	   an interface.
+	 - Generally any other situation one might encounter in a dynamically
+	   typed language that might need some introspection.
+
+	If you're more familiar with Python, it would be quite similar to being
+	unable to refer to the classes exported from the GDB module (which is to
+	say: not crippling for the most part, but makes certain tasks more
+	difficult than necessary).
+
+	This commit makes a small change to GDB's smob registration machinery
+	to make sure registered smobs get exported from the current
+	module. This will likely cause warnings to the user about conflicting
+	exports if they load both (gdb) and (oop goops) from a GDB linked
+	against Guile v2.0, but it shouldn't impact functionality (and seemed
+	preferable to trying to un-export bindings from (oop goops) if v2.0
+	was detected).
+
+	[1]: This changed with Guile commit
+	     28d0871b553a3959a6c59e2e4caec1c1509f8595
+
+	gdb/ChangeLog:
+
+	2021-06-07  George Barrett  <bob@bob131.so>
+
+		* guile/scm-gsmob.c (gdbscm_make_smob_type): Export registered
+		smob type from the current module.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-06-07  George Barrett  <bob@bob131.so>
+
+		* gdb.guile/scm-gsmob.exp (test exports): Add tests to make
+		sure the smob types currently listed in the GDB manual get
+		exported from the (gdb) module.
+
+	Change-Id: I7dcd791276b48dfc9edb64fc71170bbb42a6f6e7
+
+2021-08-10  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-09  Nick Clifton  <nickc@redhat.com>
+
+	GAS: DWARF-5: Ensure that the 0'th entry in the directory table contains the current working directory.
+		* dwarf2dbg.c (get_directory_table_entry): Ensure that dir[0]
+		contains current working directory.
+		(out_dir_and_file_list): Likewise.
+		* testsuite/gas/elf/dwarf-5-dir0.s: New test source file.
+		* testsuite/gas/elf/dwarf-5-dir0.d: New test driver.
+		* testsuite/gas/elf/elf.exp: Run the new test.
+		* testsuite/gas/elf/dwarf-5-file0.d: Adjust expected output.
+		* testsuite/gas/i386/dwarf5-line-1.d: Likewise.
+		* testsuite/gas/i386/dwarf5-line-2.d: Likewise.
+
+2021-08-09  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-08  Tom Tromey  <tom@tromey.com>
+
+	Include objfiles.h in a few .c files
+	I found a few .c files that rely on objfiles.h, but that only include
+	it indirectly, via dwarf2/read.h -> psympriv.h.  If that include is
+	removed (something my new DWARF indexer series does), then the build
+	will break.
+
+	It seemed harmless and correct to add these includes now, making the
+	eventual series a little smaller.
+
+2021-08-08  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-07  Alan Modra  <amodra@gmail.com>
+
+	PR28186, SEGV elf.c:7991:30 in _bfd_elf_fixup_group_sections
+		PR 28186
+		* elf.c (_bfd_elf_fixup_group_sections): Don't segfault on
+		objcopy/strip with NULL output_section.
+
+2021-08-07  Alan Modra  <amodra@gmail.com>
+
+	PR28176, rl78 complex reloc divide by zero
+	This is a bit more than just preventing the divide by zero.  Most of
+	the patch is tidying up error reporting, so that for example, linking
+	an object file with a reloc stack underflow produces a linker error
+	rather than just displaying a message that might be ignored.
+
+		PR 28176
+		* elf32-rl78.c (RL78_STACK_PUSH, RL78_STACK_POP): Delete.
+		(rl78_stack_push, rl78_stack_pop): New inline functions.
+		(rl78_compute_complex_reloc): Add status and error message params.
+		Use new inline stack handling functions.  Report stack overflow
+		or underflow, and divide by zero.
+		(rl78_special_reloc): Return status and error message from
+		rl78_compute_complex_reloc.
+		(rl78_elf_relocate_section): Similarly.  Modernise reloc error
+		reporting.  Delete unused bfd_reloc_other case.  Don't assume
+		DIR24S_PCREL overflow is due to undefined function.
+		(rl78_offset_for_reloc): Adjust to suit rl78_compute_complex_reloc.
+
+2021-08-07  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-06  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/symtab] Recognize .gdb_index symbol table with empty entries as empty
+	When reading a .gdb_index that contains a non-empty symbol table with only
+	empty entries, gdb doesn't recognize it as empty.
+
+	Fix this by recognizing that the constant pool is empty, and then setting the
+	symbol table to empty.
+
+	Tested on x86_64-linux.
+
+	gdb/ChangeLog:
+
+	2021-08-01  Tom de Vries  <tdevries@suse.de>
+
+		PR symtab/28159
+		* dwarf2/read.c (read_gdb_index_from_buffer): Handle symbol table
+		filled with empty entries.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-08-01  Tom de Vries  <tdevries@suse.de>
+
+		PR symtab/28159
+		* gdb.dwarf2/dw2-zero-range.exp: Remove kfail.
+
+2021-08-06  Tom Tromey  <tromey@adacore.com>
+
+	Unconditionally define _initialize_addrmap
+	The way that init.c is generated does not allow for an initialization
+	function to be conditionally defined -- doing so will result in a link
+	error.
+
+	This patch fixes a build problem that arises from such a conditional
+	definition.  It can be reproduce with --disable-unit-tests.
+
+2021-08-06  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/symtab] Fix zero address complaint for shlib
+	In PR28004 the following warning / Internal error is reported:
+	...
+	$ gdb -q -batch \
+	    -iex "set sysroot $(pwd -P)/repro" \
+	    ./repro/gdb \
+	    ./repro/core \
+	    -ex bt
+	  ...
+	 Program terminated with signal SIGABRT, Aborted.
+	 #0  0x00007ff8fe8e5d22 in raise () from repro/usr/lib/libc.so.6
+	 [Current thread is 1 (LWP 1762498)]
+	 #1  0x00007ff8fe8cf862 in abort () from repro/usr/lib/libc.so.6
+	 warning: (Internal error: pc 0x7ff8feb2c21d in read in psymtab, \
+	           but not in symtab.)
+	 warning: (Internal error: pc 0x7ff8feb2c218 in read in psymtab, \
+	           but not in symtab.)
+	  ...
+	 #2  0x00007ff8feb2c21e in __gnu_debug::_Error_formatter::_M_error() const \
+	   [clone .cold] (warning: (Internal error: pc 0x7ff8feb2c21d in read in \
+	   psymtab, but not in symtab.)
+
+	) from repro/usr/lib/libstdc++.so.6
+	...
+
+	The warning is about the following:
+	- in find_pc_sect_compunit_symtab we try to find the address
+	  (0x7ff8feb2c218 / 0x7ff8feb2c21d) in the symtabs.
+	- that fails, so we try again in the partial symtabs.
+	- we find a matching partial symtab
+	- however, the partial symtab has a full symtab, so
+	  we should have found a matching symtab in the first step.
+
+	The addresses are:
+	...
+	(gdb) info sym 0x7ff8feb2c218
+	__gnu_debug::_Error_formatter::_M_error() const [clone .cold] in \
+	  section .text of repro/usr/lib/libstdc++.so.6
+	(gdb) info sym 0x7ff8feb2c21d
+	__gnu_debug::_Error_formatter::_M_error() const [clone .cold] + 5 in \
+	  section .text of repro/usr/lib/libstdc++.so.6
+	...
+	which correspond to unrelocated addresses 0x9c218 and 0x9c21d:
+	...
+	$ nm -C  repro/usr/lib/libstdc++.so.6.0.29 | grep 000000000009c218
+	000000000009c218 t __gnu_debug::_Error_formatter::_M_error() const \
+	  [clone .cold]
+	...
+	which belong to function __gnu_debug::_Error_formatter::_M_error() in
+	/build/gcc/src/gcc/libstdc++-v3/src/c++11/debug.cc.
+
+	The partial symtab that is found for the addresses is instead the one for
+	/build/gcc/src/gcc/libstdc++-v3/src/c++98/bitmap_allocator.cc, which is
+	incorrect.
+
+	This happens as follows.
+
+	The bitmap_allocator.cc CU has DW_AT_ranges at .debug_rnglist offset 0x4b50:
+	...
+	    00004b50 0000000000000000 0000000000000056
+	    00004b5a 00000000000a4790 00000000000a479c
+	    00004b64 00000000000a47a0 00000000000a47ac
+	...
+
+	When reading the first range 0x0..0x56, it doesn't trigger the "start address
+	of zero" complaint here:
+	...
+	      /* A not-uncommon case of bad debug info.
+	         Don't pollute the addrmap with bad data.  */
+	      if (range_beginning + baseaddr == 0
+	          && !per_objfile->per_bfd->has_section_at_zero)
+	        {
+	          complaint (_(".debug_rnglists entry has start address of zero"
+	                       " [in module %s]"), objfile_name (objfile));
+	          continue;
+	        }
+	...
+	because baseaddr != 0, which seems incorrect given that when loading the
+	shared library individually in gdb (and consequently baseaddr == 0), we do see
+	the complaint.
+
+	Consequently, we run into this case in dwarf2_get_pc_bounds:
+	...
+	  if (low == 0 && !per_objfile->per_bfd->has_section_at_zero)
+	    return PC_BOUNDS_INVALID;
+	...
+	which then results in this code in process_psymtab_comp_unit_reader being
+	called with cu_bounds_kind == PC_BOUNDS_INVALID, which sets the set_addrmap
+	argument to 1:
+	...
+	      scan_partial_symbols (first_die, &lowpc, &highpc,
+	                            cu_bounds_kind <= PC_BOUNDS_INVALID, cu);
+	...
+	and consequently, the CU addrmap gets build using address info from the
+	functions.
+
+	During that process, addrmap_set_empty is called with a range that includes
+	0x9c218 and 0x9c21d:
+	...
+	(gdb) p /x start
+	$7 = 0x9989c
+	(gdb) p /x end_inclusive
+	$8 = 0xb200d
+	...
+	but it's called for a function at DIE 0x54153 with DW_AT_ranges at 0x40ae:
+	...
+	    000040ae 00000000000b1ee0 00000000000b200e
+	    000040b9 000000000009989c 00000000000998c4
+	    000040c3 <End of list>
+	...
+	and neither range includes 0x9c218 and 0x9c21d.
+
+	This is caused by this code in partial_die_info::read:
+	...
+	            if (dwarf2_ranges_read (ranges_offset, &lowpc, &highpc, cu,
+	                                    nullptr, tag))
+	             has_pc_info = 1;
+	...
+	which pretends that the function is located at addresses 0x9989c..0xb200d,
+	which is indeed not the case.
+
+	This patch fixes the first problem encountered: fix the "start address of
+	zero" complaint warning by removing the baseaddr part from the condition.
+	Same for dwarf2_ranges_process.
+
+	The effect is that:
+	- the complaint is triggered, and
+	- the warning / Internal error is no longer triggered.
+
+	This does not fix the observed problem in partial_die_info::read, which is
+	filed as PR28200.
+
+	Tested on x86_64-linux.
+
+	Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca>
+
+	gdb/ChangeLog:
+
+	2021-07-29  Simon Marchi  <simon.marchi@polymtl.ca>
+		    Tom de Vries  <tdevries@suse.de>
+
+		PR symtab/28004
+		* gdb/dwarf2/read.c (dwarf2_rnglists_process, dwarf2_ranges_process):
+		Fix zero address complaint.
+		* gdb/testsuite/gdb.dwarf2/dw2-zero-range-shlib.c: New test.
+		* gdb/testsuite/gdb.dwarf2/dw2-zero-range.c: New test.
+		* gdb/testsuite/gdb.dwarf2/dw2-zero-range.exp: New file.
+
+2021-08-06  Alan Modra  <amodra@gmail.com>
+
+	Re: Add tests for Intel AVX512_FP16 instructions
+		* testsuite/gas/i386/x86-64-avx512_fp16_pseudo_ops.d: Pass with
+		mingw section padding.
+
+2021-08-06  Alan Modra  <amodra@gmail.com>
+
+	chew ubsan warning
+	It matters not at all if pc is incremented from its initial NULL
+	value, but avoid this silly runtime ubsan error.
+
+		* doc/chew.c (perform): Avoid incrementing NULL pc.
+
+2021-08-06  Alan Modra  <amodra@gmail.com>
+
+	bfd_reloc_offset_in_range overflow
+	This patch is more about the style of bounds checking we ought to use,
+	rather than a real problem.  An overflow of "octet + reloc_size" can
+	only happen with huge sections which would certainly cause out of
+	memory errors.
+
+		* reloc.c (bfd_reloc_offset_in_range): Avoid possible overflow.
+
+2021-08-06  Alan Modra  <amodra@gmail.com>
+
+	PR28175, Segment fault in coff-tic30.c reloc_processing
+	The obj_convert table shouldn't be accessed without first checking the
+	index against the table size.
+
+		PR 28175
+		* coff-tic30.c (reloc_processing): Sanity check reloc symbol index.
+		* coff-z80.c (reloc_processing): Likewise.
+		* coff-z8k.c (reloc_processing): Likewise.
+
+2021-08-06  Alan Modra  <amodra@gmail.com>
+
+	PR28173, nds32_elf_howto_table index out of bounds
+	Indexing the howto table was seriously broken by a missing entry, and
+	use of assertions about user input rather than testing the input.
+
+		PR 28173
+		* elf32-nds32.c (nds32_elf_howto_table): Add missing empty howto.
+		(bfd_elf32_bfd_reloc_type_table_lookup): Replace assertions with
+		range checks.  Return NULL if unsupported reloc type.  Remove
+		dead code.  Take an unsigned int param.
+		(nds32_info_to_howto_rel): Test for NULL howto or howto name
+		return from lookup.  Remove assertion.
+		(nds32_info_to_howto): Remove unnecessary ATTRIBUTE_UNUSED.
+		Test for NULL howto or howto name return from lookup.
+
+2021-08-06  Alan Modra  <amodra@gmail.com>
+
+	PR28172, bfin_pcrel24_reloc heap-buffer-overflow
+	bfin pcrel24 relocs are weird, they apply to the reloc address minus
+	two.  That means reloc addresses of 0 and 1 are invalid.  Check that,
+	and fix other reloc range checking.
+
+		PR 28172
+		* elf32-bfin.c (bfin_pcrel24_reloc): Correct reloc range check.
+		(bfin_imm16_reloc, bfin_byte4_reloc, bfin_bfd_reloc): Likewise.
+		(bfin_final_link_relocate): Likewise.
+
+2021-08-06  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-05  Will Schmidt  <will_schmidt@vnet.ibm.com>
+
+	[PATCH] GDB Testsuite, update compile-cplus.exp
+	[PATCH] GDB Testsuite, update compile-cplus.exp
+
+	Update the gdb.compile/compile-cplus.exp test to
+	handle errors generated when passing bad arguments
+	into the gdb-compile command.
+	This matches changes made to gdb.compile/compile.exp
+	in the past as part of
+	"Migrate rest of compile commands to new options framework"
+	         e6ed716cd5514c08b9d7c469d185b1aa177dbc22
+
+2021-08-05  Will Schmidt  <will_schmidt@vnet.ibm.com>
+
+	[gdb] Handle .TOC. sections during gdb-compile for rs6000 target.
+	[gdb] Handle .TOC. sections during gdb-compile for rs6000 target.
+
+	  When we encounter a .TOC. symbol in the object we are loading,
+	we need to associate this with the .toc section in order to
+	properly resolve other symbols in the object.  IF a .toc section
+	is not found, iterate the sections until we find one with the
+	SEC_ALLOC flag.  If that also fails, fall back to using
+	the *ABS* section, pointed to by bfd_abs_section_ptr.
+
+2021-08-05  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/testsuite: gdb.base/attach.exp: expose bug when testing with native-extended-gdbserver
+	In gdb.base/attach.exp, proc do_attach_failure_tests, we attach to a
+	process.  When then try to attach to the same process in another
+	inferior, expecting it to fail.  We then come back to the first inferior
+	and try to kill it, to clean up the test.  When using the
+	native-extended-gdbserver board, this "kill" test passes, even though it
+	didn't actually work:
+
+	    add-inferior
+	    [New inferior 2]
+	    Added inferior 2 on connection 1 (extended-remote localhost:2347)
+	    (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: add empty inferior 2
+	    inferior 2
+	    [Switching to inferior 2 [<null>] (<noexec>)]
+	    (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: switch to inferior 2
+	    attach 817032
+	    Attaching to process 817032
+	    Attaching to process 817032 failed
+	    (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: fail to attach again
+	    inferior 1
+	    [Switching to inferior 1 [process 817032] (/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/attach/attach)]
+	    [Switching to thread 1.1 (Thread 817032.817032)]
+	    #0  main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/attach.c:19
+	    19	  while (! should_exit)
+	    (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: switch to inferior 1
+	    kill
+	    Kill the program being debugged? (y or n) y
+	    Remote connection closed  <==== That's unexpected
+	    (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: exit after attach failures
+
+	When the second attach fails, gdbserver seems to break the connection
+	(it hangs up on the existing remote target) and start listening again
+	for incoming connections.  This is documented in PR 19558 [1].
+
+	Make the expected output regexp for the kill command tighter (it
+	currently accepts anything).  Use "set confirm off" so we don't have to
+	deal with the confirmation.  And to be really sure the extended-remote
+	target still works, try to run the inferior again after killing.  The
+	now tests are kfail'ed when the target is gdbserver.
+
+	[1] https://sourceware.org/bugzilla/show_bug.cgi?id=19558
+
+	gdb/testsuite/ChangeLog:
+
+		* gdb.base/attach.exp (do_attach_failure_tests): Make kill
+		regexp tighter, run inferior after killing it.  Kfail when
+		target is gdbserver.
+
+	Change-Id: I99c5cd3968ce2ec962ace35b016f842a243b7a0d
+
+2021-08-05  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/testsuite: gdb.base/attach.exp: fix support check in test_command_line_attach_run
+	When running this test with the native-extended-gdbserver, we get:
+
+	    main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/attach.c:19
+	    19	  while (! should_exit)
+	    The program being debugged has been started already.
+	    Start it from the beginning? (y or n) PASS: gdb.base/attach.exp: cmdline attach run: run to prompt
+	    y
+	    Don't know how to run.  Try "help target".
+	    (gdb) FAIL: gdb.base/attach.exp: cmdline attach run: run to main
+
+	This test tests using both "-p <pid>" and "-ex start" on the command line,
+	making sure that we first attach and then run.
+
+	Normally, after that "y", we should see the program running again.
+	However, a particuliarity of the native-extended-gdbserver is that it
+	uses "set auto-connect-native-target off" on the command line.  The full
+	GDB command line is:
+
+	    ./gdb -nw -nx -data-directory /home/simark/build/binutils-gdb/gdb/testsuite/../data-directory \
+	          -iex set height 0 -iex set width 0 -ex set auto-connect-native-target off \
+		  -ex set sysroot -quiet -iex set height 0 -iex set width 0 --pid=536609 -ex start
+
+	The attach succeeds.  I guess it is done before "set
+	auto-connect-native-target off", or it somehow bypasses it.  When the
+	"start" is executed, the native target is unpushed, while killing the
+	existing process, but not re-pushed, due to "set
+	auto-connect-native-target off".  So we get that "Don't know how to run"
+	message.
+
+	Really, I think it's a case of the test doing things incompatible with
+	the board, I think it should just be skipped.  And as we can see with
+	the current code, there were some attempts at doing this, just using the
+	wrong checks:
+
+	 - isnative: this is a dejagnu proc which checks if the target board has
+	   the same triplet as the build machine.  In the case of
+	   native-extended-gdbserver, it does.
+	 - is_remote target: this checks whether the target board is remote, as
+	   in executing on a different machin.  native-extended-gdbserver is not
+	   remote.
+
+	Since the --pid option specifically attaches to a process using the
+	native target, change the test to use gdb_is_target_native instead.
+
+	gdb/testsuite/ChangeLog:
+
+		* gdb.base/attach.exp (test_command_line_attach_run): Use
+		gdb_is_target_native to check if test is supported.
+
+	Change-Id: I762e127f39623889999dc9ed2185540a0951bfb0
+
+2021-08-05  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: target_waitstatus_to_string: print extra info for FORKED, VFORKED, EXECD
+	Print the extra information contained in target_waitstatus for these
+	events.  For TARGET_WAITKIND_{FORKED,VFORKED}, the extra information is
+	contained in related_pid, and is the ptid of the new process.  For
+	TARGET_WAITKIND_EXECD, it,s the exec'd path name in execd_pathname.
+	Print it using the same format used for TARGET_WAITKIND_STOPPED and
+	others.
+
+	Here are sample outputs for all three events:
+
+	    [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
+	    [infrun] print_target_wait_results:   726890.726890.0 [process 726890],
+	    [infrun] print_target_wait_results:   status->kind = vforked, related_pid = 726894.726894.0
+
+	    [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
+	    [infrun] print_target_wait_results:   727045.727045.0 [process 727045],
+	    [infrun] print_target_wait_results:   status->kind = forked, related_pid = 727049.727049.0
+
+	    [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
+	    [infrun] print_target_wait_results:   727119.727119.0 [process 727119],
+	    [infrun] print_target_wait_results:   status->kind = execd, execd_pathname = /usr/bin/ls
+
+	Change-Id: I4416a74e3bf792a625a68bf26c51689e170f2184
+
+2021-08-05  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: use ptid_t::to_string in print_target_wait_results
+	The ptid_t::to_string method was introduced recently, to format a ptid_t
+	for debug purposes.  It formats the ptid exactly as is done in
+	print_target_wait_results, so make print_target_wait_results use it.
+
+	Change-Id: I0a81c8040d3e1858fb304cb28366b34d94eefe4d
+
+2021-08-05  Zoran Zaric  <Zoran.Zaric@amd.com>
+
+	Add as_lval argument to expression evaluator
+	There are cases where the result of the expression evaluation is
+	expected to be in a form of a value and not location description.
+
+	One place that has this requirement is dwarf_entry_parameter_to_value
+	function, but more are expected in the future. Until now, this
+	requirement was fulfilled by extending the evaluated expression with
+	a DW_OP_stack_value operation at the end.
+
+	New implementation, introduces a new evaluation argument instead.
+
+		* dwarf2/expr.c (dwarf_expr_context::fetch_result): Add as_lval
+		argument.
+		(dwarf_expr_context::eval_exp): Add as_lval argument.
+		* dwarf2/expr.h (struct dwarf_expr_context): Add as_lval
+		argument to fetch_result and eval_exp methods.
+		* dwarf2/frame.c (execute_stack_op): Add as_lval argument.
+		* dwarf2/loc.c (dwarf_entry_parameter_to_value): Remove
+		DWARF expression extension.
+		(dwarf2_evaluate_loc_desc_full): Add as_lval argument support.
+		(dwarf2_evaluate_loc_desc): Add as_lval argument support.
+		(dwarf2_locexpr_baton_eval): Add as_lval argument support.
+
+2021-08-05  Zoran Zaric  <zoran.zaric@amd.com>
+
+	Simplify dwarf_expr_context class interface
+	Idea of this patch is to get a clean and simple public interface for
+	the dwarf_expr_context class, looking like:
+
+	- constructor,
+	- destructor,
+	- push_address method and
+	- evaluate method.
+
+	Where constructor should only ever require a target architecture
+	information. This information is held in per object file
+	(dwarf2_per_objfile) structure, so it makes sense to keep that
+	structure as a constructor argument. It also makes sense to get the
+	address size from that structure, but unfortunately that interface
+	doesn't exist at the moment, so the dwarf_expr_context class user
+	needs to provide that information.
+
+	The push_address method is used to push a CORE_ADDR as a value on
+	top of the DWARF stack before the evaluation. This method can be
+	later changed to push any struct value object on the stack.
+
+	The evaluate method is the method that evaluates a DWARF expression
+	and provides the evaluation result, in a form of a single struct
+	value object that describes a location. To do this, the method requires
+	a context of the evaluation, as well as expected result type
+	information. If the type information is not provided, the DWARF generic
+	type will be used instead.
+
+	To avoid storing the gdbarch information in the evaluator object, that
+	information is now always acquired from the per_objfile object.
+
+	All data members are now private and only visible to the evaluator
+	class, so a m_ prefix was added to all of their names to reflect that.
+	To make this distinction clear, they are also accessed through objects
+	this pointer, wherever that was not the case before.
+
+	gdb/ChangeLog:
+
+		* dwarf2/expr.c (dwarf_expr_context::dwarf_expr_context): Add
+		address size argument.
+		(dwarf_expr_context::read_mem): Change to use property_addr_info
+		structure.
+		(dwarf_expr_context::evaluate): New function.
+		(dwarf_expr_context::execute_stack_op): Change to use
+		property_addr_info structure.
+		* dwarf2/expr.h (struct dwarf_expr_context): New evaluate
+		declaration. Change eval and fetch_result method to private.
+	        (dwarf_expr_context::gdbarch): Remove member.
+	        (dwarf_expr_context::stack): Make private and add m_ prefix.
+	        (dwarf_expr_context::addr_size): Make private and add
+	        m_ prefix.
+	        (dwarf_expr_context::recursion_depth): Make private and add
+	        m_ prefix.
+	        (dwarf_expr_context::max_recursion_depth): Make private and
+	        add m_ prefix.
+	        (dwarf_expr_context::len): Make private and add m_ prefix.
+	        (dwarf_expr_context::data): Make private and add m_ prefix.
+	        (dwarf_expr_context::initialized): Make private and add
+	        m_ prefix.
+	        (dwarf_expr_context::pieces): Make private and add m_ prefix.
+	        (dwarf_expr_context::per_objfile): Make private and add
+	        m_ prefix.
+	        (dwarf_expr_context::frame): Make private and add m_ prefix.
+	        (dwarf_expr_context::per_cu): Make private and add m_ prefix.
+	        (dwarf_expr_context::addr_info): Make private and add
+	        m_ prefix.
+		* dwarf2/frame.c (execute_stack_op): Change to call evaluate
+		method.
+		* dwarf2/loc.c (dwarf2_evaluate_loc_desc_full): Change to call
+		evaluate method.
+		(dwarf2_locexpr_baton_eval): Change to call evaluate method.
+
+2021-08-05  Zoran Zaric  <zoran.zaric@amd.com>
+
+	Make DWARF evaluator return a single struct value
+	The patch is addressing the issue of class users writing and reading
+	the internal data of the dwarf_expr_context class.
+
+	At this point, all conditions are met for the DWARF evaluator to return
+	an evaluation result in a form of a single struct value object.
+
+	gdb/ChangeLog:
+
+		* dwarf2/expr.c (pieced_value_funcs): Chenge to static
+		function.
+		(allocate_piece_closure): Change to static function.
+		(dwarf_expr_context::fetch_result): New function.
+		* dwarf2/expr.h (struct piece_closure): Remove declaration.
+		(struct dwarf_expr_context): fetch_result new declaration.
+		fetch, fetch_address and fetch_in_stack_memory members move
+		to private.
+		(allocate_piece_closure): Remove.
+		* dwarf2/frame.c (execute_stack_op): Change to use
+		fetch_result.
+		* dwarf2/loc.c (dwarf2_evaluate_loc_desc_full): Change to use
+		fetch_result.
+		(dwarf2_locexpr_baton_eval): Change to use fetch_result.
+	        * dwarf2/loc.h (invalid_synthetic_pointer): Expose function.
+
+2021-08-05  Zoran Zaric  <Zoran.Zaric@amd.com>
+
+	Make value_copy also copy the stack data member
+	Fixing a bug where the value_copy function did not copy the stack data
+	and initialized members of the struct value. This is needed for the
+	next patch where the DWARF expression evaluator is changed to return a
+	single struct value object.
+
+	        * value.c (value_copy): Change to also copy the stack data
+	          and initialized members.
+
+2021-08-05  Zoran Zaric  <zoran.zaric@amd.com>
+
+	Move piece_closure and its support to expr.c
+	Following 5 patches series is trying to clean up the interface of the
+	DWARF expression evaluator class (dwarf_expr_context).
+
+	After merging all expression evaluators into one class, the next
+	logical step is to make a clean user interface for that class. To do
+	that, we first need to address the issue of class users writing and
+	reading the internal data of the class directly.
+
+	Fixing the case of writing is simple, it makes sense for an evaluator
+	instance to be per architecture basis. Currently, the best separation
+	seems to be per object file, so having that data (dwarf2_per_objfile)
+	as a constructor argument makes sense. It also makes sense to get the
+	address size from that object file, but unfortunately that interface
+	does not exist at the moment.
+
+	Luckily, address size information is already available to the users
+	through other means. As a result, the address size also needs to be a
+	class constructor argument, at least until a better interface for
+	acquiring that information from an object file is implemented.
+
+	The rest of the user written data comes down to a context of an
+	evaluated expression (compilation unit context, frame context and
+	passed in buffer context) and a source type information that a result
+	of evaluating expression is representing. So, it makes sense for all of
+	these to be arguments of an evaluation method.
+
+	To address the problem of reading the dwarf_expr_context class
+	internal data, we first need to understand why it is implemented that
+	way?
+
+	This is actualy a question of which existing class can be used to
+	represent both values and a location descriptions and why it is not
+	used currently?
+
+	The answer is in a struct value class/structure, but the problem is
+	that before the evaluators were merged, only one evaluator had an
+	infrastructure to resolve composite and implicit pointer location
+	descriptions.
+
+	After the merge, we are now able to use the struct value to represent
+	any result of the expression evaluation. It also makes sense to move
+	all infrastructure for those location descriptions to the expr.c file
+	considering that that is the only place using that infrastructure.
+
+	What we are left with in the end is a clean public interface of the
+	dwarf_expr_context class containing:
+
+	- constructor,
+	- destructor,
+	- push_address method and
+	- eval_exp method.
+
+	The idea with this particular patch is to move piece_closure structure
+	and the interface that handles it (lval_funcs) to expr.c file.
+
+	While implicit pointer location descriptions are still not useful in
+	the CFI context (of the AMD's DWARF standard extensions), the composite
+	location descriptions are certainly necessary to describe a results of
+	specific compiler optimizations.
+
+	Considering that a piece_closure structure is used to represent both,
+	there was no benefit in splitting them.
+
+	gdb/ChangeLog:
+
+		* dwarf2/expr.c (struct piece_closure): Add from loc.c.
+		(allocate_piece_closure): Add from loc.c.
+		(bits_to_bytes): Add from loc.c.
+		(rw_pieced_value): Add from loc.c.
+		(read_pieced_value): Add from loc.c.
+		(write_pieced_value): Add from loc.c.
+		(check_pieced_synthetic_pointer): Add from loc.c.
+		(indirect_pieced_value): Add from loc.c.
+		(coerce_pieced_ref): Add from loc.c.
+		(copy_pieced_value_closure): Add from loc.c.
+		(free_pieced_value_closure): Add from loc.c.
+		(sect_variable_value): Add from loc.c.
+		* dwarf2/loc.c (sect_variable_value): Move to expr.c.
+		(struct piece_closure): Move to expr.c.
+		(allocate_piece_closure): Move to expr.c.
+		(bits_to_bytes): Move to expr.c.
+		(rw_pieced_value): Move to expr.c.
+		(read_pieced_value): Move to expr.c.
+		(write_pieced_value): Move to expr.c.
+		(check_pieced_synthetic_pointer): Move to expr.c.
+		(indirect_pieced_value): Move to expr.c.
+		(coerce_pieced_ref): Move to expr.c.
+		(copy_pieced_value_closure): Move to expr.c.
+		(free_pieced_value_closure): Move to expr.c.
+
+2021-08-05  Zoran Zaric  <zoran.zaric@amd.com>
+
+	Merge evaluate_for_locexpr_baton evaluator
+	The evaluate_for_locexpr_baton is the last derived class from the
+	dwarf_expr_context class. It's purpose is to support the passed in
+	buffer functionality.
+
+	Although, it is not really necessary to merge this class with it's
+	base class, doing that simplifies new expression evaluator design.
+
+	Considering that this functionality is going around the DWARF standard,
+	it is also reasonable to expect that with a new evaluator design and
+	extending the push object address functionality to accept any location
+	description, there will be no need to support passed in buffers.
+
+	Alternatively, it would also makes sense to abstract the interaction
+	between the evaluator and a given resource in the near future. The
+	passed in buffer would then be a specialization of that abstraction.
+
+	gdb/ChangeLog:
+
+		* dwarf2/expr.c (dwarf_expr_context::read_mem): Merge with
+		evaluate_for_locexpr_baton implementation.
+		* dwarf2/loc.c (class evaluate_for_locexpr_baton): Remove
+		class.
+		(evaluate_for_locexpr_baton::read_mem): Move to
+		dwarf_expr_context.
+		(dwarf2_locexpr_baton_eval): Instantiate dwarf_expr_context
+		instead of evaluate_for_locexpr_baton class.
+
+2021-08-05  Zoran Zaric  <zoran.zaric@amd.com>
+
+	Remove empty frame and full evaluators
+	There are no virtual methods that require different specialization in
+	dwarf_expr_context class. This means that derived classes
+	dwarf_expr_executor and dwarf_evaluate_loc_desc are not needed any
+	more.
+
+	As a result of this, the  evaluate_for_locexpr_baton class base class
+	is now the dwarf_expr_context class.
+
+	There might be a need for a better class hierarchy when we know more
+	about the direction of the future DWARF versions and gdb extensions,
+	but that is out of the scope of this patch series.
+
+	gdb/ChangeLog:
+
+		* dwarf2/frame.c (class dwarf_expr_executor): Remove class.
+		(execute_stack_op): Instantiate dwarf_expr_context instead of
+		dwarf_evaluate_loc_desc class.
+		* dwarf2/loc.c (class dwarf_evaluate_loc_desc): Remove class.
+		(dwarf2_evaluate_loc_desc_full): Instantiate dwarf_expr_context
+		instead of dwarf_evaluate_loc_desc class.
+		(struct evaluate_for_locexpr_baton): Derive from
+		dwarf_expr_context.
+
+2021-08-05  Zoran Zaric  <Zoran.Zaric@amd.com>
+
+	Inline get_reg_value method of dwarf_expr_context
+	The get_reg_value method is a small function that is only called once,
+	so it can be inlined to simplify the dwarf_expr_context class.
+
+	gdb/ChangeLog:
+
+		* dwarf2/expr.c (dwarf_expr_context::get_reg_value): Remove
+		method.
+		(dwarf_expr_context::execute_stack_op): Inline get_reg_value
+		method.
+		* dwarf2/expr.h (dwarf_expr_context::get_reg_value): Remove
+		method.
+
+2021-08-05  Zoran Zaric  <zoran.zaric@amd.com>
+
+	Move push_dwarf_reg_entry_value to expr.c
+	Following the idea of merging the evaluators, the
+	push_dwarf_reg_entry_value method can be moved from
+	dwarf_expr_executor and dwarf_evaluate_loc_desc classes
+	to their base class dwarf_expr_context.
+
+	gdb/ChangeLog:
+
+		* dwarf2/expr.c
+	        (dwarf_expr_context::push_dwarf_reg_entry_value): Move from
+		dwarf_evaluate_loc_desc.
+		* dwarf2/frame.c
+		(dwarf_expr_executor::push_dwarf_reg_entry_value): Remove
+		method.
+		* dwarf2/loc.c (dwarf_expr_reg_to_entry_parameter): Expose
+		function.
+		(dwarf_evaluate_loc_desc::push_dwarf_reg_entry_value): Move to
+		dwarf_expr_context.
+		* dwarf2/loc.h (dwarf_expr_reg_to_entry_parameter): Expose
+		function.
+
+2021-08-05  Zoran Zaric  <zoran.zaric@amd.com>
+
+	Move read_mem to dwarf_expr_context
+	Following the idea of merging the evaluators, the read_mem method can
+	be moved from dwarf_expr_executor and dwarf_evaluate_loc_desc classes
+	to their base class dwarf_expr_context.
+
+	gdb/ChangeLog:
+
+		* dwarf2/expr.c (dwarf_expr_context::read_mem): Move from
+		dwarf_evaluate_loc_desc.
+		* dwarf2/frame.c (dwarf_expr_executor::read_mem): Remove
+		method.
+		* dwarf2/loc.c (dwarf_evaluate_loc_desc::read_mem): Move to
+		dwarf_expr_context.
+
+2021-08-05  Zoran Zaric  <Zoran.Zaric@amd.com>
+
+	Move get_object_address to dwarf_expr_context
+	Following the idea of merging the evaluators, the get_object_address
+	and can be moved from dwarf_expr_executor and dwarf_evaluate_loc_desc
+	classes to their base class dwarf_expr_context.
+
+	gdb/ChangeLog:
+
+		* dwarf2/expr.c (dwarf_expr_context::get_object_address): Move
+		from dwarf_evaluate_loc_desc.
+		(class dwarf_expr_context): Add object address member to
+		dwarf_expr_context.
+		* dwarf2/expr.h (dwarf_expr_context::get_frame_pc): Remove
+		method.
+		* dwarf2/frame.c (dwarf_expr_executor::get_object_address):
+		Remove method.
+		* dwarf2/loc.c (dwarf_evaluate_loc_desc::get_object_address):
+		move to dwarf_expr_context.
+		(class dwarf_evaluate_loc_desc): Move object address member to
+		dwarf_expr_context.
+
+2021-08-05  Zoran Zaric  <zoran.zaric@amd.com>
+
+	Move dwarf_call to dwarf_expr_context
+	Following the idea of merging the evaluators, the dwarf_call and
+	get_frame_pc method can be moved from dwarf_expr_executor and
+	dwarf_evaluate_loc_desc classes to their base class dwarf_expr_context.
+	Once this is done, the get_frame_pc can be replace with lambda
+	function.
+
+	gdb/ChangeLog:
+
+		* dwarf2/expr.c (dwarf_expr_context::dwarf_call): Move from
+		dwarf_evaluate_loc_desc.
+		(dwarf_expr_context::get_frame_pc): Replace with lambda.
+		* dwarf2/expr.h (dwarf_expr_context::get_frame_pc): Remove
+		method.
+		* dwarf2/frame.c (dwarf_expr_executor::dwarf_call): Remove
+		method.
+		(dwarf_expr_executor::get_frame_pc): Remove method.
+		* dwarf2/loc.c (dwarf_evaluate_loc_desc::get_frame_pc): Remove
+		method.
+		(dwarf_evaluate_loc_desc::dwarf_call): Move to
+		dwarf_expr_context.
+		(per_cu_dwarf_call): Inline function.
+
+2021-08-05  Zoran Zaric  <zoran.zaric@amd.com>
+
+	Move compilation unit info to dwarf_expr_context
+	This patch moves the compilation unit context information and support
+	from dwarf_expr_executor and dwarf_evaluate_loc_desc to
+	dwarf_expr_context evaluator. The idea is to report an error when a
+	given operation requires a compilation unit information to be resolved,
+	which is not available.
+
+	With this change, it also makes sense to always acquire ref_addr_size
+	information from the compilation unit context, considering that all
+	DWARF operations that refer to that information require a compilation
+	unit context to be present during their evaluation.
+
+	gdb/ChangeLog:
+
+		* dwarf2/expr.c (ensure_have_per_cu): New function.
+		(dwarf_expr_context::dwarf_expr_context): Add compilation unit
+		context information.
+		(dwarf_expr_context::get_base_type): Move from
+		dwarf_evaluate_loc_desc.
+		(dwarf_expr_context::get_addr_index): Remove method.
+		(dwarf_expr_context::dwarf_variable_value): Remove method.
+		(dwarf_expr_context::execute_stack_op): Call compilation unit
+		context info check. Inline get_addr_index and
+		dwarf_variable_value methods.
+		* dwarf2/expr.h (struct dwarf_expr_context): Add compilation
+		context info.
+	        (dwarf_expr_context::get_addr_index): Remove method.
+	        (dwarf_expr_context::dwarf_variable_value): Remove method.
+	        (dwarf_expr_context::ref_addr_size): Remove member.
+		* dwarf2/frame.c (dwarf_expr_executor::get_addr_index): Remove
+		method.
+		(dwarf_expr_executor::dwarf_variable_value): Remove method.
+		* dwarf2/loc.c (sect_variable_value): Expose function.
+		(dwarf_evaluate_loc_desc::get_addr_index): Remove method.
+		(dwarf_evaluate_loc_desc::dwarf_variable_value): Remove method.
+		(class dwarf_evaluate_loc_desc): Move compilation unit context
+		information to dwarf_expr_context class.
+		* dwarf2/loc.h (sect_variable_value): Expose function.
+
+2021-08-05  Zoran Zaric  <Zoran.Zaric@amd.com>
+
+	Remove get_frame_cfa from dwarf_expr_context
+	Following the idea of merging the evaluators, the get_frame_cfa method
+	can be moved from dwarf_expr_executor and dwarf_evaluate_loc_desc
+	classes to their base class dwarf_expr_context. Once this is done,
+	it becomes apparent that the method is only called once and it can be
+	inlined.
+
+	It is also necessary to check if the frame context information was
+	provided before the DW_OP_call_frame_cfa operation is executed.
+
+	gdb/ChangeLog:
+
+		* dwarf2/expr.c (dwarf_expr_context::get_frame_cfa): Remove
+		method.
+		(dwarf_expr_context::execute_stack_op): Call frame context info
+		check for DW_OP_call_frame_cfa. Remove use of get_frame_cfa.
+		* dwarf2/expr.h (dwarf_expr_context::get_frame_cfa): Remove
+		method.
+		* dwarf2/frame.c (dwarf_expr_context::get_frame_cfa): Remove
+		method.
+		* dwarf2/loc.c (dwarf_expr_context::get_frame_cfa): Remove
+		method.
+
+2021-08-05  Zoran Zaric  <zoran.zaric@amd.com>
+
+	Move frame context info to dwarf_expr_context
+	Following 15 patches in this patch series is cleaning up the design of
+	the DWARF expression evaluator (dwarf_expr_context) to make future
+	extensions of that evaluator easier and cleaner to implement.
+
+	There are three subclasses of the dwarf_expr_context class
+	(dwarf_expr_executor, dwarf_evaluate_loc_desc and
+	evaluate_for_locexpr_baton). Here is a short description of each class:
+
+	- dwarf_expr_executor is evaluating a DWARF expression in a context
+	  of a Call Frame Information. The overridden methods of this subclass
+	  report an error if a specific DWARF operation, represented by that
+	  method, is not allowed in a CFI context. The source code of this
+	  subclass lacks the support for composite as well as implicit pointer
+	  location description.
+
+	- dwarf_evaluate_loc_desc can evaluate any expression with no
+	  restrictions. All of the methods that this subclass overrides are
+	  actually doing what they are intended to do. This subclass contains
+	  a full support for all location description types.
+
+	- evaluate_for_locexpr_baton subclass is a specialization of the
+	  dwarf_evaluate_loc_desc subclass and it's function is to add
+	  support for passed in buffers. This seems to be a way to go around
+	  the fact that DWARF standard lacks a bit offset support for memory
+	  location descriptions as well as using any location description for
+	  the push object address functionality.
+
+	It all comes down to this question: what is a function of a DWARF
+	expression evaluator?
+
+	Is it to evaluate the expression in a given context or to check the
+	correctness of that expression in that context?
+
+	Currently, the only reason why there is a dwarf_expr_executor subclass
+	is to report an invalid DWARF expression in a context of a CFI, but is
+	that what the evaluator is supposed to do considering that the evaluator
+	is not tied to a given DWARF version?
+
+	There are more and more vendor and GNU extensions that are not part of
+	the DWARF standard, so is it that impossible to expect that some of the
+	extensions could actually lift the previously imposed restrictions of
+	the CFI context? Not to mention that every new DWARF version is lifting
+	some restrictions anyway.
+
+	The thing that makes more sense for an evaluator to do, is to take the
+	context of an evaluation and checks the requirements of every operation
+	evaluated against that context. With this approach, the evaluator would
+	report an error only if parts of the context, necessary for the
+	evaluation, are missing.
+
+	If this approach is taken, then the unification of the
+	dwarf_evaluate_loc_desc, dwarf_expr_executor and dwarf_expr_context
+	is the next logical step. This makes a design of the DWARF expression
+	evaluator cleaner and allows more flexibility when supporting future
+	vendor and GNU extensions.
+
+	Additional benefit here is that now all evaluators have access to all
+	location description types, which means that a vendor extended CFI
+	rules could support composite location description as well. This also
+	means that a new evaluator interface can be changed to return a single
+	struct value (that describes the result of the evaluation) instead of
+	a caller poking around the dwarf_expr_context internal data for answers
+	(like it is done currently).
+
+	This patch starts the merging process by moving the frame context
+	information and support from dwarf_expr_executor and
+	dwarf_evaluate_loc_desc to dwarf_expr_context evaluator. The idea
+	is to report an error when a given operation requires a frame
+	information to be resolved, if that information is not present.
+
+	gdb/ChangeLog:
+
+		* dwarf2/expr.c (ensure_have_frame): New function.
+		(read_addr_from_reg): Add from frame.c.
+		(dwarf_expr_context::dwarf_expr_context): Add frame info to
+		dwarf_expr_context.
+		(dwarf_expr_context::read_addr_from_reg): Remove.
+		(dwarf_expr_context::get_reg_value): Move from
+		dwarf_evaluate_loc_desc.
+		(dwarf_expr_context::get_frame_base): Move from
+		dwarf_evaluate_loc_desc.
+		(dwarf_expr_context::execute_stack_op): Call frame context info
+		check. Remove use of read_addr_from_reg method.
+		* dwarf2/expr.h (struct dwarf_expr_context): Add frame info
+		member, read_addr_from_reg, get_reg_value and get_frame_base
+		declaration.
+		(read_addr_from_reg): Move to expr.c.
+		* dwarf2/frame.c (read_addr_from_reg): Move to
+		dwarf_expr_context.
+		(dwarf_expr_executor::read_addr_from_reg): Remove.
+		(dwarf_expr_executor::get_frame_base): Remove.
+		(dwarf_expr_executor::get_reg_value): Remove.
+		(execute_stack_op): Use read_addr_from_reg function instead of
+		read_addr_from_reg method.
+		* dwarf2/loc.c (dwarf_evaluate_loc_desc::get_frame_base): Move
+		to dwarf_expr_context.
+		(dwarf_evaluate_loc_desc::get_reg_value): Move to
+		dwarf_expr_context.
+		(dwarf_evaluate_loc_desc::read_addr_from_reg): Remove.
+		(dwarf2_locexpr_baton_eval):Use read_addr_from_reg function
+		instead of read_addr_from_reg method.
+
+2021-08-05  Zoran Zaric  <Zoran.Zaric@amd.com>
+
+	Cleanup of the dwarf_expr_context constructor
+	Move the initial values for dwarf_expr_context class data members
+	to the class declaration in expr.h.
+
+	gdb/ChangeLog:
+
+	        * dwarf2/expr.c (dwarf_expr_context::dwarf_expr_context):
+	        Remove initial data members values.
+	        * dwarf2/expr.h (dwarf_expr_context): Add initial values
+	        to the class data members.
+
+2021-08-05  Zoran Zaric  <Zoran.Zaric@amd.com>
+
+	Replace the symbol needs evaluator with a parser
+	This patch addresses a design problem with the symbol_needs_eval_context
+	class. It exposes the problem by introducing two new testsuite test
+	cases.
+
+	To explain the issue, I first need to explain the dwarf_expr_context
+	class that the symbol_needs_eval_context class derives from.
+
+	The intention behind the dwarf_expr_context class is to commonize the
+	DWARF expression evaluation mechanism for different evaluation
+	contexts. Currently in gdb, the evaluation context can contain some or
+	all of the following information: architecture, object file, frame and
+	compilation unit.
+
+	Depending on the information needed to evaluate a given expression,
+	there are currently three distinct DWARF expression evaluators:
+
+	 - Frame: designed to evaluate an expression in the context of a call
+	   frame information (dwarf_expr_executor class). This evaluator doesn't
+	   need a compilation unit information.
+
+	 - Location description: designed to evaluate an expression in the
+	   context of a source level information (dwarf_evaluate_loc_desc
+	   class). This evaluator expects all information needed for the
+	   evaluation of the given expression to be present.
+
+	 - Symbol needs: designed to answer a question about the parts of the
+	   context information required to evaluate a DWARF expression behind a
+	   given symbol (symbol_needs_eval_context class). This evaluator
+	   doesn't need a frame information.
+
+	The functional difference between the symbol needs evaluator and the
+	others is that this evaluator is not meant to interact with the actual
+	target. Instead, it is supposed to check which parts of the context
+	information are needed for the given DWARF expression to be evaluated by
+	the location description evaluator.
+
+	The idea is to take advantage of the existing dwarf_expr_context
+	evaluation mechanism and to fake all required interactions with the
+	actual target, by returning back dummy values. The evaluation result is
+	returned as one of three possible values, based on operations found in a
+	given expression:
+
+	- SYMBOL_NEEDS_NONE,
+	- SYMBOL_NEEDS_REGISTERS and
+	- SYMBOL_NEEDS_FRAME.
+
+	The problem here is that faking results of target interactions can yield
+	an incorrect evaluation result.
+
+	For example, if we have a conditional DWARF expression, where the
+	condition depends on a value read from an actual target, and the true
+	branch of the condition requires a frame information to be evaluated,
+	while the false branch doesn't, fake target reads could conclude that a
+	frame information is not needed, where in fact it is. This wrong
+	information would then cause the expression to be actually evaluated (by
+	the location description evaluator) with a missing frame information.
+	This would then crash the debugger.
+
+	The gdb.dwarf2/symbol_needs_eval_fail.exp test introduces this
+	scenario, with the following DWARF expression:
+
+	                   DW_OP_addr $some_variable
+	                   DW_OP_deref
+
+	                   # conditional jump to DW_OP_bregx
+	                   DW_OP_bra 4
+	                   DW_OP_lit0
+
+	                   # jump to DW_OP_stack_value
+	                   DW_OP_skip 3
+	                   DW_OP_bregx $dwarf_regnum 0
+	                   DW_OP_stack_value
+
+	This expression describes a case where some variable dictates the
+	location of another variable. Depending on a value of some_variable, the
+	variable whose location is described by this expression is either read
+	from a register or it is defined as a constant value 0. In both cases,
+	the value will be returned as an implicit location description on the
+	DWARF stack.
+
+	Currently, when the symbol needs evaluator fakes a memory read from the
+	address behind the some_variable variable, the constant value 0 is used
+	as the value of the variable A, and the check returns the
+	SYMBOL_NEEDS_NONE result.
+
+	This is clearly a wrong result and it causes the debugger to crash.
+
+	The scenario might sound strange to some people, but it comes from a
+	SIMD/SIMT architecture where $some_variable is an execution mask.  In
+	any case, it is a valid DWARF expression, and GDB shouldn't crash while
+	evaluating it. Also, a similar example could be made based on a
+	condition of the frame base value, where if that value is concluded to
+	be 0, the variable location could be defaulted to a TLS based memory
+	address.
+
+	The gdb.dwarf2/symbol_needs_eval_timeout.exp test introduces a second
+	scenario. This scenario is a bit more abstract due to the DWARF
+	assembler lacking the CFI support, but it exposes a different
+	manifestation of the same problem. Like in the previous scenario, the
+	DWARF expression used in the test is valid:
+
+	                       DW_OP_lit1
+	                       DW_OP_addr $some_variable
+	                       DW_OP_deref
+
+	                       # jump to DW_OP_fbreg
+	                       DW_OP_skip 4
+	                       DW_OP_drop
+	                       DW_OP_fbreg 0
+	                       DW_OP_dup
+	                       DW_OP_lit0
+	                       DW_OP_eq
+
+	                       # conditional jump to DW_OP_drop
+	                       DW_OP_bra -9
+	                       DW_OP_stack_value
+
+	Similarly to the previous scenario, the location of a variable A is an
+	implicit location description with a constant value that depends on a
+	value held by a global variable. The difference from the previous case
+	is that DWARF expression contains a loop instead of just one branch. The
+	end condition of that loop depends on the expectation that a frame base
+	value is never zero. Currently, the act of faking the target reads will
+	cause the symbol needs evaluator to get stuck in an infinite loop.
+
+	Somebody could argue that we could change the fake reads to return
+	something else, but that would only hide the real problem.
+
+	The general impression seems to be that the desired design is to have
+	one class that deals with parsing of the DWARF expression, while there
+	are virtual methods that deal with specifics of some operations.
+
+	Using an evaluator mechanism here doesn't seem to be correct, because
+	the act of evaluation relies on accessing the data from the actual
+	target with the possibility of skipping the evaluation of some parts of
+	the expression.
+
+	To better explain the proposed solution for the issue, I first need to
+	explain a couple more details behind the current design:
+
+	There are multiple places in gdb that handle DWARF expression parsing
+	for different purposes. Some are in charge of converting the expression
+	to some other internal representation (decode_location_expression,
+	disassemble_dwarf_expression and dwarf2_compile_expr_to_ax), some are
+	analysing the expression for specific information
+	(compute_stack_depth_worker) and some are in charge of evaluating the
+	expression in a given context (dwarf_expr_context::execute_stack_op
+	and decode_locdesc).
+
+	The problem is that all those functions have a similar (large) switch
+	statement that handles each DWARF expression operation. The result of
+	this is a code duplication and harder maintenance.
+
+	As a step into the right direction to solve this problem (at least for
+	the purpose of a DWARF expression evaluation) the expression parsing was
+	commonized inside of an evaluator base class (dwarf_expr_context). This
+	makes sense for all derived classes, except for the symbol needs
+	evaluator (symbol_needs_eval_context) class.
+
+	As described previously the problem with this evaluator is that if the
+	evaluator is not allowed to access the actual target, it is not really
+	evaluating.
+
+	Instead, the desired function of a symbol needs evaluator seems to fall
+	more into expression analysis category. This means that a more natural
+	fit for this evaluator is to be a symbol needs analysis, similar to the
+	existing compute_stack_depth_worker analysis.
+
+	Another problem is that using a heavyweight mechanism of an evaluator
+	to do an expression analysis seems to be an unneeded overhead. It also
+	requires a more complicated design of the parent class to support fake
+	target reads.
+
+	The reality is that the whole symbol_needs_eval_context class can be
+	replaced with a lightweight recursive analysis function, that will give
+	more correct result without compromising the design of the
+	dwarf_expr_context class. The analysis treats the expression byte
+	stream as a DWARF operation graph, where each graph node can be
+	visited only once and each operation can decide if the frame context
+	is needed for their evaluation.
+
+	The downside of this approach is adding of one more similar switch
+	statement, but at least this way the new symbol needs analysis will be
+	a lightweight mechnism and it will provide a correct result for any
+	given DWARF expression.
+
+	A more desired long term design would be to have one class that deals
+	with parsing of the DWARF expression, while there would be a virtual
+	methods that deal with specifics of some DWARF operations. Then that
+	class would be used as a base for all DWARF expression parsing mentioned
+	at the beginning.
+
+	This however, requires a far bigger changes that are out of the scope
+	of this patch series.
+
+	The new analysis requires the DWARF location description for the
+	argc argument of the main function to change in the assembly file
+	gdb.python/amd64-py-framefilter-invalidarg.S. Originally, expression
+	ended with a 0 value byte, which was never reached by the symbol needs
+	evaluator, because it was detecting a stack underflow when evaluating
+	the operation before. The new approach does not simulate a DWARF
+	stack anymore, so the 0 value byte needs to be removed because it
+	makes the DWARF expression invalid.
+
+	gdb/ChangeLog:
+
+	        * dwarf2/loc.c (class symbol_needs_eval_context): Remove.
+	        (dwarf2_get_symbol_read_needs): New function.
+	        (dwarf2_loc_desc_get_symbol_read_needs): Remove.
+	        (locexpr_get_symbol_read_needs): Use
+	        dwarf2_get_symbol_read_needs.
+
+	gdb/testsuite/ChangeLog:
+
+	        * gdb.python/amd64-py-framefilter-invalidarg.S : Update argc
+	          DWARF location expression.
+	        * lib/dwarf.exp (_location): Handle DW_OP_fbreg.
+	        * gdb.dwarf2/symbol_needs_eval.c: New file.
+	        * gdb.dwarf2/symbol_needs_eval_fail.exp: New file.
+	        * gdb.dwarf2/symbol_needs_eval_timeout.exp: New file.
+
+2021-08-05  Cui,Lili  <lili.cui@intel.com>
+
+	[PATCH 2/2] Add tests for Intel AVX512_FP16 instructions
+	Intel AVX512 FP16 instructions use maps 3, 5 and 6. Maps 5 and 6 use 3 bits
+	in the EVEX.mmm field (0b101, 0b110). Map 5 is for instructions that were FP32
+	in map 1 (0Fxx). Map 6 is for instructions that were FP32 in map 2 (0F38xx).
+	There are some exceptions to this rule. Some things in map 1 (0Fxx) with imm8
+	operands predated our current conventions; those instructions moved to map 3.
+	FP32 things in map 3 (0F3Axx) found new opcodes in map3 for FP16 because map3
+	is very sparsely populated. Most of the FP16 instructions share opcodes and
+	prefix (EVEX.pp) bits with the related FP32 operations.
+
+	Intel AVX512 FP16 instructions has new displacements scaling rules, please refer
+	to the public software developer manual for detail information.
+
+	gas/
+
+	2021-08-05  Igor Tsimbalist  <igor.v.tsimbalist@intel.com>
+	            H.J. Lu  <hongjiu.lu@intel.com>
+	            Wei Xiao <wei3.xiao@intel.com>
+	            Lili Cui  <lili.cui@intel.com>
+
+		* testsuite/gas/i386/i386.exp: Run FP16 tests.
+		* testsuite/gas/i386/avx512_fp16-intel.d: New test.
+		* testsuite/gas/i386/avx512_fp16-inval-bcast.l: Ditto.
+		* testsuite/gas/i386/avx512_fp16-inval-bcast.s: Ditto.
+		* testsuite/gas/i386/avx512_fp16.d: Ditto.
+		* testsuite/gas/i386/avx512_fp16.s: Ditto.
+		* testsuite/gas/i386/avx512_fp16_pseudo_ops.d: Ditto.
+		* testsuite/gas/i386/avx512_fp16_pseudo_ops.s: Ditto.
+		* testsuite/gas/i386/avx512_fp16_vl-intel.d: Ditto.
+		* testsuite/gas/i386/avx512_fp16_vl.d: Ditto.
+		* testsuite/gas/i386/avx512_fp16_vl.s: Ditto.
+		* testsuite/gas/i386/x86-64-avx512_fp16-intel.d: Ditto.
+		* testsuite/gas/i386/x86-64-avx512_fp16-inval-bcast.l: Ditto.
+		* testsuite/gas/i386/x86-64-avx512_fp16-inval-bcast.s: Ditto.
+		* testsuite/gas/i386/x86-64-avx512_fp16.d: Ditto.
+		* testsuite/gas/i386/x86-64-avx512_fp16.s: Ditto.
+		* testsuite/gas/i386/x86-64-avx512_fp16_pseudo_ops.d: Ditto.
+		* testsuite/gas/i386/x86-64-avx512_fp16_pseudo_ops.s: Ditto.
+		* testsuite/gas/i386/x86-64-avx512_fp16_vl-intel.d: Ditto.
+		* testsuite/gas/i386/x86-64-avx512_fp16_vl.d: Ditto.
+		* testsuite/gas/i386/x86-64-avx512_fp16_vl.s: Ditto.
+		* testsuite/gas/i386/x86-64-avx512_fp16-inval-register.l: Ditto.
+		* testsuite/gas/i386/x86-64-avx512_fp16-inval-register.s: Ditto.
+		* testsuite/gas/i386/x86-64-avx512_fp16-bad.d: Ditto.
+		* testsuite/gas/i386/x86-64-avx512_fp16-bad.s: Ditto.
+		* testsuite/gas/i386/x86-64-default-suffix-avx.d: Add new testcase.
+		* testsuite/gas/i386/x86-64-default-suffix.d: Ditto.
+		* testsuite/gas/i386/x86-64-default-suffix.s: Ditto.
+		* testsuite/gas/i386/xmmword.l: Ditto.
+		* testsuite/gas/i386/xmmword.s: Ditto.
+
+2021-08-05  Cui,Lili  <lili.cui@intel.com>
+
+	[PATCH 1/2] Enable Intel AVX512_FP16 instructions
+	Intel AVX512 FP16 instructions use maps 3, 5 and 6. Maps 5 and 6 use 3 bits
+	in the EVEX.mmm field (0b101, 0b110). Map 5 is for instructions that were FP32
+	in map 1 (0Fxx). Map 6 is for instructions that were FP32 in map 2 (0F38xx).
+	There are some exceptions to this rule. Some things in map 1 (0Fxx) with imm8
+	operands predated our current conventions; those instructions moved to map 3.
+	FP32 things in map 3 (0F3Axx) found new opcodes in map3 for FP16 because map3
+	is very sparsely populated. Most of the FP16 instructions share opcodes and
+	prefix (EVEX.pp) bits with the related FP32 operations.
+
+	Intel AVX512 FP16 instructions has new displacements scaling rules, please refer
+	to the public software developer manual for detail information.
+
+	gas/
+
+	2021-08-05  Igor Tsimbalist  <igor.v.tsimbalist@intel.com>
+	            H.J. Lu  <hongjiu.lu@intel.com>
+	            Wei Xiao <wei3.xiao@intel.com>
+	            Lili Cui  <lili.cui@intel.com>
+
+		* config/tc-i386.c (struct Broadcast_Operation): Adjust comment.
+		(cpu_arch): Add .avx512_fp16.
+		(cpu_noarch): Add noavx512_fp16.
+		(pte): Add evexmap5 and evexmap6.
+		(build_evex_prefix): Handle EVEXMAP5 and EVEXMAP6.
+		(check_VecOperations): Handle {1to32}.
+		(check_VecOperands): Handle CheckRegNumb.
+		(check_word_reg): Handle Toqword.
+		(i386_error): Add invalid_dest_and_src_register_set.
+		(match_template): Handle invalid_dest_and_src_register_set.
+		* doc/c-i386.texi: Document avx512_fp16, noavx512_fp16.
+
+	opcodes/
+
+	2021-08-05  Igor Tsimbalist  <igor.v.tsimbalist@intel.com>
+	            H.J. Lu  <hongjiu.lu@intel.com>
+	            Wei Xiao <wei3.xiao@intel.com>
+	            Lili Cui  <lili.cui@intel.com>
+
+		* i386-dis.c (EXwScalarS): New.
+		(EXxh): Ditto.
+		(EXxhc): Ditto.
+		(EXxmmqh): Ditto.
+		(EXxmmqdh): Ditto.
+		(EXEvexXwb): Ditto.
+		(DistinctDest_Fixup): Ditto.
+		(enum): Add xh_mode, evex_half_bcst_xmmqh_mode, evex_half_bcst_xmmqdh_mode
+		and w_swap_mode.
+		(enum): Add PREFIX_EVEX_0F3A08_W_0, PREFIX_EVEX_0F3A0A_W_0,
+		PREFIX_EVEX_0F3A26, PREFIX_EVEX_0F3A27, PREFIX_EVEX_0F3A56,
+		PREFIX_EVEX_0F3A57, PREFIX_EVEX_0F3A66, PREFIX_EVEX_0F3A67,
+		PREFIX_EVEX_0F3AC2, PREFIX_EVEX_MAP5_10, PREFIX_EVEX_MAP5_11,
+		PREFIX_EVEX_MAP5_1D, PREFIX_EVEX_MAP5_2A, PREFIX_EVEX_MAP5_2C,
+		PREFIX_EVEX_MAP5_2D, PREFIX_EVEX_MAP5_2E, PREFIX_EVEX_MAP5_2F,
+		PREFIX_EVEX_MAP5_51, PREFIX_EVEX_MAP5_58, PREFIX_EVEX_MAP5_59,
+		PREFIX_EVEX_MAP5_5A_W_0, PREFIX_EVEX_MAP5_5A_W_1,
+		PREFIX_EVEX_MAP5_5B_W_0, PREFIX_EVEX_MAP5_5B_W_1,
+		PREFIX_EVEX_MAP5_5C, PREFIX_EVEX_MAP5_5D, PREFIX_EVEX_MAP5_5E,
+		PREFIX_EVEX_MAP5_5F, PREFIX_EVEX_MAP5_78, PREFIX_EVEX_MAP5_79,
+		PREFIX_EVEX_MAP5_7A, PREFIX_EVEX_MAP5_7B, PREFIX_EVEX_MAP5_7C,
+		PREFIX_EVEX_MAP5_7D_W_0, PREFIX_EVEX_MAP6_13, PREFIX_EVEX_MAP6_56,
+		PREFIX_EVEX_MAP6_57, PREFIX_EVEX_MAP6_D6, PREFIX_EVEX_MAP6_D7
+		(enum): Add EVEX_MAP5 and EVEX_MAP6.
+		(enum): Add EVEX_W_MAP5_5A, EVEX_W_MAP5_5B,
+		EVEX_W_MAP5_78_P_0, EVEX_W_MAP5_78_P_2, EVEX_W_MAP5_79_P_0,
+		EVEX_W_MAP5_79_P_2, EVEX_W_MAP5_7A_P_2, EVEX_W_MAP5_7A_P_3,
+		EVEX_W_MAP5_7B_P_2, EVEX_W_MAP5_7C_P_0, EVEX_W_MAP5_7C_P_2,
+		EVEX_W_MAP5_7D, EVEX_W_MAP6_13_P_0, EVEX_W_MAP6_13_P_2,
+		(get_valid_dis386): Properly handle new instructions.
+		(intel_operand_size): Handle new modes.
+		(OP_E_memory): Ditto.
+		(OP_EX): Ditto.
+		* i386-dis-evex.h: Updated for AVX512_FP16.
+		* i386-dis-evex-mod.h: Updated for AVX512_FP16.
+		* i386-dis-evex-prefix.h: Updated for AVX512_FP16.
+		* i386-dis-evex-reg.h : Updated for AVX512_FP16.
+		* i386-dis-evex-w.h : Updated for AVX512_FP16.
+		* i386-gen.c (cpu_flag_init): Add CPU_AVX512_FP16_FLAGS,
+		and CPU_ANY_AVX512_FP16_FLAGS. Update CPU_ANY_AVX512F_FLAGS
+		and CPU_ANY_AVX512BW_FLAGS.
+		(cpu_flags): Add CpuAVX512_FP16.
+		(opcode_modifiers): Add DistinctDest.
+		* i386-opc.h (enum): (AVX512_FP16): New.
+		(i386_opcode_modifier): Add reqdistinctreg.
+		(i386_cpu_flags): Add cpuavx512_fp16.
+		(EVEXMAP5): Defined as a macro.
+		(EVEXMAP6): Ditto.
+		* i386-opc.tbl: Add Intel AVX512_FP16 instructions.
+		* i386-init.h: Regenerated.
+		* i386-tbl.h: Ditto.
+
+2021-08-05  Alan Modra  <amodra@gmail.com>
+
+	PR28167, vms-alpha build_module_list
+		PR 28167
+		* vms-alpha.c (build_module_list): Malloc and free section contents.
+		Don't read past end of section.
+
+2021-08-05  Alan Modra  <amodra@gmail.com>
+
+	PR28166, _bfd_elf_mips_get_relocated_section_contents
+	Some of the code paths unpacking mips relocs left arelent->sym_ptr_ptr
+	uninitialised.
+
+		PR 28166
+		* elf64-mips.c (mips_elf64_slurp_one_reloc_table): Don't leave
+		sym_ptr_ptr uninitialised.
+
+2021-08-05  Alan Modra  <amodra@gmail.com>
+
+	PR28165, buffer overflow in elf32-rx.c:rx_info_to_howto_rela
+		PR 28165
+		* elf32-rx.c (rx_elf_howto_table): Add missing empty entries.
+		(rx_info_to_howto_rela): Assert rx_elf_howto_table is correct size.
+		Use actual size when sanity checking r_type.
+
+2021-08-05  Alan Modra  <amodra@gmail.com>
+
+	Re: elf: Treat undefined version as hidden
+	Fix fallout in cris testsuite
+
+		PR binutils/28158
+		* ld-cris/libdso-1c.d: Update for version display change.
+		* ld-cris/libdso-15b.d: Likewise.
+
+2021-08-05  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb/testsuite: update test gdb.base/step-over-syscall.exp
+	I was looking at PR gdb/19675 and the related test
+	gdb.base/step-over-syscall.exp.  This test includes a call to kfail
+	when we are testing a displaced step over a clone syscall.
+
+	While looking at the test I removed the call to kfail and ran the
+	test, and was surprised that the test passed.
+
+	I ran the test a few times and it does sometimes fail, but mostly it
+	passed fine.
+
+	PR gdb/19675 describes how, when we displaced step over a clone, the
+	new thread is created with a $pc in the displaced step buffer.  GDB
+	then fails to "fix" this $pc (for the new thread), and the thread will
+	be set running with its current $pc value.  This means that the new
+	thread will just start executing from whatever happens to be after the
+	displaced stepping buffer.
+
+	In the original PR gdb/19675 bug report Yao Qi was seeing the new
+	thread cause a segfault, the problem is, what actually happens is
+	totally undefined.
+
+	On my machine, I'm seeing the new thread reenter main, it then starts
+	trying to run the test again (in the new thread).  This just happens
+	to be safe enough (in this simple test) that most of the time the
+	inferior doesn't crash.
+
+	In this commit I try to make the test slightly more likely to fail by
+	doing a couple of things.
+
+	First, I added a static variable to main, this is set true when the
+	first thread enters main, if a second thread ever enters main then I
+	force an abort.
+
+	Second, when the test is finishing I want to ensure that the new
+	threads have had a chance to do "something bad" if they are going to.
+	So I added a global counter, as each thread starts successfully it
+	decrements the counter.  The main thread does not proceed to the final
+	marker function (where GDB has placed a breakpoint) until all threads
+	have started successfully.  This means that if the newly created
+	thread doesn't successfully enter clone_fn then the counter will never
+	reach zero and the test will timeout.
+
+	With these two changes my hope is that the test should fail more
+	reliably, and so, I have also changed the test to call setup_kfail
+	before the specific steps that we expect to misbehave instead of just
+	calling kfail and skipping parts of the test completely.  The benefit
+	of this is that if/when we fix GDB this test will start to KPASS and
+	we'll know to update this test to remove the setup_kfail call.
+
+2021-08-05  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-05  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb: Use unwinder name in frame_info::to_string
+	While working on a stack unwinding issue using 'set debug frame on', I
+	noticed the frame_info::to_string method could be slightly improved.
+
+	Unwinders have been given a name in
+	a154d838a70e96d888620c072e2d6ea8bdf044ca.  Before this patch, frame_info
+	debug output prints the host address of the used unwinder, which is not
+	easy to interpret.  This patch proposes to use the unwinder name
+	instead since we now have it.
+
+	Before the patch:
+
+	    {level=1,type=NORMAL_FRAME,unwind=0x2ac1763ec0,pc=0x3ff7fc3460,id={stack=0x3ff7ea79b0,code=0x0000003ff7fc33ac,!special},func=0x3ff7fc33ac}
+
+	With the patch:
+
+	    {level=1,type=NORMAL_FRAME,unwinder="riscv prologue",pc=0x3ff7fc3460,id={stack=0x3ff7ea79b0,code=0x0000003ff7fc33ac,!special},func=0x3ff7fc33ac}
+
+	Tested on riscv64-linux-gnu.
+
+2021-08-04  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/testsuite: fix gdb.base/info-macros.exp with clang
+	The test gdb.base/info-macros.exp says that it doesn't pass the "debug"
+	option to prepare_for_testing because that would cause -g to appear
+	after -g3 on the command line, and that would cause some gcc versions to
+	not include macro info.  I don't know what gcc versions this refers to.
+	I tested with gcc 4.8, and that works fine with -g after -g3.
+
+	The current state is problematic when testing with CC_FOR_TARGET=clang,
+	because then only -fdebug-macro is included.  No -g switch if included,
+	meaning we get a binary without any debug info, and the test fails.
+
+	One way to fix it would be to add "debug" to the options when the
+	compiler is clang.
+
+	However, the solution I chose was to specify "debug" in any case, even
+	for gcc.  Other macro tests such as gdb.base/macscp.exp do perfectly
+	fine with it.  Also, this lets the test use the debug flag specified by
+	the board file.  For example, we can test with GCC and DWARF 5, with:
+
+	    $ make check RUNTESTFLAGS="--target_board unix/gdb:debug_flags=-gdwarf-5" TESTS="gdb.base/info-macros.exp"
+
+	With the hard-coded -g3, this wouldn't actually test with DWARF 5.
+
+	Change-Id: I33fa92ee545007d3ae9c52c4bb2d5be6b5b698f1
+
+2021-08-04  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: avoid dereferencing empty str_offsets_base optional in dwarf_decode_macros
+	Since 4d7188abfdf2 ("gdbsupport: add debug assertions in
+	gdb::optional::get"), some macro-related tests fail on Ubuntu 20.04 with
+	the system gcc 9.3.0 compiler when building with _GLIBCXX_DEBUG.  For
+	example, gdb.base/info-macros.exp results in:
+
+	   (gdb) break -qualified main
+	   /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/gdb_optional.h:206: internal-error: T& gdb::optional<T>::get() [with T = long unsigned int]: Assertion `this->has_value ()' failed.
+
+	The binary contains DWARF 4 debug info and includes a pre-standard
+	(pre-DWARF 5) .debug_macro section.  The CU doesn't have a
+	DW_AT_str_offsets_base attribute (which doesn't exist in DWARF 4).  The
+	field dwarf2_cu::str_offsets_base is therefore empty.  At
+	dwarf2/read.c:24138, we unconditionally read the value in the optional,
+	which triggers the assertion shown above.
+
+	The same thing happens when building the test program with DWARF 5 with
+	the same gcc compiler, as that version of gcc doesn't use indirect
+	string forms, even with DWARF 5.  So it still doesn't add a
+	DW_AT_str_offsets_base attribute on the CU.
+
+	Fix that by propagating down a gdb::optional<ULONGEST> for the str
+	offsets base instead of ULONGEST.  That value is only used in
+	dwarf_decode_macro_bytes, when encountering an "strx" macro operation
+	(DW_MACRO_define_strx or DW_MACRO_undef_strx).  Add a check there that
+	we indeed have a value in the optional before reading it.  This is
+	unlikely to happen, but could happen in theory with an erroneous file
+	that uses DW_MACRO_define_strx but does not provide a
+	DW_AT_str_offsets_base (in practice, some things would probably have
+	failed before and stopped processing of debug info).  I tested the
+	complaint by inverting the condition and using a clang-compiled binary,
+	which uses the strx operators.  This is the result:
+
+	    During symbol reading: use of DW_MACRO_define_strx with unknown string offsets base [in module /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/info-macros/info-macros]
+
+	The test now passes cleanly with the setup mentioned above, and the
+	testsuite looks on par with how it was before 4d7188abfdf2.
+
+	Change-Id: I7ebd2724beb7b9b4178872374c2a177aea696e77
+
+2021-08-04  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: fix typo in complaint in dwarf2/macro.c
+	I saw this complaint when my code had some bug, and spotted the typo.
+	Fix it, and while at it mention DW_MACRO as well (it would be confusing
+	to only see DW_MACINFO with a file that uses a DWARF 5 .debug_macro
+	section).  I contemplated the idea of passing the knowledge of whether
+	we are dealing with a .debug_macro section or .debug_macinfo section, to
+	print only the right one.  But in the end, I don't think that trouble is
+	necessary for a complaint nobody is going to see.
+
+	Change-Id: I276ce8da65c3eac5304f64a1e246358ed29cdbbc
+
+2021-08-04  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: fix warnings in bsd-kvm.c
+	Building on OpenBSD, I get warnings like:
+
+	      CXX    bsd-kvm.o
+	    /home/simark/src/binutils-gdb/gdb/bsd-kvm.c:241:18: error: ISO C++11 does not allow conversion from string literal to 'char *' [-Werror,-Wwritable-strings]
+	      nl[0].n_name = "_dumppcb";
+	                     ^
+
+	Silence those by adding casts.
+
+	Change-Id: I2bef4eebcc306762a4e3e5b5c52f67ecf2820503
+
+2021-08-04  Andreas Krebbel  <krebbel@linux.ibm.com>
+
+	IBM Z: Remove lpswey parameter
+	opcodes/
+		* s390-opc.c (INSTR_SIY_RD): New instruction format.
+		(MASK_SIY_RD): New instruction mask.
+		* s390-opc.txt: Change instruction format of lpswey to SIY_RD.
+
+	gas/
+		* testsuite/gas/s390/zarch-arch14.d: Remove last operand of
+		lpswey.
+		* testsuite/gas/s390/zarch-arch14.s: Likewise.
+
+2021-08-04  Alan Modra  <amodra@gmail.com>
+
+	PR28162, segment fault in mips_elf_assign_gp
+	For the testcase in the PR, _bfd_mips_elf32_gprel16_reloc is passed a
+	NULL output_bfd.  As expected for reloc special functions if called by
+	objdump or when final linking.  The function attempts to find the
+	output by
+	  output_bfd = symbol->section->output_section->owner;
+	That makes some sense, since when handling a gp-relative reloc we need
+	the relevant gp to which the symbol is relative.  Possibly the gp
+	value can be one for a shared library?  But that doesn't seem useful
+	or supported by the various abi docs and won't work as written.
+	Symbols defined in shared libraries have section->output_section
+	NULL, and what's more the code in mips_elf_assign_gp isn't set up to
+	look at shared library symbols.
+
+	Also, if the symbol is a SHN_ABS one the owner of *ABS* section is
+	NULL, which will result in the testcase segfault.  The only gp to
+	which an absolute symbol can be relative is the linker output bfd when
+	linking, or the input bfd when not.  This patch arranges to do that
+	for all gp-relative reloc symbols.
+
+		* elf32-mips.c (_bfd_mips_elf32_gprel16_reloc): Don't use the
+		section symbol to find the output bfd, use input_section.
+		(mips_elf_gprel32_reloc, mips16_gprel_reloc): Likewise.
+		* elf64-mips.c (mips_elf64_gprel16_reloc): Likewise.
+		(mips_elf64_literal_reloc, mips_elf64_gprel32_reloc): Likewise.
+		(mips16_gprel_reloc): Likewise.
+
+2021-08-04  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/symtab] Use lambda function instead of addrmap_foreach_check
+	Use a lambda function instead of addrmap_foreach_check,
+	which removes the need for static variables.
+
+	Also remove unnecessary static on local var temp_obstack in test_addrmap.
+
+	gdb/ChangeLog:
+
+	2021-08-04  Tom de Vries  <tdevries@suse.de>
+
+		* addrmap.c (addrmap_foreach_check): Remove.
+		(array, val1, val2): Move ...
+		(test_addrmap): ... here.  Remove static on temp_obstack.  Use lambda
+		function instead of addrmap_foreach_check.
+
+2021-08-04  H.J. Lu  <hjl.tools@gmail.com>
+
+	elf: Treat undefined version as hidden
+	Since undefined version can't be used to resolve any references without
+	the original definition, treat it as hidden.
+
+	bfd/
+
+		PR binutils/28158
+		* elf.c (_bfd_elf_get_symbol_version_string): Treat undefined
+		version as hidden.
+
+	ld/
+
+		PR binutils/28158
+		* testsuite/ld-elf/linux-x86.exp: Run PR binutils/28158 tests.
+		* testsuite/ld-elf/pr28158-1.c: New file.
+		* testsuite/ld-elf/pr28158-2.S: Likewise.
+		* testsuite/ld-elf/pr28158.nd: Likewise.
+		* testsuite/ld-elf/pr28158.rd: Likewise.
+		* testsuite/ld-elf/pr28158.t: Likewise.
+		* testsuite/ld-elfvers/vers2.dsym: Updated.
+		* testsuite/ld-elfvers/vers3.dsym: Likewise.
+		* testsuite/ld-elfvers/vers6.dsym: Likewise.
+		* testsuite/ld-elfvers/vers19.dsym: Likewise.
+		* testsuite/ld-elfvers/vers22.dsym: Likewise.
+		* testsuite/ld-elfvers/vers23.dsym: Likewise.
+		* testsuite/ld-elfvers/vers23d.dsym: Likewise.
+		* testsuite/ld-elfvers/vers27d4.dsym: Likewise.
+		* testsuite/ld-elfvers/vers28c.dsym: Likewise.
+
+2021-08-04  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/symtab] Implement addrmap_mutable_find
+	Currently addrmap_mutable_find is not implemented:
+	...
+	static void *
+	addrmap_mutable_find (struct addrmap *self, CORE_ADDR addr)
+	{
+	  /* Not needed yet.  */
+	  internal_error (__FILE__, __LINE__,
+	                  _("addrmap_find is not implemented yet "
+	                    "for mutable addrmaps"));
+	}
+	...
+
+	I implemented this because I needed it during debugging, to be able to do:
+	...
+	(gdb) p ((dwarf2_psymtab *)addrmap_find (map, addr))->filename
+	...
+	before and after a call to addrmap_set_empty.
+
+	Since this is not used otherwise, added addrmap unit test.
+
+	Build on x86_64-linux, tested by doing:
+	...
+	$ gdb -q -batch -ex "maint selftest addrmap"
+	Running selftest addrmap.
+	Ran 1 unit tests, 0 failed
+	...
+
+	gdb/ChangeLog:
+
+	2021-08-03  Tom de Vries  <tdevries@suse.de>
+
+	        * gdb/addrmap.c (addrmap_mutable_find): Implement
+	        [GDB_SELF_TESTS] (CHECK_ADDRMAP_FIND): New macro.
+	        [GDB_SELF_TESTS] (core_addr, addrmap_foreach_check, test_addrmap)
+		(_initialize_addrmap): New function.
+
+2021-08-04  Clément Chigot  <clement.chigot@atos.net>
+
+	gas: correctly output XCOFF tbss symbols with XTY_CM type.
+	Global tbss symbols weren't correctly handled and were generating
+	a symbol with XTY_SD instead of XTY_CM as expected.
+
+	gas/
+		* config/tc-ppc.c (ppc_frog_symbol): Generate a XTY_CM when
+		a symbol has a storage class of XMC_UL.
+
+2021-08-04  Clément Chigot  <clement.chigot@atos.net>
+
+	gas: always add dummy symbols when creating XCOFF sections.
+	Most of the algorithms for XCOFF in tc-ppc.c assume that
+	the csects field of a ppc_xcoff_section isn't NULL.
+	This was already made for most of the sections with the creation
+	of a dummy symbol.
+	This patch simply mades it default when creating a xcoff_section.
+
+	gas/
+		* config/tc-ppc.c (ppc_init_xcoff_section): Always create
+		the dummy symbol.
+		(md_begin): Adjust ppc_init_xcoff_section call.
+		(ppc_comm): Likewise.
+		(ppc_change_csect): Likewise.
+
+2021-08-04  Alan Modra  <amodra@gmail.com>
+
+	PR28156, rename.c doesn't compile with MinGW
+	Guard against lack of struct timespec definition.
+
+		PR 28156
+		* rename.c (get_stat_atime, get_stat_mtime): Don't compile
+		unless HAVE_UTIMENSAT is defined.
+
+2021-08-04  Alan Modra  <amodra@gmail.com>
+
+	PR28155, Superfluous "the" in the man page
+		PR 28155
+		* ld.texi (Options <runtime library name>): Correct grammar.
+
+	revise PE IMAGE_SCN_LNK_NRELOC_OVFL test
+		* coffcode.h (coff_set_alignment_hook): Test that the resulting
+		reloc count is not less than 0xffff.
+
+2021-08-04  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: follow-fork: push target and add thread in target_follow_fork
+	In the context of ROCm-gdb [1], the ROCm target sits on top of the
+	linux-nat target.  when a process forks, it needs to carry over some
+	data from the forking inferior to the fork child inferior.  Ideally, the
+	ROCm target would implement the follow_fork target_ops method, but there
+	are some small problems.  This patch fixes these, which helps the ROCm
+	target, but also makes things more consistent and a bit nicer in
+	general, I believe.
+
+	The main problem is: when follow-fork-mode is "parent",
+	target_follow_fork is called with the parent as the current inferior.
+	When it's "child", target_follow_fork is called with the child as the
+	current inferior.  This means that target_follow_fork is sometimes
+	called on the parent's target stack and sometimes on the child's target
+	stack.
+
+	The parent's target stack may contain targets above the process target,
+	such as the ROCm target.  So if follow-fork-child is "parent", the ROCm
+	target would get notified of the fork and do whatever is needed.  But
+	the child's target stack, at that moment, only contains the exec and
+	process target copied over from the parent.  The child's target stack is
+	set up by follow_fork_inferior, before calling target_follow_fork.  In
+	that case, the ROCm target wouldn't get notified of the fork.
+
+	For consistency, I think it would be good to always call
+	target_follow_fork on the parent inferior's target stack.  I think it
+	makes sense as a way to indicate "this inferior has called fork, do
+	whatever is needed".  The desired outcome of the fork (whether an
+	inferior is created for the child, do we need to detach from the child)
+	can be indicated by passed parameter.
+
+	I therefore propose these changes:
+
+	 - make follow_fork_inferior always call target_follow_fork with the
+	   parent as the current inferior.  That lets all targets present on the
+	   parent's target stack do some fork-related handling and push
+	   themselves on the fork child's target stack if needed.
+
+	   For this purpose, pass the child inferior down to target_follow_fork
+	   and follow_fork implementations.  This is nullptr if no inferior is
+	   created for the child, because we want to detach from it.
+
+	 - as a result, in follow_fork_inferior, detach from the parent inferior
+	   (if needed) only after the target_follow_fork call.  This is needed
+	   because we want to call target_follow_fork before the parent's
+	   target stack is torn down.
+
+	 - hand over to the targets in the parent's target stack (including the
+	   process target) the responsibility to push themselves, if needed, to
+	   the child's target stack.  Also hand over the responsibility to the
+	   process target, at the same time, to create the child's initial
+	   thread (just like we do for follow_exec).
+
+	 - pass the child inferior to exec_on_vfork, so we don't need to swap
+	   the current inferior between parent and child.  Nothing in
+	   exec_on_vfork depends on the current inferior, after this change.
+
+	   Although this could perhaps be replaced with just having the exec
+	   target implement follow_fork and push itself in the child's target
+	   stack, like the process target does... We would just need to make
+	   sure the process target calls beneath()->follow_fork(...).  I'm not
+	   sure about this one.
+
+	gdb/ChangeLog:
+
+		* target.h (struct target_ops) <follow_fork>: Add inferior*
+		parameter.
+		(target_follow_fork): Likewise.
+		* target.c (default_follow_fork): Likewise.
+		(target_follow_fork): Likewise.
+		* fbsd-nat.h (class fbsd_nat_target) <follow_fork>: Likewise.
+		(fbsd_nat_target::follow_fork): Likewise, and call
+		inf_ptrace_target::follow_fork.
+		* linux-nat.h (class linux_nat_target) <follow_fork>: Likewise.
+		* linux-nat.c (linux_nat_target::follow_fork): Likewise, and
+		call inf_ptrace_target::follow_fork.
+		* obsd-nat.h (obsd_nat_target) <follow_fork>: Likewise.
+		* obsd-nat.c (obsd_nat_target::follow_fork): Likewise, and call
+		inf_ptrace_target::follow_fork.
+		* remote.c (class remote_target) <follow_fork>: Likewise.
+		(remote_target::follow_fork): Likewise, and call
+		process_stratum_target::follow_fork.
+		* process-stratum-target.h (class process_stratum_target)
+		<follow_fork>: New.
+		* process-stratum-target.c
+		(process_stratum_target::follow_fork): New.
+		* target-delegates.c: Re-generate.
+
+	[1] https://github.com/ROCm-Developer-Tools/ROCgdb
+
+	Change-Id: I460bd0af850f0485e8aed4b24c6d8262a4c69929
+
+2021-08-04  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-03  Carl Love  <cel@us.ibm.com>
+
+	Fixes for mi-fortran-modules.exp fixes
+	Output has additional information for a given filename.
+
+	gdb/testsuite/ChangeLog
+		* gdb.mi/mi-fortran-modules.exp (system_modules_pattern,
+		system_module_symbols_pattern): Add check for additional symbols
+		on the line
+
+2021-08-03  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdbsupport: add debug assertions in gdb::optional::get
+	The libstdc++ version of optional contains some runtime checks enabled
+	when _GLIBCXX_DEBUG is defined.  I think it would be useful if our
+	version contained similar checks.
+
+	Add checks in the two `get` methods, also conditional on _GLIBCXX_DEBUG.
+	I think it's simpler to use that macro rather than introducing a new
+	GDB-specific one, as I think that if somebody is interested in enabling
+	these runtime checks, they'll also be interested in enabling the
+	libstdc++ runtime checks (and vice-versa).
+
+	I implemented these checks using gdb_assert.  Note that gdb_assert
+	throws (after querying the user), and we are in noexcept methods.  That
+	means that std::terminate / abort will immediately be called.  I think
+	this is ok, since if those were "real" _GLIBCXX_DEBUG checks, abort
+	would be called straight away.
+
+	If I add a dummy failure, it looks like so:
+
+	    $ ./gdb -q -nx --data-directory=data-directory
+	    /home/simark/src/binutils-gdb/gdb/../gdbsupport/gdb_optional.h:206: internal-error: T& gdb::optional<T>::get() [with T = int]: Assertion `this->has_value ()' failed.
+	    A problem internal to GDB has been detected,
+	    further debugging may prove unreliable.
+	    Quit this debugging session? (y or n) n
+	    [1]    658767 abort (core dumped)  ./gdb -q -nx --data-directory=data-directory
+
+	Change-Id: Iadfdcd131425bd2ca6a2de30d7b22e9b3cc67793
+
+2021-08-03  Alok Kumar Sharma  <AlokKumar.Sharma@amd.com>
+
+	[gdb/testsuite] templates.exp to accept clang++ output
+	Please consider below testcase with intended error.
+	``````````
+	    constexpr const char cstring[] = "Eta";
+	    template <const char*, typename T> class Column {};
+	    using quick = Column<cstring,double>; // cstring without '&'
+
+	    void lookup() {
+	      quick c1;
+	      c1.ls();
+	    }
+	``````````
+	It produces below error.
+	``````````
+	no member named 'ls' in 'Column<&cstring, double>'.
+	``````````
+	Please note that error message contains '&' for cstring, which is absent
+	in actual program.
+	Clang++ does not generate & in such cases and this should also be
+	accepted as correct output.
+
+	gdb/testsuite/ChangeLog:
+
+		* gdb.cp/templates.exp: Accept different but correct output
+		from the Clang++ compiled binary also.
+
+2021-08-03  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-02  Tom Tromey  <tromey@adacore.com>
+
+	Handle compiler-generated suffixes in Ada names
+	The compiler may add a suffix to a mangled name.  A typical example
+	would be splitting a function and creating a ".cold" variant.
+
+	This patch changes Ada decoding (aka demangling) to handle these
+	suffixes.  It also changes the encoding process to handle them as
+	well.
+
+	A symbol like "function.cold" will now be displayed to the user as
+	"function[cold]".  The "." is not simply preserved because that is
+	already used in Ada.
+
+2021-08-02  Tom Tromey  <tromey@adacore.com>
+
+	Remove uses of fprintf_symbol_filtered
+	I believe that many calls to fprintf_symbol_filtered are incorrect.
+	In particular, there are some that pass a symbol's print name, like:
+
+	  fprintf_symbol_filtered (gdb_stdout, sym->print_name (),
+				   current_language->la_language, DMGL_ANSI);
+
+	fprintf_symbol_filtered uses the "demangle" global to decide whether
+	or not to demangle -- but print_name does this as well.  This can lead
+	to double-demangling.  Normally this could be innocuous, except I also
+	plan to change Ada demangling in a way that causes this to fail.
+
+2021-08-02  Tom Tromey  <tromey@adacore.com>
+
+	Handle type qualifier for enumeration name
+	Pierre-Marie noticed that the Ada expression "TYPE'(NAME)" resolved
+	incorrectly when "TYPE" was an enumeration type.  Here, "NAME" should
+	be unambiguous.
+
+	This patch fixes this problem.  Note that the patch is not perfect --
+	it does not give an error if TYPE is an enumeration type but NAME is
+	not an enumerator but does have some other meaning in scope.  Fixing
+	this proved difficult, and so I've left it out.
+
+2021-08-02  Tom Tromey  <tromey@adacore.com>
+
+	Remove the type_qualifier global
+	The type_qualifier global is no longer needed in the Ada expression
+	parser, so this removes it.
+
+2021-08-02  Tom Tromey  <tromey@adacore.com>
+
+	Defer Ada character literal resolution
+	In Ada, an enumeration type can use a character literal as one of the
+	enumerators.  The Ada expression parser handles the appropriate
+	conversion.
+
+	It turns out, though, that this conversion was handled incorrectly.
+	For an expression like TYPE'(EXP), the conversion would be done for
+	any such literal appearing in EXP -- but only the outermost such
+	expression should really be affected.
+
+	This patch defers the conversion until the resolution phase, fixing
+	the bug.
+
+2021-08-02  Tom Tromey  <tromey@adacore.com>
+
+	Refactor Ada resolution
+	In a subsequent patch, it will be convenient if an Ada expression
+	operation can supply its own replacement object.  This patch refactors
+	Ada expression resolution to make this possible.
+
+	Remove add_symbols_from_enclosing_procs
+	I noticed that add_symbols_from_enclosing_procs is empty, and can be
+	removed.  The one caller, ada_add_local_symbols, can also be
+	simplified, removing some code that, I think, was an incorrect attempt
+	to handle nested functions.
+
+2021-08-02  Tom Tromey  <tromey@adacore.com>
+
+	Avoid crash in varobj deletion
+	PR varobj/28131 points out a crash in the varobj deletion code.  It
+	took a while to reproduce this, but essentially what happens is that a
+	top-level varobj deletes its root object, then deletes the "dynamic"
+	object.  However, deletion of the dynamic object may cause
+	~py_varobj_iter to run, which in turn uses gdbpy_enter_varobj:
+
+	gdbpy_enter_varobj::gdbpy_enter_varobj (const struct varobj *var)
+	: gdbpy_enter (var->root->exp->gdbarch, var->root->exp->language_defn)
+	{
+	}
+
+	However, because var->root has already been destroyed, this is
+	invalid.
+
+	I've added a new test case.  This doesn't reliably crash, but the
+	problem can easily be seen under valgrind (and, I presume, with ASAN,
+	though I did not try this).
+
+	Tested on x86-64 Fedora 32.  I also propose putting this on the GDB 11
+	branch, with a suitable ChangeLog entry of course.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28131
+
+2021-08-02  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.dwarf2/dw2-using-debug-str.exp with cc-with-dwz-m
+	When running with target board cc-with-dwz-m, we run into:
+	...
+	(gdb) file dw2-using-debug-str-no-debug-str^M
+	Reading symbols from dw2-using-debug-str-no-debug-str...^M
+	(gdb) FAIL: gdb.dwarf2/dw2-using-debug-str.exp: file dw2-using-debug-str
+	...
+
+	With native, the .debug_str section is present in the
+	dw2-using-debug-str executable, and removed from the
+	dw2-using-debug-str-no-debug-str executable.  When loading the latter, a dwarf
+	error is triggered.
+
+	With cc-with-dwz-m, the .debug_str section is not present in the
+	dw2-using-debug-str executable, because it's already moved to
+	.tmp/dw2-using-debug-str.dwz.  Consequently, the removal has no effect, and no
+	dwarf error is triggered, which causes the FAIL.
+
+	The same problem arises with target board cc-with-gnu-debuglink.
+
+	Fix this by detecting whether the .debug_str section is missing, and skipping
+	the remainder of the test-case.
+
+	Tested on x86_64-linux.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-08-02  Tom de Vries  <tdevries@suse.de>
+
+		* gdb.dwarf2/dw2-using-debug-str.exp: Handle missing .debug_str
+		section in dw2-using-debug-str.
+
+2021-08-02  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.dwarf2/dw2-using-debug-str.exp with cc-with-gdb-index
+	When running with target board cc-with-gdb-index, we run into:
+	...
+	(gdb) file dw2-using-debug-str-no-debug-str^M
+	Reading symbols from dw2-using-debug-str-no-debug-str...^M
+	Dwarf Error: DW_FORM_strp used without required section^M
+	(gdb) FAIL: gdb.dwarf2/dw2-using-debug-str.exp: file dw2-using-debug-str
+	...
+
+	The test expects the dwarf error, but has no matching pattern for the entire
+	output.
+
+	Fix this by updating the regexp.
+
+	Tested on x86_64-linux.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-08-02  Tom de Vries  <tdevries@suse.de>
+
+		* gdb.dwarf2/dw2-using-debug-str.exp: Update regexp to match
+		cc-with-gdb-index output.
+
+2021-08-02  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.dwarf2/per-bfd-sharing.exp with cc-with-gdb-index
+	When running with target board cc-with-gdb-index, we run into:
+	...
+	rm: cannot remove '/tmp/tmp.JmYTeiuFjj/*.gdb-index': \
+	  No such file or directory^M
+	FAIL: gdb.dwarf2/per-bfd-sharing.exp: \
+	  couldn't remove files in temporary cache dir
+	...
+
+	Fix this, as in gdb.base/index-cache.exp, by only FAILing when
+	$expecting_index_cache_use.
+
+	Tested on x86_64-linux.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-08-02  Tom de Vries  <tdevries@suse.de>
+
+		* gdb.dwarf2/per-bfd-sharing.exp: Only expect index-cache files
+		when $expecting_index_cache_use.
+
+2021-08-02  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.dwarf2/gdb-index-nodebug.exp with cc-with-gdb-index
+	When running with target board cc-with-gdb-index, we run into:
+	...
+	(gdb) save gdb-index .^M
+	Error while writing index for `gdb-index-nodebug': \
+	  Cannot use an index to create the index^M
+	(gdb) FAIL: gdb.dwarf2/gdb-index-nodebug.exp: try to save gdb index
+	...
+
+	Fix this by detecting an already present index, and marking the test
+	unsupported.
+
+	Tested on x86_64-linux.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-08-02  Tom de Vries  <tdevries@suse.de>
+
+		* gdb.dwarf2/gdb-index-nodebug.exp: Mark unsupported when index
+		already present.
+
+2021-08-02  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.dwarf2/fission-relative-dwo.exp with cc-with-gdb-index
+	When running with target board cc-with-gdb-index, we run into:
+	...
+	gdb compile failed, warning: Could not find DWO CU \
+	  fission-relative-dwo.dwo(0x1234) referenced by CU at offset 0xc7 \
+	  [in module outputs/gdb.dwarf2/fission-relative-dwo/.tmp/fission-relative-dwo]
+	UNTESTED: gdb.dwarf2/fission-relative-dwo.exp: fission-relative-dwo.exp
+	ERROR: failed to compile fission-relative-dwo
+	...
+
+	The problem is that:
+	- the .dwo file is found relative to the executable, and
+	- cc-with-tweaks.sh moves the executable to a temp dir, but not
+	  the .dwo file.
+
+	Fix this by copying the .dwo file alongside the executable in the temp dir.
+
+	Verified changes using shellcheck.
+
+	Tested on x86_64-linux.
+
+	gdb/ChangeLog:
+
+	2021-08-02  Tom de Vries  <tdevries@suse.de>
+
+		* contrib/cc-with-tweaks.sh: Copy .dwo files alongside executable.
+
+2021-08-02  Shahab Vahedi  <shahab@synopsys.com>
+
+	gdb: Make the builtin "boolean" type an unsigned type
+	When printing the fields of a register that is of a custom struct type,
+	the "unpack_bits_as_long ()" function is used:
+
+	    do_val_print (...)
+	      cp_print_value_fields (...)
+	        value_field_bitfield (...)
+	          unpack_value_bitfield (...)
+	            unpack_bits_as_long (...)
+
+	This function may sign-extend the extracted field while returning it:
+
+	    val >>= lsbcount;
+
+	    if (...)
+	      {
+	        valmask = (((ULONGEST) 1) << bitsize) - 1;
+	        val &= valmask;
+	        if (!field_type->is_unsigned ())
+	  	  if (val & (valmask ^ (valmask >> 1)))
+	  	      val |= ~valmask;
+	      }
+
+	    return val;
+
+	lsbcount:   Number of lower bits to get rid of.
+	bitsize:    The bit length of the field to be extracted.
+	val:        The register value.
+	field_type: The type of field that is being handled.
+
+	While the logic here is correct, there is a problem when it is
+	handling "field_type"s of "boolean".  Those types are NOT marked
+	as "unsigned" and therefore they end up being sign extended.
+	Although this is not a problem for "false" (0), it definitely
+	causes trouble for "true".
+
+	This patch constructs the builtin boolean type as such that it is
+	marked as an "unsigned" entity.
+
+	The issue tackled here was first encountered for arc-elf32 target
+	running on an x86_64 machine.  The unit-test introduced in this change
+	has passed for all the targets (--enable-targets=all) running on the
+	same x86_64 host.
+
+	Fixes: https://sourceware.org/PR28104
+
+2021-08-02  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-08-01  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.base/maint.exp with cc-with-gdb-index
+	With target board cc-with-gdb-index we run into:
+	...
+	FAIL: gdb.base/maint.exp: maint print statistics
+	...
+
+	The output that is checked is:
+	...
+	Statistics for 'maint':^M
+	  Number of "minimal" symbols read: 53^M
+	  Number of "full" symbols read: 40^M
+	  Number of "types" defined: 60^M
+	  Number of symbol tables: 7^M
+	  Number of symbol tables with line tables: 2^M
+	  Number of symbol tables with blockvectors: 2^M
+	  Number of read CUs: 2^M
+	  Number of unread CUs: 5^M
+	  Total memory used for objfile obstack: 20320^M
+	  Total memory used for BFD obstack: 4064^M
+	  Total memory used for string cache: 4064^M
+	...
+	and the regexp doesn't match because it expects the "Number of read/unread
+	CUs" lines in a different place.
+
+	Fix this by updating the regexp.
+
+	Tested on x86_64-linux.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-08-01  Tom de Vries  <tdevries@suse.de>
+
+		* gdb.base/maint.exp: Update "maint print statistics" to match
+		output with target board cc-with-gdb-index.
+
+2021-08-01  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.base/index-cache.exp with cc-with-gdb-index
+	With target board cc-with-gdb-index we run into:
+	...
+	FAIL: gdb.base/index-cache.exp: couldn't remove files in temporary cache dir
+	...
+
+	The problem is that there are no files to remove, because the index cache
+	isn't used, as indicated by $expecting_index_cache_use.
+
+	Fix this by only FAILing when $expecting_index_cache_use.
+
+	Tested on x86_64-linux.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-08-01  Tom de Vries  <tdevries@suse.de>
+
+		* gdb.base/index-cache.exp:
+
+2021-08-01  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-31  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-30  Tom Tromey  <tom@tromey.com>
+
+	Use iterator_range in more places
+	This changes a couple of spots to replace custom iterator range
+	classes with a specialization of iterator_range.
+
+	Regression tested on x86-64 Fedora 34.
+
+2021-07-30  Tom Tromey  <tom@tromey.com>
+
+	Replace exception_print_same with operator!=
+	I noticed that exception_print_same is only used in a single spot, and
+	it seemed to be better as an operator!= method attached to
+	gdb_exception.
+
+	Regression tested on x86-64 Fedora 34.
+
+2021-07-30  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/build] Disable attribute nonnull
+	With trunk gcc (12.0) we're running into a -Werror=nonnull-compare build
+	breaker in gdb, which caused a broader review of the usage of the nonnull
+	attribute.
+
+	The current conclusion is that it's best to disable this.  This is explained
+	at length in the gdbsupport/common-defs.h comment.
+
+	Tested by building with trunk gcc.
+
+	gdb/ChangeLog:
+
+	2021-07-29  Tom de Vries  <tdevries@suse.de>
+
+		* gdbsupport/common-defs.h (ATTRIBUTE_NONNULL): Disable.
+
+2021-07-30  Clément Chigot  <clement.chigot@atos.net>
+
+	gas: ensure XCOFF DWARF subsection are initialized to 0
+	debug_abbrev doesn't use end_exp to compute its size. However, it must
+	be NULL. Otherwise, ppc_xcoff_end might try to access uninitialized
+	memory.
+
+	gas/
+		* config/tc-ppc.c (ppc_dwsect): Use XCNEW instead of XNEW when creating
+		a new subsection.
+
+2021-07-30  Clément Chigot  <clement.chigot@atos.net>
+
+	bfd: ensure that symbols targeted by DWARF relocations are kept in XCOFF
+	This patch improves XCOFF garbage collector pass, in order to keep
+	symbols being referenced only by special sections like DWARF sections.
+
+	bfd/
+		* xcofflink.c (xcoff_mark): Replace SEC_MARK by gc_mark.
+		Look through relocations even if xcoff_section_data is NULL.
+		(xcoff_sweep): Check if any sections of a file is kept before
+		adding its special sections.
+		Call xcoff_mark for special sessions being kept instead of just
+		marking them.
+		(SEC_MARK): Remove
+		(xcoff_mark_symbol): Replace SEC_MARK by gc_mark.
+		(xcoff_keep_symbol_p): Likewise.
+		(bfd_xcoff_size_dynamic_sections): Likewise.
+		(xcoff_find_tc0): Likewise.
+
+2021-07-30  Clément Chigot  <clement.chigot@atos.net>
+
+	bfd: avoid a crash when debug_section isn't created in XCOFF
+	bfd/
+		* xcofflink.c (bfd_xcoff_size_dynamic_sections):
+		Add check to know if debug_section is initialized.
+
+2021-07-30  Alan Modra  <amodra@gmail.com>
+
+	readelf: catch archive_file_size of -1
+	Fuzzers might put -1 in arhdr.ar_size.  If the size is rounded up to
+	and even number of bytes we get zero.
+
+		* readelf.c (process_archive): Don't round up archive_file_size.
+		Do round up next_arhdr_offset calculation.
+
+2021-07-30  Alan Modra  <amodra@gmail.com>
+
+	reloc_upper_bound size calculations
+	Section reloc_count is an unsigned int.  Adding one for a NULL
+	terminator to an array of arelent pointers can wrap the count to
+	zero.  Avoid that by doing the addition as longs.
+
+		* coffgen.c (coff_get_reloc_upper_bound): Don't overflow unsigned
+		int expression.
+		* elf.c (_bfd_elf_get_reloc_upper_bound): Likewise.
+		* elf64-sparc.c (elf64_sparc_get_reloc_upper_bound): Likewise.
+		* mach-o.c (bfd_mach_o_get_reloc_upper_bound): Likewise.
+		* vms-alpha.c (alpha_vms_get_reloc_upper_bound): Likewise.
+
+2021-07-30  Alan Modra  <amodra@gmail.com>
+
+	Sanity check _bfd_coff_read_string_table
+		* coffgen.c (_bfd_coff_read_string_table): Catch overflows
+		when calculating string table file location.
+
+2021-07-30  Alan Modra  <amodra@gmail.com>
+
+	IMAGE_SCN_LNK_NRELOC_OVFL
+	From microsoft docs: It is an error if IMAGE_SCN_LNK_NRELOC_OVFL is
+	set and there are fewer than 0xffff relocations in the section.
+
+		* coffcode.h (coff_set_alignment_hook): Sanity check overflow
+		reloc count.
+
+2021-07-30  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: fix nr_bits gdb_assert in append_flags_type_field
+	The assertion
+
+	    gdb_assert (nr_bits >= 1 && nr_bits <= type_bitsize);
+
+	is not correct.  Well, it's correct in that we do want the number of
+	bits to be in the range [1, type_bitsize].  But we don't check anywhere
+	that the end of the specified flag is within the containing type.
+
+	The following code should generate a failed assertion, as the flag goes
+	past the 32 bits of the underlying type, but it's currently not caught:
+
+	    static void
+	    test_print_flag (gdbarch *arch)
+	    {
+	      type *flags_type = arch_flags_type (arch, "test_type", 32);
+	      type *field_type = builtin_type (arch)->builtin_uint32;
+	      append_flags_type_field (flags_type, 31, 2, field_type, "invalid");
+	    }
+
+	(You can test this by registering it as a selftest using
+	selftests::register_test_foreach_arc and running.)
+
+	Change the assertion to verify that the end bit is within the range of
+	the underlying type.  This implicitly verifies that nr_bits is not
+	too big as well, so we don't need a separate assertion for that.
+
+	Change-Id: I9be79e5fd7a5917bf25b03b598727e6274c892e8
+	Co-Authored-By: Tony Tye <Tony.Tye@amd.com>
+
+2021-07-30  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-29  John Baldwin  <jhb@FreeBSD.org>
+
+	obsd-nat: Report both thread and PID in ::pid_to_str.
+	This improves the output of info threads when debugging multiple
+	inferiors (e.g. after a fork with detach_on_fork disabled).
+
+2021-07-29  John Baldwin  <jhb@FreeBSD.org>
+
+	obsd-nat: Various fixes for fork following.
+	- Don't use #ifdef's on ptrace ops.  obsd-nat.h didn't include
+	  <sys/ptrace.h>, so the virtual methods weren't always overridden
+	  causing the fork following to not work.  In addition, the thread and
+	  fork code is intertwined in ::wait and and the lack of #ifdef's
+	  there already assumed both were present.  Finally, both of these
+	  ptrace ops have been present in OpenBSD for at least 10 years.
+
+	- Move duplicated code to enable PTRACE_FORK event reporting to a
+	  single function and invoke it on new child processes reported via
+	  PTRACE_FORK.
+
+	- Don't return early from PTRACE_FORK handling, but instead reset
+	  wptid to the correct ptid if the child reports its event before the
+	  parent.  This allows the ptid fixup code to add thread IDs if the
+	  first event for a process is a PTRACE_FORK event.  This also
+	  properly returns ptid's with thread IDs when reporting PTRACE_FORK
+	  events.
+
+	- Handle detach_fork by skipping the PT_DETACH.
+
+2021-07-29  John Baldwin  <jhb@FreeBSD.org>
+
+	obsd-nat: Various fixes to obsd_nat_target::wait.
+	- Call inf_ptrace_target::wait instead of duplicating the code.
+	  Replace a check for WIFSTOPPED on the returned status from waitpid
+	  by checking for TARGET_WAITKIND_STOPPED in the parsed status as is
+	  done in fbsd_nat_target::wait.
+
+	- Don't use inferior_ptid when deciding if a new process is a child vs
+	  parent of the fork.  Instead, use find_inferior_pid and assume that
+	  if an inferior already exists, the pid in question is the parent;
+	  otherwise, the pid is the child.
+
+	- Don't use inferior_ptid when deciding if the ptid of the process
+	  needs to be updated with an LWP ID, or if this is a new thread.
+	  Instead, use the approach from fbsd-nat which is to check if a ptid
+	  without an LWP exists and if so update the ptid of that thread
+	  instead of adding a new thread.
+
+2021-07-29  John Baldwin  <jhb@FreeBSD.org>
+
+	x86-bsd-nat: Only define gdb_ptrace when using debug registers.
+	This fixes an unused function warning on OpenBSD which does not
+	support PT_GETDBREGS.
+
+2021-07-29  John Baldwin  <jhb@FreeBSD.org>
+
+	Don't compile x86 debug register support on OpenBSD.
+	Simon Marchi tried gdb on OpenBSD, and it immediately segfaults when
+	running a program.  Simon tracked down the problem to x86_dr_low.get_status
+	being nullptr at this point:
+
+	    (lldb) print x86_dr_low.get_status
+	    (unsigned long (*)()) $0 = 0x0000000000000000
+	    (lldb) bt
+	    * thread #1, stop reason = step over
+	      * frame #0: 0x0000033b64b764aa gdb`x86_dr_stopped_data_address(state=0x0000033d7162a310, addr_p=0x00007f7ffffc5688) at x86-dregs.c:645:12
+	        frame #1: 0x0000033b64b766de gdb`x86_dr_stopped_by_watchpoint(state=0x0000033d7162a310) at x86-dregs.c:687:10
+	        frame #2: 0x0000033b64ea5f72 gdb`x86_stopped_by_watchpoint() at x86-nat.c:206:10
+	        frame #3: 0x0000033b64637fbb gdb`x86_nat_target<obsd_nat_target>::stopped_by_watchpoint(this=0x0000033b65252820) at x86-nat.h:100:12
+	        frame #4: 0x0000033b64d3ff11 gdb`target_stopped_by_watchpoint() at target.c:468:46
+	        frame #5: 0x0000033b6469b001 gdb`watchpoints_triggered(ws=0x00007f7ffffc61c8) at breakpoint.c:4790:32
+	        frame #6: 0x0000033b64a8bb8b gdb`handle_signal_stop(ecs=0x00007f7ffffc61a0) at infrun.c:6072:29
+	        frame #7: 0x0000033b64a7e3a7 gdb`handle_inferior_event(ecs=0x00007f7ffffc61a0) at infrun.c:5694:7
+	        frame #8: 0x0000033b64a7c1a0 gdb`fetch_inferior_event() at infrun.c:4090:5
+	        frame #9: 0x0000033b64a51921 gdb`inferior_event_handler(event_type=INF_REG_EVENT) at inf-loop.c:41:7
+	        frame #10: 0x0000033b64a827c9 gdb`infrun_async_inferior_event_handler(data=0x0000000000000000) at infrun.c:9384:3
+	        frame #11: 0x0000033b6465bd4f gdb`check_async_event_handlers() at async-event.c:335:4
+	        frame #12: 0x0000033b65070917 gdb`gdb_do_one_event() at event-loop.cc:216:10
+	        frame #13: 0x0000033b64af0db1 gdb`start_event_loop() at main.c:421:13
+	        frame #14: 0x0000033b64aefe9a gdb`captured_command_loop() at main.c:481:3
+	        frame #15: 0x0000033b64aed5c2 gdb`captured_main(data=0x00007f7ffffc6470) at main.c:1353:4
+	        frame #16: 0x0000033b64aed4f2 gdb`gdb_main(args=0x00007f7ffffc6470) at main.c:1368:7
+	        frame #17: 0x0000033b6459d787 gdb`main(argc=5, argv=0x00007f7ffffc6518) at gdb.c:32:10
+	        frame #18: 0x0000033b6459d521 gdb`___start + 321
+
+	On BSDs, get_status is set in _initialize_x86_bsd_nat, but only if
+	HAVE_PT_GETDBREGS is defined.  PT_GETDBREGS doesn't exist on OpenBSD, so
+	get_status (and the other fields of x86_dr_low) are left as nullptr.
+
+	OpenBSD doesn't support getting or setting the x86 debug registers, so
+	fix by omitting debug register support entirely on OpenBSD:
+
+	- Change x86bsd_nat_target to only inherit from x86_nat_target if
+	  PT_GETDBREGS is supported.
+
+	- Don't include x86-nat.o and nat/x86-dregs.o for OpenBSD/amd64.  They
+	  were already omitted for OpenBSD/i386.
+
+2021-07-29  Carl Love  <cel@us.ibm.com>
+
+	Fix for gdb.tui/tui-layout-asm.exp
+	The width of the window is too narrow to display the entire assembly line.
+	The width of the columns in the window changes as the test walks thru the
+	terminal window output.  The column change results in the first and second
+	reads of the same line to differ thus causing the test to fail.  Increasing
+	the width of the window keeps the column width consistent thru the test.
+
+	If the test fails, the added check prints an message to the log file if
+	the failure may be due to the window being too narrow.
+
+	gdb/testsuite/ChangeLog
+
+		* gdb.tui/tui-layout-asm.exp: Replace window width of 80 with the
+		tui_asm_window_width variable for the width. Add if
+		count_whitespace check.
+		(count_whitespace): New proc
+
+2021-07-29  George Barrett  <bob@bob131.so>
+
+	guile/scm-math: indentation fixes
+	Changes the indenting of a few expressions in
+	vlscm_convert_typed_number to be better in line with the prevailing
+	code style.
+
+	gdb/ChangeLog:
+
+	2021-07-30  George Barrett  <bob@bob131.so>
+
+		* guile/scm-math.c (vlscm_convert_typed_number): Fix the
+		indentation of calls to gdbscm_make_out_of_range_error.
+
+	Change-Id: I7463998b77c17a00e88058e89b52fa029ee40e03
+
+2021-07-29  George Barrett  <bob@bob131.so>
+
+	guile: fix make-value with pointer type
+	Calling the `make-value' procedure with an integer value and a pointer
+	type for the #:type argument triggers a failed assertion in
+	`get_unsigned_type_max', as that function doesn't consider pointers to
+	be an unsigned type. This commit fixes the issue by adding a separate
+	code path for pointers.
+
+	As previously suggested, range checking is done using a new helper
+	function in gdbtypes.
+
+	gdb/ChangeLog:
+
+	2021-07-30  George Barrett  <bob@bob131.so>
+
+		* gdbtypes.h (get_pointer_type_max): Add declaration.
+		* gdbtypes.c (get_pointer_type_max): Add definition for new
+		helper function.
+		* guile/scm-math.c (vlscm_convert_typed_number): Add code path
+		for handling conversions to pointer types without failing an
+		assert.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-07-30  George Barrett  <bob@bob131.so>
+
+		* gdb.guile/scm-math.exp (test_value_numeric_ops): Add test
+		for creating pointers with make-value.
+		(test_make_pointer_value, test_pointer_numeric_range): Add
+		test procedures containing checks for integer-to-pointer
+		validation.
+
+	Change-Id: I9994dd1c848840a3d995f745e6d72867732049f0
+
+2021-07-29  George Barrett  <bob@bob131.so>
+
+	gdbtypes: return value from get_unsigned_type_max
+	Changes the signature of get_unsigned_type_max to return the computed
+	value rather than returning void and writing the value into a pointer
+	passed by the caller.
+
+	gdb/ChangeLog:
+
+	2021-07-30  George Barrett  <bob@bob131.so>
+
+		* gdbtypes.h (get_unsigned_type_max): Change signature to
+		return the result instead of accepting a pointer argument in
+		which to store the result.
+		* gdbtypes.c (get_unsigned_type_max): Likewise.
+		* guile/scm-math.c (vlscm_convert_typed_number): Update caller
+		of get_unsigned_type_max.
+		(vlscm_integer_fits_p): Likewise.
+
+	Change-Id: Ibb1bf0c0fa181fac7853147dfde082a7d1ae2323
+
+2021-07-29  Clément Chigot  <clement.chigot@atos.net>
+
+	gas: improve C_BSTAT and C_STSYM symbols handling on XCOFF
+	A C_BSTAT debug symbol specifies the beginning of a static block.
+	Its n_value is the index of the csect containing static symbols.
+	A C_STSYM debug symbol represents the stabstring of a statically
+	allocated symbol. Its n_value is the offset in the csect pointed
+	by the containing C_BSTAT.
+
+	These two special n_value were not correctly handled both when
+	generating object files with gas or when reading them with objdump.
+	This patch tries to improve that and, above all, to allow gas-generated
+	object files with such symbols to be accepted by AIX ld.
+
+	bfd/
+		* coff-bfd.c (bfd_coff_get_syment): Adjust n_value of symbols
+		having fix_value = 1 in order to be an index and not a memory
+		offset.
+		* coffgen.c (coff_get_symbol_info): Likewize.
+		(coff_print_symbol): Likewize.
+
+	gas/
+		* config/tc-ppc.c (ppc_frob_label): Don't change within if
+		already set.
+		(ppc_stabx): Remove workaround changing exp.X_add_symbol's
+		within.
+		* config/tc-ppc.h (struct ppc_tc_sy): Update comments.
+		* symbols.c (resolve_symbol_value): Remove symbol update
+		when final_val is 0 and it's an AIX debug symbol.
+		* testsuite/gas/ppc/aix.exp: Add new tests.
+		* testsuite/gas/ppc/xcoff-stsym-32.d: New test.
+		* testsuite/gas/ppc/xcoff-stsym-64.d: New test.
+		* testsuite/gas/ppc/xcoff-stsym.s: New test.
+
+2021-07-29  George Barrett  <bob@bob131.so>
+
+	Guile: temporary breakpoints
+	Adds API to the Guile bindings for creating temporary breakpoints and
+	querying whether an existing breakpoint object is temporary. This is
+	effectively a transliteration of the Python implementation.
+
+	It's worth noting that the added `is_temporary' flag is ignored in the
+	watchpoint registration path. This replicates the behaviour of the
+	Python implementation, but might be a bit surprising for users.
+
+	gdb/ChangeLog:
+
+	2021-06-09  George Barrett  <bob@bob131.so>
+
+		* guile/scm-breakpoint.c (gdbscm_breakpoint_object::spec): Add
+		is_temporary field.
+		(temporary_keyword): Add keyword object for make-breakpoint
+		argument parsing.
+		(gdbscm_make_breakpoint): Accept #:temporary keyword argument
+		and store the value in the allocated object's
+		spec.is_temporary.
+		(gdbscm_register_breakpoint_x): Pass the breakpoint's
+		spec.is_temporary value to create_breakpoint.
+		(gdbscm_breakpoint_temporary): Add breakpoint-temporary?
+		procedure implementation.
+		(breakpoint_functions::make-breakpoint): Update documentation
+		string and fix a typo.
+		(breakpoint_functions::breakpoint-temporary?): Add
+		breakpoint-temporary? procedure.
+		(gdbscm_initialize_breakpoints): Initialise temporary_keyword
+		variable.
+		NEWS (Guile API): Mention new temporary breakpoints API.
+
+	gdb/doc/ChangeLog:
+
+	2021-06-09  George Barrett  <bob@bob131.so>
+
+		* guile.texi (Breakpoints In Guile): Update make-breakpoint
+		documentation to reflect new #:temporary argument.
+		Add documentation for new breakpoint-temporary? procedure.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-06-09  George Barrett  <bob@bob131.so>
+
+		* gdb.guile/scm-breakpoint.exp: Add additional tests for
+		temporary breakpoints.
+
+	Change-Id: I2de332ee7c256f5591d7141ab3ad50d31b871d17
+
+2021-07-29  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-28  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: clean up some things in features/Makefile
+	Clean up some things I noticed:
+
+	 - we generate a regformats/microblaze-with-stack-protect.dat file.  I
+	   don't think this is used.  It could be used by a GDBserver built for
+	   Microblaze, but GDBserver isn't ported to Microblaze.  So I don't
+	   think that's used at all.  Remove the entry in features/Makefile and
+	   the file itself.
+
+	 - There are a bunch of *-expedite values in features/Makefile for
+	   architectures for which we don't generate dat files.  AFAIK, these
+	   *-expedite values are only used when generating dat files.  Remove
+	   those that are not necessary.
+
+	 - 32bit-segments.xml is not listed in the Makfile, but it's used.  This
+	   means that it wouldn't get re-generated if we were to change how C
+	   files are generated from the XML.  It looks like it was simply
+	   forgotten, add it.
+
+	Change-Id: I112d00db317102270e1df924473c37122ccb6c3a
+
+2021-07-28  H.J. Lu  <hjl.tools@gmail.com>
+
+	x86: Simplify check for distinct TMM register operands
+	If any pair of operands in AMX instructions with 3 TMM register operands
+	are the same, the instruction will UD.  Don't call register_number to
+	check for distinct TMM register operands since all TMM register operands
+	have the same size.
+
+		* config/tc-i386.c (check_VecOperands): Remove register_number
+		call when checking for distinct TMM register operands.
+
+2021-07-28  H.J. Lu  <hjl.tools@gmail.com>
+
+	ld: Run tmpdir/pr28138 only for native build
+		* PR ld/28138
+		* testsuite/ld-plugin/lto.exp: Run tmpdir/pr28138 only for
+		native build.
+
+2021-07-28  H.J. Lu  <hjl.tools@gmail.com>
+
+	bfd: Close the file descriptor if there is no archive fd
+	Close the file descriptor if there is no archive plugin file descriptor
+	to avoid running out of file descriptors on thin archives with many
+	archive members.
+
+	bfd/
+
+		PR ld/28138
+		* plugin.c (bfd_plugin_close_file_descriptor): Close the file
+		descriptor there is no archive plugin file descriptor.
+
+	ld/
+
+		PR ld/28138
+		* testsuite/ld-plugin/lto.exp: Run ld/28138 tests.
+		* testsuite/ld-plugin/pr28138.c: New file.
+		* testsuite/ld-plugin/pr28138-1.c: Likewise.
+		* testsuite/ld-plugin/pr28138-2.c: Likewise.
+		* testsuite/ld-plugin/pr28138-3.c: Likewise.
+		* testsuite/ld-plugin/pr28138-4.c: Likewise.
+		* testsuite/ld-plugin/pr28138-5.c: Likewise.
+		* testsuite/ld-plugin/pr28138-6.c: Likewise.
+		* testsuite/ld-plugin/pr28138-7.c: Likewise.
+
+2021-07-28  H.J. Lu  <hjl.tools@gmail.com>
+
+	ld: Report error reason when a library cannot be found
+	With "ulimit -n 20", report:
+
+	ld: cannot find -lgcc: Too many open files
+
+	instead of
+
+	ld: cannot find -lgcc
+
+		* ldfile.c (ldfile_open_file): Rport error reason when a library
+		cannot be found.
+
+2021-07-28  Sergei Trofimovich  <siarheit@google.com>
+
+	texi2pod.pl: add no-op --no-split option support [PR28144]
+	Change 2faf902da ("generate single html manual page by default")
+	added use of --no-split option to makeinfo. binutils reuses
+	makeinfo options for texi2pod.pl wrapper. Unsupported option
+	led to silent manpage truncation.
+
+	The change adds no-op option support.
+
+	etc/
+
+		* texi2pod.pl: Handle no-op --no-split option.
+
+2021-07-28  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: fix missing space in some info variables output
+	Fixes PR gdb/28121.  When a user declares an array like this:
+
+	  int * const foo_1[3];
+
+	And in GDB the user does this:
+
+	  (gdb) info variables foo
+	  All variables matching regular expression "foo":
+
+	  File test.c:
+	  1:	int * constfoo_1[3];
+
+	Notice the missing space between 'const' and 'foo_1'.  This is fixed
+	in c_type_print_varspec_prefix (c-typeprint.c) by passing through the
+	flag that indicates if a trailing space is needed, rather than hard
+	coding the flag to false as we currently do.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28121
+
+2021-07-28  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/symtab] Fix unhandled dwarf expression opcode with gcc-11 -gdwarf-5
+	[ I've confused things by forgetting to add -gdwarf-4 in $subject of
+	commit 0057a7ee0d9 "[gdb/testsuite] Add KFAILs for gdb.ada FAILs with
+	gcc-11".  So I'm adding here -gdwarf-5 in $subject, even though -gdwarf-5 is
+	the default for gcc-11.  I keep getting confused because of working with a
+	system gcc-11 compiler that was patched to switch the default back to
+	-gdwarf-4. ]
+
+	When running test-case gdb.ada/arrayptr.exp with gcc-11 (and default
+	-gdwarf-5), I run into:
+	...
+	(gdb) print pa_ptr.all^M
+	Unhandled dwarf expression opcode 0xff^M
+	(gdb) FAIL: gdb.ada/arrayptr.exp: scenario=all: print pa_ptr.all
+	...
+
+	What happens is that pa_ptr:
+	...
+	 <2><1523>: Abbrev Number: 3 (DW_TAG_variable)
+	    <1524>   DW_AT_name        : pa_ptr
+	    <1529>   DW_AT_type        : <0x14fa>
+	...
+	has type:
+	...
+	 <2><14fa>: Abbrev Number: 2 (DW_TAG_typedef)
+	    <14fb>   DW_AT_name        : foo__packed_array_ptr
+	    <1500>   DW_AT_type        : <0x1504>
+	 <2><1504>: Abbrev Number: 4 (DW_TAG_pointer_type)
+	    <1505>   DW_AT_byte_size   : 8
+	    <1505>   DW_AT_type        : <0x1509>
+	...
+	which is a pointer to a subrange:
+	...
+	 <2><1509>: Abbrev Number: 12 (DW_TAG_subrange_type)
+	    <150a>   DW_AT_lower_bound : 0
+	    <150b>   DW_AT_upper_bound : 0x3fffffffffffffffff
+	    <151b>   DW_AT_name        : foo__packed_array
+	    <151f>   DW_AT_type        : <0x15cc>
+	    <1523>   DW_AT_artificial  : 1
+	 <1><15cc>: Abbrev Number: 5 (DW_TAG_base_type)
+	    <15cd>   DW_AT_byte_size   : 16
+	    <15ce>   DW_AT_encoding    : 7      (unsigned)
+	    <15cf>   DW_AT_name        : long_long_long_unsigned
+	    <15d3>   DW_AT_artificial  : 1
+	...
+	with upper bound of form DW_FORM_data16.
+
+	In gdb/dwarf/attribute.h we have:
+	...
+	  /* Return non-zero if ATTR's value falls in the 'constant' class, or
+	     zero otherwise.  When this function returns true, you can apply
+	     the constant_value method to it.
+	     ...
+	     DW_FORM_data16 is not considered as constant_value cannot handle
+	     that.  */
+	  bool form_is_constant () const;
+	...
+	so instead we have attribute::form_is_block (DW_FORM_data16) == true.
+
+	Then in attr_to_dynamic_prop for the upper bound, we get a PROC_LOCEXPR
+	instead of a PROP_CONST and end up trying to evaluate the constant
+	0x3fffffffffffffffff as if it were a locexpr, which causes the
+	"Unhandled dwarf expression opcode 0xff".
+
+	In contrast, with -gdwarf-4 we have:
+	...
+	    <164c>   DW_AT_upper_bound : 18 byte block: \
+	      9e 10 ff ff ff ff ff ff ff ff 3f 0 0 0 0 0 0 0 \
+	      (DW_OP_implicit_value 16 byte block: \
+	        ff ff ff ff ff ff ff ff 3f 0 0 0 0 0 0 0 )
+	...
+
+	Fix the dwarf error by translating the DW_FORM_data16 constant into a
+	PROC_LOCEXPR, effectively by prepending 0x9e 0x10, such that we have same
+	result as with -gdwarf-4:
+	...
+	(gdb) print pa_ptr.all^M
+	That operation is not available on integers of more than 8 bytes.^M
+	(gdb) KFAIL: gdb.ada/arrayptr.exp: scenario=all: print pa_ptr.all \
+	  (PRMS: gdb/20991)
+	...
+
+	Tested on x86_64-linux, with gcc-11 and target board
+	unix/gdb:debug_flags=-gdwarf-5.
+
+	gdb/ChangeLog:
+
+	2021-07-25  Tom de Vries  <tdevries@suse.de>
+
+		* dwarf2/read.c (attr_to_dynamic_prop): Handle DW_FORM_data16.
+
+2021-07-28  will schmidt  <will_schmidt@vnet.ibm.com>
+
+	Externalize the _bfd_set_gp_value function
+	This change adds an external-visible wrapper for the _bfd_set_gp_value
+	function.  This is a prerequisite for some gdb patches that better
+	handle powerpc64le relocations against ".TOC.".
+
+		* bfd.c (bfd_set_gp_value): New externally visible wrapper
+		for _bfd_set_gp_value.
+		* bfd-in2.h: Regenerate.
+
+2021-07-28  Alan Modra  <amodra@gmail.com>
+
+	PowerPC: ignore sticky options for .machine
+	PowerPC gas and objdump for a long time have allowed certain -m/-M
+	options that extend a base cpu with extra functional units to be
+	specified before the base cpu.  For example, "-maltivec -mpower4" is
+	the same as "-mpower4 -maltivec".  See
+	https://sourceware.org/pipermail/binutils/2008-January/054935.html
+
+	It doesn't make as much sense that .machine keep any of these
+	"sticky" flags when handling a new base cpu.  See gcc PR101393.  I
+	think that instead .machine ought to override the command line.
+	That's what this patch does.  It is still possible to extend cpu
+	functionality with .machine.  For example the following can be
+	assembled when selecting a basic -mppc on the command line:
+		.machine power5
+		.machine altivec
+		frin 1,2
+		lvsr 3,4,5
+	Here, ".machine altivec" extends the ".machine power5" so that both
+	the power5 "frin" instruction and the altivec "lvsr" instruction are
+	enabled.  Swapping the two ".machine" directives would result in
+	failure to assemble "lvsr".
+
+	This change will expose some assembly errors, such as the one in
+	glibc/sysdeps/powerpc/powerpc64/tst-ucontext-ppc64-vscr.c, a file
+	compiled with -maltivec but containing
+	  asm volatile (".machine push;\n"
+			".machine \"power5\";\n"
+			"vspltisb %0,0;\n"
+			"vspltisb %1,-1;\n"
+			"vpkuwus %0,%0,%1;\n"
+			"mfvscr %0;\n"
+			"stvx %0,0,%2;\n"
+			".machine pop;"
+			: "=v" (v0), "=v" (v1)
+			: "r" (vscr_ptr)
+			: "memory");
+	It's just wrong to choose power5 for a bunch of altivec instructions
+	and in fact all of those .machine directives are unnecessary.
+
+		* config/tc-ppc.c (ppc_machine): Don't use command line
+		sticky options.
+
+2021-07-28  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-27  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Add xfail for PR gcc/101643
+	With gcc 8.5.0 I run into:
+	...
+	(gdb) print bad^M
+	$2 = (0 => 0 <repeats 25 times>)^M
+	(gdb) FAIL: gdb.ada/big_packed_array.exp: scenario=minimal: print bad
+	...
+	while with gcc 9.3.1 we have instead:
+	...
+	(gdb) print bad^M
+	$2 = (false <repeats 196 times>)^M
+	(gdb) PASS: gdb.ada/big_packed_array.exp: scenario=minimal: print bad
+	...
+
+	This is caused by gcc PR, which I've filed at
+	https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101643 "[debug, ada] packed array
+	not described as packed".
+
+	Fix by marking this as XFAIL.
+
+	Tested on x86_64-linux.
+
+	gdb/ChangeLog:
+
+	2021-07-27  Tom de Vries  <tdevries@suse.de>
+
+		PR testsuite/26904
+		* gdb/testsuite/gdb.ada/big_packed_array.exp: Add xfail.
+
+2021-07-27  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Add xfail for PR gcc/101633
+	With gcc 7.5.0, I run into:
+	...
+	(gdb) print objects^M
+	$1 = ((tag => object, values => ()), (tag => unused))^M
+	(gdb) FAIL: gdb.ada/array_of_variant.exp: scenario=minimal: print entire array
+	...
+	while with gcc 8.5.0 we have:
+	...
+	(gdb) print objects^M
+	$1 = ((tag => object, values => (2, 2, 2, 2, 2)), (tag => unused))^M
+	(gdb) PASS: gdb.ada/array_of_variant.exp: scenario=minimal: print entire array
+	...
+
+	This is due to a gcc PR, which I've filed at
+	https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101633 "Bug 101633 - [debug]
+	DW_TAG_subrange_type missing DW_AT_upper_bound".
+
+	Fix by marking this and related FAILs as XFAIL.
+
+	Tested on x86_64-linux.
+
+	gdb/ChangeLog:
+
+	2021-07-27  Tom de Vries  <tdevries@suse.de>
+
+		PR testsuite/26903
+		* gdb/testsuite/gdb.ada/array_of_variant.exp: Add xfails.
+
+2021-07-27  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: remove VALUE_FRAME_ID and fix another frame debug issue
+	This commit was originally part of this patch series:
+
+	  (v1): https://sourceware.org/pipermail/gdb-patches/2021-May/179357.html
+	  (v2): https://sourceware.org/pipermail/gdb-patches/2021-June/180208.html
+	  (v3): https://sourceware.org/pipermail/gdb-patches/2021-July/181028.html
+
+	However, that series is being held up in review, so I wanted to break
+	out some of the non-related fixes in order to get these merged.
+
+	This commit addresses two semi-related issues, both of which are
+	problems exposed by using 'set debug frame on'.
+
+	The first issue is in frame.c in get_prev_frame_always_1, and was
+	introduced by this commit:
+
+	  commit a05a883fbaba69d0f80806e46a9457727fcbe74c
+	  Date:   Tue Jun 29 12:03:50 2021 -0400
+
+	      gdb: introduce frame_debug_printf
+
+	This commit replaced fprint_frame with frame_info::to_string.
+	However, the former could handle taking a nullptr while the later, a
+	member function, obviously requires a non-nullptr in order to make the
+	function call.  In one place we are not-guaranteed to have a
+	non-nullptr, and so, there is the possibility of triggering undefined
+	behaviour.
+
+	The second issue addressed in this commit has existed for a while in
+	GDB, and would cause this assertion:
+
+	  gdb/frame.c:622: internal-error: frame_id get_frame_id(frame_info*): Assertion `fi->this_id.p != frame_id_status::COMPUTING' failed.
+
+	We attempt to get the frame_id for a frame while we are computing the
+	frame_id for that same frame.
+
+	What happens is that when GDB stops we create a frame_info object for
+	the sentinel frame (frame #-1) and then we attempt to unwind this
+	frame to create a frame_info object for frame #0.
+
+	In the test case used here to expose the issue we have created a
+	Python frame unwinder.  In the Python unwinder we attemt to read the
+	program counter register.
+
+	Reading this register will initially create a lazy register value.
+	The frame-id stored in the lazy register value will be for the
+	sentinel frame (lazy register values hold the frame-id for the frame
+	from which the register will be unwound).
+
+	However, the Python unwinder does actually want to examine the value
+	of the program counter, and so the lazy register value is resolved
+	into a non-lazy value.  This sends GDB into value_fetch_lazy_register
+	in value.c.
+
+	Now, inside this function, if 'set debug frame on' is in effect, then
+	we want to print something like:
+
+	  frame=%d, regnum=%d(%s), ....
+
+	Where 'frame=%d' will be the relative frame level of the frame for
+	which the register is being fetched, so, in this case we would expect
+	to see 'frame=0', i.e. we are reading a register as it would be in
+	frame #0.  But, remember, the lazy register value actually holds the
+	frame-id for frame #-1 (the sentinel frame).
+
+	So, to get the frame_info for frame #0 we used to call:
+
+	  frame = frame_find_by_id (VALUE_FRAME_ID (val));
+
+	Where VALUE_FRAME_ID is:
+
+	  #define VALUE_FRAME_ID(val) (get_prev_frame_id_by_id (VALUE_NEXT_FRAME_ID (val)))
+
+	That is, we start with the frame-id for the next frame as obtained by
+	VALUE_NEXT_FRAME_ID, then call get_prev_frame_id_by_id to get the
+	frame-id of the previous frame.
+
+	The get_prev_frame_id_by_id function finds the frame_info for the
+	given frame-id (in this case frame #-1), calls get_prev_frame to get
+	the previous frame, and then calls get_frame_id.
+
+	The problem here is that calling get_frame_id requires that we know
+	the frame unwinder, so then have to try each frame unwinder in turn,
+	which would include the Python unwinder.... which is where we started,
+	and thus we have a loop!
+
+	To prevent this loop GDB has an assertion in place, which is what
+	actually triggers.
+
+	Solving the assertion failure is pretty easy, if we consider the code
+	in value_fetch_lazy_register and get_prev_frame_id_by_id then what we
+	do is:
+
+	  1. Start with a frame_id taken from a value,
+	  2. Lookup the corresponding frame,
+	  3. Find the previous frame,
+	  4. Get the frame_id for that frame, and
+	  5. Lookup the corresponding frame
+	  6. Print the frame's level
+
+	Notice that steps 3 and 5 give us the exact same result, step 4 is
+	just wasted effort.  We could shorten this process such that we drop
+	steps 4 and 5, thus:
+
+	  1. Start with a frame_id taken from a value,
+	  2. Lookup the corresponding frame,
+	  3. Find the previous frame,
+	  6. Print the frame's level
+
+	This will give the exact same frame as a result, and this is what I
+	have done in this patch by removing the use of VALUE_FRAME_ID from
+	value_fetch_lazy_register.
+
+	Out of curiosity I looked to see how widely VALUE_FRAME_ID was used,
+	and saw it was only used in one other place in valops.c:value_assign,
+	where, once again, we take the result of VALUE_FRAME_ID and pass it to
+	frame_find_by_id, thus introducing a redundant frame_id lookup.
+
+	I don't think the value_assign case risks triggering the assertion
+	though, as we are unlikely to call value_assign while computing the
+	frame_id for a frame, however, we could make value_assign slightly
+	more efficient, with no real additional complexity, by removing the
+	use of VALUE_FRAME_ID.
+
+	So, in this commit, I completely remove VALUE_FRAME_ID, and replace it
+	with a use of VALUE_NEXT_FRAME_ID, followed by a direct call to
+	get_prev_frame_always, this should make no difference in either case,
+	and resolves the assertion issue from value.c.
+
+	As I said, this patch was originally part of another series, the
+	original test relied on the fixes in that original series.  However, I
+	was able to create an alternative test for this issue by enabling
+	frame debug within an existing test script.
+
+	This commit probably fixes bug PR gdb/27938, though the bug doesn't
+	have a reproducer attached so it is not possible to know for sure.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27938
+
+2021-07-27  Chenghua Xu  <xuchenghua@loongson.cn>
+
+	Correct gs264e bfd_mach in mips_arch_choices.
+	opcodes/
+	    * mips-dis.c (mips_arch_choices): Correct gs264e bfd_mach.
+
+2021-07-27  Roland McGrath  <mcgrathr@google.com>
+
+	Fix ld test case that assumes --enable-textrel-check
+	ld/
+		* testsuite/ld-x86-64/x86-64.exp (Build textrel-1): Use --warn-textrel.
+
+2021-07-27  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-27  H.J. Lu  <hjl.tools@gmail.com>
+
+	bfd: Set error to bfd_error_malformed_archive only if unset
+	When reading an archive member, set error to bfd_error_malformed_archive
+	on open_nested_file failure only if the error is unset.
+
+		PR ld/28138
+		* archive.c (_bfd_get_elt_at_filepos): Don't set error to
+		bfd_error_malformed_archive if it has been set.
+
+2021-07-26  Carl Love  <cel@us.ibm.com>
+
+	Fix for mi-reverse.exp
+	This test fails on PPC64 because PPC64 prints the value of 3.5 with
+	more significant digits than on Intel. The patch updates the regular
+	expression to allow for more significant digits on the constant.
+
+	gdb/testsuite/ChangeLog
+
+		* gdb.mi/mi-reverse.exp: mi_execute_to exec-step reverse add check
+		for additional digits.
+
+2021-07-26  Tom Tromey  <tromey@adacore.com>
+
+	Fix the Windows build
+	The gdb build was broken on Windows after the patch to change
+	get_inferior_cwd.  This patch fixes the build.
+
+2021-07-26  Shahab Vahedi  <shahab@synopsys.com>
+
+	gdb: Fix numerical field extraction for target description "flags"
+	The "val_print_type_code_flags ()" function is responsible for
+	extraction of fields for "flags" data type.  These data types are
+	used when describing a custom register type in a target description
+	XML.  The logic used for the extraction though is not sound:
+
+	    unsigned field_len = TYPE_FIELD_BITSIZE (type, field);
+	    ULONGEST field_val
+	      = val >> (TYPE_FIELD_BITPOS (type, field) - field_len + 1);
+
+	TYPE_FIELD_BITSIZE: The bit length of the field to be extracted.
+	TYPE_FIELD_BITPOS:  The starting position of the field; 0 is LSB.
+	val:                The register value.
+
+	Imagine you have a field that starts at position 1 and its length
+	is 4 bits.  According to the third line of the code snippet the
+	shifting right would become "val >> -2", or "val >> 0xfff...fe"
+	to be precise.  That will result in a "field_val" of 0.
+
+	The correct extraction should be:
+
+	    ULONGEST field_val = val >> TYPE_FIELD_BITPOS (type, field);
+
+	The rest of the algorithm that masks out the higher bits is OK.
+
+	Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
+
+2021-07-26  Andrea Corallo  <andrea.corallo@arm.com>
+
+	PATCH [10/10] arm: Alias 'ra_auth_code' to r12 for pacbti.
+	gas/
+	2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* config/tc-arm.c (reg_names): Alias 'ra_auth_code' to r12.
+
+2021-07-26  Andrea Corallo  <andrea.corallo@arm.com>
+
+	PATCH [9/10] arm: add 'pacg' instruction for Armv8.1-M pacbti extension
+	gas/
+	2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* config/tc-arm.c (T16_32_TAB): Add '_pacg'.
+		(do_t_pacbti_pacg): New function.
+		(insns): Define 'pacg' insn.
+		* testsuite/gas/arm/armv8_1-m-pacbti.d: Add 'pacg' test.
+		* testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise.
+
+	opcodes/
+	2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* arm-dis.c (thumb32_opcodes): Add 'pacg'.
+
+2021-07-26  Andrea Corallo  <andrea.corallo@arm.com>
+
+	PATCH [8/10] arm: add 'autg' instruction for Armv8.1-M pacbti extension
+	gas/
+	2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* config/tc-arm.c (T16_32_TAB): Add '_autg'.
+		(insns): Define 'autg' insn.
+		* testsuite/gas/arm/armv8_1-m-pacbti.d: Add autg test.
+		* testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise.
+
+	opcodes/
+	2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* arm-dis.c (thumb32_opcodes): Add 'autg'.
+
+2021-07-26  Andrea Corallo  <andrea.corallo@arm.com>
+
+	PATCH [7/10] arm: add 'bxaut' instruction for Armv8.1-M pacbti extension
+	gas/
+	2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* config/tc-arm.c (T16_32_TAB): Add '_bxaut'.
+		(do_t_pacbti_nonop): New function.
+		(insns): Define 'bxaut' insn.
+		* testsuite/gas/arm/armv8_1-m-pacbti.d: Add 'bxaut' test.
+		* testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise.
+
+	opcodes/
+	2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* arm-dis.c (thumb32_opcodes): Add 'bxaut'.
+
+2021-07-26  Andrea Corallo  <andrea.corallo@arm.com>
+
+	PATCH [6/10] arm: Add -march=armv8.1-m.main+pacbti flag
+	gas/
+	2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* config/tc-arm.c (pacbti_ext): Define.
+		(BAD_PACBTI): New macro.
+		(armv8_1m_main_ext_table): Add 'pacbti' extension.
+
+	include/
+	2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* opcode/arm.h (ARM_EXT3_PACBTI, ARM_AEXT3_V8_1M_MAIN_PACBTI): New
+		macro.
+
+2021-07-26  Andrea Corallo  <andrea.corallo@arm.com>
+
+	PATCH [5/10] arm: Extend again arm_feature_set struct to provide more bits
+	include/
+	2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* opcode/arm.h (arm_feature_set): Extend 'core' field.
+		(ARM_CPU_HAS_FEATURE, ARM_FSET_CPU_SUBSET, ARM_CPU_IS_ANY)
+		(ARM_MERGE_FEATURE_SETS, ARM_CLEAR_FEATURE, ARM_FEATURE_EQUAL)
+		(ARM_FEATURE_ZERO, ARM_FEATURE_CORE_EQUAL): Account for
+		'core[2]'.
+		(ARM_FEATURE_CORE_HIGH_HIGH): New macro.
+
+2021-07-26  Andrea Corallo  <andrea.corallo@arm.com>
+
+	PATCH [4/10] arm: add 'pac' instruction for Armv8.1-M pacbti extension
+	gas/
+	2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* config/tc-arm.c (T16_32_TAB): Add '_pac'.
+		(insns): Add 'pac' insn.
+		* testsuite/gas/arm/armv8_1-m-pacbti-bad.l: Add pac tests.
+		* testsuite/gas/arm/armv8_1-m-pacbti-bad.s: Likewise.
+		* testsuite/gas/arm/armv8_1-m-pacbti.d: Likewise.
+		* testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise.
+
+	opcodes/
+	2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* arm-dis.c (thumb32_opcodes): Add 'pac'.
+
+2021-07-26  Andrea Corallo  <andrea.corallo@arm.com>
+
+	PATCH [3/10] arm: add 'aut' instruction for Armv8.1-M pacbti extension
+	gas/
+	2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* config/tc-arm.c (insns): Add 'aut.'
+		(T16_32_TAB): Add '_aut'.
+		* testsuite/gas/arm/armv8_1-m-pacbti-bad.l: Add 'aut' tests.
+		* testsuite/gas/arm/armv8_1-m-pacbti-bad.s: Likewise.
+		* testsuite/gas/arm/armv8_1-m-pacbti.d: Likewise.
+		* testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise.
+
+	opcodes/
+	2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* arm-dis.c (thumb32_opcodes): Add 'aut'.
+
+2021-07-26  Andrea Corallo  <andrea.corallo@arm.com>
+
+	PATCH [2/10] arm: add 'pacbti' instruction for Armv8.1-M pacbti extension
+	gas/
+	2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* config/tc-arm.c
+		(enum operand_parse_code): Add OP_SP and OP_R12.
+		(parse_operands): Add switch cases for OP_SP and OP_R12.
+		(T16_32_TAB): Add '_pacbti'.
+		(do_t_pacbti): New function.
+		(insns): Add 'pacbti'.
+		* testsuite/gas/arm/armv8_1-m-pacbti-bad.d: New file.
+		* testsuite/gas/arm/armv8_1-m-pacbti-bad.l: Likewise.
+		* testsuite/gas/arm/armv8_1-m-pacbti-bad.s: Likewise.
+		* testsuite/gas/arm/armv8_1-m-pacbti.d: Add 'pacbti' to testcase.
+		* testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise.
+
+	opcodes/
+	2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* arm-dis.c (thumb32_opcodes): Add 'pacbti' instruction.
+
+2021-07-26  Andrea Corallo  <andrea.corallo@arm.com>
+
+	PATCH [1/10] arm: add 'bti' instruction for Armv8.1-M pacbti extension
+	gas/
+	2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* config/tc-arm.c (insns): Add 'bti' insn.
+		* testsuite/gas/arm/armv8_1-m-pacbti.d: New file.
+		* testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise.
+
+	opcodes/
+	2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>
+
+		* arm-dis.c (thumb32_opcodes): Add bti instruction.
+
+2021-07-26  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb: move remaining ChangeLogs to legacy files
+	In commit:
+
+	  commit f069ea46a03ae868581d1c852da28e979ea1245a
+	  Date:   Sat Jul 3 16:29:08 2021 -0700
+
+	      Rename gdb/ChangeLog to gdb/ChangeLog-2021
+
+	The gdb/ChangeLog file was renamed, but all of the other ChangeLog
+	files relating to gdb were left in place.
+
+	As I understand things, the no ChangeLogs policy applies to all the
+	GDB related directories, so this commit renames all of the remaining
+	GDB related ChangeLog files.
+
+	As with the original commit, the intention behind this commit is to
+	hopefully stop people merging ChangeLog entries by mistake.
+
+	The renames carried out in this commit are:
+
+	    gdb/doc/ChangeLog -> gdb/doc/ChangeLog-1991-2021
+	    gdb/stubs/ChangeLog -> gdb/stubs/ChangeLog-2012-2020
+	    gdb/testsuite/ChangeLog -> gdb/testsuite/ChangeLog-2014-2021
+	    gdbserver/ChangeLog -> gdbserver/ChangeLog-2002-2021
+	    gdbsupport/ChangeLog -> gdbsupport/ChangeLog-2020-2021
+
+2021-07-26  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>
+
+	gdb/mi: handle no condition argument case for -break-condition
+	As reported in PR gdb/28076 [1], passing no condition argument to the
+	-break-condition command (e.g.: "-break-condition 2") should clear the
+	condition for breakpoint 2, just like CLI's "condition 2", but instead
+	an error message is returned:
+
+	  ^error,msg="-break-condition: Missing the <number> and/or <expr> argument"
+
+	The current implementation of the -break-condition command's argument
+	handling (79aabb7308c "gdb/mi: add a '--force' flag to the
+	'-break-condition' command") was done according to the documentation,
+	where the condition argument seemed mandatory.  However, the
+	-break-condition command originally (i.e. before the 79aabb7308c
+	patch) used the CLI's "cond" command, and back then not passing a
+	condition argument was clearing out the condition.  So, this is a
+	regression in terms of the behavior.
+
+	Fix the argument handling of the -break-condition command to allow not
+	having a condition argument, and also update the document to make the
+	behavior clear.  Also add test cases to test the scenarios which were
+	previously not covered.
+
+	[1] https://sourceware.org/bugzilla/show_bug.cgi?id=28076
+
+2021-07-26  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-25  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-24  Alan Modra  <amodra@gmail.com>
+
+	Revert: PowerPC: Don't generate unused section symbols
+	Blindly following x86 broke linux kernel builds.
+
+	bfd/
+		* elf32-ppc.c (TARGET_KEEP_UNUSED_SECTION_SYMBOLS): Define as true.
+		* elf64-ppc.c (TARGET_KEEP_UNUSED_SECTION_SYMBOLS): Likewise.
+	gas/
+		* testsuite/gas/ppc/power4.d: Adjust for section sym change.
+		* testsuite/gas/ppc/test1elf32.d: Likewise.
+		* testsuite/gas/ppc/test1elf64.d: Likewise.
+	ld/
+		* testsuite/ld-powerpc/tlsexe.r: Adjust for section sym change.
+		* testsuite/ld-powerpc/tlsexe32.r: Likewise.
+		* testsuite/ld-powerpc/tlsexe32no.r: Likewise.
+		* testsuite/ld-powerpc/tlsexeno.r: Likewise.
+		* testsuite/ld-powerpc/tlsexenors.r: Likewise.
+		* testsuite/ld-powerpc/tlsexers.r: Likewise.
+		* testsuite/ld-powerpc/tlsexetoc.r: Likewise.
+		* testsuite/ld-powerpc/tlsexetocrs.r: Likewise.
+		* testsuite/ld-powerpc/tlsget.d: Likewise.
+		* testsuite/ld-powerpc/tlsget.wf: Likewise.
+		* testsuite/ld-powerpc/tlsget2.d: Likewise.
+		* testsuite/ld-powerpc/tlsget2.wf: Likewise.
+		* testsuite/ld-powerpc/tlsso.r: Likewise.
+		* testsuite/ld-powerpc/tlsso32.r: Likewise.
+		* testsuite/ld-powerpc/tlstocso.r: Likewise.
+
+2021-07-24  Alan Modra  <amodra@gmail.com>
+
+	Re: ld script expression parsing
+	Commit 40726f16a8d7 broke references to sections within ADDR(), and
+	overlays with weird section names.
+
+		* ldgram.y (paren_script_name): New rule.
+		(exp): Use it for ALIGNOF, SIZEOF, ADDR, and LOADADDR.  Similarly
+		ensure script mode parsing for section name in SEGMENT_START.
+		(overlay_section): Delete unnecessary ldlex_script call.  Backup
+		on a lookahead NAME parsed in expression mode.
+		* testsuite/ld-elf/overlay.s: Add more sections.
+		* testsuite/ld-elf/overlay.t: Test '-' in section names.
+
+2021-07-24  Frederic Cambus  <fred@statdns.com>
+
+	Update the NetBSD system call table to match NetBSD-current.
+	Generated from sys/sys/syscall.h revision 1.319.
+
+	We can safely remove the _lwp_gettid syscall, which was never exposed
+	in libc and never made it into a release.
+
+	gdb/ChangeLog:
+
+	2021-07-23  Frederic Cambus  <fred@statdns.com>
+
+		* syscalls/netbsd.xml: Regenerate.
+
+2021-07-24  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-23  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/testsuite: test get/set value of unregistered Guile parameter
+	When creating a parameter in Guile, you have to create it using
+	make-parameter and then register it with GDB with register-parameter!.
+	In between, it's still possible (though not documented) to set the
+	parameter's value.  I broke this use case by mistake while writing this
+	series, so thought it would be good to have a test for it.
+
+	I suppose that people could use this "feature" to give their parameter
+	an initial value, even though make-parameter has an initial-value
+	parameter for this.  Nevertheless, changing this behavior could break
+	some scripts, which is why I think it's important for it to be tested.
+
+	Change-Id: I5b2103e3cec0cfdcccf7ffb00eb05fed8626e66d
+
+2021-07-23  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove cmd_list_element::function::sfunc
+	I don't understand what the sfunc function type in
+	cmd_list_element::function is for.  Compared to cmd_simple_func_ftype,
+	it has an extra cmd_list_element parameter, giving the callback access
+	to the cmd_list_element for the command being invoked.  This allows
+	registering the same callback with many commands, and alter the behavior
+	using the cmd_list_element's context.
+
+	From the comment in cmd_list_element, it sounds like at some point it
+	was the callback function type for set and show functions, hence the
+	"s".  But nowadays, it's used for many more commands that need to access
+	the cmd_list_element object (see add_catch_command for example).
+
+	I don't really see the point of having sfunc at all, since do_sfunc is
+	just a trivial shim that changes the order of the arguments.  All
+	commands using sfunc could just as well set cmd_list_element::func to
+	their callback directly.
+
+	Therefore, remove the sfunc field in cmd_list_element and everything
+	that goes with it.  Rename cmd_const_sfunc_ftype to cmd_func_ftype and
+	use it for cmd_list_element::func, as well as for the add_setshow
+	commands.
+
+	Change-Id: I1eb96326c9b511c293c76996cea0ebc51c70fac0
+
+2021-07-23  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: rename cfunc to simple_func
+	After browsing the CLI code for quite a while and trying really hard, I
+	reached the conclusion that I can't give a meaningful explanation of
+	what "sfunc" and "cfunc" functions are, in cmd_list_element.  I don't
+	see a logic at all.  That makes it very difficult to do any kind of
+	change.  Unless somebody can make sense out of all that, I'd like to try
+	to retro-fit some logic in the cmd_list_element callback function code
+	so that we can understand what is going on, do some cleanups and add new
+	features.
+
+	The first change is about "cfunc".  I can't figure out what the "c" in
+	cfunc means.  It's not const, because there's already "const" in
+	"cmd_const_cfunc_ftype", and the previous "cmd_cfunc_ftype" had nothing
+	const..  It's not "cmd" or "command", because there's already "cmd" in
+	"cmd_const_cfunc_ftype".
+
+	The "main" command callback, cmd_list_element::func, has three
+	parameters, whereas cfunc has two.  It is missing the cmd_list_element
+	parameter.  So the only reason I see for cfunc to exist is to be a shim
+	between the three and two parameter versions.  Most commands don't need
+	to receive the cmd_list_element object, so adding it everywhere would be
+	long and would just add more unnecessary boilerplate.  So since this is
+	the "simple" version of the callback, compared to the "full", I suggest
+	renaming cmd_const_cfunc_ftype into cmd_simple_func_ftype, as well as
+	everything (like the utility functions) that goes with it.
+
+	Change-Id: I4e46cacfd77a66bc1cbf683f6a362072504b7868
+
+2021-07-23  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: make inferior::m_terminal an std::string
+	Same idea as the previous patch, but for m_terminal.
+
+	Change-Id: If9367d5db8c976a4336680adca4ea5bc31ab64d2
+
+2021-07-23  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: make inferior::m_cwd an std::string
+	Same idea as the previous patch, but for m_cwd.
+
+	To keep things consistent across the board, change get_inferior_cwd as
+	well, which is shared with GDBserver.  So update the related GDBserver
+	code too.
+
+	Change-Id: Ia2c047fda738d45f3d18bc999eb67ceb8400ce4e
+
+2021-07-23  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: make inferior::m_args an std::string
+	With the current code, both a NULL pointer and an empty string can mean
+	"no arguments".  We don't need this distinction.  Changing to a string
+	has the advantage that there is now a single state for that (an empty
+	string), which makes the code a bit simpler in my opinion.
+
+	Change-Id: Icdc622820f7869478791dbaa84b4a1c7fec21ced
+
+2021-07-23  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: add setter/getter for inferior cwd
+	Add cwd/set_cwd to the inferior class, remove set_inferior_args.
+	Keep get_inferior_args, because it is used from fork_inferior, in shared
+	code.  The cwd could eventually be passed as a parameter eventually,
+	though, I think that would be cleaner.
+
+	Change-Id: Ifb72ea865d7e6f9a491308f0d5c1595579d8427e
+
+2021-07-23  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: add setter/getter for inferior arguments
+	Add args/set_args to the inferior class, remove the set_inferior_args
+	and get_inferior_args functions, that would just be wrappers around
+	them.
+
+	Change-Id: If87d52f3402ce08be26c32897ae8915d9f6d1ea3
+
+2021-07-23  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: remove inferior::{argc,argv}
+	There are currently two states that the inferior args can be stored.
+	The main one is the `args` field, where they are stored as a single
+	string.  The other one is the `argc`/`argv` fields.
+
+	This last one is only used for arguments passed in GDB's
+	command line.  And the only outcome is that when get_inferior_args is
+	called, `argc`/`argv` are serialized into `args`.  So really,
+	`argc`/`argv` is just a staging area before moving the arguments in
+	`args`.
+
+	Simplify this by only keeping the `args` field.  Change
+	set_inferior_args_vector to immediately serialize the arguments into
+	`args`, work that would be done in get_inferior_args later anyway.
+
+	The only time where this work would be "wasted" is when the user passes
+	some arguments on the command line, but does not end up running the
+	program.  But that just seems unlikely.  And it's not that much work.
+
+	Change-Id: Ica0b9859397c095f6530350c8fb3c36905f2044a
+
+2021-07-23  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: un-share set_inferior_cwd declaration
+	The declaration of set_inferior_cwd is currently shared between gdb and
+	gdbserver, in gdbsupport/common-inferior.h.  It doesn't need to be, as
+	set_inferior_cwd is not called from common code.  Only get_inferior_cwd
+	needs to.
+
+	The motivation for this is that a future patch will change the prototype
+	of set_inferior_cwd in gdb, and I don't want to change it for gdbserver
+	unnecessarily.  I see this as a good cleanup in any case, to reduce to
+	just the essential what is shared between GDB and GDBserver.
+
+	Change-Id: I3127d27d078f0503ebf5ccc6fddf14f212426a73
+
+2021-07-23  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb.base/setshow.exp: fix duplicate test name
+	Fix:
+
+	    DUPLICATE: gdb.base/setshow.exp: test_setshow_args: show args
+
+	by giving some explicit test names.
+
+	Change-Id: I2a738d3d3675ab9b45929e71f5aee0ea6bf92072
+
+2021-07-23  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb.base/setshow.exp: split in procs
+	Split in multiple procs, one per topic, and start with a fresh GDB in
+	each.  I find it easier to work on a test with multiple smaller
+	independent test procedures.  For example, it's possible to comment all
+	but one when working on one.  It's also easier to add things without
+	having to think about the impact on existing tests, and vice-versa.
+
+	Change-Id: I19691eed8f9bcb975b2eeff7577cac66251bcbe2
+
+2021-07-23  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb.base/setshow.exp: use save_vars to save/restore gdb_prompt
+	Using save_vars is a bit better than what we have now, as it ensures the
+	variable gets restored if the code within it throws an error.
+
+	Change-Id: I3bd6836e5b7efb61b078acadff1a1c8182c19a27
+
+2021-07-23  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/testsuite: split gdb.python/py-parameter.exp in procs
+	Split the file into multiple independent test procs, where each proc
+	starts with a fresh GDB.  I find it easier to understand what a test is
+	doing when each part of the test is isolated and self-contained.  It
+	makes it easier to comment out some parts of the test while working /
+	debugging a specific part.  It also makes it easier to add new things
+	(which a subsequent patch will do) without fear of impacting another part
+	of the test.
+
+	Change-Id: I8b4d52ac82b1492d79b679e13914ed177d8a836d
+
+2021-07-23  Carl Love  <cel@us.ibm.com>
+
+	Fix for gdb.python/py-breakpoint.exp
+	Not all systems have hardware breakpoint support.  Add a check
+	to see if the system supports hardware breakpoints.
+
+	gdb/testsuite/ChangeLog
+
+		* gdb.python/py-breakpoint.exp (test_hardware_breakpoints): Add
+		check for hardware breakpoint support.
+
+2021-07-23  Andrew Burgess  <andrew.burgess@embecosm.com>
+
+	gdb/testsuite: don't error when trying to unset last_spawn_tty_name
+	In spawn_capture_tty_name (lib/gdb.exp) we either set or unset
+	last_spawn_tty_name depending on whether spawn_out(slave,name) exists
+	or not.
+
+	One situation that might cause spawn_out(slave,name) to not exists is
+	if the spawn function is called with the argument -leaveopen, which is
+	how it is called when processes are created as part of a pipeline, the
+	created process has no tty, instead its output is written to a file
+	descriptor.
+
+	If a pipeline is created consisting of multiple processes then there
+	will be multiple sequential calls to spawn, all using -leaveopen.  The
+	first of these calls is fine, spawn_out(slave,name) is not set, and so
+	in spawn_capture_tty_name we unset last_spawn_tty_name.  However, on
+	the second call to spawn, spawn_out(slave,name) is still not set and
+	so in spawn_capture_tty_name we again try to unset
+	last_spawn_tty_name, this now throws an error (as last_spawn_tty_name
+	is already unset).
+
+	Fix this issue by using -nocomplain with the call to unset in
+	spawn_capture_tty_name.
+
+	Before this commit I was seeing gdb.base/gnu-debugdata.exp report 1
+	pass, and 1 unsupported test.  After this commit I now see 16 passes
+	from this test script.
+
+	I have also improved the code that used to do this:
+
+	    if { [info exists spawn_out] } {
+		set ::last_spawn_tty_name $spawn_out(slave,name)
+	    } else {
+	        ...
+	    }
+
+	The problem here is that we check for the existence of spawn_out, and
+	then unconditionally read spawn_out(slave,name).  A situation could
+	arise where some other element of spawn_out is set,
+	e.g. spawn_out(foo), in which case we would enter the if block and try
+	to read a non-existent variable.  After this commit we now check
+	specifically for spawn_out(slave,name).
+
+	Finally, it is worth noting that before this issue was fixed runtest
+	itself, or rather the expect process behind runtest, would segfault
+	while exiting.  I haven't looked at all into what the problem is here
+	that caused expect to crash, as fixing the bug in GDB's testing
+	scripts made the segfault go away.
+
+2021-07-23  Jan Beulich  <jbeulich@suse.com>
+
+	x86: express unduly set rounding control bits in disassembly
+	While EVEX.L'L are indeed ignored when EVEX.b stands for just SAE,
+	EVEX.b itself is not ignored when an insn permits neither rounding
+	control nor SAE.
+
+	While changing this aspect of EVEX.b handling, also alter unduly set
+	embedded broadcast: Don't call BadOp(), screwing up subsequent
+	disassembly, but emit "{bad}" instead.
+
+2021-07-23  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-22  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix FAILs due to PR gcc/101575
+	When running test-case gdb.ada/formatted_ref.exp with gcc-11 and target board
+	unix/gdb:debug_flags=-gdwarf-4 we run into:
+	...
+	(gdb) print/x s^M
+	No definition of "s" in current context.^M
+	(gdb) FAIL: gdb.ada/formatted_ref.exp: print/x s
+	...
+	which is caused by "runto defs.adb:20" taking us to defs__struct1IP:
+	...
+	(gdb) break defs.adb:20^M
+	Breakpoint 1 at 0x402cfd: defs.adb:20. (2 locations)^M
+	(gdb) run ^M
+	Starting program: formatted_ref ^M
+	^M
+	Breakpoint 1, defs__struct1IP () at defs.adb:20^M
+	20            return s.x;                   -- Set breakpoint marker here.^M
+	(gdb) print s1'access^M
+	...
+	instead of the expected defs.f1:
+	...
+	(gdb) break defs.adb:20^M
+	Breakpoint 1 at 0x402d0e: file defs.adb, line 20.^M
+	(gdb) run ^M
+	Starting program: formatted_ref ^M
+	^M
+	Breakpoint 1, defs.f1 (s=...) at defs.adb:20^M
+	20            return s.x;                   -- Set breakpoint marker here.^M
+	...
+
+	This is caused by incorrect line info due to gcc PR 101575 - "[gcc-11,
+	-gdwarf-4] Missing .file <n> directive causes invalid line info".
+
+	Fix this by when landing in defs__struct1IP:
+	- xfailing the runto, and
+	- issuing a continue to land in defs.f1.
+
+	Likewise in a few other test-cases.
+
+	Tested on x86_64-linux, with:
+	- system gcc.
+	- gcc-11 and target boards unix/gdb:debug_flags=-gdwarf-4 and
+	  unix/gdb:debug_flags=-gdwarf-5.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-07-22  Tom de Vries  <tdevries@suse.de>
+
+		* gdb.ada/formatted_ref.exp: Add xfail for PR gcc/101575.
+		* gdb.ada/iwide.exp: Same.
+		* gdb.ada/pkd_arr_elem.exp: Same.
+
+2021-07-22  Jan Beulich  <jbeulich@suse.com>
+
+	x86: drop dq{b,d}_mode
+	Their sole use is for {,V}EXTRACTPS / {,V}P{EXT,INS}RB respectively; for
+	consistency also limit use of dqw_mode to Jdqw. 64-bit disassembly
+	reflecting REX.W / VEX.W is not in line with the assembler's opcode
+	table having NoRex64 / VexWIG in all respective templates, i.e. assembly
+	input isn't being honored there either. Obviously the 0FC5 encodings of
+	{,V}PEXTRW then also need adjustment for consistency reasons.
+
+	x86: drop vex_scalar_w_dq_mode
+	It has only a single use and can easily be represented by dq_mode
+	instead. Plus its handling in intel_operand_size() was duplicating
+	that of vex_vsib_{d,q}_w_dq_mode anyway.
+
+	x86: drop xmm_m{b,w,d,q}_mode
+	They're effectively redundant with {b,w,d,q}_mode.
+
+	x86: fold duplicate vector register printing code
+	The bulk of OP_XMM() can be easily reused also for OP_EX(). Break the
+	shared logic out of the function, and invoke the new helper from both
+	places.
+
+	x86: drop vex_mode and vex_scalar_mode
+	These are fully redundant with, respectively, x_mode and scalar_mode.
+
+	x86: correct EVEX.V' handling outside of 64-bit mode
+	Unlike the high bit of VEX.vvvv / EVEX.vvvv, EVEX.V' is not ignored
+	outside of 64-bit mode. Oddly enough there already are tests for these
+	cases, but their expectations were wrong. (This may have been based on
+	an old SDM version, where the restriction wasn't properly spelled out.)
+
+	x86: fold duplicate code in MOVSXD_Fixup()
+	There's no need to have two paths printing the "xd" mnemonic suffix.
+
+	x86: fold duplicate register printing code
+	What so far was OP_E_register() can be easily reused also for OP_G().
+	Add suitable parameters to the function and move the invocation of
+	swap_operand() to OP_E(). Adjust MOVSXD's first operand: There never was
+	a need to use movsxd_mode there, and its use gets in the way of the code
+	folding.
+
+	x86-64: properly bounds-check %bnd<N> in OP_G()
+	The restriction to %bnd0-%bnd3 requires to also check REX.R is clear,
+	just like OP_E_Register() also includes REX.B in its check.
+
+	x86-64: generalize OP_G()'s EVEX.R' handling
+	EVEX.R' is invalid to be clear not only for mask registers, but also for
+	GPRs - IOW everything handled in this function.
+
+2021-07-22  Jan Beulich  <jbeulich@suse.com>
+
+	x86: correct VCVT{,U}SI2SD rounding mode handling
+	With EVEX.W clear the instruction doesn't ignore the rounding mode, but
+	(like for other insns without rounding semantics) EVEX.b set causes #UD.
+	Hence the handling of EVEX.W needs to be done when processing
+	evex_rounding_64_mode, not at the decode stages.
+
+	Derive a new 64-bit testcase from the 32-bit one to cover the different
+	EVEX.W treatment in both cases.
+
+2021-07-22  Jan Beulich  <jbeulich@suse.com>
+
+	x86: drop OP_Mask()
+	By moving its vex.r check there it becomes fully redundant with OP_G().
+
+2021-07-22  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-21  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.cp/step-and-next-inline.exp with gcc-11
+	When running test-case gdb.cp/step-and-next-inline.exp with gcc-11, I run
+	into:
+	...
+	KPASS: gdb.cp/step-and-next-inline.exp: no_header: next step 1 \
+	  (PRMS symtab/25507)
+	FAIL: gdb.cp/step-and-next-inline.exp: no_header: next step 2
+	KPASS: gdb.cp/step-and-next-inline.exp: no_header: next step 3 \
+	  (PRMS symtab/25507)
+	...
+
+	[ Note that I get the same result with gcc-11 and target board
+	unix/gdb:debug_flags=-gdwarf-4, so this is not a dwarf 4 vs 5 issue. ]
+
+	With gcc-10, I have this trace:
+	...
+	64        get_alias_set (&xx);
+	get_alias_set (t=0x601038 <xx>) at step-and-next-inline.cc:51
+	51        if (t != NULL
+	40        if (t->x != i)
+	52            && TREE_TYPE (t).z != 1
+	43        return x;
+	53            && TREE_TYPE (t).z != 2
+	43        return x;
+	54            && TREE_TYPE (t).z != 3)
+	43        return x;
+	main () at step-and-next-inline.cc:65
+	65        return 0;
+	...
+	and with gcc-11, I have instead:
+	...
+	64        get_alias_set (&xx);
+	get_alias_set (t=0x601038 <xx>) at step-and-next-inline.cc:51
+	51        if (t != NULL
+	52            && TREE_TYPE (t).z != 1
+	43        return x;
+	53            && TREE_TYPE (t).z != 2
+	43        return x;
+	54            && TREE_TYPE (t).z != 3)
+	43        return x;
+	main () at step-and-next-inline.cc:65
+	65        return 0;
+	...
+	and with clang-10, I have instead:
+	...
+	64        get_alias_set (&xx);
+	get_alias_set (t=0x601034 <xx>) at step-and-next-inline.cc:51
+	51        if (t != NULL
+	52            && TREE_TYPE (t).z != 1
+	53            && TREE_TYPE (t).z != 2
+	54            && TREE_TYPE (t).z != 3)
+	51        if (t != NULL
+	57      }
+	main () at step-and-next-inline.cc:65
+	65        return 0;
+	...
+
+	The test-case tries to verify that we don't step into inlined function
+	tree_check (lines 40-43) (so, with the clang trace we get that right).
+
+	The test-case then tries to kfail the problems when using gcc, but this is
+	done in such a way that the testing still gets out of sync after a failure.
+	That is: the "next step 2" check that is supposed to match
+	"TREE_TYPE (t).z != 2" is actually matching "TREE_TYPE (t).z != 1":
+	...
+	(gdb) next^M
+	52            && TREE_TYPE (t).z != 1^M
+	(gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: next step 2
+	...
+
+	Fix this by issuing extra nexts to arrive at the required lines.
+
+	Tested on x86_64-linux, with gcc-8, gcc-9, gcc-10, gcc-11, clang-8, clang-10
+	and clang-12.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-07-20  Tom de Vries  <tdevries@suse.de>
+
+		* gdb.cp/step-and-next-inline.cc (tree_check, get_alias_set, main):
+		Tag closing brace with comment.
+		* gdb.cp/step-and-next-inline.h: Update to keep identical with
+		step-and-next-inline.cc.
+		* gdb.cp/step-and-next-inline.exp: Issue extra next when required.
+
+2021-07-21  Nick Clifton  <nickc@redhat.com>
+
+	Updated Russian translation for the bfd library
+
+2021-07-21  Luca Boccassi  <luca.boccassi@microsoft.com>
+
+	Allows linker scripts to set the SEC_READONLY flag.
+	* ld.texi: Document new output section type.
+	* ldgram.y: Add new token.
+	* ldlang.c: Handle the new flag.
+	* ldlang.h: Add readonly_section to list of section types.
+	* ldlex.l: Add a new identifier.
+	* testsuite/ld-scripts/output-section-types.t: New example linker script.
+	* testsuite/ld-scripts/output-section-types.d: Test driver.
+	* testsyute/ld-scripts/script.exp: Run the new test.
+
+2021-07-21  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix FAILs due to PR gcc/101452
+	When running test-case gdb.base/ptype-offsets.exp with gcc-11 (with -gdwarf-5
+	default) or gcc-10 with target board unix/gdb:debug_flags=-gdwarf-5 we run
+	into this regression:
+	...
+	 (gdb) ptype/o static_member^M
+	 /* offset      |    size */  type = struct static_member {^M
+	-                               static static_member Empty;^M
+	 /*      0      |       4 */    int abc;^M
+	 ^M
+	                                /* total size (bytes):    4 */^M
+	                              }^M
+	-(gdb) PASS: gdb.base/ptype-offsets.exp: ptype/o static_member
+	+(gdb) FAIL: gdb.base/ptype-offsets.exp: ptype/o static_member
+	...
+
+	This is caused by missing debug info, which I filed as gcc PR101452 - "[debug,
+	dwarf-5] undefined static member removed by
+	-feliminate-unused-debug-symbols".
+
+	It's not clear yet whether this is a bug or a feature, but work around this in
+	the test-cases by:
+	- defining the static member
+	- adding additional_flags=-fno-eliminate-unused-debug-types.
+
+	Tested on x86_64-linux.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-07-20  Tom de Vries  <tdevries@suse.de>
+
+		* lib/gdb.exp (gcc_major_version): New proc.
+		* gdb.base/ptype-offsets.cc: Define static member static_member::Empty.
+		* gdb.cp/templates.exp: Define static member using -DGCC_BUG.
+		* gdb.cp/m-static.exp: Add
+		additional_flags=-fno-eliminate-unused-debug-types.
+		* gdb.cp/pr-574.exp: Same.
+		* gdb.cp/pr9167.exp: Same.
+
+2021-07-21  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Add KFAILs for gdb.ada FAILs with gcc-11
+	With gcc-11 we run into:
+	...
+	(gdb) print pa_ptr.all^M
+	That operation is not available on integers of more than 8 bytes.^M
+	(gdb) KFAIL: gdb.ada/arrayptr.exp: scenario=all: print pa_ptr.all (PRMS: gdb/20991)
+	...
+
+	This is due to PR exp/20991 - "__int128 type support".  Mark this and similar
+	FAILs as KFAIL.
+
+	Also mark this FAIL:
+	....
+	(gdb) print pa_ptr(3)^M
+	cannot subscript or call something of type `foo__packed_array_ptr'^M
+	(gdb) FAIL: gdb.ada/arrayptr.exp: scenario=minimal: print pa_ptr(3)
+	...
+	as a KFAIL for PR ada/28115 - "Support packed array encoded as
+	DW_TAG_subrange_type".
+
+	Tested on x86_64-linux, with gcc-10 and gcc-11.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-07-21  Tom de Vries  <tdevries@suse.de>
+
+		* gdb.ada/arrayptr.exp: Add KFAILs for PR20991 and PR28115.
+		* gdb.ada/exprs.exp: Add KFAILs for PR20991.
+		* gdb.ada/packed_array_assign.exp: Same.
+
+2021-07-21  Alan Modra  <amodra@gmail.com>
+
+	as_bad_subtract
+	Many places report errors of the nature "can't resolve a - b".
+	This provides a utility function to report such errors consistently.
+	I removed the section reporting and quotes around symbol names while I
+	was at it.  Compare
+	ifunc-2.s:4: Error: can't resolve `bar1' {.text.1 section} - `foo1' {.text.1 section}
+	with
+	ifunc-2.s:4: Error: can't resolve bar1 - foo1
+
+	In many cases the section names don't help the user very much in
+	figuring out what went wrong, and the quotes if present arguably ought
+	to be placed around the entire expression:
+	can't resolve `bar1 - foo1'
+
+	The patch also tidies some tc_get_reloc functions that leak memory on
+	error paths.
+
+		* write.h (as_bad_subtract): Declare.
+		* write.c (as_bad_subtract): New function.
+		(fixup_segment): Use as_bad_subtract.
+		* config/tc-arc.c (md_apply_fix): Likewise.
+		* config/tc-avr.c (md_apply_fix, tc_gen_reloc): Likewise.
+		* config/tc-cris.c (md_apply_fix): Likewise.
+		* config/tc-d10v.c (md_apply_fix): Likewise.
+		* config/tc-d30v.c (md_apply_fix): Likewise.
+		* config/tc-ft32.c (md_apply_fix): Likewise.
+		* config/tc-h8300.c (tc_gen_reloc): Likewise.
+		* config/tc-m68hc11.c (md_apply_fix): Likewise.
+		* config/tc-mmix.c (mmix_frob_file): Likewise.
+		* config/tc-mn10200.c (tc_gen_reloc): Likewise.
+		* config/tc-nds32.c (nds32_apply_fix): Likewise.
+		* config/tc-pru.c (md_apply_fix): Likewise.
+		* config/tc-riscv.c (md_apply_fix): Likewise.
+		* config/tc-s12z.c (md_apply_fix): Likewise.
+		* config/tc-s390.c (md_apply_fix): Likewise.
+		* config/tc-tilegx.c (md_apply_fix): Likewise.
+		* config/tc-tilepro.c (md_apply_fix): Likewise.
+		* config/tc-v850.c (md_apply_fix): Likewise.
+		* config/tc-vax.c (md_apply_fix): Likewise.
+		* config/tc-xc16x.c (tc_gen_reloc): Likewise.
+		* config/tc-xgate.c (md_apply_fix): Likewise.
+		* config/tc-xstormy16.c (xstormy16_md_apply_fix): Likewise.
+		* config/tc-xtensa.c (md_apply_fix): Likewise.
+		* config/tc-z80.c (tc_gen_reloc): Likewise.
+		* config/tc-spu.c (md_apply_fix): Likewise.
+		(tc_gen_reloc): Delete dead code.  Free memory on error.
+		* config/tc-cr16.c (tc_gen_reloc): Use as_bad_subtract.  Free
+		on error.
+		* config/tc-crx.c (tc_gen_reloc): Likewise.
+		* config/tc-ppc.c (tc_gen_reloc): Likewise.
+		* testsuite/gas/i386/ifunc-2.l: Adjust to suit changed error message.
+		* testsuite/gas/mips/lui-2.l: Likewise.
+		* testsuite/gas/tic6x/reloc-bad-1.l: Likewise.
+
+2021-07-21  John Ericson  <git@JohnEricson.me>
+
+	Remove `netbsdpe` support
+	netbsdpe was deprecated in c2ce831330e10dab4703094491f80b6b9a5c2289.
+	Since then, a release has passed (2.37), and it was marked obselete in
+	5c9cbf07f3f972ecffe13d858010b3179df17b32. Unless I am mistaken, that
+	means we can now remove support altogether.
+
+	All branches in the "active" code are remove, and the target is
+	additionally marked as obsolete next to the other removed ones for
+	libbfd and gdb.
+
+	Per [1] from the NetBSD toolchain list, PE/COFF support was removed a
+	decade ago. Furthermore, the sole mention of this target in the binutils
+	commit history was in 2002. Together, I'm led to believe this target
+	hasn't seen much attention in quite a while.
+
+	[1]: https://mail-index.netbsd.org/tech-toolchain/2021/06/16/msg003996.html
+
+	bfd/
+		* config.bfd: Remove netbsdpe entry.
+	binutils/
+		* configure.ac: Remove netbsdpe entry.
+		* testsuite/lib/binutils-common.exp (is_pecoff_format): Likewise.
+		* configure: Regenerate.
+	gas/
+		* configure.tgt: Remove netbsdpe entry.
+	gdb/
+		* configure.tgt: Add netbsdpe to removed targets.
+	ld/
+		* configure.tgt: Remove netbsdpe entry.
+		* testsuite/ld-bootstrap/bootstrap.exp: Likewise.
+
+2021-07-21  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-20  Alan Modra  <amodra@gmail.com>
+
+	PR28106, build of 2.37 fails on FreeBSD and Clang
+	https://en.cppreference.com/w/cpp/types/NULL says NULL might be
+	defined as nullptr.
+	https://en.cppreference.com/w/cpp/language/reinterpret_cast says
+	reinterpret_cast can't be used on nullptr.
+
+		PR gold/28106
+		PR gold/27815
+		* gc.h (gc_process_relocs): Use static_cast in Section_id constructor.
+
+2021-07-20  Luis Machado  <luis.machado@linaro.org>
+
+	Fix printing of non-address types when memory tagging is enabled
+	When the architecture supports memory tagging, we handle
+	pointer/reference types in a special way, so we can validate tags and
+	show mismatches.
+
+	Unfortunately, the currently implementation errors out when the user
+	prints non-address values: composite types, floats, references, member
+	functions and other things.
+
+	Vector registers:
+
+	 (gdb) p $v0
+	 Value can't be converted to integer.
+
+	Non-existent internal variables:
+
+	 (gdb) p $foo
+	 Value can't be converted to integer.
+
+	The same happens for complex types and printing struct/union types.
+
+	There are a few problems here.
+
+	The first one is that after print_command_1 evaluates the expression
+	to print, the tag validation code call value_as_address
+	unconditionally, without making sure we have have a suitable type
+	where it makes to sense to call it.  That results in value_as_address
+	(if it isn't given a pointer-like type) trying to treat the value as
+	an integer and convert it to an address, which #1 - doesn't make sense
+	(i.e., no sense in validating tags after "print 1"), and throws for
+	non-integer-convertible types.  We fix this by making sure we have a
+	pointer or reference type first, and only if so then proceed to check
+	if the address-like value has tags.
+
+	The second is that we're calling value_as_address even if we have an
+	optimized out or unavailable value, which throws, because the value's
+	contents aren't fully accessible/readable.  This error currently
+	escapes out and aborts the print.  This case is fixed by checking for
+	optimized out / unavailable explicitly.
+
+	Third, the tag checking process does not gracefully handle exceptions.
+	If any exception is thrown from the tag validation code, we abort the
+	print.  E.g., the target may fail to access tags via a running thread.
+	Or the needed /proc files aren't available.  Or some other untold
+	reason.  This is a bit too rigid.  This commit changes print_command_1
+	to catch errors, print them, and still continue with the normal
+	expression printing path instead of erroring out and printing nothing
+	useful.
+
+	With this patch, printing works correctly again:
+
+	 (gdb) p $v0
+	 $1 = {d = {f = {2.0546950501119882e-81, 2.0546950501119882e-81}, u = {3399988123389603631, 3399988123389603631}, s = {
+	       3399988123389603631, 3399988123389603631}}, s = {f = {1.59329203e-10, 1.59329203e-10, 1.59329203e-10, 1.59329203e-10}, u = {
+	       791621423, 791621423, 791621423, 791621423}, s = {791621423, 791621423, 791621423, 791621423}}, h = {bf = {1.592e-10,
+	       1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10}, f = {0.11224, 0.11224, 0.11224, 0.11224, 0.11224,
+	       0.11224, 0.11224, 0.11224}, u = {12079, 12079, 12079, 12079, 12079, 12079, 12079, 12079}, s = {12079, 12079, 12079, 12079,
+	       12079, 12079, 12079, 12079}}, b = {u = {47 <repeats 16 times>}, s = {47 <repeats 16 times>}}, q = {u = {
+	       62718710765820030520700417840365121327}, s = {62718710765820030520700417840365121327}}}
+	 (gdb) p $foo
+	 $2 = void
+	 (gdb) p 2 + 2i
+	 $3 = 2 + 2i
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28110
+
+2021-07-20  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: Minor updates for architecture parser.
+	* Two add subset functions is redundant.  Keep the riscv_add_implicit_subset,
+	and renamed it to riscv_add_subset.  Besides, if the subset is added in order,
+	then we just add it at the tail of the subset list.
+
+	* Removed the "-march:" prefix from the error messages.  Since not only the
+	-march= option will use the parser, but also the architecture elf attributes,
+	the default architecture setting and linker will use the same parser.
+
+	* Use a function, riscv_parse_check_conflicts, to check the conflicts
+	of extensions, including the rv64e and rv32q.
+
+	The rv32emc-elf/rv32i-elf/rv32gc-linux/rv64gc-elf/rv64gc-linux regressions
+	are tested and passed.
+
+	bfd/
+		* elfxx-riscv.c (riscv_lookup_subset): Check the subset tail list
+		first.  If the subset is added in order, then we can just add it to
+		the tail without searching the whole list.
+		(riscv_add_subset): Replaced by riscv_add_implicit_subset.
+		(riscv_add_implicit_subset): Renamed to riscv_add_subset.
+		(riscv_parse_add_subset): Updated.
+		(riscv_parsing_subset_version): Removed the "-march:" prefix from
+		the error message.
+		(riscv_parse_prefixed_ext): Likewise.
+		(riscv_parse_std_ext): Likewise.  And move the rv<xlen>e check
+		to riscv_parse_check_conflicts.
+		(riscv_parse_check_conflicts): New function used to check conflicts.
+		(riscv_parse_subset): Updated.
+	gas/
+		* testsuite/gas/riscv/march-fail-base-02.l: Updated.
+		* testsuite/gas/riscv/march-fail-unknown-std.l: Likewise.
+
+2021-07-20  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-19  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: set current thread in btrace_compute_ftrace_{bts,pt}
+	As documented in bug 28086, test gdb.btrace/enable-new-thread.exp
+	started failing with commit 0618ae414979 ("gdb: optimize
+	all_matching_threads_iterator"):
+
+	    (gdb) record btrace^M
+	    (gdb) PASS: gdb.btrace/enable-new-thread.exp: record btrace
+	    break 24^M
+	    Breakpoint 2 at 0x555555555175: file /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.btrace/enable-new-thread.c, line 24.^M
+	    (gdb) continue^M
+	    Continuing.^M
+	    /home/smarchi/src/binutils-gdb/gdb/inferior.c:303: internal-error: inferior* find_inferior_pid(process_stratum_target*, int): Assertion `pid != 0' failed.^M
+	    A problem internal to GDB has been detected,^M
+	    further debugging may prove unreliable.^M
+	    Quit this debugging session? (y or n) FAIL: gdb.btrace/enable-new-thread.exp: continue to breakpoint: cont to bp.1 (GDB internal error)
+
+	Note that I only see the failure if GDB is compiled without libipt
+	support.  This is because GDB then makes use BTS instead of PT, so
+	exercises different code paths.
+
+	I think that the commit above just exposed an existing problem.  The
+	stack trace of the internal error is:
+
+	    #8  0x0000561cb81e404e in internal_error (file=0x561cb83aa2f8 "/home/smarchi/src/binutils-gdb/gdb/inferior.c", line=303, fmt=0x561cb83aa099 "%s: Assertion `%s' failed.") at /home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:55
+	    #9  0x0000561cb7b5c031 in find_inferior_pid (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, pid=0) at /home/smarchi/src/binutils-gdb/gdb/inferior.c:303
+	    #10 0x0000561cb7b5c102 in find_inferior_ptid (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/inferior.c:317
+	    #11 0x0000561cb7f1d1c3 in find_thread_ptid (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/thread.c:487
+	    #12 0x0000561cb7f1b921 in all_matching_threads_iterator::all_matching_threads_iterator (this=0x7ffc4ee34678, filter_target=0x561cb8aafb60 <the_amd64_linux_nat_target>, filter_ptid=...) at /home/smarchi/src/binutils-gdb/gdb/thread-iter.c:125
+	    #13 0x0000561cb77bc462 in filtered_iterator<all_matching_threads_iterator, non_exited_thread_filter>::filtered_iterator<process_stratum_target* const&, ptid_t const&> (this=0x7ffc4ee34670) at /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/filtered-iterator.h:42
+	    #14 0x0000561cb77b97cb in all_non_exited_threads_range::begin (this=0x7ffc4ee34650) at /home/smarchi/src/binutils-gdb/gdb/thread-iter.h:243
+	    #15 0x0000561cb7d8ba30 in record_btrace_target::record_is_replaying (this=0x561cb8aa6250 <record_btrace_ops>, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/record-btrace.c:1411
+	    #16 0x0000561cb7d8bb83 in record_btrace_target::xfer_partial (this=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_MEMORY, annex=0x0, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, offset=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/record-btrace.c:1437
+	    #17 0x0000561cb7ef73a9 in raw_memory_xfer_partial (ops=0x561cb8aa6250 <record_btrace_ops>, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, memaddr=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1504
+	    #18 0x0000561cb7ef77da in memory_xfer_partial_1 (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, memaddr=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1635
+	    #19 0x0000561cb7ef78b5 in memory_xfer_partial (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, memaddr=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1664
+	    #20 0x0000561cb7ef7ba4 in target_xfer_partial (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, annex=0x0, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, offset=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1721
+	    #21 0x0000561cb7ef8503 in target_read_partial (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, annex=0x0, buf=0x7ffc4ee34c58 "\260g\343N\374\177", offset=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1974
+	    #22 0x0000561cb7ef861f in target_read (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, annex=0x0, buf=0x7ffc4ee34c58 "\260g\343N\374\177", offset=140737352774277, len=1) at /home/smarchi/src/binutils-gdb/gdb/target.c:2014
+	    #23 0x0000561cb7ef809f in target_read_code (memaddr=140737352774277, myaddr=0x7ffc4ee34c58 "\260g\343N\374\177", len=1) at /home/smarchi/src/binutils-gdb/gdb/target.c:1869
+	    #24 0x0000561cb7937f4d in gdb_disassembler::dis_asm_read_memory (memaddr=140737352774277, myaddr=0x7ffc4ee34c58 "\260g\343N\374\177", len=1, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/gdb/disasm.c:139
+	    #25 0x0000561cb80ab66d in fetch_data (info=0x7ffc4ee34e88, addr=0x7ffc4ee34c59 "g\343N\374\177") at /home/smarchi/src/binutils-gdb/opcodes/i386-dis.c:194
+	    #26 0x0000561cb80ab7e2 in ckprefix () at /home/smarchi/src/binutils-gdb/opcodes/i386-dis.c:8628
+	    #27 0x0000561cb80adbd8 in print_insn (pc=140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/opcodes/i386-dis.c:9587
+	    #28 0x0000561cb80abe4f in print_insn_i386 (pc=140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/opcodes/i386-dis.c:8894
+	    #29 0x0000561cb7744a19 in default_print_insn (memaddr=140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/gdb/arch-utils.c:1029
+	    #30 0x0000561cb7b33067 in i386_print_insn (pc=140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/gdb/i386-tdep.c:4013
+	    #31 0x0000561cb7acd8f4 in gdbarch_print_insn (gdbarch=0x561cbae2fb60, vma=140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/gdb/gdbarch.c:3478
+	    #32 0x0000561cb793a32d in gdb_disassembler::print_insn (this=0x7ffc4ee34e80, memaddr=140737352774277, branch_delay_insns=0x0) at /home/smarchi/src/binutils-gdb/gdb/disasm.c:795
+	    #33 0x0000561cb793a5b0 in gdb_print_insn (gdbarch=0x561cbae2fb60, memaddr=140737352774277, stream=0x561cb8ac99f8 <null_stream>, branch_delay_insns=0x0) at /home/smarchi/src/binutils-gdb/gdb/disasm.c:850
+	    #34 0x0000561cb793a631 in gdb_insn_length (gdbarch=0x561cbae2fb60, addr=140737352774277) at /home/smarchi/src/binutils-gdb/gdb/disasm.c:859
+	    #35 0x0000561cb77f53f4 in btrace_compute_ftrace_bts (tp=0x561cbba11210, btrace=0x7ffc4ee35188, gaps=...) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1107
+	    #36 0x0000561cb77f55f5 in btrace_compute_ftrace_1 (tp=0x561cbba11210, btrace=0x7ffc4ee35180, cpu=0x0, gaps=...) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1527
+	    #37 0x0000561cb77f5705 in btrace_compute_ftrace (tp=0x561cbba11210, btrace=0x7ffc4ee35180, cpu=0x0) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1560
+	    #38 0x0000561cb77f583b in btrace_add_pc (tp=0x561cbba11210) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1589
+	    #39 0x0000561cb77f5a86 in btrace_enable (tp=0x561cbba11210, conf=0x561cb8ac6878 <record_btrace_conf>) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1629
+	    #40 0x0000561cb7d88d26 in record_btrace_enable_warn (tp=0x561cbba11210) at /home/smarchi/src/binutils-gdb/gdb/record-btrace.c:294
+	    #41 0x0000561cb7c603dc in std::__invoke_impl<void, void (*&)(thread_info*), thread_info*> (__f=@0x561cbb6c4878: 0x561cb7d88cdc <record_btrace_enable_warn(thread_info*)>) at /usr/include/c++/10/bits/invoke.h:60
+	    #42 0x0000561cb7c5e5a6 in std::__invoke_r<void, void (*&)(thread_info*), thread_info*> (__fn=@0x561cbb6c4878: 0x561cb7d88cdc <record_btrace_enable_warn(thread_info*)>) at /usr/include/c++/10/bits/invoke.h:153
+	    #43 0x0000561cb7c5dc92 in std::_Function_handler<void (thread_info*), void (*)(thread_info*)>::_M_invoke(std::_Any_data const&, thread_info*&&) (__functor=..., __args#0=@0x7ffc4ee35310: 0x561cbba11210) at /usr/include/c++/10/bits/std_function.h:291
+	    #44 0x0000561cb7f2600f in std::function<void (thread_info*)>::operator()(thread_info*) const (this=0x561cbb6c4878, __args#0=0x561cbba11210) at /usr/include/c++/10/bits/std_function.h:622
+	    #45 0x0000561cb7f23dc8 in gdb::observers::observable<thread_info*>::notify (this=0x561cb8ac5aa0 <gdb::observers::new_thread>, args#0=0x561cbba11210) at /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/observable.h:150
+	    #46 0x0000561cb7f1c436 in add_thread_silent (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/thread.c:263
+	    #47 0x0000561cb7f1c479 in add_thread_with_info (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=..., priv=0x561cbb3f7ab0) at /home/smarchi/src/binutils-gdb/gdb/thread.c:272
+	    #48 0x0000561cb7bfa1d0 in record_thread (info=0x561cbb0413a0, tp=0x0, ptid=..., th_p=0x7ffc4ee35610, ti_p=0x7ffc4ee35620) at /home/smarchi/src/binutils-gdb/gdb/linux-thread-db.c:1380
+	    #49 0x0000561cb7bf7a2a in thread_from_lwp (stopped=0x561cba81db20, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/linux-thread-db.c:429
+	    #50 0x0000561cb7bf7ac5 in thread_db_notice_clone (parent=..., child=...) at /home/smarchi/src/binutils-gdb/gdb/linux-thread-db.c:447
+	    #51 0x0000561cb7bdc9a2 in linux_handle_extended_wait (lp=0x561cbae25720, status=4991) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:1981
+	    #52 0x0000561cb7bdf0f3 in linux_nat_filter_event (lwpid=435403, status=198015) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:2920
+	    #53 0x0000561cb7bdfed6 in linux_nat_wait_1 (ptid=..., ourstatus=0x7ffc4ee36398, target_options=...) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:3202
+	    #54 0x0000561cb7be0b68 in linux_nat_target::wait (this=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=..., ourstatus=0x7ffc4ee36398, target_options=...) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:3440
+	    #55 0x0000561cb7bfa2fc in thread_db_target::wait (this=0x561cb8a9acd0 <the_thread_db_target>, ptid=..., ourstatus=0x7ffc4ee36398, options=...) at /home/smarchi/src/binutils-gdb/gdb/linux-thread-db.c:1412
+	    #56 0x0000561cb7d8e356 in record_btrace_target::wait (this=0x561cb8aa6250 <record_btrace_ops>, ptid=..., status=0x7ffc4ee36398, options=...) at /home/smarchi/src/binutils-gdb/gdb/record-btrace.c:2547
+	    #57 0x0000561cb7ef996d in target_wait (ptid=..., status=0x7ffc4ee36398, options=...) at /home/smarchi/src/binutils-gdb/gdb/target.c:2608
+	    #58 0x0000561cb7b6d297 in do_target_wait_1 (inf=0x561cba6d8780, ptid=..., status=0x7ffc4ee36398, options=...) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:3640
+	    #59 0x0000561cb7b6d43e in operator() (__closure=0x7ffc4ee36190, inf=0x561cba6d8780) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:3701
+	    #60 0x0000561cb7b6d7b2 in do_target_wait (ecs=0x7ffc4ee36370, options=...) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:3720
+	    #61 0x0000561cb7b6e67d in fetch_inferior_event () at /home/smarchi/src/binutils-gdb/gdb/infrun.c:4069
+	    #62 0x0000561cb7b4659b in inferior_event_handler (event_type=INF_REG_EVENT) at /home/smarchi/src/binutils-gdb/gdb/inf-loop.c:41
+	    #63 0x0000561cb7be25f7 in handle_target_event (error=0, client_data=0x0) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:4227
+	    #64 0x0000561cb81e4ee2 in handle_file_event (file_ptr=0x561cbae24e10, ready_mask=1) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:575
+	    #65 0x0000561cb81e5490 in gdb_wait_for_event (block=0) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:701
+	    #66 0x0000561cb81e41be in gdb_do_one_event () at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:212
+	    #67 0x0000561cb7c18096 in start_event_loop () at /home/smarchi/src/binutils-gdb/gdb/main.c:421
+	    #68 0x0000561cb7c181e0 in captured_command_loop () at /home/smarchi/src/binutils-gdb/gdb/main.c:481
+	    #69 0x0000561cb7c19d7e in captured_main (data=0x7ffc4ee366a0) at /home/smarchi/src/binutils-gdb/gdb/main.c:1353
+	    #70 0x0000561cb7c19df0 in gdb_main (args=0x7ffc4ee366a0) at /home/smarchi/src/binutils-gdb/gdb/main.c:1368
+	    #71 0x0000561cb7693186 in main (argc=11, argv=0x7ffc4ee367b8) at /home/smarchi/src/binutils-gdb/gdb/gdb.c:32
+
+	At frame 45, the new_thread observable is fired.  At this moment, the
+	new thread isn't the current thread, inferior_ptid is null_ptid.  I
+	think this is ok: the new_thread observable doesn't give any guarantee
+	on the global context when observers are invoked.  Frame 35,
+	btrace_compute_ftrace_bts, calls gdb_insn_length.  gdb_insn_length
+	doesn't have a thread_info or other parameter what could indicate where
+	to read memory from, it implicitly uses the global context
+	(inferior_ptid).
+
+	So we reach the all_non_exited_threads_range in
+	record_btrace_target::record_is_replaying with a null inferior_ptid.
+	The previous implemention of all_non_exited_threads_range didn't care,
+	but the new one does.  The problem of calling gdb_insn_length and
+	ultimately trying to read memory with a null inferior_ptid already
+	existed, but the commit mentioned above made it visible.
+
+	Something between frames 40 (record_btrace_enable_warn) and 35
+	(btrace_compute_ftrace_bts) needs to be switching the global context to
+	make TP the current thread.  Since btrace_compute_ftrace_bts takes the
+	thread_info to work with as a parameter, that typically means that it
+	doesn't require its caller to also set the global current context
+	(current thread) when calling.  If it needs to call other functions
+	that do require the global current thread to be set, then it needs to
+	temporarily change the current thread while calling these other
+	functions.  Therefore, switch and restore the current thread in
+	btrace_compute_ftrace_bts.
+
+	By inspection, it looks like btrace_compute_ftrace_pt may also call
+	functions sensitive to the global context: it installs the
+	btrace_pt_readmem_callback callback in the PT instruction decoder.  When
+	this function gets called, inferior_ptid must be set appropriately.  Add
+	a switch and restore in there too.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28086
+	Change-Id: I407fbfe41aab990068bd102491aa3709b0a034b3
+
+2021-07-19  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-18  Nick Clifton  <nickc@redhat.com>
+
+	Move pending-obsolesence targets onto the obsolete list.
+		* config.bfd: Move pending obsoletion targets to obsolete list.
+
+	Update how-to-make-a-release checklist with latest changes from 2.37 release
+
+2021-07-18  Michael Krasnyk  <mkrasnyk@argo.ai>
+
+	PR28098 Skip R_*_NONE relocation entries with zero r_sym without counting
+		PR gold/28098
+		* reloc.cc (Track_relocs::advance): Skip R_*_NONE relocation entries
+		with r_sym of zero without counting in advance method.
+
+2021-07-18  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: convert nat/x86-dregs.c macros to functions
+	I'm debugging why GDB crashes on OpenBSD/amd64, turns out it's because
+	x86_dr_low.get_status is nullptr.  It would have been useful to be able
+	to break on x86_dr_low_get_status, so I thought it would be a good
+	reason to convert these function-like macros into functions.
+
+	Change-Id: Ic200b50ef8455b4697bc518da0fa2bb704cf4721
+
+2021-07-18  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-17  Tom Tromey  <tom@tromey.com>
+
+	Fix file-name handling regression with DWARF index
+	When run with the gdb-index or debug-names target boards, dup-psym.exp
+	fails.  This came up for me because my new DWARF scanner reuses this
+	part of the existing index code, and so it registers as a regression.
+	This is PR symtab/25834.
+
+	Looking into this, I found that the DWARF index code here is fairly
+	different from the psymtab code.  I don't think there's a deep reason
+	for this, and in fact, it seemed to me that the index code could
+	simply mimic what the psymtab code already does.
+
+	That is what this patch implements.  The DW_AT_name and DW_AT_comp_dir
+	are now stored in the quick file names table.  This may require
+	allocating a quick file names table even when DW_AT_stmt_list does not
+	exist.  Then, the functions that work with this data are changed to
+	use find_source_or_rewrite, just as the psymbol code does.  Finally,
+	line_header::file_full_name is removed, as it is no longer needed.
+
+	Currently, the index maintains a hash table of "quick file names".
+	The hash table uses a deletion function to free the "real name"
+	components when necessary.  There's also a second such function to
+	implement the forget_cached_source_info method.
+
+	This bug fix patch will create a quick file name object even when
+	there is no DW_AT_stmt_list, meaning that the object won't be entered
+	in the hash table.  So, this patch changes the memory management
+	approach so that the entries are cleared when the per-BFD object is
+	destroyed.  (A dwarf2_per_cu_data destructor is not introduced,
+	because we have been avoiding adding a vtable to that class.)
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25834
+
+2021-07-17  Tom Tromey  <tom@tromey.com>
+
+	Check for debug-types in map_symbol_filenames
+	map_symbol_filenames can skip type units -- in fact I think it has to,
+	due to the assertion at the top of dw2_get_file_names.  This may be a
+	regression due to the TU/CU unification patch, I did not check.
+
+	Simplify DWARF file name caching
+	The DWARF index file name caching code only records when a line table
+	has been read and the reading failed.  However, the code would be
+	simpler if it recorded any attempt, which is what this patch
+	implements.
+
+	Introduce find_source_or_rewrite
+	The final bug fix in this series would duplicate the logic in
+	psymtab_to_fullname, so this patch extracts the body of this function
+	into a new function.
+
+	Simplify file_and_directory storage management
+	file_and_directory carries a std::string in case the compilation
+	directory is computed, but a subsequent patch wants to preserve this
+	string without also having to maintain the storage for it.  So, this
+	patch arranges for the compilation directory string to be stored in
+	the per-BFD string bcache instead.
+
+	Pass file_and_directory through DWARF line-decoding code
+	This patch removes the redundant "comp_unit" parameter from
+	compute_include_file_name, and arranges to pass a file_and_directory
+	object from the readers down to this function.  It also changes the
+	partial symtab reader to use find_file_and_directory, rather than
+	reimplement this functionality by hand.
+
+	Rename and refactor psymtab_include_file_name
+	In order to fix an index-related regression, I want to use
+	psymtab_include_file_name in the DWARF index file-handling code.  This
+	patch renames this function and changes it to no longer require a
+	partial symtab to be passed in.  A subsequent patch will further
+	refactor this code to remove the redundant parameter (which was always
+	there but is now more obvious).
+
+2021-07-17  Sergey Belyashov  <Sergey.Belyashov@gmail.com>
+
+	Add basic Z80 CPU support
+	Supported ISAs:
+	- Z80 (all undocumented instructions)
+	- Z180
+	- eZ80 (Z80 mode only)
+
+	Datasheets:
+	Z80: https://www.zilog.com/manage_directlink.php?filepath=docs/z80/um0080&extn=.pdf
+	Z180: https://www.zilog.com/manage_directlink.php?filepath=docs/z180/ps0140&extn=.pdf
+	eZ80: http://www.zilog.com/force_download.php?filepath=YUhSMGNEb3ZMM2QzZHk1NmFXeHZaeTVqYjIwdlpHOWpjeTlWVFRBd056Y3VjR1Jt
+
+	To debug Z80 programs using GDB you must configure and embed
+	z80-stub.c to your program (SDCC compiler is required). Or
+	you may use some simulator with GDB support.
+
+	gdb/ChangeLog:
+
+		* Makefile.in (ALL_TARGET_OBS): Add z80-tdep.c.
+		* NEWS: Mention z80 support.
+		* configure.tgt: Handle z80*.
+		* features/Makefile (XMLTOC): Add z80.xml.
+		* features/z80-cpu.xml: New.
+		* features/z80.c: Generate.
+		* features/z80.xml: New.
+		* z80-tdep.c: New file.
+		* z80-tdep.h: New file.
+
+	gdb/stubs/ChangeLog:
+
+		* z80-stub.c: New file.
+
+	Change-Id: Id0b7a6e210c3f93c6853c5e3031b7bcee47d0db9
+
+2021-07-17  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: make all_inferiors_safe actually work
+	The test gdb.threads/fork-plus-threads.exp fails since 08bdefb58b78
+	("gdb: make inferior_list use intrusive_list"):
+
+	    FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: only inferior 1 left
+
+	Looking at the log, we see that we are left with a bunch of inferiors in
+	the detach-on-fork=off case:
+
+	    info inferiors^M
+	      Num  Description       Connection           Executable        ^M
+	    * 1    <null>                                 <snip>/fork-plus-threads ^M
+	      2    <null>                                 <snip>/fork-plus-threads ^M
+	      3    <null>                                 <snip>/fork-plus-threads ^M
+	      4    <null>                                 <snip>/fork-plus-threads ^M
+	      5    <null>                                 <snip>/fork-plus-threads ^M
+	      6    <null>                                 <snip>/fork-plus-threads ^M
+	      7    <null>                                 <snip>/fork-plus-threads ^M
+	      8    <null>                                 <snip>/fork-plus-threads ^M
+	      9    <null>                                 <snip>/fork-plus-threads ^M
+	      10   <null>                                 <snip>/fork-plus-threads ^M
+	      11   <null>                                 <snip>/fork-plus-threads ^M
+	    (gdb) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: only inferior 1 left
+
+	when we expect to have just one.  The problem is prune_inferiors not
+	pruning inferiors.  And this is caused by all_inferiors_safe not
+	actually iterating on inferiors.  The current implementation:
+
+	  inline all_inferiors_safe_range
+	  all_inferiors_safe ()
+	  {
+	    return {};
+	  }
+
+	default-constructs an all_inferiors_safe_range, which default-constructs
+	an all_inferiors_safe_iterator as its m_begin field, which
+	default-constructs a all_inferiors_iterator.  A default-constructed
+	all_inferiors_iterator is an end iterator, which means we have
+	constructed an (end,end) all_inferiors_safe_range.
+
+	We actually need to pass down the list on which we want to iterator
+	(that is the inferior_list global), so that all_inferiors_iterator's
+	first constructor is chosen.  We also pass nullptr as the proc_target
+	filter.  In this case, we don't do any filtering, but if in the future
+	all_inferiors_safe needed to allow filtering on process target (like
+	all_inferiors does), we could pass down a process target pointer.
+
+	basic_safe_iterator's constructor needs to be changed to allow
+	constructing the wrapped iterator with multiple arguments, not just one.
+
+	With this, gdb.threads/fork-plus-threads.exp is passing once again for
+	me.
+
+	Change-Id: I650552ede596e3590c4b7606ce403690a0278a01
+
+2021-07-17  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-16  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb: Support stepping out from signal handler on riscv*-linux
+	Currently, gdb cannot step outside of a signal handler on RISC-V
+	platforms.  This causes multiple failures in gdb.base/sigstep.exp:
+
+		FAIL: gdb.base/sigstep.exp: continue to handler, nothing in handler, step from handler: leave handler (timeout)
+		FAIL: gdb.base/sigstep.exp: continue to handler, si+advance in handler, step from handler: leave handler (timeout)
+		FAIL: gdb.base/sigstep.exp: continue to handler, nothing in handler, next from handler: leave handler (timeout)
+		FAIL: gdb.base/sigstep.exp: continue to handler, si+advance in handler, next from handler: leave handler (timeout)
+		FAIL: gdb.base/sigstep.exp: stepi from handleri: leave signal trampoline
+		FAIL: gdb.base/sigstep.exp: nexti from handleri: leave signal trampoline
+
+		                === gdb Summary ===
+
+		# of expected passes            587
+		# of unexpected failures        6
+
+	This patch adds support for stepping outside of a signal handler on
+	riscv*-*-linux*.
+
+	Implementation is heavily inspired from mips_linux_syscall_next_pc and
+	surroundings as advised by Pedro Alves.
+
+	After this patch, all tests in gdb.base/sigstep.exp pass.
+
+	Build and tested on riscv64-linux-gnu.
+
+2021-07-16  Lancelot SIX  <lsix@lancelotsix.com>
+
+	gdb/testsuite: Declare that riscv*-*-linux* cannot hardware_single_step
+	Many tests fail in gdb/testsuite/gdb.base/sigstep.exp on
+	riscv64-linux-gnu.  Those tests check that when stepping, if the
+	debuggee received a signal it should step inside the signal handler.
+
+	This feature requires hardware support for single stepping (or at least
+	kernel support), but none are available on riscv*-linux-gnu hosts, at
+	the moment at least.
+
+	This patch adds RISC-V to the list of configurations that does not
+	have hardware single step capability, disabling tests relying on such
+	feature.
+
+	Tested on riscv64-linux-gnu.
+
+2021-07-16  Tom Tromey  <tom@tromey.com>
+
+	Document quick_symbol_functions::expand_symtabs_matching invariant
+	While working on my series to replace the DWARF psymbol reader, I
+	noticed that the expand_symtabs_matching has an undocumented
+	invariant.  I think that, if this invariant is not followed, then GDB
+	will crash.  So, this patch documents this in the relevant spots and
+	introduces some asserts to make it clear.
+
+	Regression tested on x86-64 Fedora 32.
+
+2021-07-16  Tom Tromey  <tromey@adacore.com>
+
+	Fix array stride bug
+	Investigation of using the Python API with an Ada program showed that
+	an array of dynamic types was not being handled properly.  I tracked
+	this down to an oddity of how array strides are handled.
+
+	In gdb, an array stride can be attached to the range type, via the
+	range_bounds object.  However, the stride can also be put into the
+	array's first field.  From create_range_type_with_stride:
+
+	  else if (bit_stride > 0)
+	    TYPE_FIELD_BITSIZE (result_type, 0) = bit_stride;
+
+	It's hard to be sure why this is done, but I would guess a combination
+	of historical reasons plus a desire (mentioned in a comment somewhere)
+	to avoid modifying the range type.
+
+	This patch fixes the problem by changing type::bit_stride to
+	understand this convention.  It also fixes one spot that reproduces
+	this logic.
+
+	Regression tested on x86-64 Fedora 32.
+
+2021-07-16  Giulio Benetti  <giulio.benetti@benettiengineering.com>
+
+	or1k: fix pc-relative relocation against dynamic on PC relative 26 bit relocation.
+	bfd	* elf32-or1k.c (or1k_elf_relocate_section): Use a separate entry
+		in switch case R_OR1K_INSN_REL_26 where we need to check for
+		!SYMBOL_CALLS_LOCAL() instead of !SYMBOL_REFERENCES_LOCAL().
+
+2021-07-16  Nick Clifton  <nickc@redhat.com>
+
+	Updated Swedish translation for the binutils sub-directory
+
+2021-07-16  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-15  Tom Tromey  <tromey@adacore.com>
+
+	Avoid expression parsing crash with unknown language
+	PR gdb/28093 points out that gdb crashes when language is set to
+	"unknown" and expression parsing is attempted.  At first I thought
+	this was a regression due to the expression rewrite, but it turns out
+	that older versions crash as well.
+
+	This patch avoids the crash by changing the default expression parser
+	to throw an exception.  I think this is preferable -- the current
+	behavior of silently doing nothing does not really make sense.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28093
+
+2021-07-15  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: pass child_ptid and fork kind to target_ops::follow_fork
+	This is a small cleanup I think would be nice, that I spotted while
+	doing the following patch.
+
+	gdb/ChangeLog:
+
+		* target.h (struct target_ops) <follow_fork>: Add ptid and
+		target_waitkind parameters.
+		(target_follow_fork): Likewise.
+		* target.c (default_follow_fork): Likewise.
+		(target_follow_fork): Likewise.
+		* fbsd-nat.h (class fbsd_nat_target) <follow_fork>: Likewise.
+		* fbsd-nat.c (fbsd_nat_target::follow_fork): Likewise.
+		* linux-nat.h (class linux_nat_target) <follow_fork>: Likewise.
+		* linux-nat.c (linux_nat_target::follow_fork): Likewise.
+		* obsd-nat.h (class obsd_nat_target) <follow_fork>: Likewise.
+		* obsd-nat.c (obsd_nat_target::follow_fork): Likewise.
+		* remote.c (class remote_target) <follow_fork>: Likewise.
+		* target-debug.h (target_debug_print_target_waitkind): New.
+		* target-delegates.c: Re-generate.
+
+	Change-Id: I5421a542f2e19100a22b74cc333d2b235d0de3c8
+
+2021-07-15  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: call post_create_inferior at end of follow_fork_inferior
+	GDB doesn't handle well the case of an inferior using the JIT interface
+	to register JIT-ed objfiles and forking.  If an inferior registers a
+	code object using the JIT interface and then forks, the child process
+	conceptually has the same code object loaded, so GDB should look it up
+	and learn about it (it currently doesn't).
+
+	To achieve this, I think it would make sense to have the
+	inferior_created observable called when an inferior is created due to a
+	fork in follow_fork_inferior.  The inferior_created observable is
+	currently called both after starting a new inferior and after attaching
+	to an inferior, allowing various sub-components to learn about that new
+	executing inferior.  We can see handling a fork child just like
+	attaching to it, so any work done when attaching should also be done in
+	the case of a fork child.
+
+	Instead of just calling the inferior_created observable, this patch
+	makes follow_fork_inferior call the whole post_create_inferior function.
+	This way, the attach and follow-fork code code paths are more alike.
+
+	Given that post_create_inferior calls solib_create_inferior_hook,
+	follow_fork_inferior doesn't need to do it itself, so those calls to
+	solib_create_inferior_hook are removed.
+
+	One question you may have: why not just call post_create_inferior at the
+	places where solib_create_inferior_hook is currently called, instead of
+	after target_follow_fork?
+
+	 - there's something fishy for the second solib_create_inferior_hook
+	   call site: at this point we have switched the current program space
+	   to the child's, but not the current inferior nor the current thread.
+	   So solib_create_inferior_hook (and everything under, including
+	   check_for_thread_db, for example) is called with inferior 1 as the
+	   current inferior and inferior 2's program space as the current
+	   program space.  I think that's wrong, because at this point we are
+	   setting up inferior 2, and all that code relies on the current
+	   inferior.  We could just add a switch_to_thread call before it to
+	   make inferior 2 the current one, but there are other problems (see
+	   below).
+
+	 - solib_create_inferior_hook is currently not called on the
+	   `follow_child && detach_fork` path.  I think we need to call it,
+	   because we still get a new inferior in that case (even though we
+	   detach the parent).  If we only call post_create_inferior where
+	   solib_create_inferior_hook used to be called, then the JIT
+	   subcomponent doesn't get informed about the new inferior, and that
+	   introduces a failure in the new gdb.base/jit-elf-fork.exp test.
+
+	 - if we try to put the post_create_inferior just after the
+	   switch_to_thread that was originally at line 662, or just before the
+	   call to target_follow_fork, we introduce a subtle failure in
+	   gdb.threads/fork-thread-pending.exp.  What happens then is that
+	   libthread_db gets loaded (somewhere under post_create_inferior)
+	   before the linux-nat target learns about the LWPs (which happens in
+	   linux_nat_target::follow_fork).  As a result, the ALL_LWPS loop in
+	   try_thread_db_load_1 doesn't see the child LWP, and the thread-db
+	   target doesn't have the chance to fill in thread_info::priv.  A bit
+	   later, when the test does "info threads", and
+	   thread_db_target::pid_to_str is called, the thread-db target doesn't
+	   recognize the thread as one of its own, and delegates the request to
+	   the target below.  Because the pid_to_str output is not the expected
+	   one, the test fails.
+
+	   This tells me that we need to call the process target's follow_fork
+	   first, to make the process target create the necessary LWP and thread
+	   structures.  Then, we can call post_create_inferior to let the other
+	   components of GDB do their thing.
+
+	   But then you may ask: check_for_thread_db is already called today,
+	   somewhere under solib_create_inferior_hook, and that is before
+	   target_follow_fork, why don't we see this ordering problem!?  Well,
+	   because of the first bullet point: when check_for_thread_db /
+	   thread_db_load are called, the current inferior is (erroneously)
+	   inferior 1, the parent.  Because libthread_db is already loaded for
+	   the parent, thread_db_load early returns.  check_for_thread_db later
+	   gets called by linux_nat_target::follow_fork.  At this point, the
+	   current inferior is the correct one and the child's LWP exists, so
+	   all is well.
+
+	Since we now call post_create_inferior after target_follow_fork, which
+	calls the inferior_created observable, which calls check_for_thread_db,
+	I don't think linux_nat_target needs to explicitly call
+	check_for_thread_db itself, so that is removed.
+
+	In terms of testing, this patch adds a new gdb.base/jit-elf-fork.exp
+	test.  It makes an inferior register a JIT code object and then fork.
+	It then verifies that whatever the detach-on-fork and follow-fork-child
+	parameters are, GDB knows about the JIT code object in all the inferiors
+	that survive the fork.  It verifies that the inferiors can unload that
+	code object.
+
+	There isn't currently a way to get visibility into GDB's idea of the JIT
+	code objects for each inferior.  For the purpose of this test, add the
+	"maintenance info jit" command.  There isn't much we can print about the
+	JIT code objects except their load address.  So the output looks a bit
+	bare, but it's good enough for the test.
+
+	gdb/ChangeLog:
+
+		* NEWS: Mention "maint info jit" command.
+		* infrun.c (follow_fork_inferior): Don't call
+		solib_create_inferior_hook, call post_create_inferior if a new
+		inferior was created.
+		* jit.c (maint_info_jit_cmd): New.
+		(_initialize_jit): Register new command.
+		* linux-nat.c (linux_nat_target::follow_fork): Don't call
+		check_for_thread_db.
+		* linux-nat.h (check_for_thread_db): Remove declaration.
+		* linux-thread-db.c (check_thread_signals): Make static.
+
+	gdb/doc/ChangeLog:
+
+		* gdb.texinfo (Maintenance Commands): Mention "maint info jit".
+
+	gdb/testsuite/ChangeLog:
+
+		* gdb.base/jit-elf-fork-main.c: New test.
+		* gdb.base/jit-elf-fork-solib.c: New test.
+		* gdb.base/jit-elf-fork.exp: New test.
+
+	Change-Id: I9a192e55b8a451c00e88100669283fc9ca60de5c
+
+2021-07-15  Libor Bukata  <libor.bukata@oracle.com>
+
+	[gdb/procfs.c] Fix build failure in find_stop_signal
+	It fixes a regression caused by commit
+	1edb66d856c82c389edfd7610143236a68c76846 where thread_info::suspend was
+	made private.
+
+	The public thread_info API has to be used to get stop signal and avoid
+	build failures.
+
+	gdb/ChangeLog:
+
+	2021-07-14  Libor Bukata <libor.bukata@oracle.com>
+
+	  * gdb/procfs.c (find_stop_signal): Use thread_info API.
+
+	Change-Id: I53bc57a05cd0eca5f28ef0726d6faeeb306e7904
+
+2021-07-15  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-14  H.J. Lu  <hjl.tools@gmail.com>
+
+	x86: Add int1 as one byte opcode 0xf1
+	Also change the x86 disassembler to disassemble 0xf1 as int1, instead of
+	icebp.
+
+	gas/
+
+		PR gas/28088
+		* testsuite/gas/i386/opcode.s: Add int1.
+		* testsuite/gas/i386/x86-64-opcode.s: Add int1, int3 and int.
+		* testsuite/gas/i386/opcode-intel.d: Updated.
+		* testsuite/gas/i386/opcode-suffix.d: Likewise.
+		* testsuite/gas/i386/opcode.d: Likewise.
+		* testsuite/gas/i386/x86-64-opcode.d: Likewise.
+
+	opcodes/
+
+		PR gas/28088
+		* i386-dis.c (dis386): Replace icebp with int1.
+		* i386-opc.tbl: Add int1.
+		* i386-tbl.h: Regenerate.
+
+2021-07-14  Alan Modra  <amodra@gmail.com>
+
+	gas: default TC_VALIDATE_FIX_SUB to 0
+	gas/write.c provides a fallback TC_VALIDATE_FIX_SUB define that can be
+	a problem for some targets, the problem being that a non-zero
+	definition of TC_VALIDATE_FIX_SUB says that some uses of fx_subsy are
+	OK, in effect that the target will handle fx_subsy in md_apply_fix
+	and/or tc_gen_reloc.  A lot of targets don't have the necessary
+	md_apply_fix and tc_gen_reloc support.  So a safer default is to
+	disallow fx_subsy by default.
+
+	I've had a good look over target usage of fx_subsy, and think I've
+	caught all the cases where targets need TC_VALIDATE_FIX_SUB.  Possible
+	failures would be limited to alpha, microblaze, ppc and s390 (the
+	targets that define UNDEFINED_DIFFERENCE_OK), or targets that generate
+	fixups with BFD_RELOC_GPREL32/16 and use a syntax explicitly showing
+	a difference expression.
+
+		* write.c (TC_VALIDATE_FIX_SUB): Default to 0.
+		* config/tc-hppa.h (TC_VALIDATE_FIX_SUB): Define.
+		* config/tc-microblaze.h (TC_VALIDATE_FIX_SUB): Define.
+		* config/tc-alpha.h (TC_VALIDATE_FIX_SUB): Define for ECOFF.
+		* config/tc-ppc.h (TC_VALIDATE_FIX_SUB): Don't define for ELF.
+		Do define for XCOFF.
+
+2021-07-14  Clément Chigot  <clement.chigot@atos.net>
+
+	objdump: add DWARF support for AIX
+	DWARF sections have special names on AIX which need be handled
+	by objdump in order to correctly print them.
+	This patch also adds the correlation in bfd for future uses.
+
+	bfd/
+		* libxcoff.h (struct xcoff_dwsect_name): Add DWARF name.
+		* coff-rs6000.c (xcoff_dwsect_names): Update.
+		* coffcode.h (sec_to_styp_flags): Likewise.
+		(coff_new_section_hook): Likewise.
+	binutils/
+		* dwarf.h (struct dwarf_section): Add XCOFF name.
+		* dwarf.c (struct dwarf_section_display): Update.
+		* objdump.c (load_debug_section): Add XCOFF name handler.
+		(dump_dwarf_section): Likewise.
+	gas/
+		* config/tc-ppc.c (ppc_change_debug_section): Update to
+		match new name's field.
+
+2021-07-14  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.base/gold-gdb-index.exp
+	When running test-case gdb.base/gold-gdb-index.exp on openSUSE Tumbleweed,
+	I run into:
+	...
+	FAIL: gdb.base/gold-gdb-index.exp: maint info symtabs
+	...
+
+	This is due to a dummy .gdb_index:
+	...
+	Contents of the .gdb_index section:
+
+	Version 7
+
+	CU table:
+
+	TU table:
+
+	Address table:
+
+	Symbol table:
+	...
+
+	The dummy .gdb_index is ignored when loading the symbols, and instead partial
+	symbols are used.  Consequently, we get the same result as if we'd removed
+	-Wl,--gdb-index from the compilation.
+
+	Presumably, gold fails to generate a proper .gdb_index because it lacks
+	DWARF5 support.
+
+	Anyway, without a proper .gdb_index we can't test the gdb behaviour we're
+	trying to excercise.  Fix this by detecting whether we actually used a
+	.gdb_index for symbol loading.
+
+	Tested on x86_64-linux.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-07-14  Tom de Vries  <tdevries@suse.de>
+
+		* lib/gdb.exp (have_index): New proc.
+		* gdb.base/gold-gdb-index.exp: Use have_index.
+
+2021-07-14  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Add missing skip_tui_tests
+	When building gdb with --disable-tui, we run into:
+	...
+	(gdb) frame apply all -- -^M
+	Undefined command: "-".  Try "help".^M
+	(gdb) ERROR: Undefined command "frame apply all -- -".
+	UNRESOLVED: gdb.base/options.exp: test-frame-apply: frame apply all -- -
+	...
+
+	Fix this by detecting whether tui is supported, and skipping the tui-related
+	tests otherwise.  Same in some gdb.tui test-cases.
+
+	Tested on x86_64-linux.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-07-13  Tom de Vries  <tdevries@suse.de>
+
+		* gdb.base/options.exp: Skip tui-related tests when tui is not
+		supported.
+		* gdb.python/tui-window-disabled.exp: Same.
+		* gdb.python/tui-window.exp: Same.
+
+2021-07-14  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-13  Lancelot SIX  <lsix@lancelotsix.com>
+
+	Use /bin/sh as shebang in gdb/make-init-c
+	While testing the NixOS[1] packaging for gdb-11.0.90.tar.xz, I got the
+	following error:
+
+	  [...]
+	  CXX    aarch32-tdep.o
+	  CXX    gdb.o
+	  GEN    init.c
+	  /nix/store/26a78ync552m8j4sbjavhvkmnqir8c9y-bash-4.4-p23/bin/bash: ./make-init-c: /usr/bin/env: bad interpreter: No such file or directory
+	  make[2]: *** [Makefile:1866: stamp-init] Error 126
+	  make[2]: *** Waiting for unfinished jobs....
+	  make[2]: Leaving directory '/build/gdb-11.0.90/gdb'
+	  make[1]: *** [Makefile:9814: all-gdb] Error 2
+	  make[1]: Leaving directory '/build/gdb-11.0.90'
+	  make: *** [Makefile:903: all] Error 2
+	  builder for '/nix/store/xs8my3rrc3l4kdlbpx0azh6q0v0jxphr-gdb-gdb-11.0.90.drv' failed with exit code 2
+	  error: build of '/nix/store/xs8my3rrc3l4kdlbpx0azh6q0v0jxphr-gdb-gdb-11.0.90.drv' failed
+
+	In the nix build environment, /usr/bin/env is not present, only /bin/sh
+	is.  This patch makes sure that gdb/make-init-c uses '/bin/sh' as
+	interpreter as this is the only one available on this platform.
+
+	I do not think this change will cause regressions on any other
+	configuration.
+
+	[1] https://nixos.org/
+
+	gdb/Changelog
+
+		* make-init-c: Use /bin/sh as shebang.
+
+2021-07-13  John Baldwin  <jhb@FreeBSD.org>
+
+	arm-fbsd-nat: Use fetch_register_set and store_register_set.
+
+	aarch64-fbsd-nat: Use fetch_register_set and store_register_set.
+
+	riscv-fbsd-nat: Use fetch_register_set and store_register_set.
+
+	fbsd-nat: Add helper functions to fetch and store register sets.
+	In particular, this supports register sets described by a regcache_map
+	which are fetched and stored with dedicated ptrace operations.  These
+	functions are intended to be used in architecture-specific
+	fetch_registers and store_registers target methods.
+
+	Add regcache_map_supplies helper routine.
+	This helper can be used in the fetch_registers and store_registers
+	target methods to determine if a register set includes a specific
+	register.
+
+2021-07-13  Pedro Alves  <pedro@palves.net>
+
+	Avoid letting exceptions escape gdb_bfd_iovec_fileio_close (PR gdb/28080)
+	Before PR gdb/28080 was fixed by the previous patch, GDB was crashing
+	like this:
+
+	 (gdb) detach
+	 Detaching from program: target:/any/program, process 3671843
+	 Detaching from process 3671843
+	 Ending remote debugging.
+	 [Inferior 1 (process 3671843) detached]
+	 In main
+	 terminate called after throwing an instance of 'gdb_exception_error'
+	 Aborted (core dumped)
+
+	Here's the exception above being thrown:
+
+	 (top-gdb) bt
+	 #0  throw_error (error=TARGET_CLOSE_ERROR, fmt=0x555556035588 "Remote connection closed") at src/gdbsupport/common-exceptions.cc:222
+	 #1  0x0000555555bbaa46 in remote_target::readchar (this=0x555556a11040, timeout=10000) at src/gdb/remote.c:9440
+	 #2  0x0000555555bbb9e5 in remote_target::getpkt_or_notif_sane_1 (this=0x555556a11040, buf=0x555556a11058, forever=0, expecting_notif=0, is_notif=0x0) at src/gdb/remote.c:9928
+	 #3  0x0000555555bbbda9 in remote_target::getpkt_sane (this=0x555556a11040, buf=0x555556a11058, forever=0) at src/gdb/remote.c:10030
+	 #4  0x0000555555bc0e75 in remote_target::remote_hostio_send_command (this=0x555556a11040, command_bytes=13, which_packet=14, remote_errno=0x7fffffffcfd0, attachment=0x0, attachment_len=0x0) at src/gdb/remote.c:12137
+	 #5  0x0000555555bc1b6c in remote_target::remote_hostio_close (this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at src/gdb/remote.c:12455
+	 #6  0x0000555555bc1bb4 in remote_target::fileio_close (During symbol reading: .debug_line address at offset 0x64f417 is 0 [in module build/gdb/gdb]
+	 this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at src/gdb/remote.c:12462
+	 #7  0x0000555555c9274c in target_fileio_close (fd=3, target_errno=0x7fffffffcfd0) at src/gdb/target.c:3365
+	 #8  0x000055555595a19d in gdb_bfd_iovec_fileio_close (abfd=0x555556b9f8a0, stream=0x555556b11530) at src/gdb/gdb_bfd.c:439
+	 #9  0x0000555555e09e3f in opncls_bclose (abfd=0x555556b9f8a0) at src/bfd/opncls.c:599
+	 #10 0x0000555555e0a2c7 in bfd_close_all_done (abfd=0x555556b9f8a0) at src/bfd/opncls.c:847
+	 #11 0x0000555555e0a27a in bfd_close (abfd=0x555556b9f8a0) at src/bfd/opncls.c:814
+	 #12 0x000055555595a9d3 in gdb_bfd_close_or_warn (abfd=0x555556b9f8a0) at src/gdb/gdb_bfd.c:626
+	 #13 0x000055555595ad29 in gdb_bfd_unref (abfd=0x555556b9f8a0) at src/gdb/gdb_bfd.c:715
+	 #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540, __in_chrg=<optimized out>) at src/gdb/objfiles.c:573
+	 #15 0x0000555555ae955a in std::_Sp_counted_ptr<objfile*, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:377
+	 #16 0x000055555572b7c8 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:155
+	 #17 0x00005555557263c3 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x555556bf0588, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:730
+	 #18 0x0000555555ae745e in std::__shared_ptr<objfile, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x555556bf0580, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:1169
+	 #19 0x0000555555ae747e in std::shared_ptr<objfile>::~shared_ptr (this=0x555556bf0580, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr.h:103
+	 #20 0x0000555555b1c1dc in __gnu_cxx::new_allocator<std::_List_node<std::shared_ptr<objfile> > >::destroy<std::shared_ptr<objfile> > (this=0x5555564cdd60, __p=0x555556bf0580) at /usr/include/c++/9/ext/new_allocator.h:153
+	 #21 0x0000555555b1bb1d in std::allocator_traits<std::allocator<std::_List_node<std::shared_ptr<objfile> > > >::destroy<std::shared_ptr<objfile> > (__a=..., __p=0x555556bf0580) at /usr/include/c++/9/bits/alloc_traits.h:497
+	 #22 0x0000555555b1b73e in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::_M_erase (this=0x5555564cdd60, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556515540}) at /usr/include/c++/9/bits/stl_list.h:1921
+	 #23 0x0000555555b1afeb in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::erase (this=0x5555564cdd60, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556515540}) at /usr/include/c++/9/bits/list.tcc:158
+	 #24 0x0000555555b19576 in program_space::remove_objfile (this=0x5555564cdd20, objfile=0x555556515540) at src/gdb/progspace.c:210
+	 #25 0x0000555555ae4502 in objfile::unlink (this=0x555556515540) at src/gdb/objfiles.c:487
+	 #26 0x0000555555ae5a12 in objfile_purge_solibs () at src/gdb/objfiles.c:875
+	 #27 0x0000555555c09686 in no_shared_libraries (ignored=0x0, from_tty=1) at src/gdb/solib.c:1236
+	 #28 0x00005555559e3f5f in detach_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:2769
+
+	Note frame #14:
+
+	 #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540, __in_chrg=<optimized out>) at src/gdb/objfiles.c:573
+
+	That's a dtor, thus noexcept.  That's the reason for the
+	std::terminate.
+
+	The previous patch fixed things such that the exception above isn't
+	thrown anymore.  However, it's possible that e.g., the remote
+	connection drops just while a user types "nosharedlibrary", or some
+	other reason that leads to objfile::~objfile, and then we end up the
+	same std::terminate problem.
+
+	Also notice that frames #9-#11 are BFD frames:
+
+	 #9  0x0000555555e09e3f in opncls_bclose (abfd=0x555556bc27e0) at src/bfd/opncls.c:599
+	 #10 0x0000555555e0a2c7 in bfd_close_all_done (abfd=0x555556bc27e0) at src/bfd/opncls.c:847
+	 #11 0x0000555555e0a27a in bfd_close (abfd=0x555556bc27e0) at src/bfd/opncls.c:814
+
+	BFD is written in C and thus throwing exceptions over such frames may
+	either not clean up properly, or, may abort if bfd is not compiled
+	with -fasynchronous-unwind-tables (x86-64 defaults that on, but not
+	all GCC ports do).
+
+	Thus frame #8 seems like a good place to swallow exceptions.  More so
+	since in this spot we already ignore target_fileio_close return
+	errors.  That's what this commit does.  Without the previous fix, we'd
+	see:
+
+	 (gdb) detach
+	 Detaching from program: target:/any/program, process 2197701
+	 Ending remote debugging.
+	 [Inferior 1 (process 2197701) detached]
+	 warning: cannot close "target:/lib64/ld-linux-x86-64.so.2": Remote connection closed
+
+	Note it prints a warning, which would still be a regression compared
+	to GDB 10, if it weren't for the previous fix.
+
+	gdb/ChangeLog:
+	yyyy-mm-dd  Pedro Alves  <pedro@palves.net>
+
+		PR gdb/28080
+		* gdb_bfd.c (gdb_bfd_close_warning): New.
+		(gdb_bfd_iovec_fileio_close): Wrap target_fileio_close in
+		try/catch and print warning on exception.
+		(gdb_bfd_close_or_warn): Use gdb_bfd_close_warning.
+
+	Change-Id: Ic7a26ddba0a4444e3377b0e7c1c89934a84545d7
+
+2021-07-13  Pedro Alves  <pedro@palves.net>
+
+	Fix detach with target remote (PR gdb/28080)
+	Commit 408f66864a1a823591b26420410c982174c239a2 ("detach in all-stop
+	with threads running") regressed "detach" with "target remote":
+
+	 (gdb) detach
+	 Detaching from program: target:/any/program, process 3671843
+	 Detaching from process 3671843
+	 Ending remote debugging.
+	 [Inferior 1 (process 3671843) detached]
+	 In main
+	 terminate called after throwing an instance of 'gdb_exception_error'
+	 Aborted (core dumped)
+
+	Here's the exception above being thrown:
+
+	 (top-gdb) bt
+	 #0  throw_error (error=TARGET_CLOSE_ERROR, fmt=0x555556035588 "Remote connection closed") at src/gdbsupport/common-exceptions.cc:222
+	 #1  0x0000555555bbaa46 in remote_target::readchar (this=0x555556a11040, timeout=10000) at src/gdb/remote.c:9440
+	 #2  0x0000555555bbb9e5 in remote_target::getpkt_or_notif_sane_1 (this=0x555556a11040, buf=0x555556a11058, forever=0, expecting_notif=0, is_notif=0x0) at src/gdb/remote.c:9928
+	 #3  0x0000555555bbbda9 in remote_target::getpkt_sane (this=0x555556a11040, buf=0x555556a11058, forever=0) at src/gdb/remote.c:10030
+	 #4  0x0000555555bc0e75 in remote_target::remote_hostio_send_command (this=0x555556a11040, command_bytes=13, which_packet=14, remote_errno=0x7fffffffcfd0, attachment=0x0, attachment_len=0x0) at src/gdb/remote.c:12137
+	 #5  0x0000555555bc1b6c in remote_target::remote_hostio_close (this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at src/gdb/remote.c:12455
+	 #6  0x0000555555bc1bb4 in remote_target::fileio_close (During symbol reading: .debug_line address at offset 0x64f417 is 0 [in module build/gdb/gdb]
+	 this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at src/gdb/remote.c:12462
+	 #7  0x0000555555c9274c in target_fileio_close (fd=3, target_errno=0x7fffffffcfd0) at src/gdb/target.c:3365
+	 #8  0x000055555595a19d in gdb_bfd_iovec_fileio_close (abfd=0x555556b9f8a0, stream=0x555556b11530) at src/gdb/gdb_bfd.c:439
+	 #9  0x0000555555e09e3f in opncls_bclose (abfd=0x555556b9f8a0) at src/bfd/opncls.c:599
+	 #10 0x0000555555e0a2c7 in bfd_close_all_done (abfd=0x555556b9f8a0) at src/bfd/opncls.c:847
+	 #11 0x0000555555e0a27a in bfd_close (abfd=0x555556b9f8a0) at src/bfd/opncls.c:814
+	 #12 0x000055555595a9d3 in gdb_bfd_close_or_warn (abfd=0x555556b9f8a0) at src/gdb/gdb_bfd.c:626
+	 #13 0x000055555595ad29 in gdb_bfd_unref (abfd=0x555556b9f8a0) at src/gdb/gdb_bfd.c:715
+	 #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540, __in_chrg=<optimized out>) at src/gdb/objfiles.c:573
+	 #15 0x0000555555ae955a in std::_Sp_counted_ptr<objfile*, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:377
+	 #16 0x000055555572b7c8 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:155
+	 #17 0x00005555557263c3 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x555556bf0588, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:730
+	 #18 0x0000555555ae745e in std::__shared_ptr<objfile, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x555556bf0580, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:1169
+	 #19 0x0000555555ae747e in std::shared_ptr<objfile>::~shared_ptr (this=0x555556bf0580, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr.h:103
+	 #20 0x0000555555b1c1dc in __gnu_cxx::new_allocator<std::_List_node<std::shared_ptr<objfile> > >::destroy<std::shared_ptr<objfile> > (this=0x5555564cdd60, __p=0x555556bf0580) at /usr/include/c++/9/ext/new_allocator.h:153
+	 #21 0x0000555555b1bb1d in std::allocator_traits<std::allocator<std::_List_node<std::shared_ptr<objfile> > > >::destroy<std::shared_ptr<objfile> > (__a=..., __p=0x555556bf0580) at /usr/include/c++/9/bits/alloc_traits.h:497
+	 #22 0x0000555555b1b73e in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::_M_erase (this=0x5555564cdd60, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556515540}) at /usr/include/c++/9/bits/stl_list.h:1921
+	 #23 0x0000555555b1afeb in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::erase (this=0x5555564cdd60, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556515540}) at /usr/include/c++/9/bits/list.tcc:158
+	 #24 0x0000555555b19576 in program_space::remove_objfile (this=0x5555564cdd20, objfile=0x555556515540) at src/gdb/progspace.c:210
+	 #25 0x0000555555ae4502 in objfile::unlink (this=0x555556515540) at src/gdb/objfiles.c:487
+	 #26 0x0000555555ae5a12 in objfile_purge_solibs () at src/gdb/objfiles.c:875
+	 #27 0x0000555555c09686 in no_shared_libraries (ignored=0x0, from_tty=1) at src/gdb/solib.c:1236
+	 #28 0x00005555559e3f5f in detach_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:2769
+
+	So frame #28 already detached the remote process, and then we're
+	purging the shared libraries.  GDB had opened remote shared libraries
+	via the target: sysroot, so it tries closing them.  GDBserver is
+	tearing down already, so remote communication breaks down and we close
+	the remote target and throw TARGET_CLOSE_ERROR.
+
+	Note frame #14:
+
+	 #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540, __in_chrg=<optimized out>) at src/gdb/objfiles.c:573
+
+	That's a dtor, thus noexcept.  That's the reason for the
+	std::terminate.
+
+	Stepping back a bit, why do we still have open remote files if we've
+	managed to detach already, and, we're debugging with "target remote"?
+	The reason is that commit 408f66864a1a823591b26420410c982174c239a2
+	makes detach_command hold a reference to the target, so the remote
+	target won't be finally closed until frame #28 returns.  It's closing
+	the target that invalidates target file I/O handles.
+
+	This commit fixes the issue by not relying on target_close to
+	invalidate the target file I/O handles, instead invalidate them
+	immediately in remote_unpush_target.  So when GDB purges the solibs,
+	and we end up in target_fileio_close (frame #7 above), there's nothing
+	to do, and we don't try to talk with the remote target anymore.
+
+	The regression isn't seen when testing with
+	--target_board=native-gdbserver, because that does "set sysroot" to
+	disable the "target:" sysroot, for test run speed reasons.  So this
+	commit adds a testcase that explicitly tests detach with "set sysroot
+	target:".
+
+	gdb/ChangeLog:
+	yyyy-mm-dd  Pedro Alves  <pedro@palves.net>
+
+		PR gdb/28080
+		* remote.c (remote_unpush_target): Invalidate file I/O target
+		handles.
+		* target.c (fileio_handles_invalidate_target): Make extern.
+		* target.h (fileio_handles_invalidate_target): Declare.
+
+	gdb/testsuite/ChangeLog:
+	yyyy-mm-dd  Pedro Alves  <pedro@palves.net>
+
+		PR gdb/28080
+		* gdb.base/detach-sysroot-target.exp: New.
+		* gdb.base/detach-sysroot-target.c: New.
+
+	Reported-By: Jonah Graham <jonah@kichwacoders.com>
+
+	Change-Id: I851234910172f42a1b30e731161376c344d2727d
+
+2021-07-13  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix check-libthread-db.exp FAILs with glibc 2.33
+	When running test-case gdb.threads/check-libthread-db.exp on openSUSE
+	Tumbleweed with glibc 2.33, I get:
+	...
+	(gdb) maint check libthread-db^M
+	Running libthread_db integrity checks:^M
+	  Got thread 0x7ffff7c79b80 => 9354 => 0x7ffff7c79b80; errno = 0 ... OK^M
+	libthread_db integrity checks passed.^M
+	(gdb) FAIL: gdb.threads/check-libthread-db.exp: user-initiated check: \
+	  libpthread.so not initialized (pattern 2)
+	...
+
+	The test-case expects instead:
+	...
+	  Got thread 0x0 => 9354 => 0x0 ... OK^M
+	...
+	which is what I get on openSUSE Leap 15.2 with glibc 2.26, and what is
+	described in the test-case like this:
+	...
+	    # libthread_db should fake a single thread with th_unique == NULL.
+	...
+
+	Using a breakpoint on check_thread_db_callback we can compare the two
+	scenarios, and find that in the latter case we hit this code in glibc function
+	iterate_thread_list in nptl_db/td_ta_thr_iter.c:
+	...
+	  if (next == 0 && fake_empty)
+	    {
+	      /* __pthread_initialize_minimal has not run.  There is just the main
+	         thread to return.  We cannot rely on its thread register.  They
+	         sometimes contain garbage that would confuse us, left by the
+	         kernel at exec.  So if it looks like initialization is incomplete,
+	         we only fake a special descriptor for the initial thread.  */
+	      td_thrhandle_t th = { ta, 0 };
+	      return callback (&th, cbdata_p) != 0 ? TD_DBERR : TD_OK;
+	    }
+	...
+	while in the former case we don't because this preceding statement doesn't
+	result in next == 0:
+	...
+	  err = DB_GET_FIELD (next, ta, head, list_t, next, 0);
+	...
+
+	Note that the comment mentions __pthread_initialize_minimal, but in both cases
+	it has already run before we hit the callback, so it's possible the comment is
+	no longer accurate.
+
+	The change in behaviour bisect to glibc commit 1daccf403b "nptl: Move stack
+	list variables into _rtld_global", which moves the initialization of stack
+	list variables such as __stack_user to an earlier moment, which explains well
+	enough the observed difference.
+
+	Fix this by updating the regexp patterns to agree with what libthread-db is
+	telling us.
+
+	Tested on x86_64-linux, both with glibc 2.33 and 2.26.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-07-07  Tom de Vries  <tdevries@suse.de>
+
+		PR testsuite/27690
+		* gdb.threads/check-libthread-db.exp: Update patterns for glibc 2.33.
+
+2021-07-13  Felix Willgerodt  <felix.willgerodt@intel.com>
+
+	gdb, dwarf: Don't follow the parent of a subprogram to get a prefix.
+	During prefix resolution, if the parent is a subprogram, there is no need
+	to go to the parent of the subprogram.  The DIE will be local.
+
+	For a program like:
+	~~~
+	  class F1
+	  {
+	  public:
+	    int a;
+	    int
+	    vvv ()
+	    {
+	      class F2
+	      {
+		int f;
+	      };
+	      F2 abcd;
+	      return 1;
+	    }
+	  };
+	~~~
+
+	The class F2 should not be seen as a member of F1.
+
+	Before:
+	~~~
+	(gdb) ptype abcd
+	type = class F1::F2 {
+	  private:
+	    int f;
+	}
+	~~~
+
+	After:
+	~~~
+	(gdb) ptype abcd
+	type = class F2 {
+	  private:
+	    int f;
+	}
+	~~~
+
+	gdb/ChangeLog:
+	2021-06-23  Felix Willgerodt  <felix.willgerodt@intel.com>
+
+		* dwarf2/read.c (determine_prefix): Return an empty prefix if the
+		parent is a subprogram.
+
+	gdb/testsuite/ChangeLog:
+	2021-06-23  Felix Willgerodt  <felix.willgerodt@intel.com>
+
+		* gdb.cp/nested-class-func-class.cc: New file.
+		* gdb.cp/nested-class-func-class.exp: New file.
+
+2021-07-13  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: disable commit-resumed on -exec-interrupt --thread-group
+	As reported in PR gdb/28077, we hit an internal error when using
+	-exec-interrupt with --thread-group:
+
+	    info threads
+	    &"info threads\n"
+	    ~"  Id   Target Id             Frame \n"
+	    ~"* 1    process 403312 \"loop\" (running)\n"
+	    ^done
+	    (gdb)
+	    -exec-interrupt --thread-group i1
+	    ~"/home/simark/src/binutils-gdb/gdb/target.c:3768: internal-error: void target_stop(ptid_t): Assertion `!proc_target->commit_resumed_state' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nQuit this debugging session? (y or n) "
+
+	This is because this code path never disables commit-resumed (a
+	requirement for calling target_stop, as documented in
+	process_stratum_target::»commit_resumed_state) before calling
+	target_stop.
+
+	The other 3 code paths in mi_cmd_exec_interrupt use interrupt_target_1,
+	which does it.  But the --thread-group code path uses its own thing
+	which doesn't do it.  Fix this by adding a scoped_disable_commit_resumed
+	in this code path.
+
+	Calling -exec-interrupt with --thread-group is apparently not tested at
+	the moment (which is why this bug could creep in).  Add a new test for
+	that.  The test runs two inferiors and tries to interrupt them with
+	"-exec-interrupt --thread-group X".
+
+	This will need to be merged in the gdb-11-branch, so here are ChangeLog
+	entries:
+
+	gdb/ChangeLog:
+
+		* mi/mi-main.c (mi_cmd_exec_interrupt): Use
+		scoped_disable_commit_resumed in the --thread-group case.
+
+	gdb/testsuite/ChangeLog:
+
+		* gdb.mi/interrupt-thread-group.c: New.
+		* gdb.mi/interrupt-thread-group.exp: New.
+
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28077
+	Change-Id: I615efefcbcaf2c15d47caf5e4b9d82854b2a2fcb
+
+2021-07-13  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: Enable elf attributes when default configure option isn't set.
+	Since gcc commit, 3c70b3ca1ef58f302bf8c16d9e7c7bb8626408bf, we now enable
+	elf attributes for all riscv targets by default in gcc.  Therefore, I
+	think binutils should have the same behavior, in case users are writing
+	assembly files.  If --enable-default-riscv-attribute isn't set, then we
+	enable the elf attributes for all riscv targets by default.
+
+	ChangLog:
+
+	binutils/
+
+		* testsuite/binutils-all/readelf.s: Add comments for riscv.
+		* testsuite/binutils-all/readelf.s-64: Likewise.
+		* testsuite/binutils-all/readelf.s-64-unused: Likewise.
+		* testsuite/binutils-all/readelf.ss: Likewise.
+		* testsuite/binutils-all/readelf.ss-64: Likewise.
+		* testsuite/binutils-all/readelf.ss-64-unused: Likewise.
+
+	gas/
+
+		* configure.ac: If --enable-default-riscv-attribute isn't set,
+		then we enable the elf attributes for all riscv targets by
+		default.
+		* configure: Regenerated.
+
+2021-07-13  John Ericson  <git@JohnEricson.me>
+
+	Fix some dangling references to `netbsd-tdep`
+	These files were renamed in 1b71cfcfdc3e13a655fefa6566b5564cec044c10,
+	but evidentially a few dangling references were left behind. This causes
+	builds to fail:
+
+	    $ ./configure --target i686-netbsdelf
+	    $ make
+	    make: *** No rule to make target 'nbsd-tdep.c', needed by 'nbsd-tdep.o'.  Stop.
+
+2021-07-13  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: optimize all_matching_threads_iterator
+	all_matching_threads_iterator is used extensively in some pretty fast
+	paths, often under the all_non_exited_threads function.
+
+	If a filter target and thread-specific ptid are given, it iterates on
+	all threads of all inferiors of that target, to ultimately yield exactly
+	on thread.  And this happens quite often, which means we unnecessarily
+	spend time iterating on threads to find the one we are looking for.  The
+	same thing happens if an inferior-specific ptid is given, although there
+	the iterator yields all the threads of that inferior.
+
+	In those cases, the callers of all_non_exited_threads could have
+	different behaviors depending on the kind of ptid, to avoid this
+	inefficiency, but that would be very tedious.  Using
+	all_non_exited_threads has the advantage that one simple implementation
+	can work seamlessly on multiple threads or on one specific thread, just
+	by playing with the ptid.
+
+	Instead, optimize all_matching_threads_iterator directly to detect these
+	different cases and limiting what we iterate on to just what we need.
+
+	 - if filter_ptid is minus_one_ptid, do as we do now: filter inferiors
+	   based on filter_target, iterate on all of the matching inferiors'
+	   threads
+	 - if filter_ptid is a pid-only ptid (then a filter_target must
+	   necessarily be given), look up that inferior and iterate on all its
+	   threads
+	 - otherwise, filter_ptid is a thread-specific ptid, so look up that
+	   specific thread and "iterate" only on it
+
+	For the last case, what was an iteration on all threads of the filter
+	target now becomes a call to find_thread_ptid, which is quite efficient
+	now thanks to inferior::ptid_thread_map.
+
+	gdb/ChangeLog:
+
+		* thread-iter.h (class all_matching_threads_iterator)
+		<all_matching_threads_iterator>: Use default.
+		<enum class mode>: New.
+		<m_inf, m_thr>: Initialize.
+		<m_filter_ptid>: Remove.
+		* thread-iter.c (all_matching_threads_iterator::m_inf_matches):
+		Don't filter on m_filter_ptid.
+		(all_matching_threads_iterator::all_matching_threads_iterator):
+		Choose path based on filter_ptid (all threads, all threads of
+		inferior, single thread).
+		(all_matching_threads_iterator::advance): Likewise.
+
+	Change-Id: Ic6a19845f5f760fa1b8eac8145793c0ff431bbc9
+
+2021-07-13  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: maintain ptid -> thread map, optimize find_thread_ptid
+	When debugging a large number of threads (thousands), looking up a
+	thread by ptid_t using the inferior::thread_list linked list can add up.
+
+	Add inferior::thread_map, an std::unordered_map indexed by ptid_t, and
+	change the find_thread_ptid function to look up a thread using
+	std::unordered_map::find, instead of iterating on all of the
+	inferior's threads.  This should make it faster to look up a thread
+	from its ptid.
+
+	Change-Id: I3a8da0a839e18dee5bb98b8b7dbeb7f3dfa8ae1c
+	Co-Authored-By: Pedro Alves <pedro@palves.net>
+
+2021-07-13  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: optimize selection of resumed thread with pending event
+	Consider a case where many threads (thousands) keep hitting a breakpoint
+	whose condition evaluates to false.  random_pending_event_thread is
+	responsible for selecting a thread from an inferior among all that are
+	resumed with a pending wait status.  It is currently implemented by
+	walking the inferior's thread list twice: once to count the number of
+	candidates and once to select a random one.
+
+	Since we now maintain a per target list of resumed threads with pending
+	event, we can implement this more efficiently by walking that list and
+	selecting the first thread that matches the criteria
+	(random_pending_event_thread looks for an thread from a specific
+	inferior, and possibly a filter ptid).  It will be faster especially in
+	the common case where there isn't any resumed thread with pending
+	event.  Currently, we have to iterate the thread list to figure this
+	out.  With this patch, the list of resumed threads with pending event
+	will be empty, so it's quick to figure out.
+
+	The random selection is kept, but is moved to
+	process_stratum_target::random_resumed_with_pending_wait_status.  The
+	same technique is used: do a first pass to count the number of
+	candidates, and do a second pass to select a random one.  But given that
+	the list of resumed threads with pending wait statuses will generally be
+	short, or at least shorter than the full thread list, it should be
+	quicker.
+
+	Note that this isn't completely true, in case there are multiple
+	inferiors on the same target.  Imagine that inferior A has 10k resumed
+	threads with pending wait statuses, and random_pending_event_thread is
+	called with inferior B.  We'll need to go through the list that contains
+	inferior A's threads to realize that inferior B has no resumed threads
+	with pending wait status.  But I think that this is a corner /
+	pathological case.  And a possible fix for this situation would be to
+	make random_pending_event_thread work per-process-target, rather than
+	per-inferior.
+
+	Change-Id: I1b71d01beaa500a148b5b9797745103e13917325
+
+2021-07-13  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: optimize check for resumed threads with pending wait status in maybe_set_commit_resumed_all_targets
+	Consider a test case where many threads (thousands) keep hitting a
+	breakpoint whose condition evaluates to false.
+	maybe_set_commit_resumed_all_targets is called at each handled event,
+	when the scoped_disable_commit_resumed object in fetch_inferior_event is
+	reset_and_commit-ed.  One particularly expensive check in there is
+	whether the target has at least one resumed thread with a pending wait
+	status (in which case, we don't want to commit the resumed threads, as
+	we want to consume this status first).  It is currently implemented as
+	walking all threads of the target.
+
+	Since we now maintain a per-target list of resumed threads with pending
+	status, we can do this check efficiently, by checking whether that list
+	is empty or not.
+
+	Add the process_stratum_target::has_resumed_with_pending_wait_status
+	method for this, and use it in maybe_set_commit_resumed_all_targets.
+
+	Change-Id: Ia1595baa1b358338f94fc3cb3af7f27092dad5b6
+
+2021-07-13  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: maintain per-process-target list of resumed threads with pending wait status
+	Looking up threads that are both resumed and have a pending wait
+	status to report is something that we do quite often in the fast path
+	and is expensive if there are many threads, since it currently requires
+	walking whole thread lists.
+
+	The first instance is in maybe_set_commit_resumed_all_targets.  This is
+	called after handling each event in fetch_inferior_event, to see if we
+	should ask targets to commit their resumed threads or not.  If at least
+	one thread is resumed but has a pending wait status, we don't ask the
+	targets to commit their resumed threads, because we want to consume and
+	handle the pending wait status first.
+
+	The second instance is in random_pending_event_thread, where we want to
+	select a random thread among all those that are resumed and have a
+	pending wait status.  This is called every time we try to consume
+	events, to see if there are any pending events that we we want to
+	consume, before asking the targets for more events.
+
+	To allow optimizing these cases, maintain a per-process-target list of
+	threads that are resumed and have a pending wait status.
+
+	In maybe_set_commit_resumed_all_targets, we'll be able to check in O(1)
+	if there are any such threads simply by checking whether the list is
+	empty.
+
+	In random_pending_event_thread, we'll be able to use that list, which
+	will be quicker than iterating the list of threads, especially when
+	there are no resumed with pending wait status threads.
+
+	About implementation details: using the new setters on class
+	thread_info, it's relatively easy to maintain that list.  Any time the
+	"resumed" or "pending wait status" property is changed, we check whether
+	that should cause the thread to be added or removed from the list.
+
+	In set_thread_exited, we try to remove the thread from the list, because
+	keeping an exited thread in that list would make no sense (especially if
+	the thread is freed).  My first implementation assumed that a process
+	stratum target was always present when set_thread_exited is called.
+	That's however, not the case: in some cases, targets unpush themselves
+	from an inferior and then call "exit_inferior", which exits all the
+	threads.  If the target is unpushed before set_thread_exited is called
+	on the threads, it means we could mistakenly leave some threads in the
+	list.  I tried to see how hard it would be to make it such that targets
+	have to exit all threads before unpushing themselves from the inferior
+	(that would seem logical to me, we don't want threads belonging to an
+	inferior that has no process target).  That seemed quite difficult and
+	not worth the time at the moment.  Instead, I changed
+	inferior::unpush_target to remove all threads of that inferior from the
+	list.
+
+	As of this patch, the list is not used, this is done in the subsequent
+	patches.
+
+	The debug messages in process-stratum-target.c need to print some ptids.
+	However, they can't use target_pid_to_str to print them without
+	introducing a dependency on the current inferior (the current inferior
+	is used to get the current target stack).  For debug messages, I find it
+	clearer to print the spelled out ptid anyway (the pid, lwp and tid
+	values).  Add a ptid_t::to_string method that returns a string
+	representation of the ptid that is meant for debug messages, a bit like
+	we already have frame_id::to_string.
+
+	Change-Id: Iad8f93db2d13984dd5aa5867db940ed1169dbb67
+
+2021-07-13  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: make thread_info::suspend private, add getters / setters
+	A following patch will want to take some action when a pending wait
+	status is set on or removed from a thread.  Add a getter and a setter on
+	thread_info for the pending waitstatus, so that we can add some code in
+	the setter later.
+
+	The thing is, the pending wait status field is in the
+	thread_suspend_state, along with other fields that we need to backup
+	before and restore after the thread does an inferior function call.
+	Therefore, make the thread_suspend_state member private
+	(thread_info::suspend becomes thread_info::m_suspend), and add getters /
+	setters for all of its fields:
+
+	 - pending wait status
+	 - stop signal
+	 - stop reason
+	 - stop pc
+
+	For the pending wait status, add the additional has_pending_waitstatus
+	and clear_pending_waitstatus methods.
+
+	I think this makes the thread_info interface a bit nicer, because we
+	now access the fields as:
+
+	  thread->stop_pc ()
+
+	rather than
+
+	  thread->suspend.stop_pc
+
+	The stop_pc field being in the `suspend` structure is an implementation
+	detail of thread_info that callers don't need to be aware of.
+
+	For the backup / restore of the thread_suspend_state structure, add
+	save_suspend_to and restore_suspend_from methods.  You might wonder why
+	`save_suspend_to`, as opposed to a simple getter like
+
+	  thread_suspend_state &suspend ();
+
+	I want to make it clear that this is to be used only for backing up and
+	restoring the suspend state, _not_ to access fields like:
+
+	  thread->suspend ()->stop_pc
+
+	Adding some getters / setters allows adding some assertions.  I find
+	that this helps understand how things are supposed to work.  Add:
+
+	 - When getting the pending status (pending_waitstatus method), ensure
+	   that there is a pending status.
+	 - When setting a pending status (set_pending_waitstatus method), ensure
+	   there is no pending status.
+
+	There is one case I found where this wasn't true - in
+	remote_target::process_initial_stop_replies - which needed adjustments
+	to respect that contract.  I think it's because
+	process_initial_stop_replies is kind of (ab)using the
+	thread_info::suspend::waitstatus to store some statuses temporarily, for
+	its internal use (statuses it doesn't intent on leaving pending).
+
+	process_initial_stop_replies pulls out stop replies received during the
+	initial connection using target_wait.  It always stores the received
+	event in `evthread->suspend.waitstatus`.  But it only sets
+	waitstatus_pending_p, if it deems the event interesting enough to leave
+	pending, to be reported to the core:
+
+	      if (ws.kind != TARGET_WAITKIND_STOPPED
+		  || ws.value.sig != GDB_SIGNAL_0)
+		evthread->suspend.waitstatus_pending_p = 1;
+
+	It later uses this flag a bit below, to choose which thread to make the
+	"selected" one:
+
+	      if (selected == NULL
+		  && thread->suspend.waitstatus_pending_p)
+		selected = thread;
+
+	And ultimately that's used if the user-visible mode is all-stop, so that
+	we print the stop for that interesting thread:
+
+	  /* In all-stop, we only print the status of one thread, and leave
+	     others with their status pending.  */
+	  if (!non_stop)
+	    {
+	      thread_info *thread = selected;
+	      if (thread == NULL)
+		thread = lowest_stopped;
+	      if (thread == NULL)
+		thread = first;
+
+	      print_one_stopped_thread (thread);
+	    }
+
+	But in any case (all-stop or non-stop), print_one_stopped_thread needs
+	to access the waitstatus value of these threads that don't have a
+	pending waitstatus (those that had TARGET_WAITKIND_STOPPED +
+	GDB_SIGNAL_0).  This doesn't work with the assertions I've
+	put.
+
+	So, change the code to only set the thread's wait status if it is an
+	interesting one that we are going to leave pending.  If the thread
+	stopped due to a non-interesting event (TARGET_WAITKIND_STOPPED +
+	GDB_SIGNAL_0), don't store it.  Adjust print_one_stopped_thread to
+	understand that if a thread has no pending waitstatus, it's because it
+	stopped with TARGET_WAITKIND_STOPPED + GDB_SIGNAL_0.
+
+	The call to set_last_target_status also uses the pending waitstatus.
+	However, given that the pending waitstatus for the thread may have been
+	cleared in print_one_stopped_thread (and that there might not even be a
+	pending waitstatus in the first place, as explained above), it is no
+	longer possible to do it at this point.  To fix that, move the call to
+	set_last_target_status in print_one_stopped_thread.  I think this will
+	preserve the existing behavior, because set_last_target_status is
+	currently using the current thread's wait status.  And the current
+	thread is the last one for which print_one_stopped_thread is called.  So
+	by calling set_last_target_status in print_one_stopped_thread, we'll get
+	the same result.  set_last_target_status will possibly be called
+	multiple times, but only the last call will matter.  It just means
+	possibly more calls to set_last_target_status, but those are cheap.
+
+	Change-Id: Iedab9653238eaf8231abcf0baa20145acc8b77a7
+
+2021-07-13  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: add setter / getter for thread_info resumed state
+	A following patch will want to do things when a thread's resumed state
+	changes.  Make the `resumed` field private (renamed to `m_resumed`) and
+	add a getter and a setter for it.  The following patch in question will
+	therefore be able to add some code to the setter.
+
+	Change-Id: I360c48cc55a036503174313261ce4e757d795319
+
+2021-07-13  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: use intrusive list for step-over chain
+	The threads that need a step-over are currently linked using an
+	hand-written intrusive doubly-linked list, so that seems a very good
+	candidate for intrusive_list, convert it.
+
+	For this, we have a use case of appending a list to another one (in
+	start_step_over).  Based on the std::list and Boost APIs, add a splice
+	method.  However, only support splicing the other list at the end of the
+	`this` list, since that's all we need.
+
+	Add explicit default assignment operators to
+	reference_to_pointer_iterator, which are otherwise implicitly deleted.
+	This is needed because to define thread_step_over_list_safe_iterator, we
+	wrap reference_to_pointer_iterator inside a basic_safe_iterator, and
+	basic_safe_iterator needs to be able to copy-assign the wrapped
+	iterator.  The move-assignment operator is therefore not needed, only
+	the copy-assignment operator is.  But for completeness, add both.
+
+	Change-Id: I31b2ff67c7b78251314646b31887ef1dfebe510c
+
+2021-07-13  Pedro Alves  <pedro@palves.net>
+
+	gdb: make inferior_list use intrusive_list
+	Change inferior_list, the global list of inferiors, to use
+	intrusive_list.  I think most other changes are somewhat obvious
+	fallouts from this change.
+
+	There is a small change in behavior in scoped_mock_context.  Before this
+	patch, constructing a scoped_mock_context would replace the whole
+	inferior list with only the new mock inferior.  Tests using two
+	scoped_mock_contexts therefore needed to manually link the two inferiors
+	together, as the second scoped_mock_context would bump the first mock
+	inferior from the thread list.  With this patch, a scoped_mock_context
+	adds its mock inferior to the inferior list on construction, and removes
+	it on destruction.  This means that tests run with mock inferiors in the
+	inferior list in addition to any pre-existing inferiors (there is always
+	at least one).  There is no possible pid clash problem, since each
+	scoped mock inferior uses its own process target, and pids are per
+	process target.
+
+	Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
+	Change-Id: I7eb6a8f867d4dcf8b8cd2dcffd118f7270756018
+
+2021-07-13  Pedro Alves  <pedro@palves.net>
+
+	gdb: introduce intrusive_list, make thread_info use it
+	GDB currently has several objects that are put in a singly linked list,
+	by having the object's type have a "next" pointer directly.  For
+	example, struct thread_info and struct inferior.  Because these are
+	simply-linked lists, and we don't keep track of a "tail" pointer, when
+	we want to append a new element on the list, we need to walk the whole
+	list to find the current tail.  It would be nice to get rid of that
+	walk.  Removing elements from such lists also requires a walk, to find
+	the "previous" position relative to the element being removed.  To
+	eliminate the need for that walk, we could make those lists
+	doubly-linked, by adding a "prev" pointer alongside "next".  It would be
+	nice to avoid the boilerplate associated with maintaining such a list
+	manually, though.  That is what the new intrusive_list type addresses.
+
+	With an intrusive list, it's also possible to move items out of the
+	list without destroying them, which is interesting in our case for
+	example for threads, when we exit them, but can't destroy them
+	immediately.  We currently keep exited threads on the thread list, but
+	we could change that which would simplify some things.
+
+	Note that with std::list, element removal is O(N).  I.e., with
+	std::list, we need to walk the list to find the iterator pointing to
+	the position to remove.  However, we could store a list iterator
+	inside the object as soon as we put the object in the list, to address
+	it, because std::list iterators are not invalidated when other
+	elements are added/removed.  However, if you need to put the same
+	object in more than one list, then std::list<object> doesn't work.
+	You need to instead use std::list<object *>, which is less efficient
+	for requiring extra memory allocations.  For an example of an object
+	in multiple lists, see the step_over_next/step_over_prev fields in
+	thread_info:
+
+	  /* Step-over chain.  A thread is in the step-over queue if these are
+	     non-NULL.  If only a single thread is in the chain, then these
+	     fields point to self.  */
+	  struct thread_info *step_over_prev = NULL;
+	  struct thread_info *step_over_next = NULL;
+
+	The new intrusive_list type gives us the advantages of an intrusive
+	linked list, while avoiding the boilerplate associated with manually
+	maintaining it.
+
+	intrusive_list's API follows the standard container interface, and thus
+	std::list's interface.  It is based the API of Boost's intrusive list,
+	here:
+
+	 https://www.boost.org/doc/libs/1_73_0/doc/html/boost/intrusive/list.html
+
+	Our implementation is relatively simple, while Boost's is complicated
+	and intertwined due to a lot of customization options, which our version
+	doesn't have.
+
+	The easiest way to use an intrusive_list is to make the list's element
+	type inherit from intrusive_node.  This adds a prev/next pointers to
+	the element type.  However, to support putting the same object in more
+	than one list, intrusive_list supports putting the "node" info as a
+	field member, so you can have more than one such nodes, one per list.
+
+	As a first guinea pig, this patch makes the per-inferior thread list use
+	intrusive_list using the base class method.
+
+	Unlike Boost's implementation, ours is not a circular list.  An earlier
+	version of the patch was circular: the intrusive_list type included an
+	intrusive_list_node "head".  In this design, a node contained pointers
+	to the previous and next nodes, not the previous and next elements.
+	This wasn't great for when debugging GDB with GDB, as it was difficult
+	to get from a pointer to the node to a pointer to the element.  With the
+	design proposed in this patch, nodes contain pointers to the previous
+	and next elements, making it easy to traverse the list by hand and
+	inspect each element.
+
+	The intrusive_list object contains pointers to the first and last
+	elements of the list.  They are nullptr if the list is empty.
+	Each element's node contains a pointer to the previous and next
+	elements.  The first element's previous pointer is nullptr and the last
+	element's next pointer is nullptr.  Therefore, if there's a single
+	element in the list, both its previous and next pointers are nullptr.
+	To differentiate such an element from an element that is not linked into
+	a list, the previous and next pointers contain a special value (-1) when
+	the node is not linked.  This is necessary to be able to reliably tell
+	if a given node is currently linked or not.
+
+	A begin() iterator points to the first item in the list.  An end()
+	iterator contains nullptr.  This makes iteration until end naturally
+	work, as advancing past the last element will make the iterator contain
+	nullptr, making it equal to the end iterator.  If the list is empty,
+	a begin() iterator will contain nullptr from the start, and therefore be
+	immediately equal to the end.
+
+	Iterating on an intrusive_list yields references to objects (e.g.
+	`thread_info&`).  The rest of GDB currently expects iterators and ranges
+	to yield pointers (e.g. `thread_info*`).  To bridge the gap, add the
+	reference_to_pointer_iterator type.  It is used to define
+	inf_threads_iterator.
+
+	Add a Python pretty-printer, to help inspecting intrusive lists when
+	debugging GDB with GDB.  Here's an example of the output:
+
+	    (top-gdb) p current_inferior_.m_obj.thread_list
+	    $1 = intrusive list of thread_info = {0x61700002c000, 0x617000069080, 0x617000069400, 0x61700006d680, 0x61700006eb80}
+
+	It's not possible with current master, but with this patch [1] that I
+	hope will be merged eventually, it's possible to index the list and
+	access the pretty-printed value's children:
+
+	    (top-gdb) p current_inferior_.m_obj.thread_list[1]
+	    $2 = (thread_info *) 0x617000069080
+	    (top-gdb) p current_inferior_.m_obj.thread_list[1].ptid
+	    $3 = {
+	      m_pid = 406499,
+	      m_lwp = 406503,
+	      m_tid = 0
+	    }
+
+	Even though iterating the list in C++ yields references, the Python
+	pretty-printer yields pointers.  The reason for this is that the output
+	of printing the thread list above would be unreadable, IMO, if each
+	thread_info object was printed in-line, since they contain so much
+	information.  I think it's more useful to print pointers, and let the
+	user drill down as needed.
+
+	[1] https://sourceware.org/pipermail/gdb-patches/2021-April/178050.html
+
+	Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
+	Change-Id: I3412a14dc77f25876d742dab8f44e0ba7c7586c0
+
+2021-07-13  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-12  Tucker  <tuckkern@sourceware@gmail.com>
+
+	Add the SEC_ELF_OCTETS flag to debug sections created by the assembler.
+		PR 28054
+	gas	* config/obj-elf.c (obj_elf_change_section): Set the
+		SEF_ELF_OCTETS flag on debug sections.
+
+2021-07-12  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.btrace/tsx.exp on system with tsx disabled in microcode
+	Recently I started to see this fail with trunk:
+	...
+	(gdb) record instruction-history^M
+	1          0x00000000004004ab <main+4>: call   0x4004b7 <test>^M
+	2          0x00000000004004c6 <test+15>:        mov    $0x1,%eax^M
+	3          0x00000000004004cb <test+20>:        ret    ^M
+	(gdb) FAIL: gdb.btrace/tsx.exp: speculation indication
+	...
+
+	This is due to an intel microcode update (1) that disables Intel TSX by default.
+
+	Fix this by updating the pattern.
+
+	Tested on x86_64-linux, with both gcc 7.5.0 and clang 12.0.1.
+
+	[1] https://www.intel.com/content/www/us/en/support/articles/000059422/processors.html
+
+	gdb/testsuite/ChangeLog:
+
+	2021-07-12  Tom de Vries  <tdevries@suse.de>
+
+		PR testsuite/28057
+		* gdb.btrace/tsx.exp: Add pattern for system with tsx disabled in
+		microcode.
+
+2021-07-12  Nick Clifton  <nickc@redhat.com>
+
+	Updated French translation for the binutils sub-directory
+
+	Fix a translation problem for the text generated by readelf at the start of a dump of a dynamic section.
+		PR 28072
+	binutils * readelf.c (process_dynamic_section): Use ngettext to help with translation of header text.
+
+2021-07-12  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.mi/mi-info-sources.exp for extra debug info
+	When running test-case gdb.mi/mi-info-sources.exp, I run into:
+	...
+	Running src/gdb/testsuite/gdb.mi/mi-info-sources.exp ...
+	ERROR: internal buffer is full.
+	...
+	due to extra debug info from the shared libraries.
+
+	Fix this by using "nosharedlibrary".
+
+	Then I run into these FAILs:
+	...
+	FAIL: gdb.mi/mi-info-sources.exp: debug_read=false: \
+	  -file-list-exec-source-files (unexpected output)
+	FAIL: gdb.mi/mi-info-sources.exp: debug_read=true: \
+	  -file-list-exec-source-files (unexpected output)
+	FAIL: gdb.mi/mi-info-sources.exp: debug_read=true: \
+	  -file-list-exec-source-files --group-by-objfile, look for \
+	  mi-info-sources.c (unexpected output)
+	FAIL: gdb.mi/mi-info-sources.exp: debug_read=true: \
+	  -file-list-exec-source-files --group-by-objfile, look for \
+	  mi-info-sources-base.c (unexpected output)
+	...
+	due to openSUSE executables which have debug info for objects from sources
+	like sysdeps/x86_64/crtn.S.
+
+	Fix these by updating the patterns, and adding "maint expand-symtabs" to
+	reliably get fully-read objfiles.
+
+	Then I run into FAILs when using the readnow target board.  Fix these by
+	skipping the relevant tests.
+
+	Then I run into FAILs when using the cc-with-gnu-debuglink board.  Fix these
+	by updating the patterns.
+
+	Tested on x86_64-linux, with native, check-read1, readnow, cc-with-gdb-index,
+	cc-with-debug-names, cc-with-gnu-debuglink, cc-with-dwz, cc-with-dwz-m.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-07-05  Tom de Vries  <tdevries@suse.de>
+
+		* lib/mi-support.exp (mi_readnow): New proc.
+		* gdb.mi/mi-info-sources.exp: Use nosharedlibrary.  Update patterns.
+		Skip tests for readnow.  Use "maint expand-symtabs".
+
+2021-07-12  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>
+
+	testsuite: fix whitespace problems in gdb.mi/mi-break.exp
+	Replace leading 8-spaces with tab and remove trailing space in
+	gdb.mi/mi-break.exp.
+
+2021-07-12  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-11  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-10  Alan Modra  <amodra@gmail.com>
+
+	Tidy commit 49910fd88dcd
+	Pointer range checking is UB if the values compared are outside the
+	underlying array elements (plus one).
+
+		* dwarf2.c (read_address): Remove accidental commit.
+		(read_ranges): Compare offset rather than pointers.
+
+2021-07-10  Alan Modra  <amodra@gmail.com>
+
+	PR28069, assertion fail in dwarf.c:display_discr_list
+	We shouldn't be asserting on anything to do with leb128 values, or
+	reporting file and line numbers when something unexpected happens.
+	leb128 data is of indeterminate length, perfect for fuzzer mayhem.
+	It would only make sense to assert or report dwarf.c/readelf.c source
+	lines if the code had already sized and sanity checked the leb128
+	values.
+
+	After removing the assertions, the testcase then gave:
+
+	    <37>   DW_AT_discr_list  : 5 byte block: 0 0 0 0 0 	(label 0, label 0, label 0, label 0, <corrupt>
+	readelf: Warning: corrupt discr_list - unrecognized discriminant byte 0x5
+
+	    <3d>   DW_AT_encoding    : 0	(void)
+	    <3e>   DW_AT_identifier_case: 0	(case_sensitive)
+	    <3f>   DW_AT_virtuality  : 0	(none)
+	    <40>   DW_AT_decimal_sign: 5	(trailing separate)
+
+	So the DW_AT_discr_list was showing more data than just the 5 byte
+	block.  That happened due to "end" pointing a long way past the end of
+	block, and uvalue decrementing past zero on one of the leb128 bytes.
+
+		PR 28069
+		* dwarf.c (display_discr_list): Remove assertions.  Delete "end"
+		parameter, use initial "data" pointer as the end.  Formatting.
+		Don't count down bytes as they are read.
+		(read_and_display_attr_value): Adjust display_discr_list call.
+		(read_and_print_leb128): Don't pass __FILE__ and __LINE__ to
+		report_leb_status.
+		* dwarf.h (report_leb_status): Don't report file and line
+		numbers.  Delete file and lnum parameters,
+		(READ_ULEB, READ_SLEB): Adjust.
+
+2021-07-10  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-09  H.J. Lu  <hjl.tools@gmail.com>
+
+	ld/NEWS: Clarify -z [no]indirect-extern-access
+	-z [no]indirect-extern-access are only for x86 ELF linker.
+
+2021-07-09  H.J. Lu  <hjl.tools@gmail.com>
+
+	elf: Limits 2 GNU_PROPERTY_1_NEEDED tests to Linux/x86
+	Run property-1_needed-1b.d and property-1_needed-1c.d, which pass
+	-z [no]indirect-extern-access to linker, only run for Linux/x86 targets.
+
+		* testsuite/ld-elf/property-1_needed-1b.d: Only run for
+		Linux/x86 targets.
+		* testsuite/ld-elf/property-1_needed-1c.d: Likewise.
+
+2021-07-09  H.J. Lu  <hjl.tools@gmail.com>
+
+	elf: Add GNU_PROPERTY_1_NEEDED check
+	If GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS is set on any input
+	relocatable files:
+
+	1. Don't generate copy relocations.
+	2. Turn off extern_protected_data since it implies
+	GNU_PROPERTY_NO_COPY_ON_PROTECTED.
+	3. Treate reference to protected symbols with indirect external access
+	as local.
+	4. Set GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS on output.
+	5. When generating executable, clear this bit when there are non-GOT or
+	non-PLT relocations in input relocatable files without the bit set.
+	6. Add -z [no]indirect-extern-access to control indirect external access.
+
+	bfd/
+
+		* elf-bfd (elf_obj_tdata): Add has_indirect_extern_access.
+		(elf_has_indirect_extern_access): New.
+		* elf-properties.c (_bfd_elf_parse_gnu_properties): Set
+		elf_has_indirect_extern_access and elf_has_no_copy_on_protected
+		when seeing GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS.
+		(elf_write_gnu_propertie): Add an argument to pass link_info.
+		Set needed_1_p for GNU_PROPERTY_1_NEEDED in memory.
+		(_bfd_elf_link_setup_gnu_properties): Handle
+		GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS for
+		-z indirect-extern-access.  Set nocopyreloc to true and
+		extern_protected_data to false for indirect external access.
+		(_bfd_elf_convert_gnu_properties): Updated.
+		* elf32-i386.c (elf_i386_check_relocs): Set
+		non_got_ref_without_indirect_extern_access on legacy non-GOT or
+		non-PLT references.
+		* elf64-x86-64.c (elf_x86_64_check_relocs): Likewise.
+		* elflink.c (_bfd_elf_symbol_refs_local_p): Return true for
+		STV_PROTECTED symbols with indirect external access.
+		* elfxx-x86.c (_bfd_x86_elf_adjust_dynamic_symbol): Clear
+		indirect_extern_access for legacy non-GOT/non-PLT references.
+		* elfxx-x86.h (elf_x86_link_hash_entry): Add
+		non_got_ref_without_indirect_extern_access.
+
+	include/
+
+		* bfdlink.h (bfd_link_info): Add indirect_extern_access and
+		needed_1_p.  Change nocopyreloc to int.
+
+	ld/
+
+		* NEWS: Mention -z [no]indirect-extern-access
+		* ld.texi: Document -z [no]indirect-extern-access
+		* ldmain.c (main): Initialize link_info.indirect_extern_access
+		to -1.
+		* emulparams/extern_protected_data.sh: Support
+		-z [no]indirect-extern-access.
+		* testsuite/ld-elf/indirect-extern-access-1.rd: New file
+		* testsuite/ld-elf/indirect-extern-access-1a.c: Likewise.
+		* testsuite/ld-elf/indirect-extern-access-1b.c: Likewise.
+		* testsuite/ld-elf/indirect-extern-access-2.rd: Likewise.
+		* testsuite/ld-elf/indirect-extern-access-2a.c: Likewise.
+		* testsuite/ld-elf/indirect-extern-access-2b.c: Likewise.
+		* testsuite/ld-elf/indirect-extern-access-3.rd: Likewise.
+		* testsuite/ld-elf/indirect-extern-access.S: Likewise.
+		* testsuite/ld-elf/property-1_needed-1b.d: Likewise.
+		* testsuite/ld-elf/property-1_needed-1c.d: Likewise.
+		* testsuite/ld-x86-64/indirect-extern-access.rd: Likewise.
+		* testsuite/ld-x86-64/protected-data-1.h: Likewise.
+		* testsuite/ld-x86-64/protected-data-1a.c: Likewise.
+		* testsuite/ld-x86-64/protected-data-1b.c: Likewise.
+		* testsuite/ld-x86-64/protected-data-2a.S: Likewise.
+		* testsuite/ld-x86-64/protected-data-2b.S: Likewise.
+		* testsuite/ld-x86-64/protected-func-2a.S: Likewise.
+		* testsuite/ld-x86-64/protected-func-2b.S: Likewise.
+		* testsuite/ld-x86-64/protected-func-2c.c: Likewise.
+		* testsuite/ld-elf/linux-x86.exp: Run test with
+		GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS.
+		* testsuite/ld-x86-64/x86-64.exp: Run tests for protected
+		function and data with indirect external access.
+
+2021-07-09  H.J. Lu  <hjl.tools@gmail.com>
+
+	elf: Add GNU_PROPERTY_1_NEEDED
+	Add GNU_PROPERTY_1_NEEDED:
+
+	 #define GNU_PROPERTY_1_NEEDED      GNU_PROPERTY_UINT32_OR_LO
+
+	to indicate the needed properties by the object file.
+
+	Add GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS:
+
+	 #define GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS  (1U << 0)
+
+	to indicate that the object file requires canonical function pointers and
+	cannot be used with copy relocation.
+
+	binutils/
+
+		* readelf.c (decode_1_needed): New.
+		(print_gnu_property_note): Handle GNU_PROPERTY_1_NEEDED.
+
+	include/
+
+		* elf/common.h (GNU_PROPERTY_1_NEEDED): New.
+		(GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS): Likewise.
+
+	ld/
+
+		* testsuite/ld-elf/property-1_needed-1a.d: New file.
+		* testsuite/ld-elf/property-1_needed-1.s: Likewise.
+
+2021-07-09  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-09  Lancelot SIX  <lsix@lancelotsix.com>
+
+	Remove unused parameter in maybe_software_singlestep
+	While working around, I noticed that the last parameter of
+	maybe_software_singlestep is never used.  This path removes
+	it.
+
+	Built on x86_64-linux-gnu and riscv64-linux-gnu.
+
+	gdb/ChangeLog:
+
+		* infrun.c (maybe_software_singlestep): Remove unused PC
+		parameter.
+		(resume_1): Update calls to maybe_software_singlestep.
+
+2021-07-08  H.J. Lu  <hjl.tools@gmail.com>
+
+	x86-64: Disallow PC reloc against weak undefined symbols in PIE
+	Disallow PC relocations against weak undefined symbols in PIE since they
+	can lead to non-zero address at run-time.
+
+	bfd/
+
+		PR ld/21782
+		* elf64-x86-64.c (elf_x86_64_relocate_section): Disallow PC
+		relocations against weak undefined symbols in PIE.
+
+	ld/
+
+		PR ld/21782
+		* testsuite/ld-x86-64/pie3.d: Expect linker error.
+
+2021-07-08  H.J. Lu  <hjl.tools@gmail.com>
+
+	ld: Limit cache size and add --max-cache-size=SIZE
+	When link_info.keep_memory is true, linker caches the relocation
+	information and symbol tables of input files in memory.  When there
+	are many input files with many relocations, we may run out of memory.
+	Add --max-cache-size=SIZE to set the maximum cache size.
+
+	bfd/
+
+		PR ld/18028
+		* bfd.c (bfd): Add alloc_size.
+		* elf-bfd.h (_bfd_elf_link_info_read_relocs): New.
+		* elf32-i386.c (elf_i386_check_relocs): Use _bfd_link_keep_memory.
+		Update cache_size.
+		* elf64-x86-64.c (elf_x86_64_check_relocs): Likewise.
+		* elflink.c (_bfd_elf_link_read_relocs): Renamed to ...
+		(_bfd_elf_link_info_read_relocs): This.  Update cache_size.
+		(_bfd_elf_link_read_relocs): New.
+		(_bfd_elf_link_check_relocs): Call _bfd_elf_link_info_read_relocs
+		instead of _bfd_elf_link_read_relocs.
+		(elf_link_add_object_symbols): Likewise.
+		(elf_link_input_bfd): Likewise.
+		(init_reloc_cookie_rels): Likewise.
+		(init_reloc_cookie): Update cache_size.  Call
+		_bfd_elf_link_info_read_relocs instead of
+		_bfd_elf_link_read_relocs.
+		(link_info_ok): New.
+		(elf_gc_smash_unused_vtentry_relocs): Updated.  Call
+		_bfd_elf_link_info_read_relocs instead of
+		_bfd_elf_link_read_relocs.
+		(bfd_elf_gc_sections): Use link_info_ok.  Pass &link_info_ok
+		to elf_gc_smash_unused_vtentry_relocs.
+		* libbfd-in.h (_bfd_link_keep_memory): New.
+		* linker.c (_bfd_link_keep_memory): New.
+		* opncls.c (bfd_alloc): Update alloc_size.
+		* bfd-in2.h: Regenerated.
+		* libbfd.h: Likewise.
+
+	include/
+
+		PR ld/18028
+		* bfdlink.h (bfd_link_info): Add cache_size and max_cache_size.
+
+	ld/
+
+		PR ld/18028
+		* NEWS: Mention --max-cache-size=SIZE.
+		* ld.texi: Document --max-cache-size=SIZE.
+		* ldlex.h (option_values): Add OPTION_MAX_CACHE_SIZE.
+		* ldmain.c: (main): Set link_info.max_cache_size to -1.
+		* lexsup.c (ld_options): Add --max-cache-size=SIZE.
+		(parse_args): Support OPTION_MAX_CACHE_SIZE.
+		* testsuite/ld-bootstrap/bootstrap.exp: Add test for
+		--max-cache-size=-1.
+
+2021-07-08  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: don't set Linux-specific displaced stepping methods in s390_gdbarch_init
+	According to bug 28056, running an s390x binary gives:
+
+	    (gdb) run
+	    Starting program: /usr/bin/ls
+	    /home/ubuntu/tmp/gdb-11.0.90.20210705/gdb/linux-tdep.c:2550: internal-error: displaced_step_prepare_status linux_displaced_step_prepare(gdbarch*, thread_info*, CORE_ADDR&): Assertion `gdbarch_data->num_disp_step_buffers > 0' failed.
+
+	This is because the s390 architecture registers some Linux-specific
+	displaced stepping callbacks in the OS-agnostic s390_gdbarch_init:
+
+	    set_gdbarch_displaced_step_prepare (gdbarch, linux_displaced_step_prepare);
+	    set_gdbarch_displaced_step_finish (gdbarch, linux_displaced_step_finish);
+	    set_gdbarch_displaced_step_restore_all_in_ptid
+	      (gdbarch, linux_displaced_step_restore_all_in_ptid);
+
+	But then the Linux-specific s390_linux_init_abi_any passes
+	num_disp_step_buffers=0 to linux_init_abi:
+
+	    linux_init_abi (info, gdbarch, 0);
+
+	The problem happens when linux_displaced_step_prepare is called for the
+	first time.  It tries to allocate the displaced stepping buffers, but
+	sees that the number of displaced stepping buffers for that architecture
+	is 0, which is unexpected / invalid.
+
+	s390_gdbarch_init should not register the linux_* callbacks, that is
+	expected to be done by linux_init_abi.  If debugging a bare-metal s390
+	program, or an s390 program on another OS GDB doesn't know about, we
+	wouldn't want to use them.  We would either register no callbacks, if
+	displaced stepping isn't supported, or register a different set of
+	callbacks if we wanted to support displaced stepping in those cases.
+
+	The commit that refactored the displaced stepping machinery and
+	introduced these set_gdbarch_displaced_step_* calls is 187b041e2514
+	("gdb: move displaced stepping logic to gdbarch, allow starting
+	concurrent displaced steps").  However, even before that,
+	s390_gdbarch_init did:
+
+	  set_gdbarch_displaced_step_location (gdbarch, linux_displaced_step_location);
+
+	... which already seemed wrong.  The Linux-specific callback was used
+	even for non-Linux system.  Maybe that was on purpose, because it would
+	also happen to work in some other non-Linux case, or maybe it was simply
+	a mistake.  I'll assume that this was a small mistake when
+	s390-tdep.{h,c} where factored out of s390-linux-tdep.c, in d6e589456475
+	("s390: Split up s390-linux-tdep.c into two files").
+
+	Fix this by removing the setting of these displaced step callbacks from
+	s390_gdbarch_init.  Instead, pass num_disp_step_buffers=1 to
+	linux_init_abi, in s390_linux_init_abi_any.  Doing so will cause
+	linux_init_abi to register these same callbacks.  It will also mean that
+	when debugging a bare-metal s390 executable or an executable on another
+	OS that GDB doesn't know about, gdbarch_displaced_step_prepare won't be
+	set, so displaced stepping won't be used.
+
+	This patch will need to be merged in the gdb-11-branch, since this is a
+	GDB 11 regression, so here's the ChangeLog entry:
+
+	gdb/ChangeLog:
+
+		* s390-linux-tdep.c (s390_linux_init_abi_any): Pass 1 (number
+		of displaced stepping buffers to linux_init_abi.
+		* s390-tdep.c (s390_gdbarch_init): Don't set the Linux-specific
+		displaced-stepping gdbarch callbacks.
+
+	Change-Id: Ieab2f8990c78fde845ce7378d6fd4ee2833800d5
+	Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28056
+
+2021-07-08  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/Makefile.in: remove testsuite from SUBDIRS
+	When distclean-ing a configured / built gdb directory, like so:
+
+	    $ ./configure && make all-gdb && make distclean
+
+	The distclean operation fails with:
+
+	    Missing testsuite/Makefile
+
+	If we look at the SUBDIRS variable in the generated gdb/Makefile,
+	testsuite is there twice:
+
+	    SUBDIRS = doc  testsuite data-directory testsuite
+
+	So we try distclean-ing the testsuite directory twice.  The second time,
+	gdb/testsuite/Makefile doesn't exist, so it fails.
+
+	The first "testsuite" comes from the @subdirs@ replacement, because of
+	the `AC_CONFIG_SUBDIRS` macro in gdb/configure.ac.  The second one is
+	hard-coded in gdb/Makefile.in:
+
+	    SUBDIRS = doc @subdirs@ data-directory testsuite
+
+	The hard-coded was added by:
+
+	    bdbbcd577460 ("Always build 'all' in gdb/testsuite")
+
+	which came after `testsuite` was removed from @subdirs@ by:
+
+	    f99d1d37496f ("Remove gdb/testsuite/configure")
+
+	My commit a100a94530eb ("gdb/testsuite: restore configure script")
+	should have removed the hard-coded `testsuite`, since it added it back
+	as a "subdir", but I missed it because I only looked f99d1d37496f to
+	write my patch.
+
+	Fix this by removing the hard-coded one.
+
+	This patch should be pushed to both master and gdb-11-branch, hence the
+	ChangeLog entry:
+
+	gdb/ChangeLog:
+
+		* Makefile.in (SUBDIRS): Remove testsuite.
+
+	Change-Id: I63e5590b1a08673c646510b3ecc74600eae9f92d
+
+2021-07-08  Nick Clifton  <nickc@redhat.com>
+
+	Updated Portuguese translation for the BFD sub-directory
+
+2021-07-08  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix gdb.guile/scm-breakpoint.exp with guile 3.0
+	When running test-case gdb.guile/scm-breakpoint.exp on openSUSE Tumbleweed
+	with guile 3.0, I run into:
+	...
+	(gdb) guile (define cp (make-breakpoint "syscall" #:type BP_CATCHPOINT))^M
+	ERROR: In procedure make-breakpoint:^M
+	In procedure gdbscm_make_breakpoint: unsupported breakpoint type in \
+	  position 3: "BP_CATCHPOINT"^M
+	Error while executing Scheme code.^M
+	(gdb) FAIL: gdb.guile/scm-breakpoint.exp: test_catchpoints: \
+	  create a catchpoint via the api
+	...
+
+	The same test passes on openSUSE Leap 15.2 with guile 2.0, where the second
+	line of the error message starts with the same prefix as the first:
+	...
+	ERROR: In procedure gdbscm_make_breakpoint: unsupported breakpoint type in \
+	  position 3: "BP_CATCHPOINT"^M
+	...
+
+	I observe the same difference in many other tests, f.i.:
+	...
+	(gdb) gu (print (value-add i '()))^M
+	ERROR: In procedure value-add:^M
+	In procedure gdbscm_value_add: Wrong type argument in position 2: ()^M
+	Error while executing Scheme code.^M
+	(gdb) PASS: gdb.guile/scm-math.exp: catch error in guile type conversion
+	...
+	but it doesn't cause FAILs anywhere else.
+
+	Fix this by updating the regexp to make the "ERROR: " prefix optional.
+
+	Tested on x86_64-linux, with both guile 2.0 and 3.0.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-07-07  Tom de Vries  <tdevries@suse.de>
+
+		* gdb.guile/scm-breakpoint.exp: Make additional "ERROR: " prefix in
+		exception printing optional.
+
+2021-07-08  Mike Frysinger  <vapier@gentoo.org>
+
+	sim: erc32: use libsim.a for common objects
+	We're starting to move more objects to the common build that sis did
+	not need before, so linking them is causing problems (when common
+	objects end up needing symbols from non-common objects).  Switch it
+	to the libsim.a archive which will allow the link to pull out only
+	what it needs.
+
+2021-07-08  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-07  Nick Clifton  <nickc@redhat.com>
+
+	Remove an accidental change to elfcode.h included as part of commit 6e0dfbf420.
+		PR 27659
+		* elfcode.h (elf_swap_symbol_out): Revert accidental change that
+		removed an abort if the shndx pointer is NULL.
+
+2021-07-07  H.J. Lu  <hjl.tools@gmail.com>
+
+	ld: Check archive only for archive member
+	Since plugin_maybe_claim calls bfd_close on the original input BFD if it
+	isn't an archive member, pass NULL to bfd_plugin_close_file_descriptor
+	to indicate that the BFD isn't an archive member.
+
+	bfd/
+
+		PR ld/18028
+		* plugin.c (bfd_plugin_close_file_descriptor): Check archive
+		only of abfd != NULL.
+		(try_claim): Pass NULL to bfd_plugin_close_file_descriptor if
+		it isn't an archive member.
+
+	ld/
+
+		PR ld/18028
+		* plugin.c (plugin_input_file): Add comments for abfd and ibfd.
+		(plugin_object_p): Set input->ibfd to NULL if it isn't an
+		archive member.
+
+2021-07-07  Andreas Krebbel  <krebbel@linux.ibm.com>
+
+	Add changelog entries for last commit
+
+2021-07-07  Andreas Krebbel  <krebbel@linux.ibm.com>
+
+	IBM Z: Add another arch14 instruction
+	opcodes/
+
+		* opcodes/s390-opc.txt: Add qpaci.
+
+	gas/
+
+		* testsuite/gas/s390/zarch-arch14.d: Add qpaci.
+		* testsuite/gas/s390/zarch-arch14.s: Add qpaci.
+
+2021-07-07  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
+
+	Fix Solaris gprof build with --disable-nls
+	gprof fails to compile on Solaris 10 and 11.3 with --disable-nls:
+
+	In file included from /vol/src/gnu/binutils/hg/binutils-2.37-branch/git/gprof/gprof.h:33,
+	                 from /vol/src/gnu/binutils/hg/binutils-2.37-branch/git/gprof/basic_blocks.c:24:
+	/usr/include/libintl.h:45:14: error: expected identifier or '(' before 'const'
+	   45 | extern char *dcgettext(const char *, const char *, const int);
+	      |              ^~~~~~~~~
+	/usr/include/libintl.h:46:14: error: expected identifier or '(' before 'const'
+	   46 | extern char *dgettext(const char *, const char *);
+	      |              ^~~~~~~~
+	/usr/include/libintl.h:47:14: error: expected identifier or '(' before 'const'
+	   47 | extern char *gettext(const char *);
+	      |              ^~~~~~~
+	/vol/src/gnu/binutils/hg/binutils-2.37-branch/git/gprof/../bfd/sysdep.h:165:33:
+	error: expected identifier or '(' before 'do'
+	  165 | # define textdomain(Domainname) do {} while (0)
+	      |                                 ^~
+	/vol/src/gnu/binutils/hg/binutils-2.37-branch/git/gprof/../bfd/sysdep.h:165:39:
+	error: expected identifier or '(' before 'while'
+	  165 | # define textdomain(Domainname) do {} while (0)
+	      |                                       ^~~~~
+	/vol/src/gnu/binutils/hg/binutils-2.37-branch/git/gprof/../bfd/sysdep.h:166:46:
+	error: expected identifier or '(' before 'do'
+	  166 | # define bindtextdomain(Domainname, Dirname) do {} while (0)
+	      |                                              ^~
+	/vol/src/gnu/binutils/hg/binutils-2.37-branch/git/gprof/../bfd/sysdep.h:166:52:
+	error: expected identifier or '(' before 'while'
+	  166 | # define bindtextdomain(Domainname, Dirname) do {} while (0)
+	      |                                                    ^~~~~
+	/usr/include/libintl.h:55:14: error: expected identifier or '(' before 'unsigned'
+	   55 | extern char *dcngettext(const char *, const char *,
+	      |              ^~~~~~~~~~
+	/usr/include/libintl.h:57:14: error: expected identifier or '(' before 'unsigned'
+	   57 | extern char *dngettext(const char *, const char *,
+	      |              ^~~~~~~~~
+	/usr/include/libintl.h:59:14: error: expected identifier or '(' before 'unsigned'
+	   59 | extern char *ngettext(const char *, const char *, unsigned long int);
+	      |              ^~~~~~~~
+
+	This is a known issue already partially fixed in binutils/sysdep.h.  For
+	gprof, the same fix needs to be applied in bfd/sysdep.h, as the
+	following patch does.  Tested on i386-pc-solaris2.10 and
+	i386-pc-solaris2.11.
+
+	2021-07-06  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
+
+		bfd:
+		* sysdep.h [!ENABLE_NLS]: Prevent inclusion of <libintl.h> on
+		Solaris.
+
+2021-07-07  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
+
+	Check for strnlen declaration to fix Solaris 10 build
+	binutils currently fails to compile on Solaris 10:
+
+	/vol/src/gnu/binutils/hg/binutils-2.37-branch/git/bfd/opncls.c: In function 'bfd_get_debug_link_info_1':
+	/vol/src/gnu/binutils/hg/binutils-2.37-branch/git/bfd/opncls.c:1231:16: error: implicit declaration of function 'strnlen' [-Werror=implicit-function-declaration]
+	 1231 |	  crc_offset = strnlen (name, size) + 1;
+	      |		       ^~~~~~~
+	/vol/src/gnu/binutils/hg/binutils-2.37-branch/git/bfd/opncls.c:1231:16: error: incompatible implicit declaration of built-in function 'strnlen' [-Werror]
+	/vol/src/gnu/binutils/hg/binutils-2.37-branch/git/bfd/opncls.c: In function 'bfd_get_alt_debug_link_info':
+	/vol/src/gnu/binutils/hg/binutils-2.37-branch/git/bfd/opncls.c:1319:20: error: incompatible implicit declaration of built-in function 'strnlen' [-Werror]
+	 1319 |	  buildid_offset = strnlen (name, size) + 1;
+	      |			   ^~~~~~~
+
+	and in a couple of other places.  The platform lacks strnlen, and while
+	libiberty.h can provide a fallback declaration, the necessary configure
+	test isn't run.
+
+	Fixed with the following patch.  Tested on i386-pc-solaris2.10.
+
+	2021-07-06  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
+
+		bfd:
+		* configure.ac: Check for strnlen declaration.
+		* configure, config.in: Regenerate.
+
+		binutils:
+		* configure.ac: Check for strnlen declaration.
+		* configure, config.in: Regenerate.
+
+2021-07-07  Nick Clifton  <nickc@redhat.com>
+
+	Fix problems translating messages when a percentage sign appears at the end of a string.
+		PR 28051
+	gas	* config/tc-i386.c (offset_in_range): Reformat error messages in
+		order to fix problems when translating.
+		(md_assemble): Likewise.
+		* messages.c (as_internal_value_out_of_range): Likewise.
+		* read.c (emit_expr_with_reloc): Likewise.
+		* testsuite/gas/all/overflow.l Change expected output format.
+		* po/gas.pot: Regenerate.
+
+	bfd	* coff-rs6000.c (xcoff_reloc_type_tls): Reformat error messages in
+		order to fix problems when translating.
+		* cofflink.c (_bfd_coff_write_global_sym): Likewise.
+		* elfnn-aarch64.c (_bfd_aarch64_erratum_843419_branch_to_stub):
+		Likewise.
+		* po/bfd.pot: Regenerate.
+
+2021-07-07  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-06  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: introduce iterator_range, remove next_adapter
+	I was always a bit confused by next_adapter, because it kind of mixes
+	the element type and the iterator type.  In reality, it is not much more
+	than a class that wraps two iterators (begin and end).  However, it
+	assumes that:
+
+	 - you can construct the begin iterator by passing a pointer to the
+	   first element of the iterable
+	 - you can default-construct iterator to make the end iterator
+
+	I think that by generalizing it a little bit, we can re-use it at more
+	places.
+
+	Rename it to "iterator_range".  I think it describes a bit better: it's
+	a range made by wrapping a begin and end iterator.  Move it to its own
+	file, since it's not related to next_iterator anymore.
+
+	iterator_range has two constructors.  The variadic one, where arguments
+	are forwarded to construct the underlying begin iterator.  The end
+	iterator is constructed through default construction.  This is a
+	generalization of what we have today.
+
+	There is another constructor which receives already constructed begin
+	and end iterators, useful if the end iterator can't be obtained by
+	default-construction.  Or, if you wanted to make a range that does not
+	end at the end of the container, you could pass any iterator as the
+	"end".
+
+	This generalization allows removing some "range" classes, like
+	all_inferiors_range.  These classes existed only to pass some arguments
+	when constructing the begin iterator.  With iterator_range, those same
+	arguments are passed to the iterator_range constructed and then
+	forwarded to the constructed begin iterator.
+
+	There is a small functional difference in how iterator_range works
+	compared to next_adapter.  next_adapter stored the pointer it received
+	as argument and constructeur an iterator in the `begin` method.
+	iterator_range constructs the begin iterator and stores it as a member.
+	Its `begin` method returns a copy of that iterator.
+
+	With just iterator_range, uses of next_adapter<foo> would be replaced
+	with:
+
+	  using foo_iterator = next_iterator<foo>;
+	  using foo_range = iterator_range<foo_iterator>;
+
+	However, I added a `next_range` wrapper as a direct replacement for
+	next_adapter<foo>.  IMO, next_range is a slightly better name than
+	next_adapter.
+
+	The rest of the changes are applications of this new class.
+
+	gdbsupport/ChangeLog:
+
+		* next-iterator.h (class next_adapter): Remove.
+		* iterator-range.h: New.
+
+	gdb/ChangeLog:
+
+		* breakpoint.h (bp_locations_range): Remove.
+		(bp_location_range): New.
+		(struct breakpoint) <locations>: Adjust type.
+		(breakpoint_range): Use iterator_range.
+		(tracepoint_range): Use iterator_range.
+		* breakpoint.c (breakpoint::locations): Adjust return type.
+		* gdb_bfd.h (gdb_bfd_section_range): Use iterator_range.
+		* gdbthread.h (all_threads_safe): Pass argument to
+		all_threads_safe_range.
+		* inferior-iter.h (all_inferiors_range): Use iterator_range.
+		(all_inferiors_safe_range): Use iterator_range.
+		(all_non_exited_inferiors_range): Use iterator_range.
+		* inferior.h (all_inferiors, all_non_exited_inferiors): Pass
+		inferior_list as argument.
+		* objfiles.h (struct objfile) <compunits_range>: Remove.
+		<compunits>: Return compunit_symtab_range.
+		* progspace.h (unwrapping_objfile_iterator)
+		<unwrapping_objfile_iterator>: Take parameter by value.
+		(unwrapping_objfile_range): Use iterator_range.
+		(struct program_space) <objfiles_range>: Define with "using".
+		<objfiles>: Adjust.
+		<objfiles_safe_range>: Define with "using".
+		<objfiles_safe>: Adjust.
+		<solibs>: Return so_list_range, define here.
+		* progspace.c (program_space::solibs): Remove.
+		* psymtab.h (class psymtab_storage) <partial_symtab_iterator>:
+		New.
+		<partial_symtab_range>: Use iterator_range.
+		* solist.h (so_list_range): New.
+		* symtab.h (compunit_symtab_range):
+		New.
+		(symtab_range): New.
+		(compunit_filetabs): Change to a function.
+		* thread-iter.h (inf_threads_range,
+		inf_non_exited_threads_range, safe_inf_threads_range,
+		all_threads_safe_range): Use iterator_range.
+		* top.h (ui_range): New.
+		(all_uis): Use ui_range.
+
+	Change-Id: Ib7a9d2a3547f45f01aa1c6b24536ba159db9b854
+
+2021-07-06  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb/testsuite: restore configure script
+	Commit f99d1d37496f ("Remove gdb/testsuite/configure") removed
+	gdb/testsuite/configure, as anything gdb/testsuite/configure did could
+	be done by gdb/configure.
+
+	There is however one use case that popped up when this changed
+	propagated to downstream consumers, to run the testsuite on an already
+	built GDB.  In the workflow of ROCm-GDB at AMD, a GDB package is built
+	in a CI job.  This GDB package is then tested on different machines /
+	hardware configurations as part of other CI jobs.  To achieve this,
+	those CI jobs only configure the testsuite directory and run "make
+	check" with an appropriate board file.
+
+	In light of this use case, the way I see it is that gdb/testsuite could
+	be considered its own project.  It could be stored in a completely
+	different repo if we want to, it just happens to be stored inside gdb/.
+
+	Since the only downside of having gdb/testsuite/configure is that it
+	takes a few more seconds to run, but on the other hand it's quite useful
+	for some people, I propose re-adding it.
+
+	In a sense, this is revert of f99d1d37496f, but it's not a direct
+	git-revert, as some things have changed since.
+
+	gdb/ChangeLog:
+
+		* configure.ac: Remove things that were moved from
+		testsuite/configure.ac.
+		* configure: Re-generate.
+
+	gdb/testsuite/ChangeLog:
+
+		* configure.ac: Restore.
+		* configure: Re-generate.
+		* aclocal.m4: Re-generate.
+		* Makefile.in (distclean): Add config.status.
+		(Makefile): Adjust paths.
+		(lib/pdtrace): Adjust paths.
+		(config.status): Add.
+
+	Change-Id: Ic38c79485e1835712d9c99649c9dfb59667254f1
+
+2021-07-06  Joel Brobecker  <brobecker@adacore.com>
+
+	Rename gdb/ChangeLog to gdb/ChangeLog-2021
+	Now that ChangeLog entries are no longer used for GDB patches,
+	this commit renames the file gdb/ChangeLog to gdb/ChangeLog-2021,
+	similar to what we would do in the context of the "Start of New
+	Year" procedure.
+
+	The purpose of this change is to avoid people merging ChangeLog
+	entries by mistake when applying existing commits that they are
+	currently working on.
+
+2021-07-06  Dan Streetman  <ddstreet@canonical.com>
+
+	sim: ppc: add missing empty targets
+	These are copied from sim/common/Make-common.in.
+
+	On ppc the build fails without at least the 'info' target, e.g.:
+
+	Making info in ppc
+	make[4]: Entering directory '/<<BUILDDIR>>/gdb-10.2.2974.g5b45e89f56d+21.10.20210510155809/build/default/sim/ppc'
+	make[4]: *** No rule to make target 'info'.  Stop.
+
+2021-07-06  Yuri Chornoivan  <yurchor@ukr.net>
+
+	PR 28053: Fix spelling mistakes: usupported -> unsupported and relocatation -> relocation.
+
+2021-07-06  Michael Matz  <matz@suse.de>
+
+	elf/riscv: Fix relaxation with aliases [PR28021]
+	the fix for PR22756 only changed behaviour for hidden aliases,
+	but the same situation exists for non-hidden aliases: sym_hashes[]
+	can contain multiple entries pointing to the same symbol structure
+	leading to relaxation adjustment to be applied twice.
+
+	Fix this by testing for duplicates for everything that looks like it
+	has a version.
+
+	PR ld/28021
+
+	bfd/
+		* elfnn-riscv.c (riscv_relax_delete_bytes): Check for any
+		versioning.
+
+	ld/
+		* testsuite/ld-riscv-elf/relax-twice.ver: New.
+		* testsuite/ld-riscv-elf/relax-twice-1.s: New.
+		* testsuite/ld-riscv-elf/relax-twice-2.s: New.
+		* testsuite/ld-riscv-elf/ld-riscv-elf.exp
+		(run_relax_twice_test): New, and call it.
+
+2021-07-06  Pedro Alves  <pedro@palves.net>
+	    Qingchuan Shi  <qingchuan.shi@amd.com>
+
+	Update gdb performance testsuite to be compatible with Python 3.8
+	Running "make check-perf" on a system with Python 3.8 (e.g., Ubuntu
+	20.04) runs into this Python problem:
+
+	  Traceback (most recent call last):
+	    File "<string>", line 1, in <module>
+	    File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/perftest.py", line 65, in run
+	      self.execute_test()
+	    File "<string>", line 35, in execute_test
+	    File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/measure.py", line 45, in measure
+	      m.start(id)
+	    File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/measure.py", line 102, in start
+	      self.start_time = time.clock()
+	  AttributeError: module 'time' has no attribute 'clock'
+	  Error while executing Python code.
+	  (gdb) FAIL: gdb.perf/single-step.exp: python SingleStep(1000).run()
+
+	... many times over.
+
+	The problem is that the testsuite is using time.clock(), deprecated in
+	Python 3.3 and finaly removed in Python 3.8.  The guidelines say to
+	use time.perf_counter() or time.process_time() instead depending on
+	requirements.  Looking at the current description of those functions,
+	at:
+
+	   https://docs.python.org/3.10/library/time.html
+
+	we have:
+
+	   time.perf_counter() -> float
+
+	       Return the value (in fractional seconds) of a performance
+	       counter, i.e. a clock with the highest available resolution to
+	       measure a short duration. It does include time elapsed during
+	       sleep and is system-wide. (...)
+
+	   time.process_time() -> float
+
+	       Return the value (in fractional seconds) of the sum of the
+	       system and user CPU time of the current process. It does not
+	       include time elapsed during sleep. It is process-wide by
+	       definition. (...)
+
+	I'm thinking that it's just best to record both instead of picking
+	one.  So this patch replaces the MeasurementCpuTime measurement class
+	with two new classes -- MeasurementPerfCounter and
+	MeasurementProcessTime.  Correspondingly, this changes the reports in
+	testsuite/perftest.log -- we have two new "perf_counter" and
+	"process_time" measurements and the "cpu_time" measurement is gone.  I
+	don't suppose breaking backward compatibility here is a big problem.
+	I suspect no one is really tracking long term performance using the
+	perf testsuite today.  And if they are, it shouldn't be hard to adjust.
+
+	For backward compatility, with Python < 3.3, both perf_counter and
+	process_time use the old time.clock.
+
+	gdb/testsuite/ChangeLog:
+	yyyy-mm-dd  Qingchuan Shi  <qingchuan.shi@amd.com>
+		    Pedro Alves  <pedro@palves.net>
+
+		* gdb.perf/lib/perftest/perftest.py: Import sys.
+		(time.perf_counter, time.process_time): Map to time.clock on
+		Python < 3.3.
+		(MeasurementCpuTime): Delete, replaced by...
+		(MeasurementPerfCounter, MeasurementProcessTime): .. these two new
+		classes.
+		* gdb.perf/lib/perftest/perftest.py: Import MeasurementPerfCounter
+		and MeasurementProcessTime instead of MeasurementCpuTime.
+		(TestCaseWithBasicMeasurements): Use MeasurementPerfCounter and
+		MeasurementProcessTime instead of MeasurementCpuTime.
+
+
+	Change-Id: Ia850c05d5ce57d2dada70ba5b0061f566444aa2b
+
+2021-07-06  Pedro Alves  <pedro@palves.net>
+
+	gdb.perf/: FAIL on Python errors, avoid "ERROR: internal buffer is full"
+	Currently, if you run make check-perf on a system with Python 3.8,
+	tests seen to PASS, but they actually test a lot less than intended,
+	due to:
+
+	 PerfTest::assemble, run ...
+	 python BackTrace(64).run()
+	 Traceback (most recent call last):
+	   File "<string>", line 1, in <module>
+	   File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/perftest.py", line 65, in run
+	     self.execute_test()
+	   File "<string>", line 49, in execute_test
+	   File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/measure.py", line 45, in measure
+	     m.start(id)
+	   File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/measure.py", line 102, in start
+	     self.start_time = time.clock()
+	 AttributeError: module 'time' has no attribute 'clock'
+	 Error while executing Python code.
+	 (gdb) PASS: gdb.perf/backtrace.exp: python BackTrace(64).run()
+
+	And then, after fixing the above Python compatibility issues (which
+	will be a separate patch), I get 86 instances of overflowing expect's
+	buffer, like:
+
+	  ERROR: internal buffer is full.
+	  UNRESOLVED: gdb.perf/single-step.exp: python SingleStep(1000).run()
+
+	This patch fixes both problems by adding & using a gdb_test_python_run
+	routine that:
+
+	 - checks for Python errors
+	 - consumes output line by line
+
+	gdb/testsuite/ChangeLog:
+	yyyy-mm-dd  Pedro Alves  <pedro@palves.net>
+
+		* gdb.perf/backtrace.exp: Use gdb_test_python_run.
+		* gdb.perf/disassemble.exp: Use gdb_test_python_run.
+		* gdb.perf/single-step.exp: Use gdb_test_python_run.
+		* gdb.perf/skip-command.exp: Use gdb_test_python_run.
+		* gdb.perf/skip-prologue.exp: Use gdb_test_python_run.
+		* gdb.perf/solib.exp: Use gdb_test_python_run.
+		* gdb.perf/template-breakpoints.exp: Use gdb_test_python_run.
+		* lib/perftest.exp (gdb_test_python_run): New.
+
+	Change-Id: I007af36f164b3f4cda41033616eaaa4e268dfd2f
+
+2021-07-06  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Remove read1 timeout factor from gdb.base/info-macros.exp
+	At the moment some check-read1 timeouts are handled like this in
+	gdb.base/info-macros.exp:
+	...
+	gdb_test_multiple_with_read1_timeout_factor 10 "$test" $testname {
+	  -re "$r1$r2$r3" {
+	     pass $testname
+	  }
+	  -re ".*#define TWO.*\r\n$gdb_prompt" {
+	     fail $testname
+	  }
+	  -re ".*#define THREE.*\r\n$gdb_prompt" {
+	     fail $testname
+	  }
+	  -re ".*#define FOUR.*\r\n$gdb_prompt" {
+	     fail $testname
+	  }
+	}
+	...
+	which is not ideal.
+
+	We could use gdb_test_lines, but it currently doesn't support verifying
+	the absence of regexps, which is done using the clauses above calling fail.
+
+	Fix this by using gdb_test_lines and adding a -re-not syntax to
+	gdb_test_lines, such that we can do:
+	...
+	gdb_test_lines $test $testname $r1.*$r2 \
+	    -re-not "#define TWO" \
+	    -re-not "#define THREE" \
+	    -re-not "#define FOUR"
+	...
+
+	Tested on x86_64-linux, whith make targets check and check-read1.
+
+	Also observed that check-read1 execution time is reduced from 6m35s to 13s.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-07-06  Tom de Vries  <tdevries@suse.de>
+
+		* gdb.base/info-macros.exp: Replace use of
+		gdb_test_multiple_with_read1_timeout_factor with gdb_test_lines.
+		(gdb_test_multiple_with_read1_timeout_factor): Remove.
+		* lib/gdb.exp (gdb_test_lines): Add handling or -re-not <regexp>.
+
+2021-07-06  Nelson Chu  <nelson.chu@sifive.com>
+
+	RISC-V: Fix the build broken with -Werror.
+	ChangeLog:
+
+	bfd/
+
+		* elfnn-riscv.c(riscv_elf_additional_program_headers): Removed the
+		unused variable s.
+		(riscv_elf_modify_segment_map): Added ATTRIBUTE_UNUSED for the
+		unused parameter info.
+
+2021-07-06  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/symtab] Fix skipping of import of C++ CU
+	Tom Tromey observed that when changing the language in
+	gdb.dwarf2/imported-unit-bp.exp from c to c++, the test failed.
+
+	This is due to this code in process_imported_unit_die:
+	...
+	      /* We're importing a C++ compilation unit with tag DW_TAG_compile_unit
+	         into another compilation unit, at root level.  Regard this as a hint,
+	         and ignore it.  */
+	      if (die->parent && die->parent->parent == NULL
+	          && per_cu->unit_type == DW_UT_compile
+	          && per_cu->lang == language_cplus)
+	        return;
+	...
+	which should have a partial symtabs counterpart.
+
+	Add the missing counterpart in process_psymtab_comp_unit.
+
+	Tested on x86_64-linux (openSUSE Leap 15.2), no regressions for config:
+	- using default gcc version 7.5.0
+	  (with 5 unexpected FAILs)
+	- gcc 10.3.0 and target board
+	  unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects
+	  (with 1000 unexpected FAILs)
+
+	gdb/ChangeLog:
+
+	2021-07-06  Tom de Vries  <tdevries@suse.de>
+
+		* dwarf2/read.c (scan_partial_symbols): Skip top-level imports of
+		c++ CU.
+		* testsuite/gdb.dwarf2/imported-unit-bp.exp: Moved to ...
+		* testsuite/gdb.dwarf2/imported-unit-bp.exp.tcl: ... here.
+		* testsuite/gdb.dwarf2/imported-unit-bp-c++.exp: New test.
+		* testsuite/gdb.dwarf2/imported-unit-bp-c.exp: New test.
+		* testsuite/gdb.dwarf2/imported-unit.exp: Update.
+
+2021-07-06  Kito Cheng  <kito.cheng@sifive.com>
+
+	RISC-V: Add PT_RISCV_ATTRIBUTES and add it to PHDR.
+	We added PT_RISCV_ATTRIBUTES to program header to make
+	.riscv.attribute easier to find in dynamic loader or kernel.
+
+	Ref:
+	https://github.com/riscv/riscv-elf-psabi-doc/pull/71
+
+	ChangeLog:
+
+	bfd/
+
+		* elfnn-riscv.c(RISCV_ATTRIBUTES_SECTION_NAME): New.
+		(riscv_elf_additional_program_headers): Ditto.
+		(riscv_elf_modify_segment_map): Ditto.
+		(elf_backend_additional_program_headers): Ditto.
+		(elf_backend_modify_segment_map): Ditto.
+		(elf_backend_obj_attrs_section): Use RISCV_ATTRIBUTES_SECTION_NAME
+		rather than string literal.
+
+	binutils/
+
+		* readelf.c(get_riscv_segment_type): New.
+		(get_segment_type): Handle EM_RISCV.
+
+	include/
+
+		* elf/riscv.h (PT_RISCV_ATTRIBUTES): New.
+		* testsuite/ld-elf/orphan-region.ld: Discard .riscv.attributes
+		section for simplify testcase.
+		* testsuite/ld-riscv-elf/attr-phdr.d: New.
+		* testsuite/ld-riscv-elf/attr-phdr.s: Ditto.
+		* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Add attr-phdr to
+		testcase.
+
+2021-07-06  Alan Modra  <amodra@gmail.com>
+
+	Re: PR28055, segfault in bpf special reloc function
+		PR 28055
+		* elf64-bpf.c (bpf_elf_generic_reloc): Add missing ATTRIBUTE_UNUSED.
+
+2021-07-06  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-05  Tom Tromey  <tom@tromey.com>
+
+	Simplify debug_names index writing
+	This changes the .debug_names writer to find the TU indices in the
+	main loop over all CUs and TUs.  (An earlier patch applied this same
+	treatment to the .gdb_index writer.)
+
+	Simplify gdb_index writing
+	write_gdbindex writes the CUs first, then walks the signatured type
+	hash table to write out the TUs.  However, now that CUs and TUs are
+	unified in the DWARF reader, it's simpler to handle both of these in
+	the same loop.
+
+	Minor cleanup to addrmap_index_data::previous_valid
+	This changes addrmap_index_data::previous_valid to a bool, and
+	initializes it inline.
+
+2021-07-05  Tom Tromey  <tom@tromey.com>
+
+	Fix oddity in write_gdbindex
+	My recent patch to unify CUs and TUs introduced an oddity in
+	write_gdbindex.  Here, we pass 'i' to recursively_write_psymbols, but
+	we must instead pass 'counter', to handle the situation where a TU is
+	mixed in with the CUs.
+
+	I am not sure a test case for this is possible.  I think it can only
+	happen when using DWARF 5, where a TU appears in .debug_info.
+	However, this situation is already not handled correctly by
+	.gdb_index.  I filed a bug about this.
+
+2021-07-05  Tom Tromey  <tom@tromey.com>
+
+	Fix warning in symtab.c
+	The compiler gives this warning when building symtab.c:
+
+	../../binutils-gdb/gdb/symtab.c:4247:28: warning: 'to_match' may be used uninitialized in this function [-Wmaybe-uninitialized]
+
+	This patch fixes the warning by adding a gdb_assert_not_reached.
+
+2021-07-05  H.J. Lu  <hjl.tools@gmail.com>
+
+	ld: Cache and reuse the IR archive file descriptor
+	Linker plugin_object_p opens the IR archive for each IR archive member.
+	For GCC plugin, plugin_object_p closes the archive file descriptor.  But
+	for LLVM plugin, the archive file descriptor remains open.  If there are
+	3000 IR archive members, there are 3000 file descriptors for them.  We
+	can run out of file descriptors petty easily.
+
+	1. Add archive_plugin_fd and archive_plugin_fd_open_count to bfd so that
+	we can cache and reuse the IR archive file descriptor for all IR archive
+	members in the archive.
+	2. Add bfd_plugin_close_file_descriptor to properly close the IR archive
+	file descriptor.
+
+	bfd/
+
+		PR ld/28040
+		* archive.c (_bfd_archive_close_and_cleanup): Close the archive
+		plugin file descriptor if needed.
+		* bfd.c (bfd): Add archive_plugin_fd and
+		archive_plugin_fd_open_count.
+		* opncls.c (_bfd_new_bfd): Initialize to -1.
+		* plugin.c (bfd_plugin_open_input): Cache and reuse the archive
+		plugin file descriptor.
+		(bfd_plugin_close_file_descriptor): New function.
+		(try_claim): Call bfd_plugin_close_file_descriptor.
+		* plugin.h (bfd_plugin_close_file_descriptor): New.
+		* bfd-in2.h: Regenerated.
+
+	ld/
+
+		PR ld/28040
+		* plugin.c (plugin_input_file): Add ibfd.
+		(release_plugin_file_descriptor): New function.
+		(release_input_file): Call release_plugin_file_descriptor to
+		close input->fd.
+		(plugin_object_p): Call release_plugin_file_descriptor to close
+		input->fd.  Also call release_plugin_file_descriptor if not
+		claimed.
+		* testsuite/config/default.exp (RANLIB): New.
+		* testsuite/ld-plugin/lto.exp: Run ranlib test.
+
+2021-07-05  Nick Clifton  <nickc@redhat.com>
+
+	Restore the libiberty component of commit 50ad1254d5030d0804cbf89c758359ae202e8d55.
+	This commit has not yet been applied to the master sources in the gcc repository.
+	It was submitted here: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574405.html
+	The commit allows options to be set for the AR and RANLIB programs used when building libiberty, which in turn allows building with LTO enabled.
+
+	Updated translations (mainly Ukranian and French) triggered by creation of 2.37 branch.
+
+2021-07-05  Tom de Vries  <tdevries@suse.de>
+
+	[gdb/testsuite] Fix fail in gdb.fortran/ptype-on-functions.exp with gcc-7
+	Since commit 05b85772061 "gdb/fortran: Add type info of formal parameter for
+	clang" I see:
+	...
+	(gdb) ptype say_string^M
+	type = void (character*(*), integer(kind=4))^M
+	(gdb) FAIL: gdb.fortran/ptype-on-functions.exp: ptype say_string
+	...
+
+	The part of the commit causing the fail is:
+	...
+	 gdb_test "ptype say_string" \
+	-    "type = void \\(character\\*\\(\\*\\), integer\\(kind=\\d+\\)\\)"
+	+    "type = void \\(character\[^,\]+, $integer8\\)"
+	...
+	which fails to take into account that for gcc-7 and before, the type for
+	string length of a string argument is int, not size_t.
+
+	Fix this by allowing both $integer8 and $integer4.
+
+	Tested on x86_64-linux, with gcc-7 and gcc-10.
+
+	gdb/testsuite/ChangeLog:
+
+	2021-07-05  Tom de Vries  <tdevries@suse.de>
+
+		* gdb.fortran/ptype-on-functions.exp: Allow both $integer8 and
+		$integer4 for size of string length.
+
+2021-07-05  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: fall back on sigpending + sigwait if sigtimedwait is not available
+	The macOS platform does not provide sigtimedwait, so we get:
+
+	      CXX    compile/compile.o
+	    In file included from /Users/smarchi/src/binutils-gdb/gdb/compile/compile.c:46:
+	    /Users/smarchi/src/binutils-gdb/gdb/../gdbsupport/scoped_ignore_signal.h:69:4: error: use of undeclared identifier 'sigtimedwait'
+	              sigtimedwait (&set, nullptr, &zero_timeout);
+	              ^
+
+	An alternative to sigtimedwait with a timeout of 0 is to use sigpending,
+	to first check which signals are pending, and then sigwait, to consume
+	them.  Since that's slightly more expensive (2 syscalls instead of 1),
+	keep using sigtimedwait for the platforms that provide it, and fall back
+	to sigpending + sigwait for the others.
+
+	gdbsupport/ChangeLog:
+
+		* scoped_ignore_signal.h (struct scoped_ignore_signal)
+		<~scoped_ignore_signal>: Use sigtimedwait if HAVE_SIGTIMEDWAIT
+		is defined, else use sigpending + sigwait.
+
+	Change-Id: I2a72798337e81dd1bbd21214736a139dd350af87
+	Co-Authored-By: John Baldwin <jhb@FreeBSD.org>
+
+2021-07-05  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdbsupport/common.m4: check for sigtimedwait
+	The next patch will make the use of sigtimedwait conditional to whether
+	the platform provides it.  Start by adding a configure check for it.
+
+	gdbsupport/ChangeLog:
+
+		* common.m4 (GDB_AC_COMMON): Check for sigtimedwait.
+		* config.in, configure: Re-generate.
+
+	gdb/ChangeLog:
+
+		* config.in, configure: Re-generate.
+
+	gdbserver/ChangeLog:
+
+		* config.in, configure: Re-generate.
+
+	Change-Id: Ic7613fe14521b966b4d991bbcd0933ab14629c05
+
+2021-07-05  Alan Modra  <amodra@gmail.com>
+
+	Re: opcodes: constify & local meps macros
+	Commit f375d32b35ce changed a generated file.  Edit the source instead.
+
+		* mep.opc (macros): Make static and const.
+		(lookup_macro): Return and use const pointer.
+		(expand_macro): Make mac param const.
+		(expand_string): Make pmacro const.
+
+2021-07-05  Alan Modra  <amodra@gmail.com>
+
+	PR28055, segfault in bpf special reloc function
+	The testcase in this PR tickled two bugs fixed here.  output_bfd is
+	NULL when a reloc special_function is called for final linking and
+	when called from bfd_generic_get_relocated_section_contents.  Clearly
+	using output_bfd is wrong as it results in segfaults.  Not only that,
+	the endianness of the reloc field really should be that of the input.
+	The second bug was not checking that the entire reloc field was
+	contained in the section contents.
+
+		PR 28055
+		* elf64-bpf.c (bpf_elf_generic_reloc): Use correct bfd for bfd_put
+		and bfd_put_32 calls.  Correct section limit checks.
+
+2021-07-05  Alan Modra  <amodra@gmail.com>
+
+	PR28047, readelf crash due to assertion failure
+	DW_FORM_ref1, DW_FORM_ref2, DW_FORM_ref4, DW_FORM_ref1, and
+	DW_FORM_ref_udata are all supposed to be within the containing unit.
+
+		PR 28047
+		* dwarf.c (get_type_abbrev_from_form): Add cu_end parameter.
+		Check DW_FORM_ref1 etc. arg against cu_end rather than end of
+		section.  Adjust all callers.
+
+2021-07-05  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-04  Simon Marchi  <simon.marchi@polymtl.ca>
+
+	gdb: return early if no execution in darwin_solib_create_inferior_hook
+	When loading a file using the file command on macOS, we get:
+
+	    $ ./gdb -nx --data-directory=data-directory -q -ex "file ./test"
+	    Reading symbols from ./test...
+	    Reading symbols from /Users/smarchi/build/binutils-gdb/gdb/test.dSYM/Contents/Resources/DWARF/test...
+	    /Users/smarchi/src/binutils-gdb/gdb/thread.c:72: internal-error: struct thread_info *inferior_thread(): Assertion `current_thread_ != nullptr' failed.
+	    A problem internal to GDB has been detected,
+	    further debugging may prove unreliable.
+	    Quit this debugging session? (y or n)
+
+	The backtrace is:
+
+	    * frame #0: 0x0000000101fcb826 gdb`internal_error(file="/Users/smarchi/src/binutils-gdb/gdb/thread.c", line=72, fmt="%s: Assertion `%s' failed.") at errors.cc:52:3
+	      frame #1: 0x00000001018a2584 gdb`inferior_thread() at thread.c:72:3
+	      frame #2: 0x0000000101469c09 gdb`get_current_regcache() at regcache.c:421:31
+	      frame #3: 0x00000001015f9812 gdb`darwin_solib_get_all_image_info_addr_at_init(info=0x0000603000006d00) at solib-darwin.c:464:34
+	      frame #4: 0x00000001015f7a04 gdb`darwin_solib_create_inferior_hook(from_tty=1) at solib-darwin.c:515:5
+	      frame #5: 0x000000010161205e gdb`solib_create_inferior_hook(from_tty=1) at solib.c:1200:3
+	      frame #6: 0x00000001016d8f76 gdb`symbol_file_command(args="./test", from_tty=1) at symfile.c:1650:7
+	      frame #7: 0x0000000100abab17 gdb`file_command(arg="./test", from_tty=1) at exec.c:555:3
+	      frame #8: 0x00000001004dc799 gdb`do_const_cfunc(c=0x000061100000c340, args="./test", from_tty=1) at cli-decode.c:102:3
+	      frame #9: 0x00000001004ea042 gdb`cmd_func(cmd=0x000061100000c340, args="./test", from_tty=1) at cli-decode.c:2160:7
+	      frame #10: 0x00000001018d4f59 gdb`execute_command(p="t", from_tty=1) at top.c:674:2
+	      frame #11: 0x0000000100eee430 gdb`catch_command_errors(command=(gdb`execute_command(char const*, int) at top.c:561), arg="file ./test", from_tty=1, do_bp_actions=true)(char const*, int), char const*, int, bool) at main.c:523:7
+	      frame #12: 0x0000000100eee902 gdb`execute_cmdargs(cmdarg_vec=0x00007ffeefbfeba0 size=1, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x00007ffeefbfec20) at main.c:618:9
+	      frame #13: 0x0000000100eed3a4 gdb`captured_main_1(context=0x00007ffeefbff780) at main.c:1322:3
+	      frame #14: 0x0000000100ee810d gdb`captured_main(data=0x00007ffeefbff780) at main.c:1343:3
+	      frame #15: 0x0000000100ee8025 gdb`gdb_main(args=0x00007ffeefbff780) at main.c:1368:7
+	      frame #16: 0x00000001000044f1 gdb`main(argc=6, argv=0x00007ffeefbff8a0) at gdb.c:32:10
+	      frame #17: 0x00007fff20558f5d libdyld.dylib`start + 1
+
+	The solib_create_inferior_hook call in symbol_file_command was added by
+	commit ea142fbfc9c1 ("Fix breakpoints on file reloads for PIE
+	binaries").  It causes solib_create_inferior_hook to be called while
+	the inferior is not running, which darwin_solib_create_inferior_hook
+	does not expect.  darwin_solib_get_all_image_info_addr_at_init, in
+	particular, assumes that there is a current thread, as it tries to get
+	the current thread's regcache.
+
+	Fix it by adding a target_has_execution check and returning early.  Note
+	that there is a similar check in svr4_solib_create_inferior_hook.
+
+	gdb/ChangeLog:
+
+		* solib-darwin.c (darwin_solib_create_inferior_hook): Return
+		early if no execution.
+
+	Change-Id: Ia11dd983a1e29786e5ce663d0fcaa6846dc611bb
+
+2021-07-04  GDB Administrator  <gdbadmin@sourceware.org>
+
+	Automatic date update in version.in
+
+2021-07-03  H.J. Lu  <hjl.tools@gmail.com>
+
+	gprof: Regenerate configure
+		* configure: Regenerated.
+
+2021-07-03  Joel Brobecker  <brobecker@adacore.com>
+
+	Update NEWS post GDB 11 branch creation.
+	gdb/ChangeLog:
+
+		* NEWS: Create a new section for the next release branch.
+		Rename the section of the current branch, now that it has
+		been cut.
+
+2021-07-03  Joel Brobecker  <brobecker@adacore.com>
+
+	Bump version to 12.0.50.DATE-git.
+	Now that the GDB 11 branch has been created, we can
+	bump the version number.
+
+	gdb/ChangeLog:
+
+		GDB 11 branch created (4b51505e33441c6165e7789fa2b6d21930242927):
+		* version.in: Bump version to 12.0.50.DATE-git.
+
+	gdb/testsuite/ChangeLog:
+
+		* gdb.base/default.exp: Change $_gdb_major to 12.
+
+2021-07-03  Tom Tromey  <tom@tromey.com>
+
+	Use 'bool' more idiomatically in dwarf_decode_lines
+	I noticed a couple of spots related to dwarf_decode_lines where the
+	'include_p' field was not being used idiomatically -- it is of type
+	bool now, so treat it as such.
+
+	gdb/ChangeLog
+	2021-07-03  Tom Tromey  <tom@tromey.com>
+
+		* dwarf2/read.c (lnp_state_machine::record_line): Use 'true'.
+		(dwarf_decode_lines): Remove '=='.
+
+2021-07-03  Nick Clifton  <nickc@redhat.com>
+
+	More minor updates to the how-to-make-a-release documentation
+
+	Update version number and regenerate files
+
+	Add markers for 2.37 branch
+
+	Synchronize libiberty sources (and include/demangle.h) with GCC master version