In CLANG_PLUGIN_FILE it is possible for plugin_file to be non-NULL
when LLVMgold.so does not exist.
configure output is messy, with results not printed against their
"checking.." line, eg.
checking for clang... (cached) yes
checking for clang plugin file... checking for x86_64-pc-linux-gnu-ar... (cached) ar --plugin /usr/lib/llvm-20/lib/clang/20/../../LLVMgold.so
/usr/lib/llvm-20/lib/clang/20/../../LLVMgold.so
This patch fixes those problems, and a similar interposition of other
configure output between AC_MSG_CHECKING and AC_MSG_RESULT in
gcc-plugin.m4. It also tidies some of the message text, and makes
similar code in gcc-plugin.m4 and clang-plugin.m4 a little more
consistent.
config/
* clang-plugin.m4 (CLANG_PLUGIN_FILE): Don't place checks for
tools (llvm-config, ar) inside AC_MSG_CHECKING..AC_MSG_RESULT
for clang plugin file. Clear plugin_file before loop exit.
(CLANG_PLUGIN_FILE_FOR_TARGET): Similarly.
* gcc-plugin.m4 (GCC_PLUGIN_OPTION): Similarly.
(GCC_PLUGIN_OPTION_FOR_TARGET): Correct AC_MSG_CHECKING. Tidy
return code.
binutils/
* testsuite/lib/binutils-common.exp <llvm_plug_opt>: Set for
non-native.
* configure: Regenerate.
/
* configure: Regenerate.
bfd/
* configure: Regenerate.
gas/
* configure: Regenerate.
gdb/
* configure: Regenerate.
gprof/
* configure: Regenerate.
gprofng/
* configure: Regenerate.
* libcollector/configure: Regenerate.
ld/
* configure: Regenerate.
libbacktrace/
* configure: Regenerate.
libctf/
* configure: Regenerate.
libiberty/
* configure: Regenerate.
libsframe/
* configure: Regenerate.
opcodes/
* configure: Regenerate.
sim/
* configure: Regenerate.
zlib/
* configure: Regenerate.
This is just so the target won't need excluding in a forthcoming new
testcase. Without doing so objdump would fail saying "option -P/--private
not supported by this file".
testsuite/binutils-all/objdump.exp has
set got [remote_exec host "tail -n +4 tmpdir/objdump.out" "" "/dev/null" "tmpdir/objdump.tail"]
But the default Solaris tail doesn't support "tail -n +4". Add
ACX_PROG_GNU_TAIL to use GNU tail for 'objdump -Wi' test.
Tested on Linux and Solaris.
binutils/
PR binutils/33396
* Makefile.am (check-DEJAGNU): Also export TAIL.
* Makefile.in: Regenerated.
* aclocal.m4: Likewise.
* configure: Likewise.
* configure.ac: Add ACX_PROG_GNU_TAIL.
* testsuite/binutils-all/objdump.exp: Require GNU tail for
'objdump -Wi' test and replace tail with $env(TAIL).
config/
PR binutils/33396
* acx.m4 (ACX_PROG_GNU_TAIL): New.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Collin Funk <collin.funk1@gmail.com>
Swap AM_PO_SUBDIRS and ZW_GNU_GETTEXT_SISTER_DIR lines in
*/configure.ac. ZW_GNU_GETTEXT_SISTER_DIR indirectly invokes
AC_REQUIRE(AM_PO_SUBDIRS) so results in AM_PO_SUBDIRS being emitted
before ZW_GNU_GETTEXT_SISTER_DIR if it hasn't already been invoked.
On big endian hosts (eg. s390x) the windmc tool fails to parse even
trivial files:
$ cat test.mc
;
$ ./binutils/windmc ./test.mc
In test.mc at line 1: parser: syntax error.
In test.mc at line 1: fatal: syntax error.
The tool starts by reading the input as Windows CP1252 and then
converting it internally into an array of UTF-16LE, which it then
processes as an array of unsigned short (typedef unichar).
There are lots of ways this is wrong, but in the specific case of big
endian machines the little endian pairs of bytes are byte-swapped.
For example, the ';' character in the input above is first converted
to UTF16-LE byte sequence { 0x3b, 0x00 }, which is then cast to
unsigned short. On a big endian machine the first unichar appears to
be 0x3b00. The lexer is unable to recognize this as the comment
character ((unichar)';') and so parsing fails.
The simple fix is to convert the input to UTF-16BE on big endian
machines (and do the reverse conversion when writing the output).
Fixes: https://sourceware.org/bugzilla/show_bug.cgi?id=31283
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
Add check for libdebuginfod 0.188 in AC_DEBUGINFOD and if found
define macro HAVE_LIBDEBUGINFOD_FIND_SECTION.
This macro indicates support for downloading ELF sections from
debuginfod servers.
This regenerates config files changed by the previous 44 commits.
Note that subject lines in these commits mostly match the gcc git
originating commit.
Only the xcoff and pe extensions were enabled. Build the lot, and fix
some more printf format problems when the host is 32-bit.
* configure.ac (od_vectors): Set up for --enable-targets=all.
* configure: Regenerate.
* od-elf32_avr.c (elf32_avr_dump_mem_usage): Correct format
specifier vs. arg mismatch.
(elf32_avr_dump_avr_prop): Likewise.
* od-pe.c: New file: Dumps fields in PE format headers.
* configure.ac (od_vectors): Add objdump_private_desc_pe for PE format targets. (od_files): Add od-pe for PE format targets.
* configure: Regenerate.
* Makefile.am (CFILES): Add od-pe.c (EXTRA_objdump_SOURCE): Likewise.
* Makefile.in: Generate.
* NEWS: Mention the new feature.
* doc/binutils.texi: Document the new support.
* objdump.c (wide_output): Change from local to global.
* objdump.h (wide_output): Prototype. (objdump_private_desc_pe): Prototype.
* testsuite/binutils-all/objdump.exp: Add a test of the new feature.
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.
Delete a few files only used for obsolete targets, and tidy config,
xfails and other pieces of support specific to those targets. And
since I was editing target triplets in test files, fix the nm
alpha-linuxecoff fails.
Integrate back checks for fseeko{,64} into configure.ac, so
that regeneration works.
binutils/
* configure.ac: Add fseeko, fseeko64 checks.
* configure: Regenerate.
Changes readelf to make use first of fseeko64 and then fseeko,
depending on which of those is available. If neither is available,
reverts to the previous behavior of using fseek.
This is necessary when building readelf for LLP64 systems, where a
long will only be 32 bits wide. If the elf file in question is >= 2 GiB,
that is greater than the max long value and therefore fseek will fail
indicating that the offset is negative. On such systems, making use of
fseeko64 or fseeko will result in the ability so seek past the 2 GiB
max long boundary.
Note that large archive handling in readelf remains to be fixed.
gas uses ZSTD_compressStream2 which is only available with libzstd >=
1.4.0, leading to build errors when an older version is installed.
This patch updates the check libzstd presence to check its version is
>= 1.4.0. However, since gas seems to be the only component requiring
such a recent version this may imply that we disable ZSTD support for
all components although some would still benefit from an older
version.
I ran 'autoreconf -f' in all directories containing a configure.ac
file, using vanilla autoconf-2.69 and automake-1.15.1. I noticed
several errors from autoheader in readline, as well as warnings in
intl, but they are unrelated to this patch.
This should fix some of the buildbots.
OK for trunk?
Thanks,
Christophe
Apparently some distros have a nagging egrep that helpfully tells you
egrep is deprecated and to use "grep -E". The nag message causes a ld
testsuite failure. What's more the advice isn't that good. The "-E"
flag may not be available with older versions of grep.
This patch fixes bare invocation of egrep within binutils, replacing
it with the autoconf $EGREP or with grep.
config/
* lib-ld.m4 (AC_LIB_PROG_LD_GNU): Require AC_PROG_EGREP and
invoke $EGREP.
(AC_LIB_PROG_LD): Likewise.
binutils/
* configure: Regenerate.
* embedspu.sh: Replace egrep with grep.
gold/
* testsuite/Makefile.am (flagstest_compress_debug_sections.check):
Replace egrep with grep.
* testsuite/Makefile.in: Regenerate.
* testsuite/bnd_ifunc_1.sh: Replace egrep with $EGREP.
* testsuite/bnd_ifunc_2.sh: Likewise.
* testsuite/bnd_plt_1.sh: Likewise.
* testsuite/discard_locals_test.sh: Likewise.
* testsuite/gnu_property_test.sh: Likewise.
* testsuite/no_version_test.sh: Likewise.
* testsuite/pr18689.sh: Likewise.
* testsuite/pr26936.sh: Likewise.
* testsuite/retain.sh: Likewise.
* testsuite/split_i386.sh: Likewise.
* testsuite/split_s390.sh: Likewise.
* testsuite/split_x32.sh: Likewise.
* testsuite/split_x86_64.sh: Likewise.
* testsuite/ver_test_pr16504.sh: Likewise.
intl/
* configure: Regenerate.
ld/
* testsuite/ld-elfvers/vers.exp (test_ar): Replace egrep with grep.
PR29397 PR29563: Add new configure option --with-zstd which defaults to
auto. If pkgconfig/libzstd.pc is found, define HAVE_ZSTD and support
zstd compressed debug sections for most tools.
* bfd: for addr2line, objdump --dwarf, gdb, etc
* gas: support --compress-debug-sections=zstd
* ld: support ELFCOMPRESS_ZSTD input and --compress-debug-sections=zstd
* objcopy: support ELFCOMPRESS_ZSTD input for
--decompress-debug-sections and --compress-debug-sections=zstd
* gdb: support ELFCOMPRESS_ZSTD input. The bfd change references zstd
symbols, so gdb has to link against -lzstd in this patch.
If zstd is not supported, ELFCOMPRESS_ZSTD input triggers an error. We
can avoid HAVE_ZSTD if binutils-gdb imports zstd/ like zlib/, but this
is too heavyweight, so don't do it for now.
```
% ld/ld-new a.o
ld/ld-new: a.o: section .debug_abbrev is compressed with zstd, but BFD is not built with zstd support
...
% ld/ld-new a.o --compress-debug-sections=zstd
ld/ld-new: --compress-debug-sections=zstd: ld is not built with zstd support
% binutils/objcopy --compress-debug-sections=zstd a.o b.o
binutils/objcopy: --compress-debug-sections=zstd: binutils is not built with zstd support
% binutils/objcopy b.o --decompress-debug-sections
binutils/objcopy: zstd.o: section .debug_abbrev is compressed with zstd, but BFD is not built with zstd support
...
```
Using AS_IF rather than shell "if" is recommended for conditionals
that contain non-trivial autoconf macros, because autoconf will emit
any AC_REQUIREd autoconf macro expansions outside of the conditional.
This makes them available elsewhere in the configure script.
binutils/
* configure.ac (msgpack): Use "AS_IF" rather than "if".
* configure: Regenerate.
ld/
* configure.ac (jansson): Use "AS_IF" rather than "if".
* configure: Regenerate.
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.
This replaces dwarf_vma, dwarf_size_type and dwarf_signed_vma with
uint64_t and int64_t everywhere. The patch also gets rid of
DWARF_VMA_FMT since we can't use that with uint64_t, and all of the
configure support for deciding the flavour of HOST_WIDEST_INT.
dwarf_vmatoa also disappears, replacing most uses with one of
PRIx64, PRId64 or PRIu64. Printing of size_t and ptrdiff_t values
now use %z and %t rather than by casting to unsigned long. Also,
most warning messages that used 0x%lx or similar now use %#lx and a
few that didn't print the 0x hex prefix now also use %#. The patch
doesn't change normal readelf output, except in odd cases where values
previously might have been truncated.
sbrk hasn't been used in binutils/ or ld/ for quite some time (so the
PR was fixed a while ago). Tidy up configury.
PR 17122
binutils/
* configure.ac: Don't check for sbrk.
* sysdep.h (sbrk): Don't supply fallback declaration.
* config.in: Regenerate.
* configure: Regenerate.
ld/
* configure.ac: Don't check for sbrk.
* config.in: Regenerate.
* configure: Regenerate.
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.
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.
The AMDGPU HSA OS ABI (code object v3 and above) defines the
NT_AMDGPU_METADATA ELF note [1]. The content is a msgpack object
describing, among other things, the kernels present in the code object
and how to call them.
I think it would be useful for readelf to be able to display the content
of those notes. msgpack is a structured format, a bit like JSON, except
not text-based. It is therefore possible to dump the contents in
human-readable form without knowledge of the specific layout of the
note.
Add configury to binutils to optionally check for the msgpack C library
[2]. Add There is a new --with{,out}-msgpack configure flag, and the actual
library lookup is done using pkg-config.
If msgpack support is enabled, dumping a NT_AMDGPU_METADATA note looks
like:
$ readelf --notes amdgpu-code-object
Displaying notes found in: .note
Owner Data size Description
AMDGPU 0x0000040d NT_AMDGPU_METADATA (code object metadata)
{
"amdhsa.kernels": [
{
".args": [
{
".address_space": "global",
".name": "out.coerce",
".offset": 0,
".size": 8,
".value_kind": "global_buffer",
},
<snip>
If msgpack support is disabled, dump the contents as hex, as is done
with notes that are not handled in a special way. This allows one to
decode the contents manually (maybe using a command-line msgpack
decoder) if really needed.
[1] https://llvm.org/docs/AMDGPUUsage.html#code-object-metadata
[2] https://github.com/msgpack/msgpack-c/tree/c_master
binutils/ChangeLog:
* Makefile.am (readelf_CFLAGS): New.
(readelf_LDADD): Add MSGPACK_LIBS.
* Makefile.in: Re-generate.
* config.in: Re-generate.
* configure: Re-generate.
* configure.ac: Add --with-msgpack flag and check for msgpack
using pkg-config.
* readelf.c: Include msgpack.h if HAVE_MSGPACK.
(print_note_contents_hex): New.
(print_indents): New.
(dump_msgpack_obj): New.
(dump_msgpack): New.
(print_amdgpu_note): New.
(process_note): Handle NT_AMDGPU_METADATA note contents.
Use print_note_contents_hex.
Change-Id: Ia60a654e620bc32dfdb1bccd845594e2af328b84
netbsdpe was deprecated in c2ce831330.
Since then, a release has passed (2.37), and it was marked obselete in
5c9cbf07f3. Unless I am mistaken, that
means we can now remove support altogether.
All branches in the "active" code are remove, and the target is
additionally marked as obsolete next to the other removed ones for
libbfd and gdb.
Per [1] from the NetBSD toolchain list, PE/COFF support was removed a
decade ago. Furthermore, the sole mention of this target in the binutils
commit history was in 2002. Together, I'm led to believe this target
hasn't seen much attention in quite a while.
[1]: https://mail-index.netbsd.org/tech-toolchain/2021/06/16/msg003996.html
bfd/
* config.bfd: Remove netbsdpe entry.
binutils/
* configure.ac: Remove netbsdpe entry.
* testsuite/lib/binutils-common.exp (is_pecoff_format): Likewise.
* configure: Regenerate.
gas/
* configure.tgt: Remove netbsdpe entry.
gdb/
* configure.tgt: Add netbsdpe to removed targets.
ld/
* configure.tgt: Remove netbsdpe entry.
* testsuite/ld-bootstrap/bootstrap.exp: Likewise.
binutils currently fails to compile on Solaris 10:
/vol/src/gnu/binutils/hg/binutils-2.37-branch/git/bfd/opncls.c: In function 'bfd_get_debug_link_info_1':
/vol/src/gnu/binutils/hg/binutils-2.37-branch/git/bfd/opncls.c:1231:16: error: implicit declaration of function 'strnlen' [-Werror=implicit-function-declaration]
1231 | crc_offset = strnlen (name, size) + 1;
| ^~~~~~~
/vol/src/gnu/binutils/hg/binutils-2.37-branch/git/bfd/opncls.c:1231:16: error: incompatible implicit declaration of built-in function 'strnlen' [-Werror]
/vol/src/gnu/binutils/hg/binutils-2.37-branch/git/bfd/opncls.c: In function 'bfd_get_alt_debug_link_info':
/vol/src/gnu/binutils/hg/binutils-2.37-branch/git/bfd/opncls.c:1319:20: error: incompatible implicit declaration of built-in function 'strnlen' [-Werror]
1319 | buildid_offset = strnlen (name, size) + 1;
| ^~~~~~~
and in a couple of other places. The platform lacks strnlen, and while
libiberty.h can provide a fallback declaration, the necessary configure
test isn't run.
Fixed with the following patch. Tested on i386-pc-solaris2.10.
2021-07-06 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
bfd:
* configure.ac: Check for strnlen declaration.
* configure, config.in: Regenerate.
binutils:
* configure.ac: Check for strnlen declaration.
* configure, config.in: Regenerate.
