gas: Restore tc_pe_dwarf2_emit_offset for pe-aarch64

Restores tc_pe_dwarf2_emit_offset in tc-aarch64.c, which is needed to
make sure that DWARF offsets are encoded correctly (they're secrels in
COFF). There were remnants of this there before, but they were removed
by Jedidiah's original patch - presumably because we didn't yet have
.secrel32.

Add aarch64-w64-mingw32 target

This adds a mingw target for aarch64, including windres and dlltool.

Note that the old value of jmp_aarch64_bytes was wrong, and this does
the same thing as MSVC does.

Add .secrel32 for pe-aarch64

Adds the .secrel32 pseudo-directive and its corresponding relocation.

Add pe-aarch64 relocations

This adds the remaining pe-aarch64 relocations, and gets them working.
It also brings in the constant directives from ELF, as otherwise .word
would be 2 rather than 4 bytes, and .xword and .dword wouldn't be
defined.

Fix size of external_reloc for pe-aarch64

This patch series finishes off the work by Jedidiah Thompson, and adds
support for creating aarch64 PE images.

This should be essentially complete: I've used this to create a "hello
world" Windows program in asm, and (with GCC patches) a UEFI program in
C. I think the only things missing are the .secidx relocation, which is
needed for PDBs, and the SEH pseudos used for C++ exceptions.

This first patch fixes the size of RELSZ; I'm not sure why it was 14 in
the first place. This is the size of the "Base Relocation Block" in
https://learn.microsoft.com/en-us/windows/win32/debug/pe-format, and
AFAIK should be 10 for everything.

gdb/dwarf2: Fix 'rw_pieced_value' for values casted to different type.

