[libcxx-commits] [libcxx] [libc++][string] Replace ASAN volatile wrapper with memory barrier (PR #184693)

[Aiden Grossman via libcxx-commits]

boomanaiden154 wrote:

That sounds like a reasonable direction to go down. I can put up patches to drop the SSO container annotations.

Getting an annotation like the one proposed to work in the general case would probably not be feasible from my understanding, but might catch some low hanging fruit. It's also very possible I'm misunderstanding your proposal, so please let me know if I am. Anytime someone pulls out a pointer to the raw buffer with `.c_str()`, and that pointer escapes, it would generally be hard to track. I don't think it would be too difficult to catch intraprocedural low hanging fruit (maybe some inlining of `c_str()`):
```c++
char foo() {
  std::string test = "foo";
  // Should trap
  return test.c_str()[4];
}
```

That would be pretty easy to do data flow analysis on at the LLVM IR level given the pointer we end up loading from is directly derived from where we would be annotating the pointer. But if the pointer escapes:

```c++
char foo() {
  std::string test = "foo";
  uintptr_t testptr = reinterpret_cast<uintptr_t>(test.c_str());
  char* testptr2 = reinterpret_cast<char*>(testptr);
  // Should trap, but won't.
  return testptr2[4];
}
```

Or if we have to do any interprocedural analysis:

```c++
// foo2 may also be opaque if its definition is external
char foo2(char* input) {
  return input[4];
}

char foo() {
  std::string test = "foo";
  // Should trap, but won't.
  return foo2(test.c_str());
}
```

Ensuring we trap in these cases quickly becomes way more complex/intractable.

https://github.com/llvm/llvm-project/pull/184693