如何基于参数使用自动确定C函数间的依赖关系？

Great question—this is a classic problem in program analysis, especially when you’re trying to untangle shared state dependencies between functions. Let’s break down your approach and walk through practical, actionable steps to make this work.

Short answer: Absolutely. Using a -g compiled binary to track memory regions modified by functions, then flagging overlaps as dependent functions, is a well-established approach in static and dynamic program analysis. The -g flag gives you critical debug symbols that map raw memory addresses back to your source code variables (like the people array in your example), which is key to linking low-level memory operations to high-level function dependencies.

You can go with either dynamic analysis (tracking behavior while the program runs) or static analysis (analyzing the binary without execution)—here’s how to tackle both:

1. Dynamic Analysis (Runtime Tracking) #

This is great for validating dependencies in specific execution paths, and it’s more straightforward to get started with:

• Step 1: Compile for debugging and traceability
  Use gcc -g -O0 your_program.c -o your_program—-O0 disables optimizations to avoid compiler code rearrangements that would mess up memory tracking. For finer-grained hooks, add -finstrument-functions to insert entry/exit callbacks for every function.
• Step 2: Track memory reads/writes per function
  • GDB Scripting: Write a GDB script that sets breakpoints at the start and end of your target functions. When a function runs, log all memory addresses it modifies. For example, you can use GDB’s watch command to monitor writes to the people array, and tie those writes to the currently executing function.
  • Dynamic Instrumentation Tools: Use tools like Pin or Frida to inject code that intercepts memory store instructions. For instance, with Pin, you can write a tool that records which function is active every time a memory location is written to. Later, you can cross-reference these logs to find functions that modify overlapping memory regions.
• Step 3: Link memory regions to parameters and shared state
  Use the debug symbols from -g to map raw memory addresses back to source variables. For your example, you’d map writes to people[id] to the id parameter of each function. If two functions use the same parameter to index into the same shared array/struct, they’re dependent.

2. Static Analysis (No Execution Needed) #

This is better for batch-analyzing large programs to find all potential dependencies upfront:

• Step 1: Parse debug info and binary structure
  Use libraries like libelf or dwfl (for DWARF debug data) to extract function symbols, global/local variable addresses, and type information from your -g binary. For example, you can get the start address, element size, and length of the people array, plus the position and type of each function’s parameters.
• Step 2: Analyze memory access patterns
  Use a static analysis framework like LLVM/Clang to decompile the binary into Intermediate Representation (IR). Then, analyze each function’s IR to identify how it accesses memory:
  • For addObject, you’d detect that it uses the id parameter to calculate an index into the people array, then modifies that element.
  • For incrementID, you’d spot the same pattern: using id to index into people and modify the same field.
  • Compare these patterns across your target functions—if two functions rely on the same parameter to access the same shared memory region, mark them as dependent.
• Step 3: Build a dependency graph
  Aggregate your analysis results into a graph where nodes are functions, and edges represent shared memory dependencies. This gives you a visual or structured overview of which functions interact with the same state.

• Pointer Aliasing: If your program uses complex pointer logic (e.g., heap-allocated memory passed via parameters), you’ll need to handle pointer aliasing—determining if different pointers point to the same memory. This adds complexity, but tools like LLVM have built-in pointer analysis passes to help.
• Compiler Optimizations: If you must use optimized builds (e.g., -O2), compilers may inline functions or optimize memory accesses into register operations, which can break tracking. Stick with -O0 for analysis purposes unless you’re prepared to handle optimized code.
• Performance for Large Programs: Dynamic analysis can be slow for big programs, so consider combining it with static analysis: use static analysis to flag potential dependencies, then validate them with dynamic tracking.

• GDB: Perfect for quick, scriptable validation of small sets of functions.
• LLVM/Clang: Powerful for static analysis—you can build custom passes to analyze memory access patterns in your binary.
• Pin: Intel’s dynamic instrumentation tool, ideal for writing custom memory-tracking utilities.
• Frida: A lightweight, cross-platform tool for rapid prototyping of dynamic memory-tracking scripts.

内容的提问来源于stack exchange，提问作者Delons