The 'rw_pieced_value' function is executed when fetching a (lazy)
variable described by 'DW_OP_piece' or 'DW_OP_bit_piece'.  The
function checks the 'type' and 'enclosing_type' fields of the value
for identity.

  * The 'type' field describes the type of a value.
  * In most cases, the 'enclosing_type' field is identical to the
    'type' field.
  * Scenarios where the 'type' and 'enclosing_type' of an object
    differ are described in 'gdb/value.c'.  Possible cases are:
    * If a value represents a C++ object, then the 'type' field
      gives the object's compile-time type.  If the object actually
      belongs to some class derived from `type', perhaps with other
      base classes and additional members, then `type' is just a
      subobject of the real thing, and the full object is probably
      larger than `type' would suggest.
    * If 'type' is a dynamic class (i.e. one with a vtable), then GDB
      can actually determine the object's run-time type by looking at
      the run-time type information in the vtable.  GDB may then elect
      to read the entire object.
    * If the user casts a variable to a different type
      (e.g. 'print (<type> []) <variable>'), the value's type is
      updated before reading the value.

If a lazy value is fetched, GDB allocates space based on the enclosing
type's length and typically reads the 'full' object.  This is not
implemented for pieced values and causes an internal error if 'type'
and 'enclosing_type' of a value are not identical.

However, GDB can read the value based on its type.  Thus, this patch
fixes the previously mentioned cases by removing the check for identity.

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

gdb/ChangeLog:
2022-04-13  Stephan Rohr  <stephan.rohr@intel.com>

* dwarf2/loc.c (rw_pieced_value): Fix check on 'type' and
'enlcosing_type' when reading pieced value 'v'.

gdb/testsuite/ChangeLog:
2022-04-13  Stephan Rohr  <stephan.rohr@intel.com>

* gdb.dwarf2/shortpiece.exp: Added test cases.

Convert say_where to method on code_breakpoint

'say_where' is only useful (and only called for) code breakpoints, so
convert it to be a protected method on code_breakpoint.

gdb/doc: use @value{GDBP} in some spots

Examples are supposed to use @value{GDBP} instead of the literal "(gdb)"
(many of them already do).  Update a bunch of spots where it wasn't the
case.

Change-Id: I601adaad61fd277a5fceea1759e49cede72e456d

gdb/doc: use @value{GDBN} in some spots

Change some spots to use "@value{GDBN}" instead of just "GDB".

Change-Id: I3fc26438e603538271cf33e4d148be5fda9ece7e

gdb/doc: some whitespace fixes

For consistency, replace tabs with spaces in all gdb.texinfo menus.

Change-Id: I0801a72cf82a8afe49ec842244f42d30719634ce

IBM zSystems: Fix offset relative to static TLS

For local exec TLS relocations of the form foo@NTPOFF+x the addend was
ignored.

bfd/ChangeLog:

* elf32-s390.c (elf_s390_relocate_section): Honor addend for
R_390_TLS_LE32.
* elf64-s390.c (elf_s390_relocate_section): Honor addend for
R_390_TLS_LE64.

ld/ChangeLog:

* testsuite/ld-s390/reloctlsle-1.d: New test.
* testsuite/ld-s390/reloctlsle-1.s: New test.

PR 29981 references to init.texi

Re: Move bfd_init to bfd.c

Commit b1c95bc4dd73 resulted in
...bfd.texi:246: @include: could not find init.texi
which went unnoticed due to not building in a clean directory.

This fixes the problem by moving bfd_init earlier, giving it a
doc node, and stitching the nodes back together.

* bfd.c (bfd_init): Move earlier.  Give it a doc inode.
Adjust other inodes to suit.
* doc/bfd.texi: Don't include init.texi.  Adjust nodes to suit.

sim: disable recursive make in (most) subdirs

Now that all (other than ppc) build in the top-level, we can disable
the recursive make calls to them.  This speeds things up nicely.

sim: common: move test-hw-events to top-level build

This is an internal developer target that isn't normally compiled,
but it can still be occasionally useful.  Move it to the top-level
build so we can kill off common/Make-common.in.

sim: move arch-specific file compilation of common/ files to top-level

sim: v850: move arch-specific file compilation to top-level

The arch-specific compiler flags are duplicated, but they'll be cleaned
up once we move all subdir compiles to the top-level.

sim: sh: move arch-specific file compilation to top-level

sim: rx: move arch-specific file compilation to top-level

The arch-specific flags are only used by the arch-specific modules,
not the common/ files, so we can delete them too.

sim: rl78: move arch-specific file compilation to top-level

sim: riscv: move arch-specific file compilation to top-level

The arch-specific compiler flags are duplicated, but they'll be cleaned
up once we move all subdir compiles to the top-level.

sim: pru: move arch-specific file compilation to top-level

sim: or1k: move arch-specific file compilation to top-level

The arch-specific compiler flags are duplicated, but they'll be cleaned
up once we move all subdir compiles to the top-level.

sim: msp430: move arch-specific file compilation to top-level

sim: moxie: move arch-specific file compilation to top-level

The arch-specific flags are only used by the arch-specific modules,
not the common/ files, so we can delete them too.

sim: mn10300: move arch-specific file compilation to top-level

The arch-specific compiler flags are duplicated, but they'll be cleaned
up once we move all subdir compiles to the top-level.

sim: mips: move arch-specific file compilation to top-level

The arch-specific compiler flags are duplicated, but they'll be cleaned
up once we move all subdir compiles to the top-level.

sim: microblaze: move arch-specific file compilation to top-level

sim: mcore: move arch-specific file compilation to top-level

sim: m68hc11: move arch-specific file compilation to top-level

The arch-specific compiler flags are duplicated, but they'll be cleaned
up once we move all subdir compiles to the top-level.

sim: m32r: move arch-specific file compilation to top-level

sim: m32c: move arch-specific file compilation to top-level

The arch-specific flags are only used by the arch-specific modules,
not the common/ files, so we can delete them too.

sim: lm32: move arch-specific file compilation to top-level

sim: iq2000: move arch-specific file compilation to top-level

sim: h8300: move arch-specific file compilation to top-level

sim: ft32: move arch-specific file compilation to top-level

sim: frv: move arch-specific file compilation to top-level

The arch-specific flags are only used by the arch-specific modules,
not the common/ files, so we can delete them too.

sim: example-synacor: move arch-specific file compilation to top-level

sim: erc32: move arch-specific file compilation to top-level

The arch-specific flags are only used by the arch-specific modules,
not the common/ files, so we can delete them too.

sim: d10v: move arch-specific file compilation to top-level

sim: cris: move arch-specific file compilation to top-level

sim: cr16: move arch-specific file compilation to top-level

sim: bfin: move arch-specific file compilation to top-level

The arch-specific flags are only used by the arch-specific modules,
not the common/ files, so we can delete them too.

sim: bpf: move arch-specific file compilation to top-level

We can drop the arch-specific rules from the subdir as they're no
longer used.

sim: avr: move arch-specific file compilation to top-level

sim: arm: move arch-specific file compilation to top-level

The arch-specific flags are only used by the arch-specific modules,
not the common/ files, so we can delete them too.

sim: aarch64: move arch-specific file compilation to top-level

sim: build: add basic framework for compiling arch objects in top-level

The code so far has been assuming that we only compile common/ objects.
Now that we're ready to compile arch-specific objects, refactor some of
the flags & checks a bit to support both.

sim: modules.c: move generation to top-level

Now that all arches create libsim.a from the top-level, we have full
access to their inputs, and can move the actual generation from the
subdir up to the top-level.  This avoids recursive makes and will
help simplify state passing between the two.

sim: build: drop common/nrun.o subdir hack

Now that all the subdirs handle their own builds, we can drop this
common rule as it's unused, and we don't want to use it anymore.

sim: build: drop support for creating libsim.a in subdirs

Now that all ports have moved to creating libsim.a in the top-level,
drop all the support code to create it in a subdir.

sim: v850: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: sh: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: rx: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: rl78: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: riscv: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: pru: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: or1k: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: msp430: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: moxie: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: mn10300: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: mips: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

The mips code is a little more tricky than others because, for multi-run
targets, it generates the list of sources & objects on the fly in the
configure script.

sim: microblaze: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: mcore: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: m68hc11: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: m32r: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: m32c: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: lm32: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: iq2000: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: h8300: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: ft32: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: frv: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: example-synacor: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: erc32: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: d10v: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: cris: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: cr16: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: bpf: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: bfin: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: avr: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: arm: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: aarch64: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: build: drop support for subdir extra deps

Nothing uses this hook anymore, so punt it.  It was largely used to
track generated files (which we do in the top-level now) and extra
header files (which we use automake depgen for now).

sim: modules: trigger generation from top-level

Add rules for tracking generated subdir modules.c files.  This doesn't
actually generate the file from the top-level, but allows us to add
rules that need to be ordered wrt it.  Once those changes land, we can
rework this to actually generate from the top-level.

This currently builds off of the objects that go into the libsim.a as
we don't build those from the top-level either.  Once we migrate that
up, we can switch this to the source files directly.  It's a bit hacky
overall, but makes it easier to migrate things in smaller chunks, and
we aren't going to keep this logic long term.

gdb/linespec.c: Fix missing source file during breakpoint re-set

During breakpoint re-setting, the source_filename of an
explicit_location_spec is used to lookup the symtabs associated with
the breakpoint being re-set.  This source_filename is compared with each
known symtab filename in order to retrieve the breakpoint's symtabs.

However the source_filename may have been originally copied from a
symtab's fullname (the path where GDB found the source file) when the
breakpoint was first created.  If a breakpoint symtab's filename and
fullname differ and there is no substitute-path rule that converts the
fullname to the filename, this will cause a NOT_FOUND_ERROR to be thrown
during re-setting.

Fix this by using a symtab's filename to set the explicit_location_spec
source_filename instead of the symtab's fullname.

gdb/linespec.c: Fix -Wmaybe-uninitialized warning

Although the bool want_start_sal isn't actually used without being assigned
a value, initialize it to be false in order to prevent the following
-Wmaybe-uninitialized warning:

    linespec.c: In function ‘void minsym_found(linespec_state*, objfile*, minimal_symbol*, std::vector<symtab_and_line>*)’:
    linespec.c:4150:19: warning: ‘want_start_sal’ may be used uninitialized [-Wmaybe-uninitialized]
     4150 |   if (is_function && want_start_sal)

Automatic date update in version.in

Set dwarf2 stash pointer earlier

This fixes a memory leak in the vanishingly rare cases (found by
fuzzers of course) when something goes wrong in the save_section_vma,
htab_create_alloc or alloc_trie_leaf calls before *pinfo is written.
If *pinfo is not written, _bfd_dwarf2_cleanup_debug_info won't be able
to free that memory.

* dwarf2.c (_bfd_dwarf2_slurp_debug_info): Save stash pointer
on setting up stash.

peXXigen.c sanity checks

Also fix a memory leak, and make some style changes.  I tend to read
(sizeof * x) as a multiplication of two variables, which I would not
do if binutils followed the gcc coding conventions consistently (see
https://gcc.gnu.org/codingconventions.html#Expressions).  (sizeof *x)
looks a lot better to me, or even (sizeof (*x)) which I've used here.

* peXXigen.c (get_contents_sanity_check): New function.
(pe_print_idata): Use it here..
(pe_print_edata): ..and here.  Free data on error return.
(rsrc_parse_entry): Check entry size read from file.
(rsrc_parse_entries): Style fixes.
(rsrc_process_section): Use bfd_malloc_and_get_section.
(_bfd_XXi_final_link_postscript): Likewise.

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.