tree 9958f0a14290527385617cc7d7b3cce3d2640407
parent 08144583bb03e98350c0b8d2b51185240c9797b1
author Willy Tarreau <w@1wt.eu> 1599664074 +0200
committer Christopher Faulet <cfaulet@haproxy.com> 1599812436 +0200

BUILD: threads: better workaround for late loading of libgcc_s

Commit 77b98220e ("BUG/MINOR: threads: work around a libgcc_s issue with
chrooting") tried to address an issue with libgcc_s being loaded too late.
But it turns out that the symbol used there isn't present on armhf, thus
it breaks the build.

Given that the issue manifests itself during pthread_exit(), the safest
and most portable way to test this is to call pthread_exit(). For this
we create a dummy thread which exits, during the early boot. This results
in the relevant library to be loaded if needed, making sure that a later
call to pthread_exit() will still work. It was tested to work fine under
linux on the following platforms:

 glibc:
   - armhf
   - aarch64
   - x86_64
   - sparc64
   - ppc64le

 musl:
   - mipsel

Just running the code under strace easily shows the call in the dummy
thread, for example here on armhf:

  $ strace -fe trace=file ./haproxy -v 2>&1 | grep gcc_s
  [pid 23055] open("/lib/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 3

The code was isolated so that it's easy to #ifdef it out if needed.
This should be backported where the patch above is backported (likely
2.0).

(cherry picked from commit f734ebfac4c406f245347527bd0e5831a251cc61)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 10c627ab2ebeb0a38ae8df477a5f2d870ad77f7c)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 73f2a3f2783ed740ee29ef2ed0220ddecd50652f)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>