libctf: ctf-link outdated input check faulty

This check has a pair of faults which, combined, can lead to memory
corruption.  Firstly, it assumes that the values of the ctf_link_inputs
hash are ctf_dict_t's: they are not, they are ctf_link_input_t's, a much
shorter structure.  So the flags check which is the core of this is
faulty (but happens, by chance, to give the right output on most
architectures, since usually we happen to get a 0 here, so the test that
checks this usually passes).  Worse, the warning that is emitted when
the test fails is added to the wrong dict -- it's added to the input
dict, whose warning list is never consumed, rendering the whole check
useless.  But the dict it adds to is still the wrong type, so we end up
overwriting something deep in memory (or, much more likely,
dereferencing a garbage pointer and crashing).

Fixing both reveals another problem: the link input is an *archive*
consisting of multiple members, so we have to consider whether to check
all of them for the outdated-func-info thing we are checking here.
However, no compiler exists that emits a mixture of members with this
flag on and members with it off, and the linker always reserializes (and
upgrades) such things when it sees them: so all members in a given
archive must have the same value of the flag, so we only need to check
one member per input archive.

libctf/
PR libctf/29983
* ctf-link.c (ctf_link_warn_outdated_inputs): Get the types of
        members of ctf_link_inputs right, fixing a possible spurious
        tesst failure / wild pointer deref / overwrite.  Emit the
        warning message into the right dict.

libctf: skip the testsuite from inside dejagnu

The libctf testsuite uses Tcl try/catch to trap run_output errors.  This
is only supported in reasonably recent Tcls, so we detect the lack of
try/catch and suppress the testsuite via an Automake conditional in its
absence.

But this turns out not to work: Automake produces a check-DEJAGNU target
regardless of the value of this conditional and sticks it in an
unconditionally-executed part of the makefile, so the testsuite gets
executed anyway, and fails with a nasty-looking syntax error.  We can't
disable it by taking "dejagnu" out of AUTOMAKE_OPTIONS, because if you
do that Automake stops you using RUNTEST, RUNTESTFLAGS and other
variables users would expect to work.

So move to disabling the testsuite from inside the testsuite itself,
importing the value of the former Automake conditional as a Tcl variable
and exiting very early in default.exp if it's false.

* configure.ac (TCL_TRY): No longer an Automake conditional.
Rename to...
(HAVE_TCL_TRY): ... this.
* Makefile.am: Drop TCL_TRY.
(development.exp): Set have_tcl_try.
* testsuite/config/default.exp: Exit if have_tcl_try is false.

* configure: Regenerated.
* Makefile.in: Likewise.

ctf: fix various dreadful typos in the ctf_archive format comments

When defining a format it helps to a) get the endianness right when you
explicitly state what it is and b) define things in terms of fields that
exist rather than fields that don't.

(A bunch of changes of names during implementation were not reflected in
these comments...)

Thanks to Jose "Eye of the Eagle" Marchesi for spotting these.

include/
* ctf.h (struct ctf_archive) [ctfa_ctfs]: The size element of
this is in little-endian byte order, not network byte order.
(struct ctf_archive_modent): This is positioned right after the
end fo the struct ctf_archive, not at the offset of a
nonexistent field.  The number of elements in the array depends
on ctfa_ndicts, not another nonexistent field.

Ensure that libbacktrace/allocfail.sh is not deleted when creating release tarballs.

        * Makefile.am (CLEANFILES): Import patch from upstream to prevent
        allocafail.sh from being removed when running 'make clean'.

Use __func__ rather than __FUNCTION__

We already use C99's __func__ in places, use it more generally.  This
patch doesn't change uses in the testsuite.  I've also left one in
gold.h that is protected by GCC_VERSION < 4003.  If any of the
remaining uses bothers anyone I invite patches.

bfd/
* bfd-in.h: Replace __FUNCTION__ with __func__.
* elf32-bfin.c: Likewise.
* elfnn-aarch64.c: Likewise.
* elfxx-sparc.c: Likewise.
* bfd-in2.h: Regenerate.
gas/
* config/tc-cris.c: Replace __FUNCTION__ with __func__.
* config/tc-m68hc11.c: Likewise.
* config/tc-msp430.c: Likewise.
gold/
* dwp.h: Replace __FUNCTION__ with __func__.
* gold.h: Likewise, except for use inside GCC_VERSION < 4003.
ld/
* emultempl/pe.em: Replace __FUNCTION__ with __func__.
* emultempl/pep.em: Likewise.
* pe-dll.c: Likewise.

Remove myself as hppa32 maintainer

Reflects the reality that I haven't done much on hppa32 for years.

sim: build: drop subdir Makefile.in files

These aren't used anymore, so punt them all.

Automatic date update in version.in

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.