gdb/doc: fix install-html with Texinfo 7

Starting with Texinfo 7 (this commit [1]), the output directory for the
HTML doc format is gdb/doc/gdb_html, rather than gdb/doc/gdb previously.
This breaks the install-html target, which expects the HTML doc to be in
gdb/doc/gdb:

    $ make install-html MAKEINFO=makeinfo DESTDIR=/tmp/install
    make[1]: Entering directory '/home/simark/build/binutils-gdb/gdb'
    make[2]: Entering directory '/home/simark/build/binutils-gdb/gdb/doc'
    makeinfo  -DHAVE_MAKEINFO_CLICK --html  -I /home/simark/src/binutils-gdb/gdb/doc/../../readline/readline/doc -I /home/simark/src/binutils-gdb/gdb/doc/../mi -I /home/simark/src/binutils-gdb/gdb/doc /home/simark/src/binutils-gdb/gdb/doc/gdb.texinfo
    makeinfo  -DHAVE_MAKEINFO_CLICK --html  -I /home/simark/src/binutils-gdb/gdb/doc /home/simark/src/binutils-gdb/gdb/doc/stabs.texinfo
    makeinfo  -DHAVE_MAKEINFO_CLICK --html  -I /home/simark/src/binutils-gdb/gdb/doc /home/simark/src/binutils-gdb/gdb/doc/annotate.texinfo
    test -z "/usr/local/share/doc/gdb" || /bin/sh /home/simark/src/binutils-gdb/gdb/doc/../../mkinstalldirs "/tmp/install/usr/local/share/doc/gdb"
     /usr/bin/install -c -m 644 '/home/simark/src/binutils-gdb/gdb/doc/gdb' '/tmp/install/usr/local/share/doc/gdb/gdb'
    /usr/bin/install: cannot stat '/home/simark/src/binutils-gdb/gdb/doc/gdb': No such file or directory
     /usr/bin/install -c -m 644 '/home/simark/src/binutils-gdb/gdb/doc/stabs' '/tmp/install/usr/local/share/doc/gdb/stabs'
    /usr/bin/install: cannot stat '/home/simark/src/binutils-gdb/gdb/doc/stabs': No such file or directory
     /usr/bin/install -c -m 644 '/home/simark/src/binutils-gdb/gdb/doc/annotate' '/tmp/install/usr/local/share/doc/gdb/annotate'
    /usr/bin/install: cannot stat '/home/simark/src/binutils-gdb/gdb/doc/annotate': No such file or directory
    make[2]: *** [Makefile:278: install-html] Error 1
    make[2]: Leaving directory '/home/simark/build/binutils-gdb/gdb/doc'
    make[1]: *** [Makefile:2240: subdir_do] Error 1
    make[1]: Leaving directory '/home/simark/build/binutils-gdb/gdb'
    make: *** [Makefile:2006: install-html] Error 2

Fix this by adding -o switches to the HTML targets, to force the output
directories.

[1] https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=a868421baf9c44227c43490687f8d6b8d6c95414

Change-Id: Ie147dc7b4a52eb2348005b8dc006a41b0784621f

gdb: Update gdbarch.py with latest changes in gdbarch.c

Commit 2b16913cdca2 ("gdb: make gdbarch_alloc take ownership of the tdep")
changed gdbarch.c without updating gdbarch.py.  As a result, running
gdbarch.py reverts those changes and causes the build to fail.

So change gdbarch.py to generate the current version of gdbarch.c.

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

Set _WIN32_WINNT in common.m4 configure check

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

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

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

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

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

[gdb/testsuite] Fix regexp in gdb.threads/dlopen-libpthread.exp

Fix regexp in gdb.threads/dlopen-libpthread.exp:
'libpthread\\.so' -> '/libpthread\\.so'.

Tested on x86_64-linux.

Fix XPASS weak symbols on x86_64-mingw32

Fixes commit 16fea92ccd99.

* testsuite/ld-scripts/weak.exp: Don't xfail x86_64 PE targets.
Do xfail other PE OS triplets by moving code setting xfails.

Fix a potential illegal memory access in the BFD library when parsing a corrupt DWARF file.

PR 29988
* dwarf2.c (read_indexed_address): Fix check for an out of range
offset.

[gdb/testsuite] Fix gdb.threads/dlopen-libpthread.exp for upstream glibc, again

On an x86_64 laptop running ubuntu 22.04.1 with unity desktop:
...
$ echo $XDG_CURRENT_DESKTOP
Unity:Unity7:ubuntu
...
I have:
...
$ echo $LD_PRELOAD
libgtk3-nocsd.so.0
...
due to package gtk3-nocsd, a package recommended by unity-session.

Consequently, for each exec these dependencies are pulled in, including
libpthread.so.0:
...
$ lddtree /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0
libgtk3-nocsd.so.0 => /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 (interpreter => none)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
        ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
...

So, while test-case gdb.threads/dlopen-libpthread.exp appears to run ok:
...
 # of expected passes 12
 # of unsupported tests 1
...
with LD_PRELOAD="" we have instead:
...
(gdb) PASS: gdb.threads/dlopen-libpthread.exp: continue to breakpoint: notify
info sharedlibrary^M
From  To                  Syms Read   Shared Object Library^M
$hex  $hex  Yes         /lib64/ld-linux-x86-64.so.2^M
$hex  $hex  Yes         /lib/x86_64-linux-gnu/libc.so.6^M
$hex  $hex  Yes         dlopen-libpthread.so^M
(gdb) FAIL: gdb.threads/dlopen-libpthread.exp: libpthread.so found
...

The problem is that libpthread is expected as dependency of
dlopen-libpthread.so, but it's missing:
...
$ lddtree dlopen-libpthread.so
dlopen-libpthread.so => ./dlopen-libpthread.so (interpreter => none)
    libc.so.6 => $outputs/gdb.threads/dlopen-libpthread/dlopen-libpthread.so.d/libc.so.6
        ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
...
due to having glibc 2.35, which has libpthread integrated into libc.

Fix this by:
- adding a proc has_dependency
- using [has_dependency $exec libpthread.so] as hint that libpthread
  may be preloaded
- using ![has_dependency $shlib libpthread.so] to detect that
  the libpthread.so dependency is missing.

Also add a missing return after untested "no matching probes".

Tested on x86_64-linux, with and without LD_PRELOAD="".

gas/RISC-V: adjust assembler for opcode table re-ordering

PR gas/29940

With the single-operand JAL entry now sitting ahead of the two-operand
one, the parsing of a two-operand insn would first try to parse an 'a'-
style operand, resulting in the insertion of bogus (and otherwise
unused) undefined symbols in the symbol table, having register names.
Since 'a' is used as 1st operand only with J and JAL, and since JAL is
the only insn _also_ allowing for a register as 1st operand (and then
there being a 2nd one), special case this parsing aspect right there.

Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>

Tidy some global bfd state used by gas

* subsegs.c (subsegs_end): Clear abs and und userdata.

now_seg after closing output file

now_seg, a pointer into the output file sections, isn't valid after
the output file is closed.  gas doesn't and shouldn't use now_seg
after this point of course, but let's be safe.

* output-file.c (output_file_close): Clear now_seg and now_subseg.

Automatic date update in version.in

Fix bug in 'say_where' transform

The patch to change say_where into a method introduced a bug.  This
patch fixes it.

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.