Backport an upstream patch series that adds backend elfutils support for
DWARF relocations in MIPS debug info. This support is needed by pahole to
generate BTF for modules in BTF-enabled kernel builds.
The problem first manifests as pahole warnings during build:
BTF [M] lib/libcrc32c.ko
die__process_unit: DW_TAG_compile_unit (0x11) @ <0x932d> not handled!
die__process_unit: tag not supported 0x11 (compile_unit)!
die__process: got compile_unit unexpected tag after DW_TAG_compile_unit!
die__process_unit: DW_TAG_compile_unit (0x11) @ <0x99a3> not handled!
die__process_unit: tag not supported 0x11 (compile_unit)!
die__process: got compile_unit unexpected tag after DW_TAG_compile_unit!
During system boot the problem then causes module loading failures, which
may result in many other runtime issues:
[ 13.169785] kmodloader: loading kernel modules from /etc/modules.d/*
[ ... ]
[ 17.422840] mac80211_hwsim: initializing netlink
[ 17.526518] PPP generic driver version 2.4.2
[ 17.550346] NET: Registered PF_PPPOX protocol family
[ 17.795353] kmodloader: 26 modules could not be probed
[ 17.796084] kmodloader: dependency not loaded nf_conntrack
[ 17.796737] kmodloader: - act_connmark - 1
[ 17.797402] kmodloader: dependency not loaded nf_conntrack
[ 17.798056] kmodloader: - act_ctinfo - 1
[ ... ]
Link: https://lore.kernel.org/bpf/ZlkoM6%2FPSxVcGM6X@kodidev-ubuntu/
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/15697
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Trying to compile elfutils on Fedora 40 with GCC 14.1.1 will fail with:
/home/robimarko/Building/AX3600/qualcommax/staging_dir/host/bin/g++ -std=c++11 -D_GNU_SOURCE -DHAVE_CONFIG_H -DLOCALEDIR='"/home/robimarko/Building/AX3600/qualcommax/staging_dir/host/share/locale"' -DDEBUGPRED=0 -DSRCDIR=\"/home/robimarko/Building/AX3600/qualcommax/build_dir/host/elfutils-0.191/src\" -DOBJDIR=\"/home/robimarko/Building/AX3600/qualcommax/build_dir/host/elfutils-0.191/src\" -I. -I.. -I../libgnu -I../libgnu -I. -I. -I../lib -I.. -I./../libelf -I./../libebl -I./../libdw -I./../libdwelf -I./../libdwfl -I./../libasm -I../debuginfod -I/home/robimarko/Building/AX3600/qualcommax/staging_dir/host/include -std=c++11 -Wall -Wshadow -Wtrampolines -Wlogical-op -Wduplicated-cond -Wnull-dereference -Wimplicit-fallthrough=5 -Werror -Wunused -Wextra -Wstack-usage=262144 -D_FORTIFY_SOURCE=3 -c -o srcfiles.o srcfiles.cxx
In file included from /usr/include/c++/14/x86_64-redhat-linux/bits/os_defines.h:39,
from /usr/include/c++/14/x86_64-redhat-linux/bits/c++config.h:2521,
from /usr/include/c++/14/cstdlib:41,
from ../libgnu/gettext.h:56,
from ../libgnu/eu-config.h:62,
from ../config.h:2378,
from srcfiles.cxx:31:
/usr/include/features.h:414:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp]
414 | # warning _FORTIFY_SOURCE requires compiling with optimization (-O)
| ^~~~~~~
cc1plus: all warnings being treated as errors
So, lets do as the error says and pass -O2 in HOST_CXXFLAGS like we already
do by default in HOST_CFLAGS.
Link: https://github.com/openwrt/openwrt/pull/15368
Signed-off-by: Robert Marko <robimarko@gmail.com>
The compiled library resulting from importing gnulib has been
linked to libelf in order to easily cover other link dependencies.
However, this is not appropriate for linking libelf to other programs
as it bloats the resulting libelf library, and may result in
multiple defintions of symbols based on whether or not
certain modules from gnulib are included while elfutils
already has it's own definition of a function.
This is not a problem while building elfutils, because gnulib has
it's own way of creating function aliases and special declarations
that allow the linker to ignore the original function definitions,
however, when libelf is used to link to something else,
this results in an error at link time.
The gnulib manual recommended linking the libraries directly,
but those who have written it may not have considered how this
can affect the ability to link that library in other builds,
they likely assume the build targets would not be a dependency.
Fix this by removing the linking between gnulib and libelf
and instead overriding Make variables in order to add linking
between gnulib and each of the binaries provided by elfutils,
using Make functions to avoid applying it to other subdirectories.
The function tdestroy() would still be missing on macOS,
but the existence of the gnulib tsearch object having been built
is an indicator of whether or not it is needed
because it is only built conditionally by gnulib,
so include linking that object only when it exists.
Block the unnecessary replacement of some functions by gnulib
so that future linking with libelf doesn't require
the associated gnulib "rpl" prefixed functions.
These replacements are very strict in order to correct
minor bugs that don't have a real impact in almost all cases
or new standards requirements that are not yet in effect or used.
Tested-by: Georgi Valkov <gvalkov@gmail.com> # macOS
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Link: https://github.com/openwrt/openwrt/pull/15368
Signed-off-by: Robert Marko <robimarko@gmail.com>
Install binaries that are not common with binutils
instead of none at all. This adds a negligible time to the build.
Building shared libraries is disabled, so the AM_LDFLAGS can be reset
without the rpath-link option which is unrecognized by clang.
Some of the binaries depend on functions that are defined
using a "strong alias" instead of a normal definition,
but this is disabled by our patches in order to work on macOS,
so use the identical function directly instead.
Add fnmatch from gnulib with GNU extensions
which is needed for usage of the FNM_EXTMATCH flag.
Handle a "Wunused-const-variable" error with the same
preprocessor conditional used to include the function
that the variable is used in.
Ref: f64bd4b6c ("tools/elfutils: only build required components")
Tested-by: Georgi Valkov <gvalkov@gmail.com> # macOS
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Link: https://github.com/openwrt/openwrt/pull/15368
Signed-off-by: Robert Marko <robimarko@gmail.com>
In the 0.191 update dirname was used instead of <libgen.h> to fix the
poisoned basename error:
/usr/include/libgen.h:35:9: error: attempt to use poisoned "basename"
35 | #define basename __xpg_basename
However, doing this has lead to libelf.a pulling in xmalloc, xstrdup and
friends and statically linking them thus leading to a symbol name conflict
with FRR host build and anything else that links against libelf and uses
xmalloc and friends.
Well, it turns out that upstream has added a helper[1] for basename so it
can compile with musl 1.2.5 which dropped the basename declaration, but it
also means that we must NOT include <libgen.h> and that poisoned error is
intentional and added to prevent duplicate basename definitions.
This also means that for macOS we dont need to do any additional header
inclusions as the new helper takes care of basename.
So, to fix the symbol conflict we can simply drop the <dirname.h> inclusion
and build from elfutils.
Tested on Fedora 40 as well as macOS 14.4.1.
[1] https://sourceware.org/git/?p=elfutils.git;a=commit;h=a2194f6b305bf0d0b9dd49dccd0a5c21994c8eeaFixes: #24030
Fixes: b6f025b424 ("tools/elfutils: update to 1.91")
Link: https://github.com/openwrt/openwrt/pull/15337
Signed-off-by: Robert Marko <robimarko@gmail.com>
Quilt refresh combined two sets of changes to the same file.
The switch from using libgen.h to dirname.h because of function poisoning
from gnulib's import of basename() was added as a new patch hunk instead
of an edit to the original one.
The original patch hunk was to fix build errors on an earlier version of
elfutils before the "dirname" module was being imported to fix further
build errors with the 0.191 version.
Tested-by: Georgi Valkov <gvalkov@gmail.com> # MacOS
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
A false tdestroy() function was added in order to make elfutils build on
macOS again. A previous commit added declarations for a real version of
tdestroy() into gnulib, which is already imported, as well as the
preprocessor flags and the triggers for the Makefile.am conditional in
order to include the source to be built.
Tested-by: Georgi Valkov <gvalkov@gmail.com> # MacOS
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
On macOS, stdlib.h in the standard include paths does not provide
reallocarray() while both elfutils and gnulib do, however they are
declared differently, leading to an error:
./system.h:101:1: error: static declaration of 'reallocarray' follows non-static declaration
reallocarray (void *ptr, size_t nmemb, size_t size)
A normal "configure && make" build cycle results in both declarations
being enabled as a result of both elfutils and gnulib having completely
separate configure checks where gnulib uses an internal placeholder symbol
HAVE_REALLOCARRAY, and elfutils uses a standard autoconf macro
HAVE_DECL_REALLOCARRAY.
Fix this by excluding the import of the reallocarray module which causes
gnulib checks in the configure stage to not even consider whether to
declare reallocarray later on, so the decision is only between the
standard include stdlib.h and the elfutils header.
Tested-by: Georgi Valkov <gvalkov@gmail.com> # MacOS
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
Organize the Makefile lines involved in gnulib importing and its
workarounds. It improves readability and keeps git history organized.
Tested-by: Georgi Valkov <gvalkov@gmail.com> # MacOS
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
Instead of editing the SUBDIRS variable with a patch, it can be overriden
at the end of the command line when invoking Make.
This tool has a series of recursive Makefiles in each subdirectory,
therefore SUBDIRS is set to a pattern of Make functions so that the result
is variable depending on the current subdirectory that Make is being
invoked in.
It's not necessary to have gnulib-cache.m4 in EXTRA_DIST since we don't
need to re-import after packaging this in the SDK, so get rid of the
entire patch hunk for ./Makefile.am
Tested-by: Georgi Valkov <gvalkov@gmail.com> # MacOS
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
Release Notes:
https://sourceware.org/pipermail/elfutils-devel/2024q1/006876.html
Manually refresh:
- 100-portability.patch
Change:
- replace libgen.h with gnulib "dirname" module for compilation errors:
In file included from ./../libdw/libdwP.h:38,
from eblobjnote.c:42:
/usr/include/libgen.h:35:9: error: attempt to use poisoned "basename"
35 | #define basename __xpg_basename
| ^
Tested-by: Georgi Valkov <gvalkov@gmail.com> # MacOS
Co-Developed-by: Nick Hainke <vincent@systemli.org>
Signed-off-by: Nick Hainke <vincent@systemli.org>
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
This is only effective for host build of normal packages, not tools.
Fixes: ad79b92719 ("elfutils: move host build to tools")
Reported-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Building all of the components results in strip being installed in
staging_dir/host/bin. This strip binary will take precedence over
binutils strip that is installed in the toolchain directory.
This will not work on host systems that do not have libdw installed, as
we do not set HOST_LDFLAGS to override rpath to staging_dir/host/lib.
However, rather than overriding rpath, we should just avoid using
elfutils strip entirely.
Override the SUBDIRS variable in the Makefile to only build and install
the libraries we require for dwarves and frr.
Fixes the following build failure in toolchain/gdb:
strip: error while loading shared libraries: libdw.so.1: cannot open shared object file: No such file or directory
Fixes: ad79b92719 ("elfutils: move host build to tools")
Reported-by: Dominick Grift <dominick.grift@defensec.nl>
Reported-by: Lucian Cristian <lucian.cristian@gmail.com>
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
The upcoming dwarves host package requires elfutils. As dependencies for
tools must exist in tools, we need to move elfutils host build there.
As there is at least one package that depends on this, and there is no
proper way to create such dependency in the build system, build it
unconditionally when not building on macOS.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
