Luke Geeson, James Brotherston, Wilco Dijkstra, Alastair F. Donaldson, Lee Smith, Tyler Sorensen, John Wickerson
{"title":"混合测试:规范和测试 C/C++ Atomics 实现的 ABI 兼容性","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":null,"pages":null},"PeriodicalIF":0.0000,"publicationDate":"2024-09-02","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"0","resultStr":"{\"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\":null,\"pages\":null},\"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}","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}
Mix Testing: Specifying and Testing ABI Compatibility of C/C++ Atomics Implementations
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.