Move mips_refhi_list to bfd tdata

Similar to commit c799eddb3512, but for mips-ecoff.  mips-ecoff is
marked obsolete, but we still allow reading of these object files in
a number of mips targets.

* coff-mips.c (struct mips_hi, mips_refhi_list): Delete.
(mips_refhi_reloc, mips_reflo_reloc): Access mips_refhi_list
in ecoff_data.
* ecoff.c (_bfd_ecoff_close_and_cleanup): New function.
* libecoff.h (struct mips_hi): Moved from coff-mips.c.
(struct ecoff_tdata): Add mips_refhi_list.
(_bfd_ecoff_close_and_cleanup): Declare.

Move bfd_init to bfd.c

init.c contains just one function that doesn't do much.  Move it to
bfd.c and give it something to do, initialising static state.  So far
the only initialisation is for bfd.c static variables.

The idea behind reinitialising state is to see whether some set of
flaky oss-fuzz crashes go away.  oss-fuzz stresses binutils in ways
that can't occur in reality, feeding multiple testcases into the
internals of binutils.  So one testcase may affect the result of the
next testcase.

* init.c: Delete file.  Move bfd_init to..
* bfd.c (bfd_init): ..here.  Init static variables.
* Makefile.am (BFD32_LIBS): Remove init.lo.
(BFD32_LIBS_CFILES, BFD_H_FILES): Remove init.c.
* doc/local.mk: Remove mention of init.texi and init.c.
* Makefile.in: Regenerate.
* bfd-in2.h: Regenerate.
* po/SRC-POTFILES.in: Regenerate.

Fix crash with C++ qualified names

PR c++/29503 points out that something like "b->Base::member" will
crash when 'b' does not have pointer type.  This seems to be a simple
oversight in eval_op_member.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29503
Reviewed-By: Bruno Larsen <blarsen@redhat.com>

gdb/doc: fix @code{GDBN} -> @value{GDBN}

Change-Id: I928d6f8d6e6bc41d8c7ddbfae8f6ae0614f4993e

Skip ld/pr23169 test on arm.

The test is already skipped on several targets (including AArch64)
because it's invalid.

* testsuite/ld-ifunc/ifunc.exp: Skip pr23169 on arm.

Fix PR18841 ifunc relocation ordering

In order to get the ifunc relocs properly sorted the correct class
needs to be returned.  The code mimics what has been done for AArch64.

Fixes:
FAIL: Run pr18841 with libpr18841b.so
FAIL: Run pr18841 with libpr18841c.so
FAIL: Run pr18841 with libpr18841bn.so (-z now)
FAIL: Run pr18841 with libpr18841cn.so (-z now)

bfd/
PR ld/18841
* elf32-arm.c (elf32_arm_reloc_type_class): Return
reloc_class_ifunc for ifunc symbols.

ld/testsuite/
* ld-arm/ifunc-12.rd: Update relocations order.
* ld-arm/ifunc-3.rd: Likewise.
* ld-arm/ifunc-4.rd: Likewise.

Updated transaltions for the gprof and binutils sub-directories

testsuite: add -O0 to Intel compilers if no 'optimize' option is given

icpx/icx give the following warning if '-g' is used without '-O'.

   icpx: remark: Note that use of '-g' without any optimization-level
   option will turn off most compiler optimizations similar to use of
   '-O0'; use '-Rno-debug-disables-optimization' to disable this
   remark [-Rdebug-disables-optimization]

The warning makes dejagnu think that compilation has failed.  E.g.:

  $ make check TESTS="gdb.cp/local.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx"
  ...
  gdb compile failed, icpx: remark: Note that use of '-g' without any optimization-level option will turn off most compiler optimizations similar to use of '-O0'; use '-Rno-debug-disables-optimization' to disable this remark [-Rdebug-disables-optimization]

                  === gdb Summary ===

  # of untested testcases         1

Furthermore, if no -O flag is passed, icx/icc optimize
the code by default.  This breaks assumptions in many GDB tests
that the code is unoptimized by default.  E.g.:

  $ make check TESTS="gdb.cp/cmpd-minsyms.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx"
  ...
  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::a() const'
  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::b() volatile'
  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::c() const volatile'
  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::operator ==
  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::operator==(GDB<int> const&)
  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<char>::harder(char)
  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::harder(int)
  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at "int GDB<char>::even_harder<int>(char)"
  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::simple()

                  === gdb Summary ===

  # of expected passes            1
  # of unexpected failures        9

To fix both problems, pass the -O0 flag explicitly, if no optimization
option is given.

With this patch we get, e.g.:

  $ make check TESTS="gdb.cp/cmpd-minsyms.exp gdb.cp/local.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx"
  ...
                  === gdb Summary ===

  # of expected passes            19
  # of known failures             1

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

testsuite: handle icc and icpc deprecated remarks

