链接器为Go类型生成go.info.*符号。它通过解析type.*符号的内容来实现这一点。它还依赖于这些type.*符号的名称，以便成功地找到其他符号。
所有这些使得链接器相当脆弱。decodesym.go中的逻辑必须与编译器的rtype代码生成、运行时和reflect包保持同步。根据type.符号名称与其他链接器想要执行的操作(如重命名符号)之间的交互不佳。
在编译器中生成这些go.info.*符号更容易，就在生成type.*符号的代码旁边。数据结构都在内存中整齐地排列，不需要我们在链接器中进行繁琐的部分解码。
看起来这部分已经完成，编译器为vars生成了go.info符号。将其余的类型符号逐步转移到编译器应该是可行的。
cc @heschik @dr2chase
6条答案
按热度按时间kmpatx3s1#
在链接器中是否需要进行任何DWARF生成？或者我们应该尝试将所有DWARF生成转移到编译器/汇编器？
例如，我们还从解码PC值表生成.debug_line节。如果我们在编译器中生成它们，我们可以包含列位置信息。
4uqofj5v2#
/cc @ianlancetaylor
cdmah0mi3#
大多数链接器根本不生成任何DWARF信息。
eivgtgni4#
我认为这很好，也许顺便能通过给每个包一个CU来帮助解决#21945的问题，但我在这里看不到明显的优势。也许我漏掉了什么。
decodesym.go似乎是一个杂项项目；它的一些功能只被DWARF生成器使用，但其他功能只在死代码消除中使用，还有一些功能在链接器的其他部分中使用。虽然我们不太可能完全删除这些代码，但似乎不太可能。
你能举一个例子说明这给我们带来了麻烦吗？除了你最近的重构之外，它大部分内容已经一年没有变了。
我想知道我们最终会创建多少冗余的类型DIE,以及这对链接器性能的影响有多大。包应该为声明的类型携带DIE,我们可以将字符串等解释为运行时包中的元素，因此可以引用而不是重新创建它们。那么对于Map和其他派生类型呢？我想我们可以为它们的alg函数做任何事情。
46scxncf5#
我想知道我们最终会创建多少冗余的DIE,以及这对链接器会产生多大的性能影响。
我预计冗余的DIE数量等于冗余的反射类型描述符的数量。
nukf8bse6#
1.12太晚了。