Skip to content

Commit

Permalink
[test] Make Linux/sem_init_glibc.cpp robust
Browse files Browse the repository at this point in the history
and fix it for 32-bit ports defining sem_init@GLIBC_2.0 (i386, mips32, powerpc32) for glibc>=2.36.

Fix #58079

Reviewed By: mgorny

Differential Revision: https://reviews.llvm.org/D135023
  • Loading branch information
MaskRay committed Oct 2, 2022
1 parent 4e43a14 commit 6f46ff3
Show file tree
Hide file tree
Showing 2 changed files with 21 additions and 24 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -6727,7 +6727,7 @@ INTERCEPTOR(int, sem_init, __sanitizer_sem_t *s, int pshared, unsigned value) {
COMMON_INTERCEPTOR_ENTER(ctx, sem_init, s, pshared, value);
// Workaround a bug in glibc's "old" semaphore implementation by
// zero-initializing the sem_t contents. This has to be done here because
// interceptors bind to the lowest symbols version by default, hitting the
// interceptors bind to the lowest version before glibc 2.36, hitting the
// buggy code path while the non-sanitized build of the same code works fine.
REAL(memset)(s, 0, sizeof(*s));
int res = REAL(sem_init)(s, pshared, value);
Expand Down
Original file line number Diff line number Diff line change
@@ -1,39 +1,36 @@
// RUN: %clangxx -O0 -g %s -lutil -o %t && %run %t
// This test depends on the glibc layout of struct sem_t and checks that we
// don't leave sem_t::private uninitialized.
// UNSUPPORTED: android, lsan-x86, ubsan, target-is-mips64, target-is-mips64el
// UNSUPPORTED: android, lsan-x86, ubsan
#include <features.h>
#include <assert.h>
#include <semaphore.h>
#include <string.h>
#include <stdint.h>

// On powerpc64be semval_t must be 64 bits even with "old" versions of glibc.
#if __PPC64__ && __BIG_ENDIAN__
typedef uint64_t semval_t;

// This condition needs to correspond to __HAVE_64B_ATOMICS macro in glibc.
#elif (defined(__x86_64__) || defined(__aarch64__) || defined(__powerpc64__) || \
defined(__s390x__) || defined(__sparc64__) || defined(__alpha__) || \
defined(__ia64__) || defined(__m68k__)) && __GLIBC_PREREQ(2, 21)
typedef uint64_t semval_t;
#else
// musl and glibc's __HAVE_64B_ATOMICS==0 ports (e.g. arm, i386) use 32-bit sem
// values. 64-bit glibc ports defining sem_init@GLIBC_2.0 (mips64) use 32-bit as
// well, if the sem_init interceptor picks the oldest versioned symbol
// (glibc<2.36, see https://sourceware.org/PR14932).
#if !defined(__GLIBC__) || defined(__ILP32__) || \
!__GLIBC_PREREQ(2, 36) && defined(__mips64__)
typedef unsigned semval_t;
#else
typedef uint64_t semval_t;
#endif

// glibc 2.21 has introduced some changes in the way the semaphore value is
// handled for 32-bit platforms, but since these changes are not ABI-breaking
// they are not versioned. On newer platforms such as ARM, there is only one
// version of the symbol, so it's enough to check the glibc version. However,
// for old platforms such as i386, glibc contains two or even three versions of
// the sem_init symbol, and the sanitizers always pick the oldest one.
// Therefore, it is not enough to rely on the __GLIBC_PREREQ macro - we should
// instead check the platform as well to make sure we only expect the new
// behavior on platforms where the older symbols do not exist.
#if defined(__arm__) && __GLIBC_PREREQ(2, 21)
#define GET_SEM_VALUE(V) ((V) >> 1)
// glibc __HAVE_64B_ATOMICS==0 ports define a sem_init which shifts the value by
// 1 (https://sourceware.org/PR12674 glibc 2.21). The version is picked if
// either glibc>=2.36 or sem_init@GLIBC_2.0 is absent (arm and newer ports).
//
// The __GLIBC_PREREQ check is brittle in that it requires matched
// __GLIBC_PREREQ values for build time and run time.
#if defined(__GLIBC__) && defined(__ILP32__) && \
(__GLIBC_PREREQ(2, 36) || (__GLIBC_PREREQ(2, 21) && !defined(__i386__) && \
!defined(__mips__) && !defined(__powerpc__)))
# define GET_SEM_VALUE(V) ((V) >> 1)
#else
#define GET_SEM_VALUE(V) (V)
# define GET_SEM_VALUE(V) (V)
#endif

void my_sem_init(bool priv, int value, semval_t *a, unsigned char *b) {
Expand Down

0 comments on commit 6f46ff3

Please sign in to comment.