OneFile is a tool for mangling C source files. For historical reasons, the 502.gcc_r benchmark in the SPEC CPU2017 suite can only compile C programs that exist in a single compilation unit. Most large and interesting programs are designed to be modular and are saved in multiple files which splits the compilation process into several compilation units. Therefore, OneFile attempts to transform multiple-compilation-units programs into single-compilation-unit programs.
To use OneFile you need to be in a directory which contains a directory named
must contain the C source files that are to be transformed into a single-compilation-unit program
outfile is the name of the single-compilation-unit program. E.g. the name of the resulting
OneFile successfully created single compilation units for the code source used for the 505.mcfr and 519.lbmr (with one manual fix required to insert a macro definition as explained below) from the SPEC CPU 2017 benchmark suite and for
johnripper, which is a password cracker. These benchmarks have a simple source-code organization: all the .c and .h files are in the root directory, and hence there are no files with the same name.
There are some known limitations of this tool. One problem we encountered is with different .h files that have the same name. This was not a problem in the original C project that we were trying to convert because the .h files were in different directories. However, when placing them in the same directory in order to produce the single-file workload required by 502.gcc_r, multiple files with the same name becomes a problem. The solution was to include the entire path to each file in its name and to fix the include directives accordingly.
When an error is identified by the OneFile tool, the error is reported in the original source file where the line causing the error was extracted from. There is a corresponding line in the single-file source that was generated by the OneFile tool. Fixing the error (as explained with the 519.lbm_r below) may involve mapping the line to the correct line in the single-file source generated by OneFile.
Another known issue is the need to address compilations that contain macro definitions.
At the moment, OneFile calls gcc without any -D flags.
This means that macro definitions stated in Makefiles will not be considered during the single-file transformation problem.
Macros that are defined in source code that are defined between conditional
#ifdef blocks will also not be considered.
This macro issue has not been addressed.
For instance, when generating a single-file version for the 519.lbmr benchmark program, the OneFile tool will
However, trying to compile the single-file version of 519.lbmr benchmark program with the 502.gcc_r will fail.
This will be the error message seen:
modified/includes.c: In function 'global_opt':
modified/includes.c:642:45: error: expected ')' before 'PRId64'
modified/includes.c:644:45: error: expected ')' before 'PRId64'
modified/includes.c:653:62: error: expected ')' before 'PRId64'
modified/includes.c:661:61: error: expected ')' before 'PRId64'
modified/includes.c: In function 'main':
modified/includes.c:706:44: error: expected ')' before 'PRId64'
modified/includes.c: In function 'primal_feasible':
modified/includes.c:872:61: error: expected ')' before 'PRId64'
modified/includes.c:880:43: error: expected ')' before 'PRId64'
The messages identifies the error in the non-existent
modified/includes.c file, however the error will be located in the single-file version of 519.lbmr.
This specific error is because the macro
PRId64 was not defined.
In the original 519.lbmr source the
PRId64 macro is defined conditionally.
Adding a definition of the
PRId64 macro manually will allow the single-file version of 519.lbm_r to compile to assembly using SPEC's gcc version.
There are some cases in which a definition is placed out of order and an unsatisfied dependence will cause the program to fail. OneFile will warn the user when this happens and the user will be required to manually inspect the code.
The OneFile tool supports the creation of new workloads for the 505.mcf_r benchmark in the collection of new workloads for the SPEC CPU 2017 benchmark suite designed at the University of Alberta in collaboration with Universidade de Campinas in Brazil. Please visit the website to read the detailed report which includes a walkthrough of the program.