https://bugs.kde.org/show_bug.cgi?id=526075
Mark Wielaard <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|[email protected] |[email protected] Status|REPORTED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Mark Wielaard <[email protected]> --- (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? > 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.
