Sync toplevel files from binutils-gdbHEADtrunkmaster

commit 28ea7ae220a0343ff7fe531ec761bd77d00dcb1c
Author: Matthieu Longo <matthieu.longo@arm.com>
Date:   Tue May 28 10:49:45 2024 +0100

    autoupdate: replace old version of AC_INIT by the new one

    - old AC_INIT by AC_INIT + AC_CONFIG_SRC_DIR
      https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fINIT-3

commit 29496481662736f0a24bfc1daf31dbfc9d2bb7ee
Author: Matthieu Longo <matthieu.longo@arm.com>
Date:   Tue May 28 10:49:43 2024 +0100

    autoupdate: replace obsolete macros AC_CANONICAL_SYSTEM

    - AC_CANONICAL_SYSTEM by:
        * AC_CANONICAL_HOST where host, and host_alias are needed
        * AC_CANONICAL_TARGET where target_alias is needed
      https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fCANONICAL_005fTARGET-1

commit d9639e091c77689b10363ecb197466deaa161ade
Author: Maciej W. Rozycki <macro@redhat.com>
Date:   Mon Apr 28 18:53:30 2025 +0100

    Fix 64-bit BFD detection causing build failures

    We have a discrepancy with 64-bit BFD handling across our component
    subdirectories leading to link failures such as:

    ld: ../opcodes/.libs/libopcodes.a(disassemble.o): in function `disassembler': disassemble.c:(.text+0x65): undefined reference to `print_insn_alpha'
    ld: disassemble.c:(.text+0x105): undefined reference to `print_insn_ia64'
    ld: disassemble.c:(.text+0x11d): undefined reference to `print_insn_loongarch'
    ld: disassemble.c:(.text+0x1a1): undefined reference to `print_insn_big_mips'
    [...]

    with some configurations having a 32-bit host and 64-bit BFD, such as:
    `--host=i386-linux-gnu --target=riscv64-linux-gnu --enable-targets=all'.
    This is ultimately due to how 64-bit BFD is enabled for bfd/ itself and
    other subdirectorses and has been a regression from commit 1d5269c994bf
    ("unify 64-bit bfd checks").

    For bfd/ the BFD_64_BIT autoconf macro from config/bfd64.m4 is used
    combined with this logic in bfd/configure.ac:

    case ${host64}-${target64}-${want64} in
      *true*)
        wordsize=64
        bfd64_libs='$(BFD64_LIBS)'
        all_backends='$(BFD64_BACKENDS) $(BFD32_BACKENDS)'
        [...]
        ;;
      false-false-false)
        wordsize=32
        all_backends='$(BFD32_BACKENDS)'
        ;;
    esac

    where the value of ${wordsize} switches between 32-bit and 64-bit BFD
    via these pieces:

    #define BFD_ARCH_SIZE @wordsize@

    and:

    #if BFD_ARCH_SIZE >= 64
    #define BFD64
    #endif

    in bfd/bfd-in.h, which ultimately becomes a part of "bfd.h".

    Then ${host64} is determined in bfd/configure.ac from the host's word
    size, via the host's pointer size:

    if test "x${ac_cv_sizeof_void_p}" = "x8"; then
      host64=true
    fi

    And ${target64} is determined in bfd/configure.ac from the target's word
    size:

        if test ${target_size} = 64; then
            target64=true
        fi

    Where multiple targets have been requested with `--enable-targets=all'
    the presence of any 64-bit target will set "true" here.

    Finally ${want64} is set according to `--enable-64-bit-bfd' user option
    with an arrangement involving BFD_64_BIT:

    BFD_64_BIT
    if test $enable_64_bit_bfd = yes ; then
      want64=true
    else
      want64=false
    fi

    which also, redundantly, checks and sets its result upon the host's word
    size.  Lastly ${want64} is also selectively set by target fragments in
    bfd/config.bfd, which mostly if not completely overlaps with ${target64}
    setting as described above.

    Conversely other subdirectories only rely on BFD_64_BIT, so they fail to
    notice that BFD is 64-bit and do not enable their 64-bit handling where
    the host requested is 32-bit and 64-bit BFD has been enabled other than
    with `--enable-64-bit-bfd'.  One consequence is opcodes/disassemble.c
    enables calls to its numerous own 64-bit backends by checking the BFD64
    macro from "bfd.h", however does not actually enable said backends in
    its Makefile.  Hence the link errors quoted above.

    Address the problem then by moving the `--enable-64-bit-bfd' option back
    to bfd/configure.ac and remove the call to BFD_64_BIT from there and
    then rewrite the macro in terms of checking for the presence of BFD64
    macro in "bfd.h", which is the canonical way of determining whether BFD
    is 64-bit or not.

    Rather than running `grep' directly on ../bfd/bfd-in3.h as the opcodes/
    fragment used to before the problematic commit:

        if grep '#define BFD_ARCH_SIZE 64' ../bfd/bfd-in3.h > /dev/null; then

    run the preprocessor on "bfd.h", which allows to invoke the macro from
    configure.ac files placed in subdirectories located at deeper levels, by
    relying on the preprocessor's search path.

    This requires however that the invokers rely on `all-bfd' rather than
    `configure-bfd' for their `configure' invocation stage, because "bfd.h"
    is made by `make all' rather than `configure' in bfd/.

    Do not cache the result of this check however, as reconfiguring a tree
    such as to flip `--enable-64-bit-bfd' on or to change a secondary target
    may affect BFD64 and we have no access to information about secondary
    targets in BFD_64_BIT.

    Also remove the ENABLE_BFD_64_BIT automake conditional, as it's not used
    anywhere.

    Last but not least remove the hack from gdb/configure.ac to fail builds
    for `mips*-*-*' hosts where `--enable-targets=all' has been requested,
    but `--enable-64-bit-bfd' has not as it's no longer needed.  Such builds
    complete successfully now, having enabled 64-bit BFD implicitly.

    Tested-By: Guinevere Larsen <guinevere@redhat.com>
    Tested-By: Luis Machado <luis.machado@arm.com>
    Approved-By: Alan Modra <amodra@gmail.com>
    Approved-By: Luis Machado <luis.machado@arm.com>

	* Makefile.def: Synced from binutils-gdb.
	* Makefile.in: Regenerated.

commit 319719bb2921e978738acd408e6b16dabf0e7f5e
Author: Tom Tromey <tom@tromey.com>
Date:   Thu Mar 21 17:12:23 2024 -0600

    Revert "Pass GUILE down to subdirectories"

    This reverts commit b7e5a29602143b53267efcd9c8d5ecc78cd5a62f.

    This patch caused problems for some users when building gdb, because
    it would cause 'guild' to be invoked with the wrong versin of guile.
    On the whole it seems simpler to just back this out.

    I'm checking this in to the binutils-gdb repository in the interest of
    fixing the build for Andrew.  No one has responded to the identical
    patch sent to gcc-patches, but I will ping it there.

commit da48217f315084097ef25226c0acab3bbd55ebd3
Author: Simon Marchi <simon.marchi@efficios.com>
Date:   Thu Mar 14 13:39:18 2024 -0400

    gdbserver/linux: probe for libiconv in configure

    Make gdbserver's build system locate libiconv when building for Linux.

    Commit 07b3255c3bae ("Filter invalid encodings from Linux thread names")
    make libiconv madantory for building gdbserver on Linux.

    While trying to cross-compile gdb for xtensa-fsf-linux-uclibc (with a
    toolchain generated with crosstool-ng), I got:

        /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:48:10: fatal error: iconv.h: No such file or directory
           48 | #include <iconv.h>
              |          ^~~~~~~~~

    I downloaded GNU libiconv, built it for that host, and installed it in
    an arbitrary directory.  I had to modify the gdbserver build system to
    locate libiconv and use it, the result is this patch.

    I eventually found that crosstool-ng has a config option to make uclibc
    provide an implementation of iconv, which is of course much easier.  But
    given that this patch is now written, I think it would be worth merging
    it, it could help some people who do not have iconv built-in their libc
    in the future (and may not have the luxury of rebuilding their libc like
    I do).

    Using AM_ICONV in configure.ac adds these options for configure (the
    same we have for gdb):

        --with-libiconv-prefix[=DIR]  search for libiconv in DIR/include and DIR/lib
        --without-libiconv-prefix     don't search for libiconv in includedir and libdir
        --with-libiconv-type=TYPE     type of library to search for (auto/static/shared)

    It sets the `LIBICONV` variable with whatever is needed to link with
    libiconv, and adds the necessary `-I` flag to `CPPFLAGS`.

    To avoid unnecessarily linking against libiconv on hosts that don't need
    it, set `MAYBE_LIBICONV` with the contents of `LIBICONV` only if the
    host is Linux, and use `MAYBE_LIBICONV` in `Makefile.in`.

    Since libiconv is a hard requirement for Linux hosts, error out if it is
    not found.

    The bits in acinclude.m4 are similar to what we have in
    gdb/acinclude.m4.

    Update the top-level build system to support building against an in-tree
    libiconv (I did not test this part though).  Something tells me that the
    all-gdbserver dependency on all-libiconv is unnecessary, since there is
    already a dependency of configure-gdbserver on all-libiconv (and
    all-gdbserver surely depends on configure-gdbserver).  I just copied
    what's done for GDB though.

	* Makefile.def: Synced from binutils-gdb.
	* Makefile.tpl: Likewise.
	* configure.ac: Likewise.
	* Makefile.in: Regenerated.
	* configure: Likewise.

config/

	* acx.m4: Synced from binutils-gdb.
	* lthostflags.m4: Likewise.

libbacktrace/

	* configure.ac: Synced from binutils-gdb.
	* configure: Regenerated.

zlib/
	* configure.ac: Synced from binutils-gdb.
	* configure: Regenerated.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>

0 files changed, 0 insertions, 0 deletions