On Tue, Sep 08, 2020 at 11:47:25PM +0200, Vincent Bernat wrote:
> ? 8 septembre 2020 16:13 -04, Alex Evonosky:
>
> > Just compiling 2.2.3 and getting this reference:
> >
> >
> > /haproxy-2.2.3/src/thread.c:212: undefined reference to
> > `_Unwind_Find_FDE'
>
> I am getting the same issue on armhf only. Other platforms don't get
> this issue. On this platform, we only get:
>
> 00000000 w DF *UND* 00000000 GLIBC_2.4 __gnu_Unwind_Find_exidx
> 000165d0 g DF .text 0000000c GCC_3.0 _Unwind_DeleteException
> 0000d1f6 g DF .text 00000002 GCC_3.0 _Unwind_GetTextRelBase
> 00016e1c g DF .text 00000022 GCC_4.3.0 _Unwind_Backtrace
> 00016df8 g DF .text 00000022 GCC_3.0 _Unwind_ForcedUnwind
> 00016dd4 g DF .text 00000022 GCC_3.3 _Unwind_Resume_or_Rethrow
> 0000d1f0 g DF .text 00000006 GCC_3.0 _Unwind_GetDataRelBase
> 0001662c g DF .text 00000036 GCC_3.5 _Unwind_VRS_Set
> 00016db0 g DF .text 00000022 GCC_3.0 _Unwind_Resume
> 000169d8 g DF .text 000002ba GCC_3.5 _Unwind_VRS_Pop
> 00017178 g DF .text 0000000a GCC_3.0 _Unwind_GetRegionStart
> 000165cc g DF .text 00000002 GCC_3.5 _Unwind_Complete
> 00017184 g DF .text 00000012 GCC_3.0 _Unwind_GetLanguageSpecificData
> 000165dc g DF .text 00000036 GCC_3.5 _Unwind_VRS_Get
> 000164f0 g DF .text 00000004 GCC_3.3 _Unwind_GetCFA
> 00016d8c g DF .text 00000022 GCC_3.0 _Unwind_RaiseException
>
> So, older symbols are:
>
> 000165d0 g DF .text 0000000c GCC_3.0 _Unwind_DeleteException
> 0000d1f6 g DF .text 00000002 GCC_3.0 _Unwind_GetTextRelBase
> 00016df8 g DF .text 00000022 GCC_3.0 _Unwind_ForcedUnwind
> 0000d1f0 g DF .text 00000006 GCC_3.0 _Unwind_GetDataRelBase
> 00016db0 g DF .text 00000022 GCC_3.0 _Unwind_Resume
> 00017178 g DF .text 0000000a GCC_3.0 _Unwind_GetRegionStart
> 00017184 g DF .text 00000012 GCC_3.0 _Unwind_GetLanguageSpecificData
> 00016d8c g DF .text 00000022 GCC_3.0 _Unwind_RaiseException
>
> Moreover, comment says _Unwind_Find_DFE doesn't take arguments, but the
> signature I have in glibc is:
>
> fde *
> _Unwind_Find_FDE (void *pc, struct dwarf_eh_bases *bases)
Ah I'm really angry because I tested on many platforms, *including* armhf,
but now I'm not seeing it, so either I failed on one test or it depends
on the compiler combination :-(
The principle was just to force to load libgcc_s that tends to cause
aborts on reload for some users in chroots when threads exit, because
pthread_exit() tends to be the first one to require libgcc_s and it's
quite too late.
In the mean time you can probably get away with this:
diff --git a/src/thread.c b/src/thread.c
index 5eb68e33a..167e26e9d 100644
--- a/src/thread.c
+++ b/src/thread.c
@@ -201,7 +201,7 @@ static void __thread_init(void)
exit(1);
}
-#if defined(__GNUC__) && (__GNUC__ >= 3) && defined(__GNU_LIBRARY__) &&
!defined(__clang__)
+#if defined(__GNUC__) && (__GNUC__ >= 3) && defined(__GNU_LIBRARY__) &&
!defined(__clang__) && !defined(__arm__)
/* make sure libgcc_s is already loaded, because pthread_exit() may
* may need it on exit after the chroot! _Unwind_Find_FDE() is defined
* there since gcc 3.0, has no side effect, doesn't take any argument
But I'd really like to find a *reliable* way to force libgcc_s to be loaded
if available and required (i.e. not if statically built). I thought about
causing a 64/64 bit divide that usually is done via divsi3 and friend but
on x86_64 (where the problem was encountered) it will not do it.
I'm thinking about something: maybe I can have a look around
pthread_getspecific() and pthread_key_create(). I would be very surprised
if they didn't rely on some compiler-specific help from libgcc_s.
I'll keep testing and will get back to you guys.
Willy