Starting with icc/icpc version 2021.7.0 and higher both compilers emit a
deprecation remark when used.  E.g.

  >> icc --version
  icc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is
  deprecated and will be removed from product release in the second half
  of 2023. The Intel(R) oneAPI DPC++/C++ Compiler (ICX) is the recommended
  compiler moving forward. Please transition to use this compiler. Use
  '-diag-disable=10441' to disable this message.
  icc (ICC) 2021.7.0 20220713
  Copyright (C) 1985-2022 Intel Corporation.  All rights reserved.

  >> icpc --version
  icpc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is
  deprecated ...
  icpc (ICC) 2021.7.0 20220720
  Copyright (C) 1985-2022 Intel Corporation.  All rights reserved.

As the testsuite compile fails when unexpected output by the compiler is
seen this change in the compiler breaks all existing icc and icpc tests.
This patch makes the gdb testsuite more forgiving by a) allowing the
output of the remark when trying to figure out the compiler version
and by b) adding '-diag-disable=10441' to the compile command whenever
gdb_compile is called without the intention to detect the compiler.

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

Automatic date update in version.in

PR29972, inconsistent format specification in singular form

PR 29972
* readelf.c (process_dynamic_section): Correct format string.

Automatic date update in version.in

Automatic date update in version.in

sframe: fix the defined SFRAME_FRE_TYPE_*_LIMIT constants

An earlier commit 3f107464 defined the SFRAME_FRE_TYPE_*_LIMIT
constants.  These constants are used (by gas and libsframe) to pick an
SFrame FRE type based on the function size.  Those constants, however,
were buggy, causing the generated SFrame sections to be bloated as
SFRAME_FRE_TYPE_ADDR2/SFRAME_FRE_TYPE_ADDR4 got chosen more often than
necessary.

gas/
* sframe-opt.c (sframe_estimate_size_before_relax): Use
typecast.
(sframe_convert_frag): Likewise.

libsframe/
* sframe.c (sframe_calc_fre_type): Use a more appropriate type
for argument.  Adjust the check for SFRAME_FRE_TYPE_ADDR4_LIMIT
to keep it warning-free but meaningful.

include/
* sframe-api.h (sframe_calc_fre_type): Use a more appropriate
type for the argument.
* sframe.h (SFRAME_FRE_TYPE_ADDR1_LIMIT): Correct the constant.
(SFRAME_FRE_TYPE_ADDR2_LIMIT): Likewise.
(SFRAME_FRE_TYPE_ADDR4_LIMIT): Likewise.

libsframe: adjust an incorrect check in flip_sframe

When sframe_encoder_write needs to flip the buffer containing the SFrame
section before writing, it is not necessary that the SFrame FDES are in
the order of their sfde_func_start_fre_off.  On the contrary, SFrame
FDEs will be sorted in the order of their start address.  So, remove
this incorrect assumption which is basically assuming that the last
sfde_func_start_fre_off seen will help determine the end of the flipped
buffer.

The function now keeps track of the bytes_flipped and then compares it with
the expected value.  Also, added two more checks at appropriate places:
 - check that the SFrame FDE read is within bounds
 - check that the SFrame FRE read is within bounds

libsframe/

* sframe.c (flip_sframe): Adjust an incorrect check.
Add other checks to ensure reads are within the buffer size.

ld: yet another PDB build fix (or workaround)

Older bash looks to improperly deal with backslashes in here-documents,
leaving them in place on the escaped double quotes inside the parameter
expansion. Convert to a model without using such a construct, by simply
splitting the here-documents into three ones.

Updated Bulgarian and Russian translations for LD and BFD respectively

Fix an aout memory leak

* aoutx.h (aout_bfd_free_cached_info): Free line_buf.

Tidy pe flag in coff_data

Make it a bool, use obj_pe accessor everywhere.

Make coff backend data read-only

The bfd_coff_backend_data struct should be read-only, the only thing
preventing this is that objcopy writes to one of the fields,
_bfd_coff_long_section_names.  This patch creates a copy of the field
in bfd coff_obj_tdata, which makes more sense anyway.  When enabling
long section names the intent is to do so for a particular bfd, not
for all bfds that might happen to be using the target xvec.

bfd/
* coffcode.h: Update coff long section name comment.
(bfd_coff_set_long_section_names_allowed): Use macro accessor
to set flag.
(bfd_coff_set_long_section_names_disallowed): Tidy.
(coff_backend_info): Return a const pointer.
(bfd_coff_std_swap_table, ticoff0_swap_table, ticoff1_swap_table),
(bigobj_swap_table): Make const.
(bfd_coff_long_section_names): Use tdata copy.
(coff_mkobject): Set long_section_names from coff_backend_info.
* coff-go32.c (_bfd_go32_mkobject): Likewise.
* peicode.h (pe_mkobject): Likewise.
* coff-sh.c (bfd_coff_small_swap_table): Make const.
* libcoff-in.h (struct coff_tdata): Add long_section_names,
reorder fields.
* libcoff.h: Regenerate.
binutils/
* objcopy.c (set_long_section_mode): Move earlier in file.
(copy_object): Call set_long_section_mode here, after setting
output format.
(copy_file): Don't call set_long_section_mode.

gdb/c++: Detect ambiguous variables in imported namespaces

