[compiler-rt][ASan] Add function copying annotations

[AdvenamTacet]

This PR adds a __sanitizer_copy_contiguous_container_annotations function, which copies annotations from one memory area to another. New area is annotated in the same way as the old region at the beginning (within limitations of ASan).

Overlapping case: The function supports overlapping containers, however no assumptions should be made outside of no false positives in new buffer area. (It doesn't modify old container annotations where it's not necessary, false negatives may happen in edge granules of the new container area.) I don't expect this function to be used with overlapping buffers, but it's designed to work with them and not result in incorrect ASan errors (false positives).

If buffers have granularity-aligned distance between them (old_beg % granularity == new_beg % granularity), copying algorithm works faster. If the distance is not granularity-aligned, annotations are copied byte after byte.

void __sanitizer_copy_contiguous_container_annotations(
    const void *old_storage_beg_p, const void *old_storage_end_p,
    const void *new_storage_beg_p, const void *new_storage_end_p) {

This function aims to help with short string annotations and similar container annotations. Right now we change trait types of std::basic_string when compiling with ASan and this function purpose is reverting that change as soon as possible.

llvm-project/libcxx/include/string

Lines 738 to 751 in 87f3407

	#if !defined(_LIBCPP_HAS_NO_ASAN) && defined(_LIBCPP_INSTRUMENTED_WITH_ASAN)
	// When compiling with AddressSanitizer (ASan), basic_string cannot be trivially
	// relocatable. Because the object's memory might be poisoned when its content
	// is kept inside objects memory (short string optimization), instead of in allocated
	// external memory. In such cases, the destructor is responsible for unpoisoning
	// the memory to avoid triggering false positives.
	// Therefore it's crucial to ensure the destructor is called.
	using __trivially_relocatable = void;
	#else
	using __trivially_relocatable = __conditional_t<
	__libcpp_is_trivially_relocatable<allocator_type>::value && __libcpp_is_trivially_relocatable<pointer>::value,
	basic_string,
	void>;
	#endif

The goal is to not change __trivially_relocatable when compiling with ASan. If this function is accepted and upstreamed, the next step is creating a function like __memcpy_with_asan moving memory with ASan. And then using this function instead of __builtin__memcpy while moving trivially relocatable objects.

llvm-project/libcxx/include/__memory/uninitialized_algorithms.h

Lines 644 to 646 in 11a6799

	} else {
	__builtin_memcpy(const_cast<__remove_const_t<_Tp>*>(__result), __first, sizeof(_Tp) * (__last - __first));
	}

---

I'm thinking if there is a good way to address fact that in a container the new buffer is usually bigger than the previous one. We may add two more arguments to the functions to address it (the beginning and the end of the whole buffer.

Another potential change is removing new_storage_end_p as it's redundant, because we require the same size.

Potential future work is creating a function __asan_unsafe_memmove, which will be basically memmove, but with turned off instrumentation (therefore it will allow copy data from poisoned area).

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[philnik777]

trivial relocation is also interesting for erasing object from a vector, so the builtins should probably be more akin to a memmove than a memcpy.

[vitalybuka]

LGTM for Asan however HWASAN story is not clear.
Let's make sure we can use this for HWASAN as well.

It's probably fine, but I'd like to think about this more.

[AdvenamTacet]

I still have to fix failing CI, I can sit to it on Monday and, if necessary, spend next week enough of time to fix it (Edit: testing it actually takes prohibitive amount of time, but I'm committed to make this PR work). I expect the problem to be a small implementation bug. Let me know if you have any high level requests for that code, I'm happy to implement them.
I will also create a separate PR cleaning compiler-rt ASan code, as I noticed a little bit of outdated code while writing this one.

trivial relocation is also interesting for erasing object from a vector, so the builtins should probably be more akin to a memmove than a memcpy.

Should we change __builtin_memcpy to __builtin_memmove? Then I would have to add support for overlapping areas to this PR. (It complicates the implementation a little bit.)

It's probably fine, but I'd like to think about this more.

Sure, let me know what are your conclusions!

[philnik777]

trivial relocation is also interesting for erasing object from a vector, so the builtins should probably be more akin to a memmove than a memcpy.

Should we change __builtin_memcpy to __builtin_memmove? Then I would have to add support for overlapping areas to this PR. (It complicates the implementation a little bit.)

Yes. My plan is to change the __builtin_memcpy to __builtin_memmove in __uninitialized_allocator_relocate to implement more optimizations in vector.

[AdvenamTacet]

Alright, I will update that PR accordingly in the coming week.

[vitalybuka]

I assume work in progress.