https://bugs.kde.org/show_bug.cgi?id=526075
--- Comment #2 from yegorich <[email protected]> --- (In reply to Mark Wielaard from comment #1) > (In reply to yegorich from comment #0) > > Linking the tools fails when the toolchain's libgcc.a has been built without > > optimisation: > > > > 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 > > make[4]: *** [Makefile:1180: memcheck-x86-linux] Error 1 > > > > Seen on x86/Linux (32 bit) with gcc 15.3.0 and binutils 2.45, in Buildroot's > > autobuilders. It is not Buildroot specific: any toolchain whose libgcc was > > compiled at -O0 triggers it. > > Just one question. How common is this? Why does Buildroot do this? Honestly, it's rare. Nobody picks "build libgcc at -O0" on purpose. It's a side effect of how Buildroot builds its internal toolchain. Buildroot has a global optimisation-level choice (BR2_OPTIMIZE_0/1/2/3/S/G/FAST) that becomes part of TARGET_CFLAGS for the whole target system. People use -O0 mainly to debug their target userspace. When Buildroot builds its own cross gcc, it passes the same flags to the gcc target libraries on purpose, through CFLAGS_FOR_TARGET/CXXFLAGS_FOR_TARGET. This happens in package/gcc/gcc.mk, and it's done so that libgcc, libstdc++ and friends get the same ABI and architecture flags as everything else. Those flags also used to replace --enable-target-optspace. The optimisation level comes along with them. Because libgcc's Makefile puts GCC_CFLAGS after its own -O2, the -O0 wins. In practice, we mostly see this on Buildroot's autobuilders. They build random configurations, including BR2_OPTIMIZE_0, which is how this failure turned up. A real user would hit it if they chose -O0 for their whole system and also enabled valgrind. That's not unreasonable, since people debugging their system are the ones who want valgrind. > > The attached patch adds dummy definitions of _Unwind_Resume() and > > __gcc_personality_v0() to coregrind/m_libgcc_sup.c, which is exactly the > > place for "supplemental functions for libgcc". They can never be reached, > > since the core is plain C and never raises an exception. > > > > Because they end up in libgcc-sup-<platform>.a, which is linked after -lgcc, > > archive members are only pulled in on demand: a toolchain that does provide > > the real symbols in libgcc.a keeps using those and the dummies are never > > extracted. > > Yes. Good. > > > Verified on x86/Linux: with an object reproducing an -O0 built _divdi3.o > > added to the tool link, the link fails with exactly the two errors above > > without libgcc-sup-x86-linux.a and succeeds with it. A full build of 3.26.0 > > for i686 with the patch applied is clean. > > Thanks. > > > Happy to rework it if you would rather gate the definitions on a configure > > check, or have them call VG_(core_panic)() instead of __builtin_trap() — I > > used the builtin to keep m_libgcc_sup.o free of references back into > > libcoregrind.a, since it is linked last. > > Yes, that looks fine. The idea indeed is that m_libgcc_sup is as simple as > possible. > > This looks fine and should impact anything else. Happy to merge this. > Just like to know if this (building libgcc with -O0) is something people > really do. -- You are receiving this mail because: You are watching all bug changes.
