how do you build armh ? can you share details ? if that's cross build, we can easily add to github actions, for example.
unfortunately, it is hard to get armh native CI. ср, 9 сент. 2020 г. в 20:01, Willy Tarreau <[email protected]>: > 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 > >
