The first set of Ghidra import test cases relied on external packages. Add new import test cases compiled (or assembled) from source code with an imported cross-platform toolchain.
Initially, the test cases will use a riscv-64, gcc 12 linux toolchain with C, C++, and possibly assembly sources. The build options should try to model a mix of normal user process, user sharable library, and loadable kernel module elements.
The first tests are limited to exercise features involving riscv-64 relocation and concurrency controls.
Example:
Compile the following with a riscv-64 toolchain with PIE enabled and PIC disabled.
char bssString[4096];
#include <stdio.h>
int
main (void)
{
// exercise store into .bss with small offset
bssString[8] = 0;
// exercise store into .bss with 12 bit offset
bssString[2049] = 0;
// reference bssString to prevent optimization erasure and pass a bss address as a parameter
printf(bssString);
return 0;
}
Readelf shows that this generates an object file with multiple relocation types - more relocations than lines of actual code!
the toolchain configuration used to compile that source code into an object file and a linked executable
readelf or other analyses of the generated output
a Ghidra decompiler export from the object file that should essentially match the input source code
optionally include other data, such as the Gnu assembler source code emitted by the gcc compiler
RISCV has a lot of different relocation codes. To get started, we will ignore any RISCV relocation codes that aren't known to the binutils-2_40 assembler. So we will care about relocations to GOT and BSS, but ignore relocations into things like task-local storage. Debugging relocations and frame tables are similarly out of scope.
The first set of Ghidra import test cases relied on external packages. Add new import test cases compiled (or assembled) from source code with an imported cross-platform toolchain.
Initially, the test cases will use a riscv-64, gcc 12 linux toolchain with C, C++, and possibly assembly sources. The build options should try to model a mix of normal user process, user sharable library, and loadable kernel module elements.
The first tests are limited to exercise features involving riscv-64 relocation and concurrency controls.
Example:
Compile the following with a riscv-64 toolchain with PIE enabled and PIC disabled.
Readelf shows that this generates an object file with multiple relocation types - more relocations than lines of actual code!
A successful test case will bundle:
RISCV has a lot of different relocation codes. To get started, we will ignore any RISCV relocation codes that aren't known to the
binutils-2_40
assembler. So we will care about relocations to GOT and BSS, but ignore relocations into things like task-local storage. Debugging relocations and frame tables are similarly out of scope.