OSPP2024: 基于LLVM实现静态调用栈分析工具 · Pull Request !96 · openEuler/llvm-project

# Overview
This PR implements a static analysis tool for the call stack analysis based on LLVM. The tool is designed to help developers analyze call stacks in LLVM bitcode files (.bc) and identify potential stack overflow issues. It provides two main analysis options to understand the call graph structure and its implications on stack usage.

# Run Tests
```bash
llvm-lit llvm/test/tools/stackanalyzer
```

# Usage
To use the tool, use the following command format:

```
stackanalyzer [options] <Input .bc file>
```
# Options:
## `--analysis`
Outputs possible paths in the call graph that could potentially lead to stack overflow. Any recursive function will be considered a potential path due to the unbounded stack size usage that can not be estimated at compile time.

## `--callgraph`
Outputs the complete call graph of the provided .bc file. This is useful for understanding the overall structure and flow of function calls within the program.

## `--entry` (optional)
Specifies the entry point function for the analysis. By default, the tool will analyze the call graph starting from some function by the linking order. However, using this option, you can set a different function as the entry point. This is useful when you want to focus the analysis on a specific portion of the codebase, especially in cases where the program has multiple entry points or when you are interested in analyzing a particular module or function.

## `--anders` (optional)
Uses Andersen's pointer analysis to evaluate the call graph of the given .bc file. This option provides a more sound analysis of the call graph compared to previous `CallGraphAnalysis` Pass, considering pointer aliasing.

## `--stacksize=<uint>` (optional)
Sets the maximum stack size limit for a path within the call graph. This option is used in conjunction with the --analysis option to determine which paths might exceed the specified stack size, allowing for early detection of potential stack overflows. The default value is 1024 bytes.

## `-o` (optional)
Generate a callgraph in .dot format with call stack cost labeled for each function. It should be used together with `--callgraph`.

## `--target` (optional)
Specifying the backend target to analyzed, use the default build target if not set, eg. x86, aarch64.

# Example Command:
```
# Compile the source files foo.c and bar.c into LLVM bitcode files
clang -emit-llvm -c foo.c -o foo.bc
clang -emit-llvm -c bar.c -o bar.bc

# Link the generated bitcode files into a single bitcode file
llvm-link *.bc -o foobar.bc

# Analyze the call stack for potential stack overflows with a specified stack size limit
stackanalyzer --analysis --stacksize=1024 foobar.bc

# Alternatively, generate the call graph with stack size information
# The output will be in .dot format, which can be visualized with graph visualization tools
stackanalyzer --callgraph foobar.bc -o callgraph.dot
```
To enable cross-file analysis, users first need to link multiple bitcode files into a single one using `llvm-link`, `stackanalyzer` will analyze the `foobar.bc` file and output potential call graph paths that could cause a stack overflow if the stack size exceeds 1024 bytes.
# Implementation
- The tool utilizes the `.su` file, generated when emitting an LLVM bitcode file to an object file by turning on `stack-usage` option, to obtain stack size information for each function.
- Andersen's pointer-style analysis is implemented to refine the potential call graph, improving the soundness of the callgraph analysis.

# Evaluation in a Real-World Program
Evaluating the effectiveness of a static analysis tool, particularly one designed to identify potential stack overflows, presents challenges due to the lack of ground truth when analyzing real-world programs. Considering this fact, the following simple evaluation mainly focuses on the pointer analysis component, which plays a critical role in refining the call graph. The following procedure was used to evaluate the tool on gawk-4.2.0.

### Procedure

```bash
# Build gawk and generate bitcode files
wget https://ftp.gnu.org/gnu/gawk/gawk-4.2.0.tar.gz
tar zxvf gawk-4.2.0.tar.gz
cd gawk-4.2.0/
./configure CC=clang
make CC=clang CFLAGS+="-emit-llvm -c"
llvm-link *.o -o single.bc

# Analyze the call graph of the generated bitcode file
stackanalyzer --callgraph single.bc [--anders] -o callgraph.dot
```

## Result
As an example, consider the function `next_sourcefile` defined in `awkgram.c`. Here is a code snippet of this function from the gawk-4.2.0 source code:
```c
// gawk-4.2.0/awkgram.c
static void
next_sourcefile()
{
  static int (*closefunc)(int fd) = NULL;

if (closefunc == NULL) {
    char *cp = getenv("AWKREADFUNC");

/* If necessary, one day, test value for different functions.  */
    if (cp == NULL)
      closefunc = close;
    else
      closefunc = one_line_close;
  }
  // ...
}
```
With the `--anders` option enabled, `stackanalyzer` successfully infers that this function calls both `close` and `one_line_close`. This demonstrates the enhanced precision of the tool when using Andersen's pointer analysis, albeit with a significant increase in analysis time. The trade-off between accuracy and performance is evident, making the choice of whether to enable `--anders` dependent on the specific requirements of the analysis task.
![output callgraph edges for `next_sourcefile` when disabling `--anders`](https://foruda.gitee.com/images/1723963213472947650/ed469cda_9423380.png)
*Figure 1: output callgraph edges for `next_sourcefile` when disabling `--anders`*

![output callgraph edges for `next_sourcefile` when disabling `--anders`](https://foruda.gitee.com/images/1723964237166815263/dd2294d1_9423380.png)
*Figure 2: output callgraph edges for `next_sourcefile` when enabling `--anders`*

You can also try to dump paths that might cause call stack overflow (limit: 2040 bytes) started from `main` on your default platform using the following command:
```bash
stackanalyzer --analysis single.bc --entry=main --stacksize=2048
```
and here is its output:
```bash
Potential stack overflow path found(limit:2048 bytes):
CallStack:
  main: 72 bytes.
  dump_prog: 40 bytes.
  pprint: 296 bytes.
  pprint: 296 bytes.
Analysis:
- Recursive call without proper base case check.
- Unbounded recursion may lead to stack overflow.
Potential stack overflow path found(limit:2048 bytes):
CallStack:
  main: 72 bytes.
  debug_prog: 56 bytes.
  unserialize_list: 56 bytes.
  unserialize_breakpoint: 88 bytes.
  parse_condition: 120 bytes.
  parse_program: 24 bytes.
  yyparse: 2648 bytes.
Analysis:
- Stack usage exceeds the limit along the call stack.
- Total stack usage: 3064 bytes.
Potential stack overflow path found(limit:2048 bytes):
CallStack:
  main: 72 bytes.
  debug_prog: 56 bytes.
  unserialize_list: 56 bytes.
  unserialize_list_item: 120 bytes.
  parse_condition: 120 bytes.
  parse_program: 24 bytes.
  yyparse: 2648 bytes.
Analysis:
- Stack usage exceeds the limit along the call stack.
- Total stack usage: 3096 bytes.
Potential stack overflow path found(limit:2048 bytes):
CallStack:
  main: 72 bytes.
  debug_prog: 56 bytes.
  unserialize_list: 56 bytes.
  unserialize_list_item: 120 bytes.
  unserialize_commands: 24 bytes.
  zzparse: 2312 bytes.
Analysis:
- Stack usage exceeds the limit along the call stack.
- Total stack usage: 2640 bytes.
Potential stack overflow path found(limit:2048 bytes):
CallStack:
  main: 72 bytes.
  debug_prog: 56 bytes.
  zzparse: 2312 bytes.
Analysis:
- Stack usage exceeds the limit along the call stack.
- Total stack usage: 2440 bytes.
Potential stack overflow path found(limit:2048 bytes):
CallStack:
  main: 72 bytes.
  arg_assign: 88 bytes.
  r_get_lhs: 40 bytes.
  array_vname: 88 bytes.
  make_aname: 24 bytes.
  make_aname: 24 bytes.
Analysis:
- Recursive call without proper base case check.
- Unbounded recursion may lead to stack overflow.
Potential stack overflow path found(limit:2048 bytes):
CallStack:
  main: 72 bytes.
  parse_program: 24 bytes.
  yyparse: 2648 bytes.
Analysis:
- Stack usage exceeds the limit along the call stack.
- Total stack usage: 2744 bytes.
```

openEuler/llvm-project .gitee-modal { width: 500px !important; }

搜索帮助

openEuler/llvm-project