Feature: Embedded design
speed, and more. T e test cycle also captures some optional compiler results, like debug information. Compliance tests are fi rst compiled and
then executed to verify their behaviour against the C standard. T e test execution is then simulated for the target platform. T e simulation test-case binaries check the correctness of the compilation from start to fi nish. T e SuperTest built-in utilities capture and summarise statistical data about the test runs, helping evaluate the test cycle. It is straightforward to compare test results from diff erent test runs against the approved reference version.
Common errors One very valuable feature of SuperTest is detecting and uncovering deviations from the C language standard as implemented by the compiler. Although catastrophic errors are not oſt en expected in a mainstream variant of GCC, the situation is diff erent when GCC is customised for a specifi c target architecture that has not been the focus of the developer community. Individual adaptations for specifi c architectures are aff ecting essential language attributes such as the scope and defi nition of data types and, thus, most likely bring their own defi nitions within the C standard. T e same applies to common infrastructure, such as calling conventions or even when architecture- specifi c language extensions are added. Here SuperTest gives that assurance that the compiler is solid. Severe errors found during a test
cycle oſt en show as internal compiler error messages like “segmentation fault”, for example. It requires very good understanding of the inner workings of a compiler to even fi nd an entry point to start investigating the problem causing such an error. However, reasons for internal compiler errors and crashes are manifold and you don’t want your customers to encounter any of them.
Compiler rules T e GCC compiler is constructed around rules that dictate what patterns to look for when analysing the input program, and how to transform it into machine code. T ese analyses are performed on diff erent internal
representations of the actual source code. Well-known formats for GCC are
“intermediate representation” (IR) and “register transfer level” (RTL). T ey enable diff erent perspectives and operations for transforming and optimising the program code. A GCC compiler engineer then develops rules to analyse, break down and transform the IR, and optimise it for a specifi c target architecture, implemented by rules that match patterns in the IR. GCC has non-trivial rule formats. Here,
a compiler engineer’s extensive experience counts for a lot, as does a study of other compiler implementations. T e shape of the rules and their sequencing is almost artistic craſt manship and is undeniably prone to mistakes. Even worse, these mistakes only show up in very specifi c paths through a compiler’s control or data fl ow, with limited options as to how to avoid them. Apart from entrusting rule design only to
distinguished engineers and reviewing their contributions by an equally-distinguished group of peer developers, the best option is to test – extensively! T is in turn requires a test suite with a huge, heterogeneous spectrum of diff erent test cases, like SuperTest. Although a test suite can hardly be designed
to provide test cases matching specifi c rules that a compiler engineer might have created, SuperTest provides a broad variety of source code constructs that trigger corresponding analyses and transformation rules, no matter their design detail. T at way SuperTest also helps uncover the most complex bugs that can occur in a compiler tool.
20 February 2022
www.electronicsworld.co.uk
SuperTest ISO standards
conformance testing
Registers and libraries T ere’s another frequently-encountered internal error: “In extract_constrain_insn, at recog.c:2213”. Is this more informative than “segmentation fault”? Normally, this one is associated with register allocation problems. T e challenge for register allocation is
to place program variables into machine registers. T e more active variables there are in the source code and the fewer registers the target architecture has, the more diffi cult this is for the compiler. SuperTest provides a rich set of variable
manipulations that extract the most out of the source code and thus constitute challenges for the compiler’s register allocation. However, beyond detecting the error, the compiler engineer is still challenged with fi nding the actual root of the problem. T at is generally due to the branched and interconnected nature of analyses, rules, transformations and optimisations in the compiler and the many paths through this network. For a C compiler it is very common and
good practice to provide a set of libraries with functions specifi cally optimised for the respective target architecture. T is is achieved by using knowledge about how the respective compiler can best optimise particular source- code constructs. It can use inline assembler code and language extensions (e.g. special data types) that perform particular operations very effi ciently. An example is the C function to dynamically allocate and reserve contiguous blocks of memory, “malloc()”. Depending on the memory size and alignment attributes of the target architecture, the parameters designed for the malloc function and its
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46
