[BOLT] AArch64 Crash During Shared Library Instrumentation

by Admin 59 views

[BOLT] AArch64 Crash: Instrumenting Shared Library with Relocation

[BOLT] AArch64 Crash: Instrumenting Shared Library with Relocation

Hey guys, this is a deep dive into a tricky issue I encountered while using BOLT (Binary Optimization and Layout Tool) to instrument an aarch64 shared library. I'll walk you through the problem, the error messages, and what might be causing the crash. It's a bit technical, but we'll break it down so it's easy to understand. This is for those who are trying to optimize and analyze aarch64 shared libraries using BOLT.

The Problem: BOLT Crashing During Instrumentation

BOLT is a powerful tool within the LLVM project, designed for optimizing binary code. It works by instrumenting and re-arranging instructions to improve performance. My goal was to instrument libUnreal.so, a shared library. However, during the instrumentation process, BOLT crashed. The error messages point to a problem within the RewriteInstance::handleRelocation function, specifically related to handling relocations and getting valid symbols.

The core of the problem lies in how BOLT processes relocations. Relocations are instructions within the binary that tell the program how to adjust addresses during runtime. The error suggests that BOLT is encountering an invalid or missing symbol while processing these relocations. Think of symbols as labels that help the program find specific functions or data. When a symbol is missing or incorrect, it can lead to a crash.

Error Analysis: Diving into the Details

Let's break down the error messages to understand what's happening. The error log includes a few key lines that provide clues:

  • Get Invalid Symbol?: This is a direct indicator that BOLT couldn't find a symbol it was expecting. This often happens if the symbol is missing from the symbol table, or if there's a problem during the relocation process.
  • Failure value returned from cantFail wrapped call: This suggests that an operation that should not fail, did fail, leading to an exception.
  • can't read an entry at 0x2628030: it goes past the end of the section (0x2628030): This indicates a potential issue with reading data from a specific section of the library. It suggests that BOLT is trying to read beyond the boundaries of a section, which can occur when handling relocations if addresses or offsets are miscalculated or incorrect.
  • UNREACHABLE executed at /llvm/llvm-project/llvm/include/llvm/Support/Error.h:810!: This is a critical error, meaning that the code execution reached a point that it shouldn't. This can be caused by various reasons, including the invalid symbol issue.

These errors, taken together, suggest that during relocation processing, BOLT is either misinterpreting the relocation information or failing to find the associated symbols, leading to memory access errors and a crash. The error at RewriteInstance::handleRelocation is the specific function where this failure is happening.

Code Snippet and Context: Understanding the Root Cause

The provided code snippet from RewriteInstance.cpp gives us further insights. The code checks if the relocation's symbol is valid. If it isn't, the Get Invalid Symbol? message is printed. This confirms that BOLT is explicitly detecting the problem of missing or invalid symbols.

      { 
        auto Itr = Rel.getSymbol();
        if (Itr == InputFile->symbol_end()) {
          BC->outs() << "Get Invalid Symbol?\n";
        }
      }

This check is a critical part of the process, and when it fails, it can lead to the crash. The handleRelocation function is crucial for processing the relocation entries and ensuring that the instrumented code is correctly linked and can execute without errors.

Reproduction and Environment

To reproduce the issue, you'll need the following:

  • The libUnreal.so shared library (or a similar aarch64 library).
  • The BOLT tool (version llvmorg-21.1.4). Make sure you have the correct version of BOLT, as newer versions may include fixes.
  • The command line used for instrumentation:
bin/llvm-bolt  -instrument libUnreal-rel.so  -o libUnreal-instr.so --instrumentation-file=/data/local/tmp/prof.fdata --instrumentation-sleep-time=3

This command attempts to instrument the shared library and create an instrumented output file. The --instrumentation-file and --instrumentation-sleep-time options control the profiling output and add a delay for debugging purposes. When running the command, BOLT is expected to analyze the library, insert instrumentation code, and generate an instrumented version. The crash happens during this process.

Potential Causes and Solutions

Here are some potential causes and possible solutions for the crash:

  1. Corrupted or Incompatible Library: The libUnreal.so library itself might be corrupted or have an unusual structure that BOLT doesn't handle correctly. Check if the library is valid and if the build process is producing the library correctly.
  2. Relocation Issues: The library could have complex or unusual relocation types that BOLT doesn't fully support. Examine the relocation entries using tools like readelf or objdump to see if there are any unusual relocation types. You might need to modify BOLT to support these relocation types.
  3. Symbol Table Problems: The symbol table might be incomplete or have incorrect entries. Check the symbol table using readelf -s to look for missing or corrupted symbols. Make sure that all necessary symbols are present in the library.
  4. Version Compatibility: Ensure that the version of BOLT you are using is compatible with the library's architecture and the compiler used to build it. Sometimes, newer versions of compilers may generate binaries that are not fully compatible with older versions of optimization tools.
  5. BOLT Bugs: It's possible there is a bug in BOLT itself, especially if the library has complex relocation patterns. Check the BOLT issue tracker in the LLVM project to see if there are similar reports. You might need to update to a newer version or build from source if the issue is already fixed. Also, report the issue with the library and command to BOLT developers.

Troubleshooting Steps and Tips

If you encounter this issue, here's a structured approach to troubleshoot:

  1. Verify the Library:
    • Use readelf -h libUnreal.so to check the ELF header and confirm the architecture (aarch64). Ensure the library is valid.
    • Use readelf -l libUnreal.so to examine the program headers, which describe the segments and sections of the library. Make sure there are no unusual or missing headers.
  2. Inspect Relocations:
    • Use readelf -r libUnreal.so to list all relocation entries. This will help you identify the type of relocations and the associated symbols.
    • Look for any unusual relocation types. This can give you an idea if the tool can handle it.
  3. Check the Symbol Table:
    • Use readelf -s libUnreal.so to list all symbols. Check for missing or corrupted symbols. Make sure all required symbols are present and have the correct attributes.
  4. Simplify the Command:
    • Try a simpler BOLT command with fewer options to rule out any interference from the command-line arguments.
    • If possible, try instrumenting a simpler shared library to see if it works. This helps determine whether the problem is specific to libUnreal.so or a more general issue.
  5. Update BOLT:
    • Try a newer version of BOLT from the LLVM project. The issue might be resolved in a more recent release.
    • If you're comfortable, try building BOLT from the source and apply any relevant patches or fixes.
  6. Debug the Code:
    • If you're able to modify the BOLT source code, add more debugging output (e.g., printing relocation types, addresses, and symbol names) to pinpoint the exact location of the error within the handleRelocation function. Add logging to identify the problematic relocation entries.
  7. Report the Issue:
    • If you suspect a bug in BOLT, report the issue to the LLVM project. Provide the library, the command you used, and the error messages. The developers might be able to offer a fix or workaround.

Conclusion: Navigating the Crash

The crash while instrumenting aarch64 shared libraries with BOLT can be a challenging issue, but by carefully analyzing the error messages, inspecting the binary, and following a systematic troubleshooting approach, it's possible to identify the root cause and find a solution. The key is to examine the relocation entries, symbol table, and ensure that the tool is compatible with the library's structure. Remember to verify the validity of the library itself and consider if there's a problem with BOLT. Debugging the tool, reporting the issue, or updating to a newer version are also valid steps.

Good luck, guys!