When running gdb.cp/nsusing.cc and stopping at line 17, we can ask GDB
to print x and get a compiler-dependent answer. Using gcc 12.2.1, GDB
will print M::x, and using clang 16.0.0 prints N::x. Not only is this
behavior confusing to users, it is also not consistent with compiler
behaviors, which would warn that using x is ambiguous at this point.

This commit makes GDB behavior consistent with compilers. it achieves
this by making it so instead of exiting early when finding any symbol
with the correct name, GDB continues searching through all include
directives, storing all matching symbols in a relational map betwen the
mangled name and the found symbols.

If the resulting map has more than one entry, GDB says that the
reference is ambiguous and lists all possibilities. Otherwise it returns
the block_symbol structure for the desired symbol, or an empty struct if
nothing was found.

The commit also changes gdb.cp/nsusing.exp to test the ambiguous
detection.

gdb/mi: add no-history stop reason

When executing in reverse and runs out of recorded history, GDB prints
a warning to the user, but does not add a reason in the stopped record,
for example:

*stopped,frame={addr="0x000000000040113e",func="main",args=[],file="/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.reverse/solib-reverse.c",fullname="/home/blarsen/Documents/binutils-gdb/gdb/testsuite/gdb.reverse/solib-reverse.c",line="27",arch="i386:x86-64"},thread-id="1",stopped-threads="all",core="1"

This problem was reported as record/29260.

This commit adds the reason no-history to the record, making it easier
for interfaces using the mi interpreter to report the result.  It also
changes the test gdb.mi/mi-reverse.exp to test that the reason shows up
correctly.

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

gdb/testsuite: Fix FAILs in gdb.linespec/cpcompletion.exp when using clang

When using clang 16.0.0 to test gdb.linespec/cpcompletion.exp, I get 99
unexpected failures.  They all fail to produce a complete list of
completion options for a function, either overload2_function,
overload3_function or anon_ns_function.  This happens because clang is
optimizing them away, since they are never used.

Fix this by adding __attribute__((used)) to all declarations to the
aforementioned functions.

configure: remove dependencies on gmp and mpfr when gdb is disabled

Since 991180627851801f1999d1ebbc0e569a17e47c74, the configure checks
about GMP and MPFR for gdb builds have been moved to the toplevel
configure.
However, it doesn't take into account the --disable-gdb option. Meaning
that a build without gdb will require these libraries even if not
needed.

ChangeLog:

* configure.ac: Skip GMP and MPFR when --disable-gdb is
provided.
* configure: Regenerate.

Automatic date update in version.in

gdbsupport: fix scoped_debug_start_end's move constructor

I spotted a problem with scoped_debug_start_end's move constructor.
When constructing a scoped_debug_start_end through it, it doesn't
disable the moved-from object, meaning there are now two objects that
will do the side-effects of decrementing the debug_print_depth global
and printing the "end" message.  Decrementing the debug_print_depth
global twice is actually problematic, because the increments and
decrements get out of sync, meaning we should hit this assertion, in
theory:

    gdb_assert (debug_print_depth > 0);

However, in practice, we don't see that.  This is because despite the
move constructor being required for this to compile:

    template<typename PT>
    static inline scoped_debug_start_end<PT &> ATTRIBUTE_NULL_PRINTF (6, 7)
    make_scoped_debug_start_end (PT &&pred, const char *module, const char *func,
          const char *start_prefix,
          const char *end_prefix, const char *fmt, ...)
    {
      va_list args;
      va_start (args, fmt);
      auto res = scoped_debug_start_end<PT &> (pred, module, func, start_prefix,
        end_prefix, fmt, args);
      va_end (args);

      return res;
    }

... it is never actually called, because compilers elide the move
constructors all the way (the scoped_debug_start_end gets constructed
directly in the instance of the top-level caller).  To confirm this, I
built GDB with -fno-elide-constructors, and now I see it:

    /home/simark/src/binutils-gdb/gdb/../gdbsupport/common-debug.h:147: internal-error: ~scoped_debug_start_end: Assertion `debug_print_depth > 0' failed.

    #9  0x00005614ba5f17c3 in internal_error_loc (file=0x5614b8749960 "/home/simark/src/binutils-gdb/gdb/../gdbsupport/common-debug.h", line=147, fmt=0x5614b8733fa0 "%s: Assertion `%s' failed.") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:58
    #10 0x00005614b8e1b2e5 in scoped_debug_start_end<bool&>::~scoped_debug_start_end (this=0x7ffc6c5e7b40, __in_chrg=<optimized out>) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/common-debug.h:147
    #11 0x00005614b96dbe34 in make_scoped_debug_start_end<bool&> (pred=@0x5614baad7200: true, module=0x5614b891d840 "infrun", func=0x5614b891d800 "infrun_debug_show_threads", start_prefix=0x5614b891d7c0 "enter", end_prefix=0x5614b891d780 "exit", fmt=0x0) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/common-debug.h:235

Fix this by adding an m_disabled field to scoped_debug_start_end, and
setting it in the move constructor.

Change-Id: Ie5213269c584837f751d2d11de831f45ae4a899f

gdbsupport: add gdb::string_view_hash

