I've wanted this as well.

/cc @aclements

I've just tried discovering some performance data with tracing, also noting that go tool profile has a -pprof option, which however doesn't give out some kind of cpuprofile like output that would give us a bundled performance overview, or data suitable for a flame graph or something like the call graph options from pprof. This would be a great thing to have. Maybe I'm just not connecting the dots here, if it's possible to get this overview somehow differently?

I assume you mean go tool trace, not go tool profile. I'm not sure I quite understand what you're asking, but the execution trace currently doesn't have enough information in it to produce any sort of call graph profile. We could add profiling samples to the trace, which could then be extracted as a profile, though that wouldn't be any different from simply taking a pprof CPU profile (unless you filtered it or something first, as suggested by @FiloSottile).

I think there's some difference with pprof as the trace is complete and pprof is sampled, no?

While that's true, the differences are far more drastic. The execution trace records specific runtime events, like goroutine scheduling, network events, and GC.

Basically I'd want a full pprof profile (without sampling)

It sounds like what you want is a function call trace, which is not what runtime/trace is (or anything else built in to Go). Function call traces are very expensive to collect, which makes them basically useless for performance optimization. There has been recent work on this topic in general (e.g., https://research.google.com/pubs/pub45287.html), but even that has 20–40% overhead when enabled.

I've re-titled this to be what I understand the request to be, which is not actually CPU profiling, but function entry/exit tracing. That's a reasonable feature request, and one could imagine implementing something like XRay for Go, though I don't think anyone is going to work on this unless there's significantly more demand for it. It may be that in the long run something like Intel Processor Trace (PT) is a better answer.

The other issue of adding CPU profiling samples to the execution trace is #16895.

Given that doing this efficiently is basically an active research topic, we're not going to lead here. The "profiles during SIGPROF" is #16895, which is still open, but I'm going to close this issue.

(There's also #16619 for user-defined events, which you might use (if we had it) in this situation.)