This causes us to reject the following (reduced from AOSP):

int sprintf(char* __s, const char* __fmt, ...)
    __attribute__((__format__(printf, 2, 3))) ;
int sprintf(char* dest, const char* format)
    __attribute__((overloadable))
    __attribute__((enable_if(((__builtin_object_size(((dest)), (1))) != ((unsigned long) -1) && (__builtin_object_size(((dest)), (1))) < (__builtin_strlen(format))), "format string will always overflow destination buffer")))

• Instead of updating an existing ring buffer entry, create a new entry

• Disable memory tagging in the test allocator if disabled via prctl()

In D94212#2488097, @eugenis wrote:

Can we have a setting where the secondary ring buffer is used for primary allocations, too? The primary record could be pushed when the chunk is about to be reused.

Fixes for Fuchsia

It's ready to go in if you don't mind me breaking Fuchsia. Otherwise I can wait for a Fuchsia implementation of setMemoryPermission() from you.

• Rename test

Sure, here is the .ll file.

It looks like this patch caused an assertion failure:

$ cat test.ii
# 1 "" 3
typedef int a;
typedef unsigned b;
struct c {
  template <typename d> c(d e) : f(e) {}
  int f;
};
struct g {
  template <typename h, typename ad> g(h e, ad) : ae(e), af(0) {}
  c ae;
  c af;
};
template <typename ag, typename i> auto ah(ag e, i) { return g(e, 0); }
class j {
public:
  void k();
};
class l;
class m {
public:
  m(int, l, int);
};
class l {
public:
  l(int, int);
};
class n {
  bool o();
  int ax;
};
template <typename> using ay = m;
template <typename, typename> using bc = l;
class p {
public:
  int *m_fn3();
  a q();
};
class r {
public:
  r(int)
      : bh(0, bc<int, int>(int(), bi), bi), bj(int(), bi), bk(int(), bi),
        bl(int(), bi) {
    p bn;
    int *base = bn.m_fn3();
    a bo = base == nullptr ?: bn.q();
    if (bo)
      for (auto bp = ah(bo, 0); __builtin_expect(bp.ae.f >= bp.af.f, false);)
        j().k();
  }
  int bi;
  ay<bc<int, int>> bh;
  bc<int, int> bj;
  bc<b, bool> bk;
  bc<b, int> bl;
};
bool n::o() { r bq(ax); }
$ ~/l2/ra/bin/clang -O2 test.ii
clang: ../llvm/include/llvm/IR/Instructions.h:2767: llvm::Value *llvm::PHINode::getIncomingValueForBlock(const llvm::BasicBlock *) const: Assertion `Idx >= 0 && "Invalid basic block argument!"' failed.

• Set MAP_MEMTAG only if tagging enabled

In D93495#2462581, @DavidSpickett wrote:

I assume that the signal displays without tag bits just like any other SEGV?

I was thinking about testing but I don't see any tests for specific signals so it would only be needed if your change to add the tag bits to siginfo has gone in.
(I have been following it from a distance but not sure of the status)

Show fault address for SEGV_MTESERR

Add test

Fix MTE issue

I don't think we should do this unless it fixes a bug. What happens if you remove it from the other two places?

LGTM

I think @cferris was asking whether old scudo was still being used by asan/hwasan. To which the answer is "no" I believe, the sanitizers have their own independent copy of the allocator.

LGTM

Can we not just drop support for Android in non-standalone Scudo? As far as I know it is only being used (if at all) on a limited set of platforms which does not include Android.

LGTM

In D91583#2404678, @tejohnson wrote:

In D91583#2404519, @pcc wrote:

I've said before that I think that --lto-whole-program-visibility should relax visibility of vtable symbols etc to hidden. That way, --export-dynamic wouldn't actually allow you to make this kind of mistake.

That would presumably result in an error in some of the problematic cases, whereas here we want to simply suppress --lto-whole-program-visibility to avoid any issues automatically.

But isn't it the case that you don't even need for the vtable symbol itself to be exported in order to derive from the class and override its virtual methods?

I've said before that I think that --lto-whole-program-visibility should relax visibility of vtable symbols etc to hidden. That way, --export-dynamic wouldn't actually allow you to make this kind of mistake.

What is the use case?

How does Zircon handle tagged addresses in syscalls? Are they handled equivalently to Linux's tagged address ABI?

LGTM

With this change we will end up with blocks distributed randomly among all of the transfer batches that we create at one time instead of having all of a transfer batch's blocks be consecutive. So we improve randomness at the cost of some locality which could impact performance. I'd be fine with letting this land though and we can see if it significantly impacts performance in practice once it's picked up downstream.

I agree with @MaskRay that this should be a binutils-specific option. The flag -mlinker-version seems to have been designed around macOS-specific assumptions i.e. there is a single linker (ld64) and that the linker and assembler are not version coupled. Having this option be binutils-specific seems like the best way to reflect the binutils-specific requirements.

Correct, clang no longer uses objcopy for this as of D47093.

Revert unnecessary change, fix tests

For the kernel I measured a small regression in boot time (with a version of this change that uses x20 for the v1 checks as well since the kernel doesn't use short granules yet) -- from 6.65s to 6.70s or 0.8%. But that's a fraction of the size gains which were 4% for kernel and (as mentioned) 3% for userspace.