Add the string_view_hash type, which will be useful to be able to use
gdb::string_view as std::unordered_map keys.

Use it in gdb/symtab.c, to exercise it.

Change-Id: Id69a466ab19a9f6620b5df8a2dd29b5cddd94c00
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdbsupport: move fast_hash to gdbsupport/common-utils.h

The following patch adds a hash type for gdb::string_view in gdbsupport,
which will use the fast_hash function.  Move the latter to gdbsupport.

Change-Id: Id74510e17801e775bd5ffa5f443713d79adf14ad
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdbsupport: move libxxhash configure check to gdbsupport

The following patch moves the fast_hash function, which uses libxxhash,
to gdbsupport.  Move the libxxhash configure check to gdbsupport (and
transitively to gdbserver).

Change-Id: I242499e50c8cd6fe9f51e6e92dc53a1b3daaa96e
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb: make gdbarch_alloc take ownership of the tdep

It's currently not clear how the ownership of gdbarch_tdep objects
works.  In fact, nothing ever takes ownership of it.  This is mostly
fine because we never free gdbarch objects, and thus we never free
gdbarch_tdep objects.  There is an exception to that however: when
initialization fails, we do free the gdbarch object that is not going to
be used, and we free the tdep too.  Currently, i386 and s390 do it.

To make things clearer, change gdbarch_alloc so that it takes ownership
of the tdep.  The tdep is thus automatically freed if the gdbarch is
freed.

Change all gdbarch initialization functions to pass a new gdbarch_tdep
object to gdbarch_alloc and then retrieve a non-owning reference from
the gdbarch object.

Before this patch, the xtensa architecture had a single global instance
of xtensa_gdbarch_tdep.  Since we need to pass a dynamically allocated
gdbarch_tdep_base instance to gdbarch_alloc, remove this global
instance, and dynamically allocate one as needed, like we do for all
other architectures.  Make the `rmap` array externally visible and
rename it to the less collision-prone `xtensa_rmap` name.

Change-Id: Id3d70493ef80ce4bdff701c57636f4c79ed8aea2
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb/testsuite: add back needed -re clause in gdb_breakpoint

Commit 4b9728be ("gdb: use gdb_test_multiple in gdb_breakpoint") caused,
amongst others:

   (gdb) break 1^M
   No line 1 in the current file.^M
   Make breakpoint pending on future shared library load? (y or [n]) n^M
   (gdb) FAIL: gdb.dwarf2/dw2-main-no-line-number.exp: gdb_breakpoint: set breakpoint at 1
   FAIL: gdb.dwarf2/dw2-main-no-line-number.exp: !$breakpoint_at_missing_lineno_set

This is because it removed one empty -re clause (matching just the
prompt) that is necessary after replying "n" to the pending breakpoint
question.  Add this clause back.

Change-Id: Ibfaa059d58bbea660bc29f0547e2f75c323fcbc6
Approved-By: Tom de Vries <tdevries@suse.de>

[gdb/python] Avoid queue.SimpleQueue for python 3.6

On openSUSE Leap 15.4 with python 3.6, the gdb.dap/basic-dap.exp test-case
fails as follows:
...
ERROR: eof reading json header
    while executing
"error "eof reading json header""
    invoked from within
"expect {
-i exp19 -timeout 10
        -re "^Content-Length: (\[0-9\]+)\r\n" {
            set length $expect_out(1,string)
            exp_continue
        }
        -re "^(\[^\r\n\]+)..."
    ("uplevel" body line 1)
    invoked from within
"uplevel $body" NONE eof reading json header
UNRESOLVED: gdb.dap/basic-dap.exp: startup - initialize
...

Investigation using a "catch throw" shows that:
...
(gdb)
    at gdb/python/py-utils.c:396
396             error (_("Error occurred in Python: %s"), msg.get ());
(gdb) p msg.get ()
$1 = 0x2b91d10 "module 'queue' has no attribute 'SimpleQueue'"
...

The python class queue.SimpleQueue was introduced in python 3.7.

Fix this by falling back to queue.Queue for python <= 3.6.

Tested on x86_64-linux, by successfully running the test-case:
...
 # of expected passes            47
...

Add type to expression dump of symbol

I recently had cause to dump some expressions from gdb.  I got output
like this:

 Operation: BINOP_GTR
  Operation: OP_VAR_VALUE
   Block symbol:
    Symbol: small_value
    Block: 0x39b4c20
  Operation: OP_LONG
   Operation: OP_LONG
    Type: int
    Constant: 0x0000000000000014

This is ok, but it would have been handy to see the type of the
symbol.  This patch adds this information.

Reviewed-By: Bruno Larsen <blarsen@redhat.com>

Remove Stephen Casner as the PDP11 maintainer.

Add an extra emulation called arm64pe to the aarch64pe emulation.

Un xfail the PR19719 test for the AArch64 architecture

Updated Bulgarian and Russian translations for the gprof subdirectory

PR29963, PDP11 link produces spurious relocation truncated messages

PDP11 is a 16-bit processor with 16-bit logical addresses.  Therefore
wrapping should be allowed on the 16-bit relocs, and may as well be
allowed for the 32-bit reloc too.

