Rust核心团队将64位ARM上的Linux提升至第1层支持平台状态

我们用来组织在提交RFC之前完成的所有工作的指导方针是现有的目标层策略文档，不幸的是，在我们进行的所有讨论中，堆栈探测方面没有直接或间接地出现。毫无疑问，这显然是一个需要填补的空白。

正如前面提到的：目前，在LLVM中添加对AArch64的堆栈探测支持的工作计划于今年第四季度开始，作为Linaro工具链工作组活动(前面提供的链接)的一部分。不幸的是，这并不是一个保证(它涉及投票等)，所以考虑到这里的叙述，我们现在将尝试寻找替代方法来填补这一空白。我个人非常有信心，我们将在合理的时间框架内解决这个问题。然而，目前还不可能说明确切的时间。根据过去的经验，考虑到与所讨论的处理器目标相关联的多个三元组的潜在含义，这种类型的编译器模块在登陆主线repos之前确实倾向于拖延相当长的一段时间。

正如这里前面提到的：堆栈冲突-堆栈探测是缓解的主要场景-可以说是一种可以利用的病态场景。当然，我不是想轻视这种情况，但我想把它作为一个事实摆在桌面上，我觉得在做出这样的决定时应该考虑到这一点。我确实意识到，围绕这里缺乏堆栈探测而使用的一些争论的方向有点不同-就像在-它引发了人们对Rust POV的UB影响的担忧，而不是更直接的堆栈冲突现实。我还是觉得最好提出来。完全同意已经提出了一个明确的问题，无论如何，我们希望看到正确的解决方案发生-即使这意味着RFC的合并被推迟。

关于延迟：在这样一个论坛上阐述这是一个有点不寻常的问题，但我觉得这样做很重要。请注意，这是我个人的观点。这需要相当多的工程：实际的、社会的和战略的，才能让ARM这样的组织中的合适人员认识到Rust为ARM生态系统提出的价值主张。就像任何这样的组织不可避免的情况一样，感知和光学在塑造长期战略行动的轨迹方面发挥着强大的作用-特别是围绕相对较新的技术。今天，我们知道AArch64 Linux上的Rust已经在生产了，尽管这个目标三元组没有Tier-1；徽章(因为没有更好的短语)。这已经是个好兆头了，这很好。然而，没有徽章确实限制了这种语言的普及速度，特别是在基于AArch64的Linux系统上-这些系统在惊人的市场领域非常受欢迎-其中大多数都非常适合Rust。