cmd/compile: provide parameter escape information in DWARF

[heschi]

Now that we have function calls in debuggers (#21678), the next step is to make them safer. When the compiler generates a function call, it knows which parameters may leak to the heap, and makes sure that those parameters are heap-allocated. When a debugger forms a function call, it needs that same information so that it can do safety checks.

Just as a motivating example, consider:

var theThing *Thing
func SaveThing(t *Thing) {
   theThing = t
}

func MakeAThing() {
  var t Thing
  ...
  return t
}

func DoTheThing(t *Thing) {
   t := MakeAThing()
   ...
}

If we break in DoTheThing and try to pass t to SaveThing, the debugger should be able to warn the user that they may be setting themselves up for a crash by passing a stack-allocated variable to a function that could leak it to the heap. (This isn't always dangerous, since many parameters that "escape" don't actually get saved anywhere. Some human judgment is required.)

The most obvious implementation is to have the compiler add a bit to each function parameter's DWARF indicating whether it escapes or not. I think this should be as simple as copying (*gc.Node).Noescape() to a custom DWARF attribute.

cc @dr2chase, @aarzilli, @derekparker

[heschi]

I think this should be as simple as copying (*gc.Node).Noescape() to a custom DWARF attribute.

Hahahaha no. @griesemer, am I correct that I need to decode escape information from fn.Type.Params().FieldsSlice().Note? How do I do that?

[griesemer]

@heschik You'll have to look at cmd/compile/internal/gc/esc.go, func parseTag and func describeEscape. FWIW, the importer/exporter simply read/write the Node w/o interpretation.

[cherrymui]

fn.Type.Params().FieldsSlice().Note

Seems correct to me. The receiver is probably not on that list and needs to be handled separately.

Yeah, parsetag will get the encoding, which is described at https://go.googlesource.com/go/+/f6f27bfb97b8dcaa2350829dd043d7c5a5f341ab/src/cmd/compile/internal/gc/esc.go#357

[gopherbot]

Change https://golang.org/cl/146819 mentions this issue: cmd/compile: add DW_AT_go_param_escapes

[findleyr]

A bit of additional context: we've observed a few times in VS Code (recently golang/vscode-go#2522) that users are confused about why they can't watch strings.Builder.String(). It would be nice to be able to to fix this.