Support HWASan for memory detection

[PeacefulBlack]

I am using asan to detect memory leaks and other issues in the dart vm. But hwasan is not supported.
My first question is that is there any special reason why hwasan is not supported？

In addition, when I was trying to adapt the HWasan feature with reference to asan, I found some strange code. Are they bugs left over from previous development or do they have a special purpose?

1、In the implementation of Exceptions::JumpToFrame, it is necessary to unpoison the stack memory of the thread that encounter exceptions, but the stack address is deliberately subtracted by 1024 bytes. Why is the actual stack memory size deliberately subtracted by 1024 bytes?

uword current_sp = OSThread::GetCurrentStackPointer() - 1024; ASAN_UNPOISON(reinterpret_cast<void*>(current_sp), stack_pointer - current_sp);

I tracked the relevant git logs and found that the initial implementation here was
uword current_sp = reinterpret_cast<uword>(&program_counter) - 1024; __asan_unpoison_memory_region(reinterpret_cast<void*>(current_sp), stack_pointer - current_sp);

program_counter is a parameter of the function Exceptions::JumpToFrame whose address dose not contain t he stack frame of Exceptions::JumpToFrame, so I guess subtracting 1024 is to include the size of the stack content occupied by the function Exceptions::JumpToFrame itself in the unpoison range.

If my guess is correct, is there need to subtract an additional 1024 bytes now？ As the OSThread::GetCurrentStackPointer() function returns the address containing the stack frame of Exceptions::JumpToFrame.

2、I checked all the call points of the asan_unpoison function, there are some asan_unpoison calls in zone.cc and profiler.cc,. What are the purpose of these calls?

In profiler.cc the comments says that the asan_unpoison calls are due to some memory may actually be uninitialized by design. But asan does not check for uninitialized memory, which is the function of msan, so is the asan_unpoison call useful?

In zone.cc asan_unpoison function seems to be used to enable a certain memory detection feature when the asan option is turned on, such as performing memory unpoison before writing kZapDeleedByte to a specific memory region. However, I have not find any code to check kZapDeleedByte, so is this memory feature currently useless?

[mraleph]

I have added a rudimentary HWASAN support few weeks ago in 5f32e78, it seems to work in simple testing I have done with it.

If my guess is correct, is there need to subtract an additional 1024 bytes now？

I think you are correct. 97c6a8b should have just removed -1024.

I checked all the call points of the asan_unpoison function, there are some asan_unpoison calls in zone.cc and profiler.cc,. What are the purpose of these calls?

Unpoisons in zone.cc are likely leftovers from attempts to make ASAN aware of out custom allocators. See c7b2884 - which got reverted in ac06671 and never relanded. (cc @rmacnak-google).

Those in profiler.cc are likely because profiler can accidentally touch poisoned part of the stack when unwinding.

However, I have not find any code to check kZapDeletedByte, so is this memory feature currently useless?

kZapDeletedByte is just a debugging aid. If you have a crash and you see that memory is filled with 0x42 you can immediately know what happened to it.