PR 29963
* pdp11.c (howto_table_pdp11): Use complain_overflow_dont.

sim: mips: add multi source to built sources

The multirun generation mode is a bit of a mess as generated run files
depend on generate igen files, all with unknown names ahead of time.
In the multirun mode, be lazy and declare all of these generated source
files as built sources so they'll be created early on.

sim: Move getopt checking inside SIM_AC_PLATFORM

This commit moves getopt declaration checker originally in sim/
configure.ac; added in commit 340aa4f6872c ("sim: Check known getopt
definition existence") to sim/m4/sim_ac_platform.m4 (inside the
SIM_AC_PLATFORM macro).

It also regenerates configuration files using the maintainer mode.

sim: bpf: fix testsuite due to linker warnings [PR sim/29954]

On a bpf-*-* testsuite fails:
./ld/ld-new: warning: test has a LOAD segment with RWX permissions

Adjusting `--memory-size=10Mb' to the simulator bpf testsuite passes.

Tested on bpf-*-*:

Bug: https://sourceware.org/PR29954

sim/testsuite:
* bpf/allinsn.exp (SIMFLAGS_FOR_TARGET): Adjust sim flags.

Automatic date update in version.in

MAINTAINERS: add myself as maintainer of libsframe

binutils/
* MAINTAINERS: Add myself as maintainer of libsframe.

x86: Remove duplicated I386_PCREL_TYPE_P/X86_64_PCREL_TYPE_P

I386_PCREL_TYPE_P and X86_64_PCREL_TYPE_P are defined twice.  Remove
the duplications.

* elfxx-x86.h (I386_PCREL_TYPE_P): Remove duplication.
(X86_64_PCREL_TYPE_P): Likewise.

gdb: ensure test_name is initialized in gdb_breakpoint

A refactoring in 4b9728bec15 (gdb: use gdb_test_multiple in
gdb_breakpoint) left the $test_name variable undefined.

This patch fixes this.

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

Use first_opcode in another spot

I found one place that could use expression::first_opcode.

Reviewed-By: Lancelot Six <lancelot.six@amd.com>

Convert exp_uses_objfile to a method of expression

This changes the exp_uses_objfile function to be a method of
'expression'.

Reviewed-By: Lancelot Six <lancelot.six@amd.com>

gdb: use gdb_test_multiple in gdb_breakpoint

When running the testsuite in a non-optimized build on a slow machine, I
sometimes get:

    UNTESTED: gdb.gdb/selftest.exp: Cannot set breakpoint at captured_main, skipping testcase.

do_self_tests, in lib/selftest-support.exp, uses `with_timeout_factor
10`, to account for the fact that reading the debug info of the gdb
binary (especially in a non-optimized GDB) can take time.  But then it
ends up calling gdb_breakpoint, which uses gdb_expect with a hard-coded
timeout of 30 seconds.

Fix this by making gdb_breakpoint use gdb_test_multiple, which is a
desired change anyway for this kind of simple command / expected
output case.

Change-Id: I9b06ce991cc584810d8cc231b2b4893980b8be75
Reviewed-By: Lancelot Six <lancelot.six@amd.com>

Re: Avoid unaligned pointer reads in PEP .idata section

Fix testsuite fallout.

* testsuite/ld-pe/cfi.d: Adjust for changed .idata padding.
* testsuite/ld-pe/secidx_64.d: Likewise.
* testsuite/ld-pe/secrel_64.d: Likewise.

objcopy fuzzed pe out of memory

This occurs when attempting to read back a section from the output
file in _bfd_XX_bfd_copy_private_bfd_data_common.  The copy of the
section failed size sanity checking, thus it won't be written.

* objcopy.c (copy_object): Return false if copy_section or
copy_relocations_in_section fails.

fuzzed file timeout

objcopy of archive, element containing an object with a fuzzed section
size far exceeding the element size.  copy_section detects this, but
the temp file is laid out for the large section.  It can take a long
time to write terabytes of sparse file, a waste of time when it will
be deleted.

* objcopy.c (copy_archive): Don't write element contents after
bad status result from copy_object.

asan: segv in parse_module

* vms-alpha.c (parse_module): Ignore DST__K_SRC_SETFILE data
if out of range.

addr2line out of memory on fuzzed file

Another case of fuzzers finding the section size sanity checks are
avoided with SHT_NOBITS sections.

* dwarf2.c (read_section): Check that the DWARF section being
read has contents.

gdb: fix some #ifdef logic in bt-utils.h

In passing I spotted some incorrect #ifdef logic in bt-utils.h.  The
logic in question has existed since the file was originally added in
commit:

  commit abbbd4a3e0ca51132e7fb31a43f896d29894dae0
  Date:   Wed Aug 11 13:24:33 2021 +0100

      gdb: use libbacktrace to create a better backtrace for fatal signals

The code is trying to select between using libbacktrace or using the
execinfo supplied backtrace API.

First we check to see if we can use libbacktrace.  If we can then we
include some header files, and then set some defines to indicate that
libbacktrace is being used.

Then we check if execinfo is available, if it is then we include
<execinfo.h> and set some alternative defines.

In theory the second block of logic should not trigger if the first
block (that uses libbacktrace) has also triggered, but we incorrectly
check the define 'PRINT_BACKTRACE_ON_FATAL_SIGNAL' instead of checking
for 'GDB_PRINT_INTERNAL_BACKTRACE_USING_LIBBACKTRACE', so the second
block triggers more than it should.  The
'PRINT_BACKTRACE_ON_FATAL_SIGNAL' define is not defined anywhere, this
was a mistake in the original commit.

In reality this is harmless, we include <execinfo.h> when we don't
need too, but in by-utils.c the libbacktrace define is always checked
for before the execinfo define, so we never actually end up using the
execinfo path (when libbacktrace is available).  But I figure its
still worth cleaning this up.

I've tested GDB in a "default" build where libbacktrace is used, and
when configuring with --disable-libbacktrace which causes the execinfo
backtrace API to be used instead, both still appear to work fine.

There should be no user visible changes after this commit.

gdb: add 'maintenance print record-instruction' command

While chasing some reverse debugging bugs, I found myself wondering what
was recorded by GDB to undo and redo a certain instruction. This commit
implements a simple way of printing that information.

If there isn't enough history to print the desired instruction (such as
when the user hasn't started recording yet or when they request 2
instructions back but only 1 was recorded), GDB warns the user like so:

(gdb) maint print record-instruction
Not enough recorded history

If there is enough, GDB prints the instruction like so:

(gdb) maint print record-instruction
4 bytes of memory at address 0x00007fffffffd5dc changed from: 01 00 00 00
Register eflags changed: [ IF ]
Register rip changed: (void (*)()) 0x401115 <main+15>

Approved-by: Eli Zaretskii <eliz@gnu.org>
Reviewed-by: Alexandra Hajkova <ahajkova@redhat.com>
Reviewed-by: Lancelot Six <lsix@lancelotsix.com>
Approved-by: Tom Tromey <tom@tromey.com>

Fix AArch64 linker testsuite failures trigeered by differences in build environments.

PR 29843
* testsuite/ld-aarch64/bti-plt-5.d: Relax regxps slightly to allow
for differences in build environments.
* testsuite/ld-aarch64/tls-relax-gdesc-le-now.d: Likewise.

Avoid unaligned pointer reads in PEP .idata section

This is something I discovered when working on aarch64, though it's
relevant to x86_64 too.

The PE32+ imports are located in the .idata section, which starts off
with a 20-byte structure for each DLL, containing offsets into the rest
of the section. This is the Import Directory Table in
https://learn.microsoft.com/en-us/windows/win32/debug/pe-format, which
is a concatenation of the .idata$2 sections. This is then followed by an
20 zero bytes generated by the linker script, which calls this .idata$3.

After this comes the .idata$4 entries for each function, which the
loader overwrites with the function pointers. Because there's no padding
between .idata$3 and .idata$4, this means that if there's an even number
of DLLs, the function pointers won't be aligned on an 8-byte boundary.

Misaligned reads are slower on x86_64, but this is more important on
aarch64, as the e.g. `ldr x0, [x0, :lo12:__imp__func]` the compiler
might generate requires __imp__func (the .idata$4 entry) to be aligned
to 8 bytes. Without this you get IMAGE_REL_ARM64_PAGEOFFSET_12L overflow
errors.

Merge config/picflag.m4 from gcc

and regen libiberty/configure

sim: Regenerate using the maintainer mode

Those files have changed by regenerating using the maintainer mode.
The first line of sim/ppc/pk.h have changed by an effect of the commit
319e41e83a40 ("sim: ppc: inline the sim-packages option").

Automatic date update in version.in

opcodes: xtensa: fix jump visualization for FLIX

opcodes/
* xtensa-dis.c (print_insn_xtensa): Add local variables
insn_type, target and imm_pcrel to track control flow across
multiple slots.

opcodes: xtensa: implement styled disassembly

opcodes/
* xtensa-dis.c (print_xtensa_operand)
(print_insn_xtensa): Replace fprintf_func with
fprintf_styled_func.

Add test case for "finish" with variably-sized types

This adds a test case for "finish" with variably-sized types, and for
inferior calls as well.  This also extends the "runto" proc to handle
temporary breakpoints.

Use value_at_non_lval in get_call_return_value

get_call_return_value can handle RETURN_VALUE_STRUCT_CONVENTION,
because the call is completely managed by gdb.  However, it does not
handle variably-sized types correctly.  The simplest way to fix this
is to use value_at_non_lval, which does type resolution.

Fix inferior calls with variably-sized return type

This patch updates the gdbarch_return_value_as_value implementations
to work correctly with variably-sized return types.

Convert selected architectures to gdbarch_return_value_as_value

This converts a few selected architectures to use
gdbarch_return_value_as_value rather than gdbarch_return_value.  The
architectures are just the ones that I am able to test.  This patch
should not introduce any behavior changes.

Don't let property evaluation affect the current language

On PPC, we saw that calling an inferior function could sometimes
change the current language, because gdb would select the call dummy
frame -- associated with _start.

This patch changes gdb so that the current language is never affected
by DWARF property evaluation.

Introduce value_at_non_lval

In some cases, while a value might be read from memory, gdb should not
record the value as being equivalent to that memory.

In Ada, the inferior call code will call ada_convert_actual -- and
here, if the argument is already in memory, that address will simply
be reused.  However, for a call like "f(g())", the result of "g" might
be on the stack and thus overwritten by the call to "f".

This patch introduces a new function that is like value_at but that
ensures that the result is non-lvalue.

Don't emit gdbarch_return_value

The previous patch introduced a new overload of gdbarch_return_value.
The intent here is that this new overload always be called by the core
of gdb -- the previous implementation is effectively deprecated,
because a call to the old-style method will not work with any
converted architectures (whereas calling the new-style method is will
delegate when needed).

This patch changes gdbarch.py so that the old gdbarch_return_value
wrapper function can be omitted.  This will prevent any errors from
creeping in.

Add new overload of gdbarch_return_value

The gdbarch "return_value" can't correctly handle variably-sized
types.  The problem here is that the TYPE_LENGTH of such a type is 0,
until the type is resolved, which requires reading memory.  However,
gdbarch_return_value only accepts a buffer as an out parameter.

Fixing this requires letting the implementation of the gdbarch method
resolve the type and return a value -- that is, both the contents and
the new type.

After an attempt at this, I realized I wouldn't be able to correctly
update all implementations (there are ~80) of this method.  So,
instead, this patch adds a new method that falls back to the current
method, and it updates gdb to only call the new method.  This way it's
possible to incrementally convert the architectures that I am able to
test.

Fix crash in amd64-tdep.c

amd64-tdep.c could crash when 'finish'ing from a function whose return
type had variable length.  In this situation, the value will be passed
by reference, and this patch avoids the crash.

(Note that this does not fully fix the bug reported, but it does fix
the crash, so it seems worthwhile to land independently.)

[gdb/testsuite] Add xfail in gdb.arch/i386-pkru.exp

On a x86_64-linux machine with pkru register, I run into:
...
(gdb) PASS: gdb.arch/i386-pkru.exp: set pkru value
info register pkru^M
pkru           0x12345678          305419896^M
(gdb) FAIL: gdb.arch/i386-pkru.exp: read value after setting value
...

This is a regression due to kernel commit e84ba47e313d ("x86/fpu: Hook up PKRU
onto ptrace()").  This is fixed by recent kernel commit 4a804c4f8356
("x86/fpu: Allow PKRU to be (once again) written by ptrace.").

The regression occurs for kernel versions v5.14-rc1 (the first tag containing
the regression) up to but excluding v6.2-rc1 (the first tag containing the fix).

Fix this by adding an xfail for the appropriate kernel versions.

Tested on x86_64-linux.

PR testsuite/29790
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29790

Do not use PyObject_CallNoArgs

PyObject_CallNoArgs was introduced in Python 3.9, so avoid it in favor
of PyObject_CallObject.

Fix a potential problem in the BFD library when accessing the Windows' nul device driver.

PR 29947
* bfdio.c (_bfd_real_fopen): Do not add a prefix to the Windows'
nul device filename.

Fix a translation problem in the x86 assembler.

PR 29952
* config/tc-i386.c (md_assemble): Avoid constructing translatable
strings.

Updated translations for various languages and sub-directories

Add new NT_ARM_ZA and NT_ARM_SSVE register set constants.

[gdb] Fix segfault during inferior call to ifunc

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

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

Fatal signal: Segmentation fault
...

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

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

Fix this by using prepare_reinflate and reinflate.

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

Tested on x86_64-linux.

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

sim: sh: move some generated source files to built sources

This should have been part of the previous commit 80636a54bcfa2bca3dc8f
("sim: build: move generated headers to built sources"), but they were
missed because they're .c files effectively treated as .h files.

sim: build: add var for tracking sim enable directly

Rather than rely on SIM_SUBDIRS being set, add a dedicated variable
to track whether to enable the sim.  While the current code works
fine, it won't work as we remove the recursive make logic (i.e. the
SIM_SUBDIRS variable).

sim: common: drop libcommon.a linkage

All of these objects should be in libsim.a already, so don't link to
it too.  In practice it never gets used, but no point in listing it.

sim: build: move generated headers to built sources

Automake's automatic header deptracking has a bootstrap problem where
it can't detect generated headers when compiling.  We've been handling
that by adding a custom SIM_ALL_RECURSIVE_DEPS variable, but that only
works when building objects recursively in subdirs.  As we move those
out to the top-level, we don't have any recursive steps anymore.  The
Automake approach is to declare those headers in BUILT_SOURCES.

This isn't completely foolproof as the Automake manual documents: it
only activates for `make all`, not `make foo.o`, but that shouldn't be
a huge limitation as it only affects the initial compile.  After that,
rebuilds should work fine.

sim: cgen: drop common subdir build rules

Now that everything has been hoisted to the top-level, we can delete
this unused logic.

sim: or1k: hoist cgen rules to top-level

sim: m32r: hoist cgen rules to top-level

sim: lm32: hoist cgen rules to top-level

sim: iq2000: hoist cgen rules to top-level

sim: frv: hoist cgen rules to top-level

sim: cris: hoist cgen rules to top-level

sim: bpf: hoist cgen rules to top-level

sim: cgen: hoist rules to the top-level build

The rules seem to generate the same output as existing subdir cgen
rules with cgen ports, so hopefully this should be correct.  These
are the last set of codegen rules that we run in subdirs, so this
will help unblock killing off subdir builds entirely.

sim: build: use Automake include vars

Rather than define our own hack for emitting an include statement,
use the existing Automake include variables.  These have the nice
side-effect of being more portable.

Automatic date update in version.in

Simplify debug_exp

debug_exp should call expression::dump rather than using the 'op'
member.

Initial implementation of Debugger Adapter Protocol

The Debugger Adapter Protocol is a JSON-RPC protocol that IDEs can use
to communicate with debuggers.  You can find more information here:

    https://microsoft.github.io/debug-adapter-protocol/

Frequently this is implemented as a shim, but it seemed to me that GDB
could implement it directly, via the Python API.  This patch is the
initial implementation.

DAP is implemented as a new "interp".  This is slightly weird, because
it doesn't act like an ordinary interpreter -- for example it doesn't
implement a command syntax, and doesn't use GDB's ordinary event loop.
However, this seemed like the best approach overall.

To run GDB in this mode, use:

    gdb -i=dap

The DAP code will accept JSON-RPC messages on stdin and print
responses to stdout.  GDB redirects the inferior's stdout to a new
pipe so that output can be encapsulated by the protocol.

The Python code uses multiple threads to do its work.  Separate
threads are used for reading JSON from the client and for writing JSON
to the client.  All GDB work is done in the main thread.  (The first
implementation used asyncio, but this had some limitations, and so I
rewrote it to use threads instead.)

This is not a complete implementation of the protocol, but it does
implement enough to demonstrate that the overall approach works.

There is a rudimentary test suite.  It uses a JSON parser written in
pure Tcl.  This parser is under the same license as Tcl itself, so I
felt it was acceptable to simply import it into the tree.

There is also a bit of documentation -- just documenting the new
interpreter name.

Fix target remote pipe command for MinGW

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

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

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

Remove target: prefix from gdb_sysroot in find_separate_debug_file

I noticed that, when using gdbserver, gdb might print:

Reading /usr/lib/debug/lib64//libcap.so.2.48-2.48-4.fc36.x86_64.debug from remote target...
Reading target:/usr/lib/debug/lib64//libcap.so.2.48-2.48-4.fc36.x86_64.debug from remote target...

The second line has the "target:" prefix, but from the code it's clear
that this string is being passed verbatim to gdbserver -- which seems
wrong.

I filed PR remote/29929 for this.

The problem here is that find_separate_debug_file uses gdb_sysroot
without checking to see if it starts with the "target:" prefix.  This
patch changes this code to be a little more careful.

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

[gdb/testsuite] Fix gdb.python/py-breakpoint.exp with libstdc++ debug info

On x86_64-linux, I run into:
...
(gdb) python hbp1 = gdb.Breakpoint("add", type=gdb.BP_HARDWARE_BREAKPOINT)^M
Hardware assisted breakpoint 2 at 0x40072e: add. (7 locations)^M
(gdb) FAIL: gdb.python/py-breakpoint.exp: test_hardware_breakpoints: \
  Set hardware breakpoint
...
due to libstdc++ debug info:
...
$ gdb -q -batch outputs/gdb.python/py-breakpoint/py-breakpoint \
  -ex start \
  -ex "b add" \
  -ex "info break"
Temporary breakpoint 1 at 0x40076a: file py-breakpoint.c, line 50.

Temporary breakpoint 1, main (argc=1, argv=$hex) at py-breakpoint.c:50
50        int foo = 5;
Breakpoint 2 at 0x40072e: add. (7 locations)
Num     Type           Disp Enb Address            What
2       breakpoint     keep y   <MULTIPLE>
2.1                         y   0x000000000040072e in add(int) at \
  py-breakpoint.c:39
2.2                         y   0x00007ffff7b131de in \
  (anonymous namespace)::fast_float::bigint::add at \
  ../../../../../libstdc++-v3/src/c++17/fast_float/fast_float.h:1815
  ...
2.7                         y   0x00007ffff7b137e4 in \
  (anonymous namespace)::fast_float::bigint::add at \
  ../../../../../libstdc++-v3/src/c++17/fast_float/fast_float.h:1815
...

Fix this by using qualified=True.

Tested on x86_64-linux.
PR testsuite/29910
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29910

sim: replace -I$srcroot/bfd include with -I$srcroot

Clean up includes a bit by making ports include bfd/ headers
explicitly.  This matches other projects, and makes it more clear
where these headers are coming from.

sim: replace -I$srcroot/opcodes include with -I$srcroot

Clean up includes a bit by making ports include opcodes/ headers
explicitly.  This matches other projects, and makes it more clear
where these headers are coming from.