aboutsummaryrefslogtreecommitdiff
path: root/opcodes/configure
AgeCommit message (Collapse)AuthorFilesLines
2024-11-26nios2: Remove binutils support for Nios II target.Sandra Loosemore1-1/+0
The Nios II architecture has been EOL'ed by the vendor. This patch removes all binutils, bfd, gas, binutils, and opcodes support for this target with the exception of the readelf utility. (The ELF EM_* number remains valid and the relocation definitions from the Nios II ABI will never change in future, so retaining the readelf support seems consistent with its purpose as a utility that tries to parse the headers in any ELF file provided as an argument regardless of target.)
2024-07-20Change version to 2.43.50Nick Clifton1-10/+10
2024-06-20Revert "Remove LIBINTL_DEP"Alan Modra1-2/+6
This reverts commit e874cbd3879843a83e4bcc4b54cd7107387b1df6. The patch was wrong. LIBINTL_DEP is needed with an in-tree gettext.
2024-06-20Remove LIBINTL_DEPAlan Modra1-6/+2
The intl directory in the source no longer exists. LIBINTL_DEP is thus always empty. Remove references to it. config/ * gettext-sister.m4: Don't AC_SUBST LIBINTL_DEP. bfd/ * Makefile.in: Regenerate. * configure: Regenerate. binutils/ * Makefile.am (*_DEPENDENCIES): Remove LIBINTL_DEP. * Makefile.in: Regenerate. * configure: Regenerate. gas/ * Makefile.am (as_new_DEPENDENCIES): Remove LIBINTL_DEP. * Makefile.in: Regenerate. * configure: Regenerate. gdb/ * Makefile.in (INTL_DEPS): Don't set or reference. * configure: Regenerate. gdbserver/ * Makefile.in (INTL_DEPS): Don't set or reference. gdbsupport/ * Makefile.in: Regenerate. * configure: Regenerate. gold/ * Makefile.am (deps_var): Remove LIBINTL_DEP. (incremental_dump_DEPENDENCIES, dwp_DEPENDENCIES): Likewise. * Makefile.in: Regenerate. * configure: Regenerate. * testsuite/Makefile.am (DEPENDENCIES): Remove LIBINTL_DEP. * testsuite/Makefile.in: Regenerate. gprof/ * Makefile.am (gprof_DEPENDENCIES): Remove LIBINTL_DEP. * Makefile.in: Regenerate. * configure: Regenerate. ld/ * Makefile.am (ld_new_DEPENDENCIES): Remove LIBINTL_DEP. * Makefile.in: Regenerate. * configure: Regenerate. libctf/ * Makefile.in: Regenerate. * configure: Regenerate. opcodes/ * configure.ac (BUILD_LIBS): Remove LIBINTL. (BUILD_LIB_DEPS): Remove LIBINTL_DEP. * Makefile.in: Regenerate. * configure: Regenerate.
2024-06-10autoupdate: regen after replacing obsolete macrosMatthieu Longo1-4/+2
2024-01-15Change version to 2.42.50 and regenerate filesNick Clifton1-10/+10
2023-11-15Finalized intl-update patchesArsen Arsenovi?1-49/+2060
* intl: Remove directory. Replaced with out-of-tree GNU gettext. * .gitignore: Add '/gettext*'. * configure.ac (host_libs): Replace intl with gettext. (hbaseargs, bbaseargs, baseargs): Split baseargs into {h,b}baseargs. (skip_barg): New flag. Skips appending current flag to bbaseargs. <library exemptions>: Exempt --with-libintl-{type,prefix} from target and build machine argument passing. * configure: Regenerate. * Makefile.def (host_modules): Replace intl module with gettext module. (configure-ld): Depend on configure-gettext. * Makefile.in: Regenerate. * src-release.sh: Remove references to the intl/ directory.
2023-09-25Revert "arc: Add new opcode functions for ARCv3 ISA."Claudiu Zissulescu1-1/+0
This reverts commit c99dc76089a2de97ea0ee755aa8e87037a17b6d6.
2023-09-25arc: Add new opcode functions for ARCv3 ISA.Claudiu Zissulescu1-0/+1
opcodes/ xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com> Cupertino Miranda <cmiranda@synopsys.com> * opcodes/Makefile.am: Add ARC64 opcode file. * opcodes/Makefile.in: Regenerate. * opcodes/arc-opc.c: Move the common functionality to arcxx-opc.inc. Keep only ARCv2 ARCv1 specifics. * opcodes/arc-ext-tbl.h: Deleted file. * opcodes/arcxx-opc.inc: New file. * opcodes/arc64-opc.c: Likewise. * opcodes/arc-fxi.h (insert_uimm9_a32_11_s): New function. (extract_uimm9_a32_11_s): Likewise. (insert_uimm10_13_s): Likewise. (extract_uimm10_13_s): Likewise. * opcodes/configure: Regenerate. * opcodes/configure.ac: Add ARC64 target. * opcodes/disassemble.c: Likewise. * opcodes/arc-dis.c (regmod_t): New type. (regmods): New structure. (fpnames): New strings with fp-regs name. (REG_PCL, REG_LIMM, REG_LIMM_S, REG_U32, REG_S32): New defines. (getregname): New function. (find_format_from_table): Discriminate between signed and unsigned 32bit immediates. (find_format): Handle extract function for flags. (arc_insn_length): Update insn lengths to various architectures. (print_insn_arc): Update printing for various ARC architectures. * opcodes/arc-flag-classes.def: New file. * opcodes/arc-flag.def: New file. * opcodes/arc-operands.def: New file. * opcodes/arc-regs.h: Changed. Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>
2023-08-19sim --enable-cgen-maintAlan Modra1-1/+4
I had reason yesterday to want to regenerate configury files which I do with --enable-maintainer-mode, and added --enable-cgen-maint accidentally. The first problem I hit is that sim looks for cgen in a different directory by default than opcodes, and I had my source layout set up for opcodes rather than sim. Fix that by making both use ../cgen first, then ../../cgen relative to sim/ and opcodes/. The next problem was that various sim local.mk files expected generated sources in the build dir rather than the source dir. Fix that by adding $(srcdir) to paths. Finally, the generated iq2000 files had a compile error, fixed by the cpu/iq2000.cpu patch. cpu/ * iq2000.cpu (syscall): Add pc arg. opcodes/ * configure.ac (cgendir): Default to ../../cgen, but use ../cgen if found there. * configure: Regenerate. sim/m4/ * sim_ac_option_cgen_maint.m4 (cgendir): Look in ../cgen too. sim/ * cris/local.mk: Add $(srcdir) to paths for regenerated source. * frv/local.mk: Likewise. * iq2000/local.mk: Likewise. * lm32/local.mk: Likewise. * m32r/local.mk: Likewise. * or1k/local.mk: Likewise. * Makefile.in: Regenerate. * configure: Regenerate.
2023-08-16kvx: New port.Paul Iannetta1-0/+1
2023-08-12regen configAlan Modra1-21/+52
This regenerates config files changed by the previous 44 commits. Note that subject lines in these commits mostly match the gcc git originating commit.
2023-08-02Revert "2.41 Release sources"Sam James1-11/+11
This reverts commit 675b9d612cc59446e84e2c6d89b45500cb603a8d. See https://sourceware.org/pipermail/binutils/2023-August/128761.html.
2023-08-022.41 Release sourcesbinutils-2_41-releaseNick Clifton1-11/+11
2023-07-21DesCGENization of the BPF binutils portJose E. Marchesi1-1/+1
CGEN is cool, but the BPF architecture is simply too bizarre for it. The weird way of BPF to handle endianness in instruction encoding, the weird C-like alternative assembly syntax, the weird abuse of multi-byte (or infra-byte) instruction fields as opcodes, the unusual presence of opcodes beyond the first 32-bits of some instructions, are all examples of what makes it a PITA to continue using CGEN for this port. The bpf.cpu file is becoming so complex and so nested with p-macros that it is very difficult to read, and quite challenging to update. Also, every time we are forced to change something in CGEN to accommodate BPF requirements (which is often) we have to do extensive testing to make sure we do not break any other target using CGEN. This is getting un-maintenable. So I have decided to bite the bullet and revamp/rewrite the port so it no longer uses CGEN. Overall, this involved: * To remove the cpu/bpf.{cpu,opc} descriptions. * To remove the CGEN generated files. * To replace the CGEN generated opcodes table with a new hand-written opcodes table for BPF. * To replace the CGEN generated disassembler wih a new disassembler that uses the new opcodes. * To replace the CGEN generated assembler with a new assembler that uses the new opcodes. * To replace the CGEN generated simulator with a new simulator that uses the new opcodes. [This is pushed in GDB in another patch.] * To adapt the build systems to the new situation. Additionally, this patch introduces some extensions and improvements: * A new BPF relocation BPF_RELOC_BPF_DISP16 plus corresponding ELF relocation R_BPF_GNU_64_16 are added to the BPF BFD port. These relocations are used for section-relative 16-bit offsets used in load/store instructions. * The disassembler now has support for the "pseudo-c" assembly syntax of BPF. What dialect to use when disassembling is controlled by a command line option. * The disassembler now has support for dumping instruction immediates in either octal, hexadecimal or decimal. The used output base is controlled by a new command-line option. * The GAS BPF test suite has been re-structured and expanded in order to test the disassembler pseudoc syntax support. Minor bugs have been also fixed there. The assembler generic tests that were disabled for bpf-*-* targets due to the previous implementation of pseudoc syntax are now re-enabled. Additional tests have been added to test the new features of the assembler. .dump files are no longer used. * The linker BPF test suite has been adapted to the command line options used by the new disassembler. The result is very satisfactory. This patchs adds 3448 lines of code and removes 10542 lines of code. Tested in: * Target bpf-unknown-none with 64-bit little-endian host and 32-bit little-endian host. * Target x86-64-linux-gnu with --enable-targets=all Note that I have not tested in a big-endian host yet. I will do so once this lands upstream so I can use the GCC compiler farm. I have not included ChangeLog entries in this patch: these would be massive and not very useful, considering this is pretty much a rewrite of the port. I beg the indulgence of the global maintainers.
2023-07-03Change version number to 2.41.50 and regenerate filesNick Clifton1-10/+10
2022-12-31Update version number and regenerate filesNick Clifton1-10/+10
2022-12-12x86: remove i386-opc.cJan Beulich1-1/+1
Remove the now empty i386-opc.c. To compensate, tie table generation in opcodes/ to the building of i386-dis.o, despite the file not really depending on the generated data.
2022-09-14bfd: Stop using -Wstack-usage=262144 when built with ClangTsukasa OI1-0/+18
Some components of GNU Binutils will pass "-Wstack-usage=262144" when "GCC >= 5.0" is detected. However, Clang does not support "-Wstack-usage", despite that related configuration part in bfd/warning.m4 handles the latest Clang (15.0.0 as of this writing) as "GCC >= 5.0". The option "-Wstack-usage" was ignored when the first version of Clang is released but even this "ignoring" behavior is removed before Clang 4.0.0. So, if we give Clang "-Wstack-usage=262144", it generates a warning, making the build failure. This commit checks "__clang__" macro to prevent adding the option if the compiler is identified as Clang. bfd/ChangeLog: * warning.m4: Stop appending "-Wstack-usage=262144" option when compiled with Clang. * configure: Regenerate. binutils/ChangeLog: * configure: Regenerate. gas/ChangeLog: * configure: Regenerate. gold/ChangeLog: * configure: Regenerate. gprof/ChangeLog: * configure: Regenerate. ld/ChangeLog: * configure: Regenerate. opcodes/ChangeLog: * configure: Regenerate.
2022-07-09Regenerate with automake-1.15.1Alan Modra1-118/+103
Until we update the recommended versions of autoconf/automake, files should be regenerated with automake-1.15.1 and autoconf-2.69. That's not because we think those versions are golden, and newer versions are bad. It's simply because maintainers want to be able to update configury files without trouble, and if someone regenerates files with automake-1.16.5 then --enable-maintainer-mode builds will hit errors: checking that generated files are newer than configure... configure.ac:26: error: version mismatch. This is Automake 1.15.1, configure.ac:26: but the definition used by this AM_INIT_AUTOMAKE configure.ac:26: comes from Automake 1.16.5. You should recreate configure.ac:26: aclocal.m4 with aclocal and run automake again. WARNING: 'automake-1.15' is probably too old. Correcting this requires regenerating the files by hand.
2022-07-08Update version to 2.39.50 and regenerate filesNick Clifton1-113/+128
2022-06-27drop XC16x bitsJan Beulich1-1/+0
Commit 04f096fb9e25 ("Move the xc16x target to the obsolete list") moved the architecture from the "obsolete but still available" to the "obsolete / support removed" list in config.bfd, making the architecture impossible to enable (except maybe via "enable everything" options"). Note that I didn't touch */po/*.po{,t} on the assumption that these would be updated by some (half)automatic means.
2022-03-31x86: Remove bfd_arch_l1om and bfd_arch_k1omH.J. Lu1-1/+1
Remove bfd_arch_l1om and bfd_arch_k1om since L1OM/K1OM support has been removed from gas, ld and opcodes. bfd/ * Makefile.am (ALL_MACHINES): Remove cpu-l1om.lo and cpu-k1om.lo. (ALL_MACHINES_CFILES): Remove cpu-l1om.c and cpu-k1om.c. * archures.c (bfd_mach_l1om): Removed. (bfd_mach_l1om_intel_syntax): Likewise. (bfd_mach_k1om): Likewise. (bfd_mach_k1om_intel_syntax): Likewise. (bfd_k1om_arch): Likewise. (bfd_l1om_arch): Likewise. (bfd_archures_list): Remove bfd_k1om_arch and bfd_l1om_arch references. * config.bfd (targ_selvecs): Remove l1om_elf64_vec. l1om_elf64_fbsd_vec, k1om_elf64_vec and k1om_elf64_fbsd_vec. (targ_archs): Remove bfd_l1om_arch and bfd_k1om_arch. * configure.ac (k1om_elf64_vec): Removed. (k1om_elf64_fbsd_vec): Likewise. (l1om_elf64_vec): Likewise. (l1om_elf64_fbsd_vec): Likewise. * cpu-k1om.c: Removed. * cpu-l1om.c: Likewise. * elf64-x86-64.c (elf64_l1om_elf_object_p): Removed. (elf64_k1om_elf_object_p): Likewise. (l1om_elf64_vec): Removed. (l1om_elf64_fbsd_vec): Likewise. (k1om_elf64_vec): Likewise. (k1om_elf64_fbsd_vec): Likewise. (ELF_TARGET_OS): Undefine. * targets.c (_bfd_target_vector): Remove k1om_elf64_vec, k1om_elf64_fbsd_vec, l1om_elf64_vec and l1om_elf64_fbsd_vec. * Makefile.in: Regenerate. * bfd-in2.h: Likewise. * configure: Likewise. opcodes/ * configure.ac: Remove bfd_arch_l1om/bfd_arch_k1om references. * disassemble.c (disassembler): Likewise. * configure: Regenerate.
2022-03-25libtool.m4: fix the NM="/nm/over/here -B/option/with/path" caseNick Alcock1-7/+13
My previous nm patch handled all cases but one -- if the user set NM in the environment to a path which contained an option, libtool's nm detection tries to run nm against a copy of nm with the options in it: e.g. if NM was set to "nm --blargle", and nm was found in /usr/bin, the test would try to run "/usr/bin/nm --blargle /usr/bin/nm --blargle". This is unlikely to be desirable: in this case we should run "/usr/bin/nm --blargle /usr/bin/nm". Furthermore, as part of this nm has to detect when the passed-in $NM contains a path, and in that case avoid doing a path search itself. This too was thrown off if an option contained something that looked like a path, e.g. NM="nm -B../prev-gcc"; libtool then tries to run "nm -B../prev-gcc nm" which rarely works well (and indeed it looks to see whether that nm exists, finds it doesn't, and wrongly concludes that nm -p or whatever does not work). Fix all of these by clipping all options (defined as everything including and after the first " -") before deciding whether nm contains a path (but not using the clipped value for anything else), and then removing all options from the path-modified nm before looking to see whether that nm existed. NM=my-nm now does a path search and runs e.g. /usr/bin/my-nm -B /usr/bin/my-nm NM=/usr/bin/my-nm now avoids a path search and runs e.g. /usr/bin/my-nm -B /usr/bin/my-nm NM="my-nm -p../wombat" now does a path search and runs e.g. /usr/bin/my-nm -p../wombat -B /usr/bin/my-nm NM="../prev-binutils/new-nm -B../prev-gcc" now avoids a path search: ../prev-binutils/my-nm -B../prev-gcc -B ../prev-binutils/my-nm This seems to be all combinations, including those used by GCC bootstrap (which, before this commit, fails to bootstrap when configured --with-build-config=bootstrap-lto, because the lto plugin is now using --export-symbols-regex, which requires libtool to find a working nm, while also using -B../prev-gcc to point at the lto plugin associated with the GCC just built.) Regenerate all affected configure scripts. * libtool.m4 (LT_PATH_NM): Handle user-specified NM with options, including options containing paths.
2022-03-16opcodes: handle bfd_amdgcn_arch in configure scriptSimon Marchi1-0/+1
There isn't an actual opcodes implementation for the AMDGCN arch (yet), this is just the bare minimum to get $ ./configure --target=amdgcn-hsa-amdhsa --disable-gas $ make all-binutils working later in this series. opcodes/ChangeLog: * configure.ac: Handle bfd_amdgcn_arch. * configure: Re-generate. Change-Id: Ib7d7c5533a803ed8b2a293e9275f667ed781ce79
2022-01-23Regenerate configure files with autoconf 2.69H.J. Lu1-15/+3
Regenerate configure files with the unmodified autoconf 2.69 to remove --runstatedir=DIR modifiable per-process data [LOCALSTATEDIR/run] bfd/ * configure: Regenerate. binutils/ * configure: Regenerate. gas/ * configure: Regenerate. gold/ * configure: Regenerate. gprof/ * configure: Regenerate. ld/ * configure: Regenerate. opcodes/ * configure: Regenerate.
2022-01-22Change version number to 2.38.50 and regenerate filesNick Clifton1-13/+25
2022-01-01unify 64-bit bfd checksMike Frysinger1-3/+258
Move the 64-bit bfd logic out of bfd/configure.ac and into bfd64.m4 under config so it can be shared between all the other subdirs. This replaces want64 with enable_64_bit_bfd which was already being declared, but not used directly.
2021-11-29opcodes: enable silent build rulesMike Frysinger1-2/+41
Also add $(AM_V_xxx) to various manual rules in here.
2021-11-12Don't compile some opcodes files when bfd is 32-bit onlyAlan Modra1-1/+5
* Makefile.am (TARGET_LIBOPCODES_CFILES): Split into.. (TARGET64_LIBOPCODES_CFILES): ..this and.. (TARGET32_LIBOPCODES_CFILES): ..this. (ALL_MACHINES): Likewise split to (ALL64_MACHINES, ALL32_MACHINES): ..this. * disassemble.c: Define some ARCH_* when ARCH_all only if BFD64. * configure.ac (BFD_MACHINES): Defined depending on BFD_ARCH_SIZE. * Makefile.in: Regenerate. * configure: Regenerate.
2021-10-27opcodes: Fix RPATH not being set for dynamic libbfd dependencyMaciej W. Rozycki1-12/+1
If built as a shared library, libopcodes has a load-time dependency on libbfd, which is recorded in the dynamic section, however without a corresponding RPATH entry for the directory to find libbfd in. This causes loading to fail whenever libbfd is only pulled by libopcodes indirectly and libbfd has been installed in a directory that is not in the dynamic loader's search path. It does not happen with the programs included with binutils or GDB, because they all also pull libbfd when using libopcodes, but it can happen with external software, e.g.: $ gdbserver --help gdbserver: error while loading shared libraries: libbfd-[...].so: cannot open shared object file: No such file or directory $ (not our `gdbserver'). Indirect dynamic dependencies are handled by libtool automatically by adding RPATH entries as required, however our setup for libopcodes prevents this from happening by linking in libbfd with an explicit file reference sneaked through to the linker directly behind libtool's back via the `-Wl' linker command-line option rather than via `-l' combined with a suitable library search path specified via `-L', as it would be usually the case, or just referring to the relevant .la file in a fully libtool-enabled configuration such as ours. According to an observation in the discussion back in 2007[1][2][3] that has led to the current arrangement it is to prevent libtool from picking up the wrong version of libbfd. It does not appear to be needed though, not at least with our current libtool incarnation, as directly referring `libbfd.la' does exactly what it should, as previously suggested[4], and with no link-time reference to the installation directory other than to set RPATH. Uninstalled version of libopcodes has libbfd's build-time location prepended to RPATH too, as also expected. Use a direct reference to `libbfd.la' then, making the load error quoted above go away. Alternatively `-L' and `-l' could be used to the same effect, but it seems an unnecessary complication and just another way to circumvent rather than making use of libtool. References: [1] "compile failure due to undefined symbol", <https://sourceware.org/ml/binutils/2007-08/msg00476.html> [2] same, <https://sourceware.org/ml/binutils/2007-09/msg00000.html> [3] same, <https://sourceware.org/ml/binutils/2007-10/msg00019.html> [4] same, <https://sourceware.org/ml/binutils/2007-10/msg00034.html> opcodes/ * Makefile.am: Remove obsolete comment. * configure.ac: Refer `libbfd.la' to link shared BFD library except for Cygwin. * Makefile.in: Regenerate. * configure: Regenerate.
2021-10-24LoongArch opcodes supportliuzhensong1-0/+1
2021-10-22 Chenghua Xu <xuchenghua@loongson.cn> Zhensong Liu <liuzhensong@loongson.cn> Weinan Liu <liuweinan@loongson.cn> include/ * opcode/loongarch.h: New. * dis-asm.h: Declare print_loongarch_disassembler_options. opcodes/ * Makefile.am: Add LoongArch. * configure.ac: Likewise. * disassemble.c: Likewise. * disassemble.h: Declare print_insn_loongarch. * loongarch-coder.c: New. * loongarch-dis.c: New. * loongarch-opc.c: New. * Makefile.in: Regenerate. * configure: Regenerate. * po/POTFILES.in: Regenerate.
2021-09-27configure: regenerate in all projects that use libtool.m4Nick Alcock1-45/+46
(including sim/, which has no changelog.) bfd/ChangeLog 2021-09-27 Nick Alcock <nick.alcock@oracle.com> * configure: Regenerate. binutils/ChangeLog 2021-09-27 Nick Alcock <nick.alcock@oracle.com> * configure: Regenerate. gas/ChangeLog 2021-09-27 Nick Alcock <nick.alcock@oracle.com> * configure: Regenerate. gprof/ChangeLog 2021-09-27 Nick Alcock <nick.alcock@oracle.com> * configure: Regenerate. ld/ChangeLog 2021-09-27 Nick Alcock <nick.alcock@oracle.com> * configure: Regenerate. libctf/ChangeLog 2021-09-27 Nick Alcock <nick.alcock@oracle.com> * configure: Regenerate. * Makefile.in: Regenerate. opcodes/ChangeLog 2021-09-27 Nick Alcock <nick.alcock@oracle.com> * configure: Regenerate. zlib/ChangeLog 2021-09-27 Nick Alcock <nick.alcock@oracle.com> * configure: Regenerate.
2021-09-02Add support for the haiku operating system. These are the os support ↵Alexander von Gluck IV1-1/+1
patches we have been grooming and maintaining for quite a few years over on git.haiku-os.org. All of these architectures are working and most have been stable for quite some time.
2021-07-03Update version number and regenerate filesNick Clifton1-10/+10
2021-05-24opcodes: cris: move desc & opc files from sim/Mike Frysinger1-1/+1
All other cgen ports keep their generated desc & opc files under opcodes/, so move the cris files over too. The cris-opc.c file, while not generated, is already here to complement.
2021-04-13ENABLE_CHECKING in bfd, opcodes, binutils, ldAlan Modra1-2/+20
gas already has this. Here it enables checking hash table type passed to elf_link_hash_lookup and elf_link_hash_traverse. bfd/ * elf-bfd.h (ENABLE_CHECKING): Define. (elf_link_hash_lookup): Abort if wrong type of hash table. (elf_link_hash_traverse): Likewise. * configure.ac (--enable-checking): Add support. * config.in: Regenerate. * configure: Regenerate. binutils/ * configure.ac (--enable-checking): Add support. * config.in: Regenerate. * configure: Regenerate. ld/ * configure.ac (--enable-checking): Add support. * config.in: Regenerate. * configure: Regenerate. opcodes/ * configure.ac (--enable-checking): Add support. * config.in: Regenerate. * configure: Regenerate.
2021-04-05C99 opcodes configuryAlan Modra1-1215/+515
* configure.ac: Don't check for limits.h, string.h, strings.h or stdlib.h. (AC_ISC_POSIX): Don't invoke. * sysdep.h: Include stdlib.h and string.h unconditionally. * i386-opc.h: Include limits.h unconditionally. * wasm32-dis.c: Likewise. * cgen-opc.c: Don't include alloca-conf.h. * config.in: Regenerate. * configure: Regenerate.
2021-02-10bfd, opcodes, libctf: support --with-included-gettextNick Alcock1-1/+7
Right now, these libraries hardwire -L../intl -lintl on a few fixed platforms, which works fine on those platforms but on other platforms leads to shared libraries that lack libintl_* symbols when configured --with-included-gettext, and/or static libraries that contain libintl as *another* static library. If we instead use the LIBINTL variable defined in ../intl/config.intl, this gives us the right thing on all three classes of platform (gettext in libc, gettext in system libintl, gettext in ../intl/libintl.a).. This also means we can rip out some Darwin-specific machinery from configure.ac and also simplify the Cygwin side. This also means that the libctf testsuite (and other places that include libbfd, libopcodes or libctf) don't need to grow libintl dependencies just on account of those libraries (though they still need such dependencies if they themselves use gettext machinery). bfd/ChangeLog 2021-02-03 Nick Alcock <nick.alcock@oracle.com> * configure.ac (SHARED_LIBADD): Remove explicit -lintl population in favour of LIBINTL. * configure: Regenerated. libctf/ChangeLog 2021-02-02 Nick Alcock <nick.alcock@oracle.com> * configure.ac (CTF_LIBADD): Remove explicit -lintl population in favour of LIBINTL. * Makefile.am (libctf_nobfd_la_LIBADD): No longer explicitly include $(LIBINTL). (check-DEJAGNU): Pass down to tests as well. * configure: Regenerated. * Makefile.in: Likewise. opcodes/ChangeLog 2021-02-04 Nick Alcock <nick.alcock@oracle.com> * configure.ac (SHARED_LIBADD): Remove explicit -lintl population in favour of LIBINTL. * configure: Regenerated.
2021-01-12Implement a workaround for GNU mak jobserverH.J. Lu1-0/+18
Compiling binutils using -flto=jobserver with GCC 11 leads to libtool: link: gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Wwrite-strings -I../../gas/../zlib -g -O2 -fprofile-generate -flto=jobserver -o as-new app.o as.o atof-generic.o compress-debug.o cond.o depend.o dwarf2dbg.o dw2gencfi.o ecoff.o ehopt.o expr.o flonum-copy.o flonum-konst.o flonum-mult.o frags.o hash.o input-file.o input-scrub.o listing.o literal.o macro.o messages.o output-file.o read.o remap.o sb.o stabs.o subsegs.o symbols.o write.o config/tc-i386.o config/obj-elf.o config/atof-ieee.o ../opcodes/.libs/libopcodes.a ../bfd/.libs/libbfd.a -L/tmp/binutils-gdb/objdir/zlib -lz ../libiberty/libiberty.a -ldl lto-wrapper: warning: jobserver is not available: '--jobserver-auth=' is not present in 'MAKEFLAGS' since the '+' is missing on the recipe line in Makefiles generated by automake. Add the '+' to the recipe line by hand. bfd/ PR binutils/26792 * configure.ac: Use GNU_MAKE_JOBSERVER. * aclocal.m4: Regenerated. * configure: Likewise. binutils/ PR binutils/26792 * configure.ac: Use GNU_MAKE_JOBSERVER. * aclocal.m4: Regenerated. * configure: Likewise. config/ PR binutils/26792 * jobserver.m4: New file. gas/ PR binutils/26792 * configure.ac: Use GNU_MAKE_JOBSERVER. * aclocal.m4: Regenerated. * configure: Likewise. gprof/ PR binutils/26792 * configure.ac: Use GNU_MAKE_JOBSERVER. * aclocal.m4: Regenerated. * configure: Likewise. ld/ PR binutils/26792 * configure.ac: Use GNU_MAKE_JOBSERVER. * aclocal.m4: Regenerated. * configure: Likewise. libctf/ PR binutils/26792 * configure.ac: Use GNU_MAKE_JOBSERVER. * aclocal.m4: Regenerated. * configure: Likewise. opcodes/ PR binutils/26792 * configure.ac: Use GNU_MAKE_JOBSERVER. * aclocal.m4: Regenerated. * configure: Likewise.
2021-01-11Binutils: Check if AR works with --plugin and rcH.J. Lu1-3/+11
Check if AR works with --plugin and rc before passing --plugin to AR and RANLIB. bfd/ PR ld/27173 binutils/ PR ld/27173 * configure: Regenerated. gas/ PR ld/27173 * configure: Regenerated. gprof/ PR ld/27173 * configure: Regenerated. ld/ PR ld/27173 * configure: Regenerated. libctf/ PR ld/27173 * configure: Regenerated. opcodes/ PR ld/27173 * configure: Regenerated.
2021-01-09Binutils: Pass --plugin to AR and RANLIBH.J. Lu1-2/+25
Detect GCC LTO plugin. Pass --plugin to AR and RANLIB to support LTO build. bfd/ * configure: Regenerated. binutils/ * configure: Regenerated. gas/ * configure: Regenerated. gprof/ * configure: Regenerated. ld/ * configure: Regenerated. libctf/ * configure: Regenerated. opcodes/ * configure: Regenerated.
2021-01-09Change version number to 2.36.50 and regenerate filesNick Clifton1-10/+10
2021-01-09configure regenAlan Modra1-2/+2
commit f478212851 did the regen by hand, missed a change in ld/configure and didn't update line numbers. Fix that, and an old regen of ld/Makefile.in with the wrong automake. bfd/ * configure: Regenerate. binutils/ * configure: Regenerate. gas/ * configure: Regenerate. gprof/ * configure: Regenerate. ld/ * Makefile.in: Regenerate. * configure: Regenerate. libctf/ * configure: Regenerate. opcodes/ * configure: Regenerate. zlib/ * configure: Regenerate.
2021-01-07libtool.m4: update GNU/Hurd test from upstream. In upstream libtool, ↵Samuel Thibault1-11/+1
47a889a4ca20 ("Improve GNU/Hurd support.") fixed detection of shlibpath_overrides_runpath, thus avoiding unnecessary relink. This backports it. . * libtool.m4: Match gnu* along other GNU systems. */ChangeLog: * configure: Re-generate.
2020-07-04Update version to 2.35.50 and regenerate filesNick Clifton1-10/+10
2020-01-18Update version to 2.34.50. Regenerate configure and .pot files.Nick Clifton1-10/+10
2019-12-17Remove tic80 supportAlan Modra1-1/+0
This is one way of fixing ubsan bug reports, just delete the code. The assembler support was removed back in 2005 along with other non-BFD assemblers, but somehow the remainder of the port stayed in. bfd/ * coff-tic80.c: Delete file. * cpu-tic80.c: Delete file. * archures.c: Remove tic80 support. * coffcode.h: Likewise. * coffswap.h: Likewise. * targets.c: Likewise. * config.bfd: Likewise. * configure.ac: Likewise. * Makefile.am: Likewise. * Makefile.in: Regenerate. * bfd-in2.h: Regenerate. * configure: Regenerate. * po/SRC-POTFILES.in: Regenerate. binutils/ * testsuite/binutils-all/objcopy.exp: Remove tic80 support. * testsuite/binutils-all/objdump.exp: Likewise. gas/ * doc/as.texi: Remove mention of tic80. include/ * coff/tic80.h: Delete file. * opcode/tic80.h: Delete file. ld/ * emulparams/tic80coff.sh: Delete file. * scripttempl/tic80coff.sc: Delete file. * configure.tgt: Remove tic80 support. * Makefile.am: Likewise. * Makefile.in: Regenerate. * po/BLD-POTFILES.in: Regenerate. opcodes/ * tic80-dis.c: Delete file. * tic80-opc.c: Delete file. * disassemble.c: Remove tic80 support. * disassemble.h: Likewise. * Makefile.am: Likewise. * configure.ac: Likewise. * Makefile.in: Regenerate. * configure: Regenerate. * po/POTFILES.in: Regenerate.
2019-09-18Re-generate many configure and Makefile.in filesSimon Marchi1-15/+3
I get some spurious changes when running autoconf/automake for various projects in the tree. This is likely because they were generated using distro-patched tools last time. I ran `autoreconf -f` in the various automake projects of the binutils-gdb tree, and this is the result. The tools I am using have been compiled from source, from the upstream release. bfd/ChangeLog: * Makefile.in: Re-generate. * configure: Re-generate. * doc/Makefile.in: Re-generate. binutils/ChangeLog: * Makefile.in: Re-generate. * configure: Re-generate. * doc/Makefile.in: Re-generate. gas/ChangeLog: * Makefile.in: Re-generate. * configure: Re-generate. * doc/Makefile.in: Re-generate. gold/ChangeLog: * testsuite/Makefile.in: Re-generate. gprof/ChangeLog: * Makefile.in: Re-generate. * configure: Re-generate. ld/ChangeLog: * Makefile.in: Re-generate. * configure: Re-generate. opcodes/ChangeLog: * Makefile.in: Re-generate. * configure: Re-generate.
2019-09-16Update version to 2.33.50 and regenerate configure scripts.Phil Blundell1-10/+10
generated by cgit v1.1 at 2025-02-15 05:47:31 +0000