Mix Testing: Specifying and Testing ABI Compatibility of C/C++ Atomics Implementations

Luke Geeson, James Brotherston, Wilco Dijkstra, Alastair F. Donaldson, Lee Smith, Tyler Sorensen, John Wickerson
{"title":"Mix Testing: Specifying and Testing ABI Compatibility of C/C++ Atomics Implementations","authors":"Luke Geeson, James Brotherston, Wilco Dijkstra, Alastair F. Donaldson, Lee Smith, Tyler Sorensen, John Wickerson","doi":"arxiv-2409.01161","DOIUrl":null,"url":null,"abstract":"The correctness of complex software depends on the correctness of both the\nsource code and the compilers that generate corresponding binary code.\nCompilers must do more than preserve the semantics of a single source file:\nthey must ensure that generated binaries can be composed with other binaries to\nform a final executable. The compatibility of composition is ensured using an\nApplication Binary Interface (ABI), which specifies details of calling\nconventions, exception handling, and so on. Unfortunately, there are no\nofficial ABIs for concurrent programs, so different atomics mappings, although\ncorrect in isolation, may induce bugs when composed. Indeed, today, mixing\nbinaries generated by different compilers can lead to an erroneous resulting\nbinary. We present mix testing: a new technique designed to find compiler bugs when\nthe instructions of a C/C++ test are separately compiled for multiple\ncompatible architectures and then mixed together. We define a class of compiler\nbugs, coined mixing bugs, that arise when parts of a program are compiled\nseparately using different mappings from C/C++ atomic operations to assembly\nsequences. To demonstrate the generality of mix testing, we have designed and\nimplemented a tool, atomic-mixer, which we have used: (a) to reproduce one\nexisting non-mixing bug that state-of-the-art concurrency testing tools are\nlimited to being able to find (showing that atomic-mixer at least meets the\ncapabilities of these tools), and (b) to find four previously-unknown mixing\nbugs in LLVM and GCC, and one prospective mixing bug in mappings proposed for\nthe Java Virtual Machine. Lastly, we have worked with engineers at Arm to\nspecify, for the first time, an atomics ABI for Armv8, and have used\natomic-mixer to validate the LLVM and GCC compilers against it.","PeriodicalId":501197,"journal":{"name":"arXiv - CS - Programming Languages","volume":"109 1","pages":""},"PeriodicalIF":0.0000,"publicationDate":"2024-09-02","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"0","resultStr":null,"platform":"Semanticscholar","paperid":null,"PeriodicalName":"arXiv - CS - Programming Languages","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/arxiv-2409.01161","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
引用次数: 0

Abstract

The correctness of complex software depends on the correctness of both the source code and the compilers that generate corresponding binary code. Compilers must do more than preserve the semantics of a single source file: they must ensure that generated binaries can be composed with other binaries to form a final executable. The compatibility of composition is ensured using an Application Binary Interface (ABI), which specifies details of calling conventions, exception handling, and so on. Unfortunately, there are no official ABIs for concurrent programs, so different atomics mappings, although correct in isolation, may induce bugs when composed. Indeed, today, mixing binaries generated by different compilers can lead to an erroneous resulting binary. We present mix testing: a new technique designed to find compiler bugs when the instructions of a C/C++ test are separately compiled for multiple compatible architectures and then mixed together. We define a class of compiler bugs, coined mixing bugs, that arise when parts of a program are compiled separately using different mappings from C/C++ atomic operations to assembly sequences. To demonstrate the generality of mix testing, we have designed and implemented a tool, atomic-mixer, which we have used: (a) to reproduce one existing non-mixing bug that state-of-the-art concurrency testing tools are limited to being able to find (showing that atomic-mixer at least meets the capabilities of these tools), and (b) to find four previously-unknown mixing bugs in LLVM and GCC, and one prospective mixing bug in mappings proposed for the Java Virtual Machine. Lastly, we have worked with engineers at Arm to specify, for the first time, an atomics ABI for Armv8, and have used atomic-mixer to validate the LLVM and GCC compilers against it.
混合测试:规范和测试 C/C++ Atomics 实现的 ABI 兼容性
复杂软件的正确性既取决于源代码的正确性,也取决于生成相应二进制代码的编译器的正确性。编译器不仅要保留单个源文件的语义,还必须确保生成的二进制文件可以与其他二进制文件组成最终的可执行文件。编译器不仅要保留单个源文件的语义,还必须确保生成的二进制文件能与其他二进制文件组成最终的可执行文件。组成的兼容性是通过应用程序二进制接口(ABI)来保证的,该接口指定了调用约定、异常处理等细节。遗憾的是,目前还没有针对并发程序的官方 ABI,因此不同的原子映射虽然在孤立情况下是正确的,但在组合时可能会产生错误。事实上,如今混合使用不同编译器生成的二进制文件可能会导致错误的二进制结果。我们提出了混合测试:这是一种新技术,旨在发现 C/C++ 测试指令在为多种兼容架构分别编译后混合在一起时的编译器错误。我们定义了一类编译器错误,称为混合错误,当程序的各个部分分别使用不同的映射从 C/C++ 原子操作编译到汇编序列时,就会出现这类错误。为了证明混合测试的通用性,我们设计并实现了一个工具--原子混合器,并使用了它:(a) 重现了一个现有的非混合 Bug,而最先进的并发测试工具只能发现这些 Bug(表明 atomic-mixer 至少达到了这些工具的能力);(b) 在 LLVM 和 GCC 中发现了四个以前未知的混合 Bug,并在为 Java 虚拟机提出的映射中发现了一个潜在的混合 Bug。最后,我们与 Arm 公司的工程师合作,首次为 Armv8 确定了原子 ABI,并使用原子混合器对 LLVM 和 GCC 编译器进行了验证。
本文章由计算机程序翻译,如有差异,请以英文原文为准。
求助全文
约1分钟内获得全文 求助全文
来源期刊
自引率
0.00%
发文量
0
×
引用
GB/T 7714-2015
复制
MLA
复制
APA
复制
导出至
BibTeX EndNote RefMan NoteFirst NoteExpress
×
提示
您的信息不完整,为了账户安全,请先补充。
现在去补充
×
提示
您因"违规操作"
具体请查看互助需知
我知道了
×
提示
确定
请完成安全验证×
copy
已复制链接
快去分享给好友吧!
我知道了
右上角分享
点击右上角分享
0
联系我们:info@booksci.cn Book学术提供免费学术资源搜索服务,方便国内外学者检索中英文文献。致力于提供最便捷和优质的服务体验。 Copyright © 2023 布克学术 All rights reserved.
京ICP备2023020795号-1
ghs 京公网安备 11010802042870号
Book学术文献互助
Book学术文献互助群
群 号:481959085
Book学术官方微信