Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile: provide parameter escape information in DWARF #27007

Open
heschi opened this issue Aug 15, 2018 · 5 comments
Open

cmd/compile: provide parameter escape information in DWARF #27007

heschi opened this issue Aug 15, 2018 · 5 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. Debugging
Milestone

Comments

@heschi
Copy link
Contributor

heschi commented Aug 15, 2018

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 heschi added this to the Go1.12 milestone Aug 15, 2018
@heschi
Copy link
Contributor Author

heschi commented Oct 31, 2018

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
Copy link
Contributor

@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
Copy link
Member

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
Copy link

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

@findleyr
Copy link
Contributor

findleyr commented Nov 3, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. Debugging
Projects
None yet
Development

No branches or pull requests

5 participants