gabi-250 / llvm-guard-handler Goto Github PK

View Code? Open in Web Editor NEW

1.0 3.0 0.0 152 KB

Experimenting with LLVM

License: MIT License

C++ 27.91% CMake 1.72% Makefile 3.28% C 62.80% Shell 0.16% Assembly 1.25% Python 2.87%

llvm-guard-handler's Introduction

llvm-guard-handler

Dependencies

The following libraries are required for the native guard failure handler to run:

In addition, Clang 5.0.0 must be installed.

To view the execution, it is necessary to install gdb or a similar debugger. It is recommended to use cgdb as an interface to gdb.

Using `llvm-guard-handler`

Clone the project using git clone --recursive https://github.com/gabi-250/llvm-guard-handler. This will also clone the llvm submodule, so it may take a few minutes to complete.

Compiling `llc`

The native guard failure handler requires a custom version of llc to run. For this reason, LLVM was included as a submodule of the project. To compile llc, cd into the folder in which you cloned the repository, and run:

cd src/llvm/
mkdir build
cd build
cmake ..
make llc

This will compile llc. Note that this may be a slow process.

Compiling the preprocessing passes

To compile the preprocessing passes, ensure the current directory is the root of the project and run:

cd src/passes
./build_pass

Running the test programs

To run the test programs, ensure the current directory is the root of the project and run:

cd src/tests/test_control_flow/passes/
./build_pass
cd ../../../
pytest tests

Using `gdb` to examine the execution

First, compile the test programs by running:

cd src/tests/test_programs
make

Then, run one of the resulting binaries in gdb. If, for example, you want to test the trace binary, run gdb trace.

In gdb, run the following commands to display the assembly instructions of the program, and the register state:

(gdb) layout asm
(gdb) layout regs

To set break points at the two recovery routines execute the following com- mands:

(gdb) break restore_inlined
(gdb) break jmp_to_addr

This will pause the execution before resuming execution in the unoptimised version of trace.

To run the program in gdb, type run. Then, to execute the next instruction, type ni. To view the state of the program, as the execution is being resumed in its unoptimised version, continue typing ni, until the execution completes. Alternatively, set multiple break points in the program, and use continue to run the program until the next breakpoint is reached.

llvm-guard-handler's People

Contributors

Stargazers

Watchers

llvm-guard-handler's Issues

Stackmap Insertions

Stackmaps should be inserted everywhere they may be necessary, not just in the trace and __unopt_trace functions.

Registers

Each frame_t has its own set of registers.

The frames which correspond to inlined functions are supposed to have the same register state as the function inside which they were inlined. If each frame_t stores its own register array, then the register state may become inconsistent.

Jumping to the Wrong Address

In trace.c, changing:

...
        uint64_t opt_location_value =
            stmap_get_location_value(sm, opt_rec.locations[i], r, bp);
        if (type == REGISTER) {
            uint16_t reg_num = unopt_rec.locations[i].dwarf_reg_num;
            uint64_t loc_size =
                stmap_get_location_value(sm, opt_rec.locations[i + 1], r, bp);
            memcpy(r + reg_num, &opt_location_value, loc_size);
...

...
        uint64_t opt_location_value =
            stmap_get_location_value(sm, opt_rec.locations[i], r, bp);
            uint16_t reg_num = 0;
        if (type == REGISTER) {
            reg_num = unopt_rec.locations[i].dwarf_reg_num;
            uint64_t loc_size =
                stmap_get_location_value(sm, opt_rec.locations[i + 1], r, bp);
            memcpy(r + reg_num, &opt_location_value, loc_size);
...

causes the wrong address to be stored in the stack map.

Direct Stack Map Locations

Direct stack map locations represent an alloca's relative location on the stack.

How many bytes to copy when mapping the direct locations of trace to the direct locations of __unopt_trace?

Live Variable Analysis

Which locations should be passed as arguments to llvm.experimental.stackmap and llvm.experimental.patchpoint?

Global Values

Global values are not currently recorded in the stack map. This means an llvm.experimental.patchpoint call inserted before an instruction such as printf might not record the correct state. This is because printf uses a format string, which is a global value.

For example, consider the following scenario: in the optimized version, the global value is loaded into a register after the call to the patchpoint intrinsic happens (so its value is never recorded), while in the unoptimized version, the global variable is loaded before the stackmap call.

Indirect Locations

Indirect stack map locations (register spills) are not currently handled.

Restoring Large Locations

Locations which cannot fit in a uint64_t are not restored correctly. This can be fixed by returning a uint64_t * in stmap_get_location_value.

Return Addresses

The return address is supposed to be 0x40313f, but the stackmap call generated for __unopt_get_number is at 0x403141.

11│    0x0000000000403137 <+23>:    mfence
12│    0x000000000040313a <+26>:    callq  0x403120 <__unopt_get_number>
13│    0x000000000040313f <+31>:    mov    %eax,%ebx
14│    0x0000000000403141 <+33>:    mfence
15│    0x0000000000403144 <+36>:    mov    %ebx,-0xc(%rbp)

Floating-point Registers (x86-64)

Live locations stored in floating-point registers cannot be restored, because unw_get_fpreg is not implemented for x86-64.

Functions with more than 6 arguments

The current implementation crashes if a guard fails in a function that takes more than 6 arguments, or inside a function called by a function with more than 6 arguments. The return address cannot be found, due to the fact that an incorrect number of values are popped off the stack after the call.

The unoptimized function:

...
  4035cc:	31 ff                	xor    %edi,%edi
  4035ce:	be 01 00 00 00       	mov    $0x1,%esi
  4035d3:	ba 02 00 00 00       	mov    $0x2,%edx
  4035d8:	b9 03 00 00 00       	mov    $0x3,%ecx
  4035dd:	41 b8 fb ff ff ff    	mov    $0xfffffffb,%r8d
  4035e3:	45 31 c9             	xor    %r9d,%r9d
  4035e6:	c7 04 24 0a 00 00 00 	movl   $0xa,(%rsp)
  4035ed:	c7 44 24 08 6e 00 00 	movl   $0x6e,0x8(%rsp)
  4035f4:	00 
  4035f5:	c7 44 24 10 e6 00 00 	movl   $0xe6,0x10(%rsp)
  4035fc:	00 
  4035fd:	e8 ae fe ff ff       	callq  4034b0 <__unopt_more_indirection2>
<the stack is not resized here, even though this instruction is reached from the optimized function, which pushes additional values to the stack>
...

The optimized function:

...
  4032a1:	31 ff                	xor    %edi,%edi
  4032a3:	be 01 00 00 00       	mov    $0x1,%esi
  4032a8:	ba 02 00 00 00       	mov    $0x2,%edx
  4032ad:	b9 03 00 00 00       	mov    $0x3,%ecx
  4032b2:	41 b8 fb ff ff ff    	mov    $0xfffffffb,%r8d
  4032b8:	45 31 c9             	xor    %r9d,%r9d
  4032bb:	68 e6 00 00 00       	pushq  $0xe6
  4032c0:	6a 6e                	pushq  $0x6e
  4032c2:	6a 0a                	pushq  $0xa
  4032c4:	e8 d7 fe ff ff       	callq  4031a0 <more_indirection2>
  4032c9:	48 83 c4 20          	add    $0x20,%rsp
...