Add Go-specific hacks to fix demo.go

[cgaebel]

See the comment in trace_writer.ml for more details about what this entails. The gist of what I've done here is review every call to gogo within demo.go and make sure the stack returns to the right spot.

This definitely fixes demo.go, but I'm not sure if it's sufficient for full-fledged go programs. @prattmic, could you please try out the artifact built by this CI run and let me know if it works on more a non-trivial go program you have lying around?

Refs #100, but does not fix it.

Here's a copy of the trace file generated by this PR for the go demo.

And here's a screenshot of it:

[Xyene]

Looks good, thanks!

[prattmic]

Oh wow, thanks for working on this! This is much better, but I think things are getting a bit confused. I took a look at a trace of gofmt, the autoformatter, which I'd call a medium size program. You can build it yourself with the proper dwarf flags:

$ go build -ldflags=-compressdwarf=false -o /tmp/gofmt cmd/gofmt

And point at a directory with a bunch of Go files. I used:

$ _build/default/bin/magic_trace_bin.exe run -multi-thread /tmp/gofmt -- $(go env GOROOT)/src/runtime/*.go

The trace generally looks much better than before this PR, but I still see some mixups.

1. Extra frames above new goroutine:

Here in "main 4", we switch from a goroutine running go/printer code to a GC worker running runtime.gcBgMarkWorker [1]. Notice that go/printer.(*printer).block appears as a caller of runtime.gcBgMarkWorker, which is not the case. runtime.gcBgMarkWorker should be the top frame.

Interestingly, sometimes these extra frames are dropped later. e.g., here we lose the go/printer.(*printer).block frame after a call to runtime.systemstack.abi0.

Here is a different case that looks much worse:

I think this is actually the same problem as above though. gofmt starts one main.processFile goroutine per input file, so I think we are just seeing extra frames added each time we switch between those goroutines.

These are just my initial impressions, I still want to take a closer look and perhaps hack on the heuristics to see what I can do. One case I want to check out is asynchronous preemption, which I worry may be broken given that I see the code looking for specific callees after gogo.

[1] N.B. Though this is part of the GC, it is just a normal goroutine, nothing special.

[cgaebel]

Thanks for trying this out, and the tip to try out gofmt. Despite being imperfect, this PR is a clear improvement on the status quo, so I'm going to merge it as-is.

Next, I'll let you take a whack at improving the heuristic. Hopefully this PR can act as a guide to what you'd need to change and where. Let me know if you give up and I'll come back to this.

I recommend making reduced perf scripts tests as you work. See test/perf_script.mli for how to do so, and the test I added in this feature as an example of one. They drastically speed up iteration speed when trying out different hacks. And you get a free regression test out of it!

Depending on what you learn as you hack on this, you may learn that a heuristic is impossible. For example, we know that's true for certain classes of exception in OCaml. For OCaml, we're going to have the compiler generate a guide of where exceptions jump to in a binary's elf notes. I would not be against adding a similar level of integration with the go compiler.

[cgaebel]

Oh, I just thought of another hack that might work:

When gogo jumps somewhere else, close stack frames until either hitting the bottom of the stack or the function you're jumping into.

@prattmic

[prattmic]

Next, I'll let you take a whack at improving the heuristic. Hopefully this PR can act as a guide to what you'd need to change and where. Let me know if you give up and I'll come back to this.

Sounds good. I'm about to go on vacation for a few weeks, but hope to get back to this at some point.

[cgaebel]

Ok. I'll probably get around to trying the alternative hack in that time. I'll let you know how that goes.