Re: Haproxy 2.2.3 source
On Wed, Sep 16, 2020 at 5:42 PM Илья Шипицин wrote: > > > ср, 16 сент. 2020 г. в 16:33, Carlos Goncalves : > >> >> >> On Wed, Sep 9, 2020 at 7:53 PM Willy Tarreau wrote: >> >>> On Wed, Sep 09, 2020 at 07:20:17PM +0200, Willy Tarreau wrote: >>> > Feel free to pick this patch if that helps for your builds, I'm going >>> > to backport it to 2.2 once all platforms are happy. >>> >>> All builds are OK now, the commit was backported to 2.2 and the patch >>> can be retrieved here: >>> >>> >>> http://git.haproxy.org/?p=haproxy-2.2.git;a=commitdiff_plain;h=10c627ab >>> >>> Sorry for the mess :-/ >>> >> >> Thanks for the patch, Willy! >> >> Fedora has hit this bug in CI, too. This holds off the release of 2.2.3 >> RPMs for all other architectures. >> > > where is Fedora CI ? is is publicly available ? > 2.2.3 builds: https://koji.fedoraproject.org/koji/taskinfo?taskID=51459401 Failed armv7hl build log: https://kojipkgs.fedoraproject.org//work/tasks/9533/51459533/build.log > > > >> I wonder if 2.2.4 could be released soonish. Alternatively, distros could >> try to cherry-pick the patch you linked above to unblock their CI/CD >> systems. >> >> Thanks, >> Carlos >> >> >>> >>> Willy >>> >>>
Re: Haproxy 2.2.3 source
ср, 16 сент. 2020 г. в 16:33, Carlos Goncalves : > > > On Wed, Sep 9, 2020 at 7:53 PM Willy Tarreau wrote: > >> On Wed, Sep 09, 2020 at 07:20:17PM +0200, Willy Tarreau wrote: >> > Feel free to pick this patch if that helps for your builds, I'm going >> > to backport it to 2.2 once all platforms are happy. >> >> All builds are OK now, the commit was backported to 2.2 and the patch >> can be retrieved here: >> >> http://git.haproxy.org/?p=haproxy-2.2.git;a=commitdiff_plain;h=10c627ab >> >> Sorry for the mess :-/ >> > > Thanks for the patch, Willy! > > Fedora has hit this bug in CI, too. This holds off the release of 2.2.3 > RPMs for all other architectures. > where is Fedora CI ? is is publicly available ? > I wonder if 2.2.4 could be released soonish. Alternatively, distros could > try to cherry-pick the patch you linked above to unblock their CI/CD > systems. > > Thanks, > Carlos > > >> >> Willy >> >>
Re: Haproxy 2.2.3 source
On Wed, Sep 9, 2020 at 7:53 PM Willy Tarreau wrote: > On Wed, Sep 09, 2020 at 07:20:17PM +0200, Willy Tarreau wrote: > > Feel free to pick this patch if that helps for your builds, I'm going > > to backport it to 2.2 once all platforms are happy. > > All builds are OK now, the commit was backported to 2.2 and the patch > can be retrieved here: > > http://git.haproxy.org/?p=haproxy-2.2.git;a=commitdiff_plain;h=10c627ab > > Sorry for the mess :-/ > Thanks for the patch, Willy! Fedora has hit this bug in CI, too. This holds off the release of 2.2.3 RPMs for all other architectures. I wonder if 2.2.4 could be released soonish. Alternatively, distros could try to cherry-pick the patch you linked above to unblock their CI/CD systems. Thanks, Carlos > > Willy > >
Re: Haproxy 2.2.3 source
On Wed, Sep 09, 2020 at 10:03:29PM +0200, Vincent Bernat wrote: > ? 9 septembre 2020 19:31 +02, Willy Tarreau: > > >> Feel free to pick this patch if that helps for your builds, I'm going > >> to backport it to 2.2 once all platforms are happy. > > > > All builds are OK now, the commit was backported to 2.2 and the patch > > can be retrieved here: > > > > http://git.haproxy.org/?p=haproxy-2.2.git;a=commitdiff_plain;h=10c627ab > > All good on Debian: > https://buildd.debian.org/status/package.php?p=haproxy=experimental Great, thank you Vincent for the quick update! Willy
Re: Haproxy 2.2.3 source
Thank you Willy! A On Wed, Sep 9, 2020 at 1:31 PM Willy Tarreau wrote: > On Wed, Sep 09, 2020 at 07:20:17PM +0200, Willy Tarreau wrote: > > Feel free to pick this patch if that helps for your builds, I'm going > > to backport it to 2.2 once all platforms are happy. > > All builds are OK now, the commit was backported to 2.2 and the patch > can be retrieved here: > > http://git.haproxy.org/?p=haproxy-2.2.git;a=commitdiff_plain;h=10c627ab > > Sorry for the mess :-/ > > Willy >
Re: Haproxy 2.2.3 source
❦ 9 septembre 2020 19:31 +02, Willy Tarreau: >> Feel free to pick this patch if that helps for your builds, I'm going >> to backport it to 2.2 once all platforms are happy. > > All builds are OK now, the commit was backported to 2.2 and the patch > can be retrieved here: > > http://git.haproxy.org/?p=haproxy-2.2.git;a=commitdiff_plain;h=10c627ab All good on Debian: https://buildd.debian.org/status/package.php?p=haproxy=experimental -- Small things make base men proud. -- William Shakespeare, "Henry VI"
Re: Haproxy 2.2.3 source
On Wed, Sep 09, 2020 at 07:20:17PM +0200, Willy Tarreau wrote: > Feel free to pick this patch if that helps for your builds, I'm going > to backport it to 2.2 once all platforms are happy. All builds are OK now, the commit was backported to 2.2 and the patch can be retrieved here: http://git.haproxy.org/?p=haproxy-2.2.git;a=commitdiff_plain;h=10c627ab Sorry for the mess :-/ Willy
Re: Haproxy 2.2.3 source
On Wed, Sep 09, 2020 at 05:49:50PM +0200, Willy Tarreau wrote:
> On Wed, Sep 09, 2020 at 05:40:05PM +0200, Vincent Bernat wrote:
> > ? 9 septembre 2020 16:58 +02, Willy Tarreau:
> >
> > > 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 :-(
> >
> > I am getting it on Debian Unstable (gcc 10.2.0, glibc 2.31), Ubuntu
> > Focal (gcc 9.3.0, glibc 2.31) and Ubuntu Bionic (gcc 7.5.0, glibc 2.27).
>
> Thanks. Now I'm trying to work on it but can't reproduce the loading
> problem anymore... That's a heisenbug... The trick I'm trying right now
> is to really create a thread that exits on startup. This way we'll be
> certain pthread_exit() was already called once. It's much uglier than
> the first work around but should be more portable and more reliable.
OK, I've pushed this one into -dev:
f734ebfac ("BUILD: threads: better workaround for late loading of libgcc_s")
I found a more reliable and safer way to address this, exactly the same
as the one we did for backtrace(), which consists in calling the offending
function once at boot. So what we do now very early during initialization
is that we create a new thread that exits using pthread_exit(). This way
we're certain the function is usable before going further, and we don't
care if libgcc_s or whatever else provides the functionality.
I tested it on armhf, aarch64, x86_64, mipsel, ppc64le, and sparc64 with
success. It was also tested on musl which uses a different threading
library and met not issue. On Travis it's OK on all platforms. On Cirrus
and Cygwin it's still in progrss but Centos is already OK so I'm quite
confident.
Feel free to pick this patch if that helps for your builds, I'm going
to backport it to 2.2 once all platforms are happy.
Willy
Re: Haproxy 2.2.3 source
On Wed, Sep 09, 2020 at 05:40:05PM +0200, Vincent Bernat wrote: > ? 9 septembre 2020 16:58 +02, Willy Tarreau: > > > 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 :-( > > I am getting it on Debian Unstable (gcc 10.2.0, glibc 2.31), Ubuntu > Focal (gcc 9.3.0, glibc 2.31) and Ubuntu Bionic (gcc 7.5.0, glibc 2.27). Thanks. Now I'm trying to work on it but can't reproduce the loading problem anymore... That's a heisenbug... The trick I'm trying right now is to really create a thread that exits on startup. This way we'll be certain pthread_exit() was already called once. It's much uglier than the first work around but should be more portable and more reliable. Willy
Re: Haproxy 2.2.3 source
It is not cross-built. Debian builds armhf from arm64 builders. It seems Ubuntu is also using arm64 hardware to build armhf. An alternative that could work is to use QEMU user emulation. You can directly use "qemu-debootstrap --arch=armhf" to get a working chroot. -- Format a program to help the reader understand it. - The Elements of Programming Style (Kernighan & Plauger) ――― Original Message ――― From: Илья Шипицин Sent: 9 septembre 2020 20:38 +05 Subject: Re: Haproxy 2.2.3 source To: Willy Tarreau Cc: Vincent Bernat; Alex Evonosky; haproxy@formilux.org > 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 : > >> 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: >> > >> > w DF *UND* GLIBC_2.4 __gnu_Unwind_Find_exidx >> > 000165d0 gDF .text 000c GCC_3.0 _Unwind_DeleteException >> > d1f6 gDF .text 0002 GCC_3.0 _Unwind_GetTextRelBase >> > 00016e1c gDF .text 0022 GCC_4.3.0 _Unwind_Backtrace >> > 00016df8 gDF .text 0022 GCC_3.0 _Unwind_ForcedUnwind >> > 00016dd4 gDF .text 0022 GCC_3.3 _Unwind_Resume_or_Rethrow >> > d1f0 gDF .text 0006 GCC_3.0 _Unwind_GetDataRelBase >> > 0001662c gDF .text 0036 GCC_3.5 _Unwind_VRS_Set >> > 00016db0 gDF .text 0022 GCC_3.0 _Unwind_Resume >> > 000169d8 gDF .text 02ba GCC_3.5 _Unwind_VRS_Pop >> > 00017178 gDF .text 000a GCC_3.0 _Unwind_GetRegionStart >> > 000165cc gDF .text 0002 GCC_3.5 _Unwind_Complete >> > 00017184 gDF .text 0012 GCC_3.0 >> _Unwind_GetLanguageSpecificData >> > 000165dc gDF .text 0036 GCC_3.5 _Unwind_VRS_Get >> > 000164f0 gDF .text 0004 GCC_3.3 _Unwind_GetCFA >> > 00016d8c gDF .text 0022 GCC_3.0 _Unwind_RaiseException >> > >> > So, older symbols are: >> > >> > 000165d0 gDF .text 000c GCC_3.0 _Unwind_DeleteException >> > d1f6 gDF .text 0002 GCC_3.0 _Unwind_GetTextRelBase >> > 00016df8 gDF .text 0022 GCC_3.0 _Unwind_ForcedUnwind >> > d1f0 gDF .text 0006 GCC_3.0 _Unwind_GetDataRelBase >> > 00016db0 gDF .text 0022 GCC_3.0 _Unwind_Resume >> > 00017178 gDF .text 000a GCC_3.0 _Unwind_GetRegionStart >> > 00017184 gDF .text 0012 GCC_3.0 >> _Unwind_GetLanguageSpecificData >> > 00016d8c gDF .text 0022 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 >> >>
Re: Haproxy 2.2.3 source
❦ 9 septembre 2020 16:58 +02, Willy Tarreau: > 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 :-( I am getting it on Debian Unstable (gcc 10.2.0, glibc 2.31), Ubuntu Focal (gcc 9.3.0, glibc 2.31) and Ubuntu Bionic (gcc 7.5.0, glibc 2.27). -- Sometimes I wonder if I'm in my right mind. Then it passes off and I'm as intelligent as ever. -- Samuel Beckett, "Endgame"
Re: Haproxy 2.2.3 source
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 : > 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: > > > > w DF *UND* GLIBC_2.4 __gnu_Unwind_Find_exidx > > 000165d0 gDF .text 000c GCC_3.0 _Unwind_DeleteException > > d1f6 gDF .text 0002 GCC_3.0 _Unwind_GetTextRelBase > > 00016e1c gDF .text 0022 GCC_4.3.0 _Unwind_Backtrace > > 00016df8 gDF .text 0022 GCC_3.0 _Unwind_ForcedUnwind > > 00016dd4 gDF .text 0022 GCC_3.3 _Unwind_Resume_or_Rethrow > > d1f0 gDF .text 0006 GCC_3.0 _Unwind_GetDataRelBase > > 0001662c gDF .text 0036 GCC_3.5 _Unwind_VRS_Set > > 00016db0 gDF .text 0022 GCC_3.0 _Unwind_Resume > > 000169d8 gDF .text 02ba GCC_3.5 _Unwind_VRS_Pop > > 00017178 gDF .text 000a GCC_3.0 _Unwind_GetRegionStart > > 000165cc gDF .text 0002 GCC_3.5 _Unwind_Complete > > 00017184 gDF .text 0012 GCC_3.0 > _Unwind_GetLanguageSpecificData > > 000165dc gDF .text 0036 GCC_3.5 _Unwind_VRS_Get > > 000164f0 gDF .text 0004 GCC_3.3 _Unwind_GetCFA > > 00016d8c gDF .text 0022 GCC_3.0 _Unwind_RaiseException > > > > So, older symbols are: > > > > 000165d0 gDF .text 000c GCC_3.0 _Unwind_DeleteException > > d1f6 gDF .text 0002 GCC_3.0 _Unwind_GetTextRelBase > > 00016df8 gDF .text 0022 GCC_3.0 _Unwind_ForcedUnwind > > d1f0 gDF .text 0006 GCC_3.0 _Unwind_GetDataRelBase > > 00016db0 gDF .text 0022 GCC_3.0 _Unwind_Resume > > 00017178 gDF .text 000a GCC_3.0 _Unwind_GetRegionStart > > 00017184 gDF .text 0012 GCC_3.0 > _Unwind_GetLanguageSpecificData > > 00016d8c gDF .text 0022 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 > >
Re: Haproxy 2.2.3 source
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: > > w DF *UND* GLIBC_2.4 __gnu_Unwind_Find_exidx > 000165d0 gDF .text 000c GCC_3.0 _Unwind_DeleteException > d1f6 gDF .text 0002 GCC_3.0 _Unwind_GetTextRelBase > 00016e1c gDF .text 0022 GCC_4.3.0 _Unwind_Backtrace > 00016df8 gDF .text 0022 GCC_3.0 _Unwind_ForcedUnwind > 00016dd4 gDF .text 0022 GCC_3.3 _Unwind_Resume_or_Rethrow > d1f0 gDF .text 0006 GCC_3.0 _Unwind_GetDataRelBase > 0001662c gDF .text 0036 GCC_3.5 _Unwind_VRS_Set > 00016db0 gDF .text 0022 GCC_3.0 _Unwind_Resume > 000169d8 gDF .text 02ba GCC_3.5 _Unwind_VRS_Pop > 00017178 gDF .text 000a GCC_3.0 _Unwind_GetRegionStart > 000165cc gDF .text 0002 GCC_3.5 _Unwind_Complete > 00017184 gDF .text 0012 GCC_3.0 _Unwind_GetLanguageSpecificData > 000165dc gDF .text 0036 GCC_3.5 _Unwind_VRS_Get > 000164f0 gDF .text 0004 GCC_3.3 _Unwind_GetCFA > 00016d8c gDF .text 0022 GCC_3.0 _Unwind_RaiseException > > So, older symbols are: > > 000165d0 gDF .text 000c GCC_3.0 _Unwind_DeleteException > d1f6 gDF .text 0002 GCC_3.0 _Unwind_GetTextRelBase > 00016df8 gDF .text 0022 GCC_3.0 _Unwind_ForcedUnwind > d1f0 gDF .text 0006 GCC_3.0 _Unwind_GetDataRelBase > 00016db0 gDF .text 0022 GCC_3.0 _Unwind_Resume > 00017178 gDF .text 000a GCC_3.0 _Unwind_GetRegionStart > 00017184 gDF .text 0012 GCC_3.0 _Unwind_GetLanguageSpecificData > 00016d8c gDF .text 0022 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
Re: Haproxy 2.2.3 source
Correct.. this is arm based on my side as well. Sent from my Pixel 3XL On Tue, Sep 8, 2020, 5:47 PM 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: > > w DF *UND* GLIBC_2.4 __gnu_Unwind_Find_exidx > 000165d0 gDF .text 000c GCC_3.0 _Unwind_DeleteException > d1f6 gDF .text 0002 GCC_3.0 _Unwind_GetTextRelBase > 00016e1c gDF .text 0022 GCC_4.3.0 _Unwind_Backtrace > 00016df8 gDF .text 0022 GCC_3.0 _Unwind_ForcedUnwind > 00016dd4 gDF .text 0022 GCC_3.3 _Unwind_Resume_or_Rethrow > d1f0 gDF .text 0006 GCC_3.0 _Unwind_GetDataRelBase > 0001662c gDF .text 0036 GCC_3.5 _Unwind_VRS_Set > 00016db0 gDF .text 0022 GCC_3.0 _Unwind_Resume > 000169d8 gDF .text 02ba GCC_3.5 _Unwind_VRS_Pop > 00017178 gDF .text 000a GCC_3.0 _Unwind_GetRegionStart > 000165cc gDF .text 0002 GCC_3.5 _Unwind_Complete > 00017184 gDF .text 0012 GCC_3.0 > _Unwind_GetLanguageSpecificData > 000165dc gDF .text 0036 GCC_3.5 _Unwind_VRS_Get > 000164f0 gDF .text 0004 GCC_3.3 _Unwind_GetCFA > 00016d8c gDF .text 0022 GCC_3.0 _Unwind_RaiseException > > So, older symbols are: > > 000165d0 gDF .text 000c GCC_3.0 _Unwind_DeleteException > d1f6 gDF .text 0002 GCC_3.0 _Unwind_GetTextRelBase > 00016df8 gDF .text 0022 GCC_3.0 _Unwind_ForcedUnwind > d1f0 gDF .text 0006 GCC_3.0 _Unwind_GetDataRelBase > 00016db0 gDF .text 0022 GCC_3.0 _Unwind_Resume > 00017178 gDF .text 000a GCC_3.0 _Unwind_GetRegionStart > 00017184 gDF .text 0012 GCC_3.0 > _Unwind_GetLanguageSpecificData > 00016d8c gDF .text 0022 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) > -- > Don't sacrifice clarity for small gains in "efficiency". > - The Elements of Programming Style (Kernighan & Plauger) >
Re: Haproxy 2.2.3 source
❦ 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: w DF *UND* GLIBC_2.4 __gnu_Unwind_Find_exidx 000165d0 gDF .text 000c GCC_3.0 _Unwind_DeleteException d1f6 gDF .text 0002 GCC_3.0 _Unwind_GetTextRelBase 00016e1c gDF .text 0022 GCC_4.3.0 _Unwind_Backtrace 00016df8 gDF .text 0022 GCC_3.0 _Unwind_ForcedUnwind 00016dd4 gDF .text 0022 GCC_3.3 _Unwind_Resume_or_Rethrow d1f0 gDF .text 0006 GCC_3.0 _Unwind_GetDataRelBase 0001662c gDF .text 0036 GCC_3.5 _Unwind_VRS_Set 00016db0 gDF .text 0022 GCC_3.0 _Unwind_Resume 000169d8 gDF .text 02ba GCC_3.5 _Unwind_VRS_Pop 00017178 gDF .text 000a GCC_3.0 _Unwind_GetRegionStart 000165cc gDF .text 0002 GCC_3.5 _Unwind_Complete 00017184 gDF .text 0012 GCC_3.0 _Unwind_GetLanguageSpecificData 000165dc gDF .text 0036 GCC_3.5 _Unwind_VRS_Get 000164f0 gDF .text 0004 GCC_3.3 _Unwind_GetCFA 00016d8c gDF .text 0022 GCC_3.0 _Unwind_RaiseException So, older symbols are: 000165d0 gDF .text 000c GCC_3.0 _Unwind_DeleteException d1f6 gDF .text 0002 GCC_3.0 _Unwind_GetTextRelBase 00016df8 gDF .text 0022 GCC_3.0 _Unwind_ForcedUnwind d1f0 gDF .text 0006 GCC_3.0 _Unwind_GetDataRelBase 00016db0 gDF .text 0022 GCC_3.0 _Unwind_Resume 00017178 gDF .text 000a GCC_3.0 _Unwind_GetRegionStart 00017184 gDF .text 0012 GCC_3.0 _Unwind_GetLanguageSpecificData 00016d8c gDF .text 0022 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) -- Don't sacrifice clarity for small gains in "efficiency". - The Elements of Programming Style (Kernighan & Plauger)
