Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yegor Yefremov via buildroot <buildroot@buildroot.org>
To: buildroot@buildroot.org
Subject: [Buildroot] [PATCH] package/valgrind: fix build with a libgcc built without optimization
Date: Tue, 22 Sep 2026 12:53:23 +0200	[thread overview]
Message-ID: <20260922105323.2939955-1-yegorslists@gmail.com> (raw)

From: Yegor Yefremov <yegorslists@googlemail.com>

The 64 bit division helpers of libgcc (__divdi3 and friends) are
compiled with -fexceptions -fnon-call-exceptions. Buildroot passes
TARGET_CFLAGS to gcc through CFLAGS_FOR_TARGET, so with BR2_OPTIMIZE_0
libgcc itself is built with -O0, and the resulting objects keep
references to _Unwind_Resume() and __gcc_personality_v0(), which are
normally provided by libgcc_eh.a. Valgrind links its tools with
-nodefaultlibs, so that library is not available and the link fails:

  ld: libgcc.a(_divdi3.o): in function `__divdi3':
  libgcc2.c:1226: undefined reference to `_Unwind_Resume'
  ld: libgcc.a(_divdi3.o):(.data.rel.local.DW.ref.__gcc_personality_v0[DW.ref.__gcc_personality_v0]+0x0):
      undefined reference to `__gcc_personality_v0'
  collect2: error: ld returned 1 exit status
  make[4]: *** [Makefile:1180: memcheck-x86-linux] Error 1

Add a patch providing dummy definitions of both symbols in
libgcc-sup-<platform>.a, which is linked after -lgcc, so toolchains
providing the real symbols are unaffected. They can never be reached,
as Valgrind's core is plain C and never raises an exception.

Fixes:
  http://autobuild.buildroot.net/results/4a58c34308095e4d8ae91e0a779c94123ee497f6/

Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>

Assisted-by: Claude:claude-opus-5
---
 ...-provide-dummy-unwinder-entry-points.patch | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 package/valgrind/0003-coregrind-provide-dummy-unwinder-entry-points.patch

diff --git a/package/valgrind/0003-coregrind-provide-dummy-unwinder-entry-points.patch b/package/valgrind/0003-coregrind-provide-dummy-unwinder-entry-points.patch
new file mode 100644
index 0000000000..72390ca822
--- /dev/null
+++ b/package/valgrind/0003-coregrind-provide-dummy-unwinder-entry-points.patch
@@ -0,0 +1,80 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Yegor Yefremov <yegorslists@googlemail.com>
+Date: Sun, 21 Sep 2026 12:00:00 +0200
+Subject: [PATCH] coregrind: provide dummy unwinder entry points
+
+The 64 bit division helpers of libgcc (__divdi3 and friends) are
+compiled with -fexceptions -fnon-call-exceptions. When libgcc itself is
+built without optimisation, the resulting objects keep references to
+_Unwind_Resume() and __gcc_personality_v0(), which are normally provided
+by libgcc_eh.a. As tools are linked with -nodefaultlibs, that library is
+not available and linking a tool fails with:
+
+  ld: libgcc.a(_divdi3.o): in function `__divdi3':
+  libgcc2.c:1226: undefined reference to `_Unwind_Resume'
+  ld: libgcc.a(_divdi3.o):(.data.rel.local.DW.ref.__gcc_personality_v0[DW.ref.__gcc_personality_v0]+0x0):
+      undefined reference to `__gcc_personality_v0'
+  ld: libgcc.a(_moddi3.o): in function `__moddi3':
+  libgcc2.c:1249: undefined reference to `_Unwind_Resume'
+  ld: libgcc.a(_umoddi3.o): in function `__udivmoddi4':
+  libgcc2.c:1204: undefined reference to `_Unwind_Resume'
+  collect2: error: ld returned 1 exit status
+
+So provide dummy definitions. They can never be reached, since the core
+is plain C and never raises an exception. They live in
+libgcc-sup-<platform>.a, which is linked after -lgcc, so toolchains that
+do provide the real symbols keep using those.
+
+Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
+Upstream: https://bugs.kde.org/show_bug.cgi?id=526075
+---
+ coregrind/m_libgcc_sup.c | 33 +++++++++++++++++++++++++++++++++
+ 1 file changed, 33 insertions(+)
+
+diff --git a/coregrind/m_libgcc_sup.c b/coregrind/m_libgcc_sup.c
+index 111111111..222222222 100644
+--- a/coregrind/m_libgcc_sup.c
++++ b/coregrind/m_libgcc_sup.c
+@@ -60,6 +60,39 @@ unsigned long int __getauxval (unsigned long int type)
+ }
+ #endif
+ 
++/*====================================================================*/
++/*=== Dummy unwinder entry points needed by libgcc                 ===*/
++/*====================================================================*/
++
++/* The 64 bit division helpers of libgcc (__divdi3 and friends) are
++   compiled with -fexceptions -fnon-call-exceptions.  When libgcc itself
++   is built without optimisation, the resulting objects keep references
++   to _Unwind_Resume() and __gcc_personality_v0(), which are normally
++   provided by libgcc_eh.a.  As tools are linked with -nodefaultlibs,
++   that library is not available and linking a tool fails with e.g.:
++
++     libgcc.a(_divdi3.o): in function `__divdi3':
++     libgcc2.c:1226: undefined reference to `_Unwind_Resume'
++
++   So provide dummy definitions.  They can never be reached, since the
++   core is plain C and never raises an exception.  They live in
++   libgcc-sup-<platform>.a, which is linked after -lgcc, so toolchains
++   that do provide the real symbols keep using those.  */
++
++#if defined(VGO_linux)
++void _Unwind_Resume ( void* exc );
++void _Unwind_Resume ( void* exc )
++{
++   __builtin_trap();
++}
++
++void __gcc_personality_v0 ( void );
++void __gcc_personality_v0 ( void )
++{
++   __builtin_trap();
++}
++#endif
++
+ #if defined(VGO_solaris)
+ /* At least on Solaris 11.3 ar does not like
+    empty .ar files */
+-- 
+2.51.0
+
-- 
2.34.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

             reply	other threads:[~2026-09-22 10:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-22 10:53 Yegor Yefremov via buildroot [this message]
2026-10-22  7:57 ` [Buildroot] [PATCH v2] package/valgrind: fix build with a libgcc built without optimization Yegor Yefremov via buildroot
2026-10-22  9:32   ` Thomas Petazzoni via buildroot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260922105323.2939955-1-yegorslists@gmail.com \
    --to=buildroot@buildroot.org \
    --cc=yegorslists@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox