* [Buildroot] [PATCH] package/valgrind: fix build with a libgcc built without optimization
@ 2026-09-22 10:53 Yegor Yefremov via buildroot
2026-10-22 7:57 ` [Buildroot] [PATCH v2] " Yegor Yefremov via buildroot
0 siblings, 1 reply; 3+ messages in thread
From: Yegor Yefremov via buildroot @ 2026-09-22 10:53 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply related [flat|nested] 3+ messages in thread* [Buildroot] [PATCH v2] package/valgrind: fix build with a libgcc built without optimization
2026-09-22 10:53 [Buildroot] [PATCH] package/valgrind: fix build with a libgcc built without optimization Yegor Yefremov via buildroot
@ 2026-10-22 7:57 ` Yegor Yefremov via buildroot
2026-10-22 9:32 ` Thomas Petazzoni via buildroot
0 siblings, 1 reply; 3+ messages in thread
From: Yegor Yefremov via buildroot @ 2026-10-22 7:57 UTC (permalink / raw)
To: buildroot
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. GCC then keeps the (empty) exception
landing pads in those objects, which therefore reference
_Unwind_Resume() and __gcc_personality_v0(), normally provided by
libgcc_eh.a. Valgrind links its tools with -nodefaultlibs, so that
library is not available and the link fails on 32 bit targets:
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
Backport the upstream commit 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.
This issue has been present since commit 0fe633cdff66 ("gcc: explicitly
use C{XX}FLAGS_FOR_TARGET instead of --enable-target-optspace"), which
started building the gcc target libraries with TARGET_CFLAGS, and thus
with -O0 when BR2_OPTIMIZE_0 is enabled, instead of -Os. This is not a
gcc regression: both gcc 11 and gcc 15 emit these landing pads at -O0.
It therefore affects 2015.08 and later, including 2025.02.x and
2026.02.x.
Fixes:
https://autobuild.buildroot.org/results/4a58c34308095e4d8ae91e0a779c94123ee497f6
Fixes: 0fe633cdff66febadc50bab3e0af4b3be53811c8 ("gcc: explicitly use C{XX}FLAGS_FOR_TARGET instead of --enable-target-optspace")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
---
Changes v1 -> v2:
- replace the local patch with a backport of the upstream commit
0ff27aab0831 (NEWS hunk dropped, it does not apply to 3.27.1)
- describe since when the issue has been present and add a Fixes:
tag for the culprit commit
- fix the trailer order
...winder-entry-points-needed-by-libgcc.patch | 88 +++++++++++++++++++
1 file changed, 88 insertions(+)
create mode 100644 package/valgrind/0003-Provide-dummy-unwinder-entry-points-needed-by-libgcc.patch
diff --git a/package/valgrind/0003-Provide-dummy-unwinder-entry-points-needed-by-libgcc.patch b/package/valgrind/0003-Provide-dummy-unwinder-entry-points-needed-by-libgcc.patch
new file mode 100644
index 0000000000..78ebf3e5f0
--- /dev/null
+++ b/package/valgrind/0003-Provide-dummy-unwinder-entry-points-needed-by-libgcc.patch
@@ -0,0 +1,88 @@
+From 0ff27aab0831786c7f419e73a2b5217cbbcc792d Mon Sep 17 00:00:00 2001
+From: Yegor Yefremov <yegorslists@googlemail.com>
+Date: Mon, 21 Sep 2026 23:45:52 +0200
+Subject: [PATCH] Provide 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 is built
+without optimisation, GCC keeps the exception landing pads in those
+objects, so _divdi3.o, _moddi3.o and _umoddi3.o end up referencing
+_Unwind_Resume() and __gcc_personality_v0(), which normally live in
+libgcc_eh.a. At -O1 and above the landing pads are optimised away and
+the references are gone.
+
+Tools are linked with -static -nodefaultlibs and pull the 64 bit
+division helpers out of -lgcc, but libgcc_eh.a is not available, so
+linking a tool against such a libgcc 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
+
+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.
+
+https://bugs.kde.org/show_bug.cgi?id=526075
+
+Upstream: https://sourceware.org/git/?p=valgrind.git;a=commit;h=0ff27aab0831786c7f419e73a2b5217cbbcc792d
+Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
+[Yegor: drop NEWS change]
+---
+ 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 df509be08d..10ad8ff86f 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.43.7
+
--
2.34.1
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [Buildroot] [PATCH v2] package/valgrind: fix build with a libgcc built without optimization
2026-10-22 7:57 ` [Buildroot] [PATCH v2] " Yegor Yefremov via buildroot
@ 2026-10-22 9:32 ` Thomas Petazzoni via buildroot
0 siblings, 0 replies; 3+ messages in thread
From: Thomas Petazzoni via buildroot @ 2026-10-22 9:32 UTC (permalink / raw)
To: Yegor Yefremov; +Cc: buildroot
On Thu, Oct 22, 2026 at 09:57:34AM +0200, Yegor Yefremov via buildroot wrote:
> 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. GCC then keeps the (empty) exception
> landing pads in those objects, which therefore reference
> _Unwind_Resume() and __gcc_personality_v0(), normally provided by
> libgcc_eh.a. Valgrind links its tools with -nodefaultlibs, so that
> library is not available and the link fails on 32 bit targets:
>
> 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
>
> Backport the upstream commit 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.
>
> This issue has been present since commit 0fe633cdff66 ("gcc: explicitly
> use C{XX}FLAGS_FOR_TARGET instead of --enable-target-optspace"), which
> started building the gcc target libraries with TARGET_CFLAGS, and thus
> with -O0 when BR2_OPTIMIZE_0 is enabled, instead of -Os. This is not a
> gcc regression: both gcc 11 and gcc 15 emit these landing pads at -O0.
> It therefore affects 2015.08 and later, including 2025.02.x and
> 2026.02.x.
>
> Fixes:
> https://autobuild.buildroot.org/results/4a58c34308095e4d8ae91e0a779c94123ee497f6
>
> Fixes: 0fe633cdff66febadc50bab3e0af4b3be53811c8 ("gcc: explicitly use C{XX}FLAGS_FOR_TARGET instead of --enable-target-optspace")
> Assisted-by: Claude:claude-opus-5-5
> Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Applied to master, thanks!
Best regards,
Thomas Petazzoni
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-10-22 9:32 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-22 10:53 [Buildroot] [PATCH] package/valgrind: fix build with a libgcc built without optimization Yegor Yefremov via buildroot
2026-10-22 7:57 ` [Buildroot] [PATCH v2] " Yegor Yefremov via buildroot
2026-10-22 9:32 ` Thomas Petazzoni via buildroot
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.