Go运行时没有读取DWARF的机制。这个机制在debug/dwarf包中可用，但是debug/dwarf依赖于许多其他包，这些包也不在Go运行时中。将debug/dwarf引入运行时并不是一件简单的事情，而且它也不是一个相对较小的附加项。它还会增加所有Go程序的大小，以使更少的程序受益。
SetCgoTraceback设施就是为了避免这个问题而设计的。

我们生活在集装箱化应用程序的时代。在许多情况下，唯一可以依赖的诊断操作来进行问题分析的就是堆栈跟踪。现在我们面临以下情况：

1. "上游"开发者可能甚至不知道他们的应用程序有一个cgo元素。而cgo并不罕见，它被用于一些非常流行的库(如sqlite、opengl等)。
2. cgo代码中的应用程序崩溃给出了关于出错原因的确切信息，尤其是在musl-libc上。
3. 全面失败！
   至于二进制大小的惩罚，如果可以轻易地将其设置为实际存在的cgo条件。没有cgo - 没有惩罚(如果某个开发者觉得幸运，还可以加上标签来禁用它)。

一个在cgo调用期间崩溃的Go程序应该显示导致调用的Go代码的堆栈跟踪。我同意，一个在C代码新启动的线程中崩溃的Go程序不会显示任何有用的信息。
如果有人能实现这个改变而不对不使用cgo的Go程序造成任何显著的惩罚，我不会反对这个改变。不幸的是，我认为你大大低估了这个难度。我很乐意被证明是错的。

当然，Go调用在栈上。然而，通常的问题是，当类似SIGSEGV的错误发生在原生代码的几个帧之后时，对最后一个Go函数的知识并没有特别大的用处。
你的cgosymbolizer包只有十几文件。它为什么默认被包含？

cgosymbolizer包部分用C编写，使用它需要使用外部链接器。对我们来说，重要的是人们能够编写纯Go程序，不需要安装编译器和库。
话虽如此，我想我们可以考虑将cgosymbolizer添加到runtime/cgo包中。它需要移植到macOS上。当使用除GCC或clang之外的C编译器时，它将无法工作。
cgosymbolizer实现没有提供上下文函数，这意味着它不支持在Go调用C、然后Go调用Go时的回溯。支持这一点很困难，因为它需要实现unwinder。