7 Commits

Author SHA1 Message Date
Alan Modra
87b6078fc2 tidy m4 plugin config support
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.
2025-11-03 10:59:50 +10:30
H.J. Lu
10deea6e2f Binutils/GCC: Add clang LTO support to AR, NM and RANLIB
Add CLANG_PLUGIN_FILE to find the clang plugin file and pass it to
--plugin for ar, nm and ranlib so that binutils can be built with
clang LTO.  Run CLANG_PLUGIN_FILE before GCC_PLUGIN_OPTION since
GCC_PLUGIN_OPTION may return the wrong PLUGIN_OPTION with clang.

	PR binutils/33470
	* Makefile.in: Regenerated.
	* Makefile.tpl (NM): Add @NM_PLUGIN_OPTION@.
	* configure: Regenerated.
	* configure.ac: Include config/clang-plugin.m4.
	Run CLANG_PLUGIN_FILE before GCC_PLUGIN_OPTION to set
	PLUGIN_OPTION.  Set and subst NM_PLUGIN_OPTION.
	* libtool.m4 (_LT_CMD_OLD_ARCHIVE): Use CLANG_PLUGIN_FILE and
	GCC_PLUGIN_OPTION.

config/

	PR binutils/33470
	* clang-plugin.m4: New file.

libbacktrace/

	PR binutils/33470
	* Makefile.in: Regenerated.
	* aclocal.m4: Likewise.
	* configure: Likewise.

libiberty/

	PR binutils/33470
	* aclocal.m4: Regenerated.
	* configure: Likewise.
	* configure.ac: Move GCC_PLUGIN_OPTION after GCC_NO_EXECUTABLES.
	Run CLANG_PLUGIN_FILE before GCC_PLUGIN_OPTION to set
	PLUGIN_OPTION.  Don't add the redundant --plugin option.

zlib/

	PR binutils/33470
	* Makefile.in: Regenerated.
	* aclocal.m4: Likewise.
	* configure: Likewise.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
2025-09-25 12:30:13 +08:00
Matthieu Longo
e83746f535 autoupdate: regen after replacing obsolete macros 2024-06-10 08:25:56 +09:30
Sam James
b450e10273 Sync libbacktrace from gcc [PR31327]
Note that this includes Nick's fix from edf64cd235 which
landed upstream a bit differently as r13-1566-g9ed57796235abc in GCC.

This pulls in libbacktrace as of r14-9404-gc775a030af9cad in GCC trunk.

Note that I have dropped a top-level Darwin change from r14-4825-g6a6d3817afa02b
which would've required an autoreconf, as it should be handled separately.

Approved-By: Tom Tromey <tom@tromey.com>
2024-03-11 23:10:33 +00:00
Alan Modra
6a6859cbff regen config
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-12 10:27:57 +09:30
Nick Alcock
caf606c90d libtool.m4: fix the NM="/nm/over/here -B/option/with/path" case
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-25 12:02:35 +00:00
Andrew Burgess
63a4b10683 Copy in libbacktrace from gcc
This copies in libbacktrace from the gcc repository as it was in the
commit 62e420293a293608f383d9b9c7f2debd666e9fc9.  GDB is going to
start using this library soon.

A dependency between GDB and libbacktrace has already been added to
the top level Makefile, so, after this commit, when building GDB,
libbacktrace will be built first.  However, libbacktrace is not yet
linked into GDB, or used by GDB in any way.

It is possible to stop libbacktrace being built by configuring the
tree with --disable-libbacktrace.

This commit does NOT update src-release.sh, that will be done in the
next commit, this commit ONLY imports libbacktrace from gcc.  This
means that if you try to make a release of GDB from exactly this
commit then the release tar file will not include libbacktrace.
However, as libbacktrace is an optional dependency this is fine.
2021-09-28 12:21:21 +01:00