The Go runtime does not have the machinery to read DWARF. That machinery is available in the debug/dwarf package, but debug/dwarf depends on a number of other packages, which are also not in the Go runtime. Bringing debug/dwarf into the runtime would not be trivial, and it would not be a relatively small addition. It would also increase the size of all Go programs, for the benefit of a much smaller number of programs.

The SetCgoTraceback facility was designed as it is exactly to avoid this problem.

We live in the time of containerized applications. In many cases, the only diagnostic operations can rely on for problem analysis is the stack trace.

Now we have the following situation:

1. "Upstream" developers may not even be aware their app has a cgo element. And cgo is not at all rare, being used in some very popular libraries (sqlite, opengl, etc).
2. Application crashing in cgo code gives out exactly zero information about what went wrong, especially on musl-libc.
3. Total defeat!

As to the binary size penalty, if can trivially be made conditional on actual cgo presence. No cgo - no penalty (plus tag to disable it if a particular developer feels lucky).

A Go program that crashes during a cgo call should display a stack trace for the Go code that made the call. I agree that a Go program that crashes in a thread newly started by C code will not display anything useful.

I would not be opposed to this change if someone can implement it without imposing any significant penalty on Go programs that do not use cgo. Unfortunately I think you are significantly underestimating the difficulty. I would be happy to be proven wrong.

The Go call is of course there, on the stack. The usual problem, though, that when something like SIGSEGV happens several frames into the native code, the knowledge of the last go function is not of particular use.

Your cgosymbolizer package is only a dozen of files. What's wrong with it being included by default?

The cgosymbolizer package is written partly in C and using it requires using the external linker. It's important to us that people be able to write pure Go programs that do not require installing a compiler and libraries.

That said I suppose we could consider adding cgosymbolizer to the runtime/cgo package. It would need to be ported to macOS. It won't work when using a C compiler other than GCC or clang.

The cgosymbolizer implementation does not provide a context function, meaning that it does not support a traceback when Go calls C calls Go. Supporting that is difficult, as it requires an implementation of the unwinder.