You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
@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.
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.
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:
If we break in
DoTheThing
and try to passt
toSaveThing
, 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
The text was updated successfully, but these errors were encountered: