cmd/compile: //go:norace for ASAN and other instrumentation

[znkr]

What version of Go are you using (go version)?

tip

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

Linux with GOARCH='amd64' and GOARCH='arm64'

What did you do?

Our Go toolchain contains a patch that allows handling Go runtime crashes for reporting. Code that needs to run as part of that patch is very restricted. The biggest restriction is that it doesn't allow memory allocation. It's possible to write Go code that doesn't allocate memory, but it's near impossible when the code is instrumented. For example, to make the crash handling work with the race detector, all functions have to be annotated with //go:norace.

We're now running into this problem again when enabling ASAN using -asan. The problem is that when ASAN is enabled, the existing code starts to allocate memory where it doesn't without the instrumentation. My best guess is that the ASAN instrumentation leads to different escape analysis results. (I suspected inlining decisions as well, but I don't see any additional allocations when I disable inlining completely).

It would help a lot to be able to either disable ASAN instrumentation for crash handling functions with //go:noasan or, even better, to disable all instrumentation with, say,//go:noinstrumentation.

/cc @cherrymui, @dr2chase

[mauri870]

I wonder if this related to #64257

[cherrymui]

I wonder if this related to #64257

Not directly related, although it can be, e.g. it is possible that in order to make all tests passing some function needs to be marked no-instrumentation.

[zhangfannie]

The problem is that when ASAN is enabled, the existing code starts to allocate memory where it doesn't without the instrumentation. My best guess is that the ASAN instrumentation leads to different escape analysis results. (I suspected inlining decisions as well, but I don't see any additional allocations when I disable inlining completely).

@znkr The reason for allocating memory may be that when -asan is turned on, the -checkptr option is implicitly set to 2, which is implemented by CL 393315, so some stack objects with usafe.Pointer operations will escape to the heap, resulting in additional heap allocation. Does your code have stack objects with unsafe.Pointer operations?

I'm a little curious why no additional memory is allocated after disabling inlining. Does anyone know about this? Thanks.

[znkr]

@znkr The reason for allocating memory may be that when -asan is turned on, the -checkptr option is implicitly set to 2, which is implemented by CL 393315, so some stack objects with usafe.Pointer operations will escape to the heap, resulting in additional heap allocation. Does your code have stack objects with unsafe.Pointer operations?

Thank you, that's probably it. The code is unsafe.Pointer heavy out of necessity. I suspect there's no annotation to turn that off?

[cherrymui]

Thanks. There is //go:nocheckptr. Maybe you'd like to try that?

[znkr]

Thank you! I don't have time to test this right away, but I'll get to it eventually and will report back.

[znkr]

This worked, thank you very much!