While accepting all these inside of string and character literals in C and C++20 and older is fine, accepting them inside of identifiers can change meaning of valid programs.
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600620.html
#define z(x) 0
#define a z(
int x = a\N{LATIN SMALL LETTER U WITH DIAERESIS});
int y = a\u{1234});
int z = a\U{12345678});

What kind of problems are you talking about? Is it that some non-glibc system wants also the NULL resolved_path handling and doesn't have it in the libc?
To be precise, the patch would work fine if only the INIT_REALPATH macro is changed to the COMMON_INTERCEPT_FUNCTION_GLIBC_VER_MIN macro, but no reordering will help,
the problem is that tsan disables the wrappers altogether at some points and then it only calls the original function. And it is crucial that the original function is the right one.

In D107819#2936888, @dvyukov wrote:

I don't remember if you have commit access or not. Do you want me to land this?

It used to be 3 times per thread, now it is 2 times per thread.

https://reviews.llvm.org/D100645 contains the details.

The reason why the previous change was done is because it is no longer a constant on Linux with recent glibc (2.34 to be released later this year). But it is still constant for older glibcs, or on non-Linux.

It will succeed once. But if another thread calls GetAltStackSize() while the first one just returned from __sync_bool_compare_and_swap(&kAltStackSize, 0, 1) but hasn't yet stored the SIGSTKSZ * 4 value (e.g. is inside of sysconf), or even has stored, but the value hasn't propagated to other CPU caches yet, then they can see kAltStackSize of 1 rather than the right value.

This is certainly wrong. It will happily return 1 when some other thread is changing it, and the store is non-atomic.
Perhaps you want something like:

static atomic_uint32_t  kAltStackSize;
uptr ret = atomic_load(&kAltStackSize, memory_order_relaxed);
if (ret == 0) {
  ret = SIGSTKSZ * 4;
  atomic_store(&kAltStackSize, ret, memory_order_relaxed);
}
return ret;

on the assumption that SIGSTKSZ will always evaluate to the same non-zero constant and it is ok to evaluate it more than once, but faster not to do that if possible.
Would be nice to get rid of the overhead if SIGSTKSZ is a constant expression though, maybe:

if (__builtin_constant_p (SIGSTKSZ * 4))
  return SIGSTKSZ * 4;
else {
  // Above atomic stuff.
}

Alternative to this would be

As a minor optimization for the latter you could do in SetAlternateSignalStack() do

const uptr kAltStackSize = GetAltStackSize();
void *base = MmapOrDie(kAltStackSize, __func__);
altstack.ss_sp = (char*) base;
altstack.ss_flags = 0;
altstack.ss_size = kAltStackSize;

LGTM. For older glibc it will be most likely inlined and optimized into const like it was before, for new glibc it will be slightly more costly at startup but will be thread-safe (the usual C++ local static init costs).

In D92052#2452686, @MaskRay wrote:

OK my bad (I don't regularly see "See Also"... ) I've sent https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97827#c9 . I'll follow up with GCC folks there. I don't subscribe gcc-patches so it will be a bit inconvenient for me if most people comment on the mailing list instead...

In D87974#2409829, @zoecarver wrote:

@jwakely It looks like UnsizedTail causes a crash.

Can somebody please commit it? I don't have access to llvm repo. Thanks.

The change looks wrong, the upcoming glibc 2.31 changes aren't just about ARM, but actually most of the architectures, so adding a special case just for ARM is just weird.
Either we should change the structures to match what glibc 2.31 will have and disable this ipc_perm mode checking if not __GLIBC_PREREQ (2, 31) on SANITIZER_LINUX,
or the check needs to be disabled on most Linux architectures.
Affected are e.g. x86_64, i?86, riscv*, sparc 32-bit, s390 31-bit, arm. And, on arm big endian and s390 31-bit there is even an important ABI change, so shmctl interception
won't be able to use dlsym but will need to use dlvsym.
Completely untested patch would be something like:

• sanitizer_common/sanitizer_platform_limits_posix.h 2019-11-07 17:56:23.530835549 +0100

+++ sanitizer_common/sanitizer_platform_limits_posix.h 2019-11-12 12:22:26.314511706 +0100
@@ -207,26 +207,13 @@ struct __sanitizer_ipc_perm {

u64 __unused1;                                                                                                                                  
u64 __unused2;

#elif defined(sparc)
-#if defined(arch64)

unsigned mode;

• unsigned short __pad1;

-#else

• unsigned short __pad1;
• unsigned short mode; unsigned short __pad2;

-#endif

unsigned short __seq;                                                                                                                           
unsigned long long __unused1;                                                                                                                   
unsigned long long __unused2;

-#elif defined(mips) || defined(aarch64) || defined(s390x)

• unsigned int mode;
• unsigned short __seq;
• unsigned short __pad1;
• unsigned long __unused1;
• unsigned long __unused2; #else
• unsigned short mode;
• unsigned short __pad1;

+ unsigned int mode;

unsigned short __seq;                                                                                                                           
unsigned short __pad2;

#if defined(x86_64) && !defined(_LP64)
---sanitizer_common/sanitizer_platform_limits_posix.cpp 2019-11-07 17:56:23.551835239 +0100
+++ sanitizer_common/sanitizer_platform_limits_posix.cpp 2019-11-12 12:23:42.959358844 +0100
@@ -1128,11 +1128,9 @@ CHECK_SIZE_AND_OFFSET(ipc_perm, uid);
CHECK_SIZE_AND_OFFSET(ipc_perm, gid);
CHECK_SIZE_AND_OFFSET(ipc_perm, cuid);
CHECK_SIZE_AND_OFFSET(ipc_perm, cgid);
-#if (!defined(aarch64) || !SANITIZER_LINUX || __GLIBC_PREREQ (2, 21)) && \

• !defined(arm)

-/* On aarch64 glibc 2.20 and earlier provided incorrect mode field. */
-/* On Arm newer glibc provide a different mode field, it's hard to detect

• so just disable the check. */

+#if !SANITIZER_LINUX || __GLIBC_PREREQ (2, 31)
+/* glibc 2.30 and earlier provided 16-bit mode field instead of 32-bit
+ on most architectures. */
CHECK_SIZE_AND_OFFSET(ipc_perm, mode);
#endif

In D44623#1126626, @Lekensteyn wrote:

Could you push it @jakubjelinek? If nobody takes care of it I'll try to merge it later.

Updated patch, which uses a template with 2 support classes to avoid some code duplication. I must say that I find

#ifndef __GLIBC_PREREQ
# define __GLIBC_PREREQ(x, y) 0
#endif

easier to read over the longer sequence of #ifs, and as I said earlier, the proposed

#if defined(__i386__) && (!defined(__GLIBC_PREREQ) || !__GLIBC_PREREQ(2, 27))

is not valid C/C++ if __GLIBC_PREREQ macro is not defined.

In D44623#1042762, @kcc wrote:

Is this related to https://github.com/google/sanitizers/issues/914 or this is another problem?

glibc 2.27 has added the glob@@GLIBC_2.27 symbols approx. one month after these internal_function changes, so it is closer to that than e.g. trying to parse confstr for glibc 2.27 and later, and is also smaller than trying to parse the confstr string.

Can you or Konstantin please commit it? I don't have write access to llvm repo.
Thanks.

Phabriactor doesn't allow me to update this patch, so I've uploaded it to D40600 instead. If you have a way to update the diff here, please do.

Can you please commit it?

I have no idea how to CC those mailing lists (Change Subscribers doesn't seem to allow those) in this tool (or shall I just mail them normally)?
As for tests, the ones I have for GCC are:

In D38991#899950, @kcc wrote:

LGTM
Do you need me to commit it?

Shouldn't detect_invalid_pointer_pairs=1 be the default? I mean, the user already makes the decision to enable it through a compiler option/parameter and the generated code adds non-zero amount of .text space and some runtime cost, and there is no extra runtime costs for this if code isn't instrumented, so detect_invalid_pointer_pairs=0 by default only causes false assumption that code is error clean.

Besides the patch, we'd like to coordinate on options enabling this in the compilers.
From what I can see, in clang it is currently an experimental asan-detect-invalid-pointer-pair param,
what Martin has implemented is handle it as another kind of sanitization (separate kinds for pointer compare and pointer subtract),
-fsanitize=pointer-subtract or -fsanitize=pointer-compare. One can then do:
-fsanitize=address,pointer-subtract,pointer-compare etc., if address is not specified but one of these is, then
right now we error out. I could imagine pointer-subtract or pointer-compare to be supported even without address
sanitization, where we'd link against libasan and add poisoning/unpoisoning/global variable registration etc., but not
memory dereference checks, the problem is that the compiler then doesn't know if it should do the registration etc.
in kernel-address or user address style.

Could somebody please commit it? Thanks.

Using stack_t in the internal_sigaltstack prototype is problematic, because stack_t is only defined in the *.cc file which includes signal.h through sys/wait.h. But describing what it points to isn't really necessary, the function could be also declared with uptr arguments, or sanitizer_stack_t if we define it independently, etc.
Alternative to using struct res_state * is using res_state, i.e.

res_state statp = (res_state)state;

In D29992#679484, @kcc wrote:

Please:

• no more #ifdefs int this part of code, at least in the first two hunks
• no code duplications (the first two hunks look similar)
• no C-style comments, use //
• a test

Also, if possible, please try to change the logic from "harm, then unharm" to "don't harm"

In D29825#674022, @kcc wrote:

• please upload patches with full context, otherwise they are harder to review

In D29824#674011, @kcc wrote:

Is this change testable?

Note, in theory __builtin_extract_return_addr should be used on all architectures, but not sure if it can't break anything, so I'm proposing to use it for now just on s390 31-bit.
In GCC, the builtin returns something other than its unmodified arguments on:
alpha-vms in certain cases
arm (for 26-bit mode)
mips (always masks off lsb)
hppa (always masks off 2 ls bits)
s390 31-bit mode (always masks off msb)
sparc adds 8 or 12 bytes to it
microblaze adds 8 bytes to it

In D29735#672682, @kcc wrote:

check-asan does not pass with this change due to lint"
/tmp/check_lint.XhMkOExnXU/tmp.TSPGZQsNod.sanitizer_common_interceptors.inc.cc:4611: Extra space before ( in function call [whitespace/parens] [4]
/tmp/check_lint.XhMkOExnXU/tmp.TSPGZQsNod.sanitizer_common_interceptors.inc.cc:4611: All parameters should be named in a function [readability/function] [3]
/tmp/check_lint.XhMkOExnXU/tmp.TSPGZQsNod.sanitizer_common_interceptors.inc.cc:4614: Extra space before ( in function call [whitespace/parens] [4]
/tmp/check_lint.XhMkOExnXU/tmp.TSPGZQsNod.sanitizer_common_interceptors.inc.cc:4615: Extra space before ( in function call [whitespace/parens] [4]

Shall I upload a new patch with that? What is the process now, can somebody check it in for me?

Updated patch for that.

In D29735#671362, @kcc wrote:

This seems to be a S390-only change, right?

Defining the builtins directly is certainly not going to work very well.
E.g. GCC libatomic uses:

void libat_load (size_t, void *, void *, int) __asm ("__atomic_load");

or e.g.

void lbat_load (size_t, void *, void *, int);
...
typeof (libat_load) export_load __asm ("__atomic_load") __attribute__((alias ("libat_load")));

or ifuncs.

An interesting question is how to test it upstream.

In theory you could just test it even with C++11, with something like:

#include <new>

Well want to merge all the libsanitizer changes in the next month or two at most, but sure, this can be also desirable for release branch backporting eventually.