Actually, the compiler marks "unsafe points" for places that are not safe to be interrupted, and everywhere else is considered a safe point. In that sense, it is already safe point almost everywhere, except in a few specific places. The "call not at safe point" is due to that the stopped place is in the small range that are marked as an unsafe point. Could you show the source code and the disassembly of the stopped function? So we can see if there is anything we could do to improve the unsafe point situation. Thanks.

I'm not sure we can eliminate unsafe points entirely, as there are places where it is actually unsafe to make a call. Maybe certain functions are okay, but we don't know. Or maybe in some cases the debugger could single step to the end of the unsafe point (depending on the nature of the unsafe point, this may or may not change the program's state).

I'm taking this out of the proposal process, as it is not an API change.

Got a reproducer offline. It seems the compiler marks some seemingly safe code as unsafe points. Still looking into why this happens.

FYI unsafe point marking for write barriers will change in 1.21, due to https://go-review.googlesource.com/c/go/+/447777 (and related CLs).

Found the problem. For example, for this code

package p

var g int

func F(x []string) {
	g = 1
	for _, s := range x {
		f2(s)
	}
}

func f2(string)

it looks pretty safe. In particular, the store g=1 shouldn't be an unsafe point. However, it is currently marked as unsafe point:

    19        00025 (/tmp/x.go:7)	PCDATA	$0, $-2            // -2 is (starting) unsafe point
    19     -2 00025 (/tmp/x.go:7)	MOVQ	BX, p.x+56(SP)
    1e        00030 (/tmp/x.go:7)	PCDATA	$3, $2
    1e        00030 (/tmp/x.go:6)	MOVQ	$1, p.g(SB)        // this is the g=1 store
    29        00041 (/tmp/x.go:7)	XORL	CX, CX
    2b        00043 (/tmp/x.go:7)	JMP	96
    2d        00045 (/tmp/x.go:7)	MOVQ	CX, p..autotmp_9+16(SP)

This is due to

• the compiler marks uintptr->unsafe.Pointer conversions as unsafe points, and back propagates the unsafeness to a "very safe" point, i.e. a call, or the function entry.
• the code itself doesn't any unsafe, but currently the compiler generates unsafe pointer conversions for range loops, for the pointer increment of the loop variable.

Due to this, any code before a range loop from the last call or function entry would be marked unsafe.

The unsafe pointer conversions for range loop is from the IR lowering, where OCONVNOPs are emitted, which turn into SSA OpConvert. I wonder if we could somehow generate SSA OpAddPtr without the unsafe conversions? That would avoid this problem.

It might also be possible to eliminate the uintptr->unsafe.Pointer marking. This is subtle. I'll need to think more carefully.

Change https://go.dev/cl/461696 mentions this issue: cmd/compile: don't mark uintptr->unsafe.Pointer conversion unsafe points