dev-util/valgrind: Add patch to support linking with LLD

Signed-off-by: Matt Turner <mattst88@gentoo.org>

2 files changed, 79 insertions, 0 deletions

diff --git a/dev-util/valgrind/files/valgrind-3.17.0-lld.patch b/dev-util/valgrind/files/valgrind-3.17.0-lld.patch
new file mode 100644
index 000000000000..56a7c0f72f46
--- /dev/null
+++ b/dev-util/valgrind/files/valgrind-3.17.0-lld.patch
@@ -0,0 +1,77 @@
+https://bugs.kde.org/show_bug.cgi?id=439046
+---
+diff --git a/configure.ac b/configure.ac
+index 4582fb5d0..63fd6c25e 100755
+--- a/configure.ac
++++ b/configure.ac
+@@ -2639,30 +2639,52 @@ CFLAGS=$safe_CFLAGS
+ # will reside. -Ttext aligns just the .text section start (but not any
+ # other section).
+ #
+-# So test for -Ttext-segment which is supported by all bfd ld versions
++# LLVM ld.lld 10.0 changed the semantics of its -Ttext. See "Breaking changes"
++# in https://releases.llvm.org/10.0.0/tools/lld/docs/ReleaseNotes.html
++# The --image-base option (since version 6.0?) provides the semantics needed.
++# -Ttext-segment generates an error, but -Ttext now more closely
++# follows the GNU (bfd) ld's -Ttext.
++#
++# So test first for --image-base support, and if that fails then
++# for -Ttext-segment which is supported by all bfd ld versions
+ # and use that if it exists. If it doesn't exist it must be an older
+ # version of gold and we can fall back to using -Ttext which has the
+ # right semantics.
+ 
+-AC_MSG_CHECKING([if the linker accepts -Wl,-Ttext-segment])
+-
+ safe_CFLAGS=$CFLAGS
+-CFLAGS="-static -nodefaultlibs -nostartfiles -Wl,-Ttext-segment=$valt_load_address_pri_norml -Werror"
++AC_MSG_CHECKING([if the linker accepts -Wl,--image-base])
++
++CFLAGS="-static -nodefaultlibs -nostartfiles -Wl,--image-base=$valt_load_address_pri_norml -Werror"
+ 
+ AC_LINK_IFELSE(
+ [AC_LANG_SOURCE([int _start () { return 0; }])],
+ [
+   linker_using_t_text="no"
+-  AC_SUBST([FLAG_T_TEXT], ["-Ttext-segment"])
++  AC_SUBST([FLAG_T_TEXT], ["--image-base"])
+   AC_MSG_RESULT([yes])
+ ], [
+-  linker_using_t_text="yes"
+-  AC_SUBST([FLAG_T_TEXT], ["-Ttext"])
+   AC_MSG_RESULT([no])
++
++  AC_MSG_CHECKING([if the linker accepts -Wl,-Ttext-segment])
++
++  CFLAGS="-static -nodefaultlibs -nostartfiles -Wl,-Ttext-segment=$valt_load_address_pri_norml -Werror"
++
++  AC_LINK_IFELSE(
++  [AC_LANG_SOURCE([int _start () { return 0; }])],
++  [
++    linker_using_t_text="no"
++    AC_SUBST([FLAG_T_TEXT], ["-Ttext-segment"])
++    AC_MSG_RESULT([yes])
++  ], [
++    linker_using_t_text="yes"
++    AC_SUBST([FLAG_T_TEXT], ["-Ttext"])
++    AC_MSG_RESULT([no])
++  ])
+ ])
++
+ CFLAGS=$safe_CFLAGS
+ 
+-# If the linker only supports -Ttext (not -Ttext-segment) then we will
++# If the linker only supports -Ttext (not -Ttext-segment or --image-base) then we will
+ # have to strip any build-id ELF NOTEs from the statically linked tools.
+ # Otherwise the build-id NOTE might end up at the default load address.
+ # (Pedantically if the linker is gold then -Ttext is fine, but newer
+@@ -2688,7 +2710,7 @@ AC_LINK_IFELSE(
+   AC_MSG_RESULT([no])
+ ])
+ else
+-AC_MSG_NOTICE([ld -Ttext-segment used, no need to strip build-id NOTEs.])
++AC_MSG_NOTICE([ld --image-base or -Ttext-segment used, no need to strip build-id NOTEs.])
+ AC_SUBST([FLAG_NO_BUILD_ID], [""])
+ fi
+ CFLAGS=$safe_CFLAGS
+-- 
diff --git a/dev-util/valgrind/valgrind-3.17.0.ebuild b/dev-util/valgrind/valgrind-3.17.0.ebuild
index 890f41044529..148f504a5702 100644
--- a/dev-util/valgrind/valgrind-3.17.0.ebuild
+++ b/dev-util/valgrind/valgrind-3.17.0.ebuild
@@ -33,6 +33,8 @@ src_prepare() {
 
 	eapply "${FILESDIR}"/${PN}-3.15.0-Build-ldst_multiple-test-with-fno-pie.patch
 
+	eapply "${FILESDIR}"/${PN}-3.17.0-lld.patch
+
 	if [[ ${CHOST} == *-solaris* ]] ; then
 		# upstream doesn't support this, but we don't build with
 		# Sun/Oracle ld, we have a GNU toolchain, so get some things