proposal: cmd/compile: do not implicitly set `-checkptr` to 2 when `-asan` is turned on

[zhangfannie]

To implement -asan to detect invalid memory access to the stack object, it does not add readzones around the stack object like the implementation of the heap object, but implicitly sets -checkptr to 2, which is implemented by CL 393315. In this way, all pointer operations on the stack objects will become operations on the escaped heap objects. As we've already supported ASan detection of error memory accesses to heap objects. With this trick, we can use -asan option to report errors on bad stack operations.

However, based on the current implementation, when -asan is turned on, stack objects oprated with unsafe.Pointer will escape to the heap, resulting in additional memory alloctions. This will cause some issues. For example, turning on -asan will cause some tests to fail, see #64257. More seriously, some codes do not allow memory allocation, so -asan cannot be used, see #64310.

So I'm wondering if the implementation of setting -checkptr to 2 is doing more harm than good. I would like to suggest changing this implementation and instead of setting -checkptr to 2, just set -checkprt to 1 like -msan and -race do. But this way, -asan cannot check for invalid memory access to stack objects. If the user wants to use -asan to check, they can explicitly set -checkptr to 2.

Thank you.

[mdempsky]

[Sorry for the administrative noise. I thought the policy of enabling -d=checkptr for instrumentation was specified in cmd/go, but it looks like it's actually in cmd/compile.]

It seems fine to me to stop kicking objects to the heap aggressively for -asan if it's causing problems.

[znkr]

With regards to #64310. The code in question is so special that we can live with annotating every function. We already need to do that for the race detector anyway. That said, it was a bit frustrating to debug that issue.