Consider an ABI extension to define metadata for binary analysis

[smithp35]

With increasing adoption of tools like BOLT and use of binary analysis by the Linux kernel, there may be demand for additional metadata to aid control flow discovery.

Examples include:

• Identifying static linker generated stubs/veneers/thunks.
• Identifying function pointer destinations.

If there are to be metadata added to toolchains such as LLVM and GCC, it would be useful to document these in the ABI to help with interoperability of tools.

This issue is a placeholder for further discussion.

[kbeyls]

Other useful pieces of info for binary analysis reconstruction of control flow graphs include:

• a list of possible targets of indirect jumps, for example as generated by lowering of switch statements to jump tables.
• an indication of whether a called function is considered "no-return", and hence the binary analysis tool should assume control flow cannot continue past a specific function call.
  • [BOLT] Lack of support for noreturn functions results in incorrect CFG generation. llvm/llvm-project#115154 indicates this would help binary analysis tools to reconstruct CFGs better.
  • https://nebelwelt.net/files/17CC.pdf at the end of section "4.2 Function boundaries recovery" also clearly documents the need to identify noreturn functions well during reconstruction of a CFG in binary analysis tools.

[peterwaller-arm]

• [BOLT] GOT array pointer incorrectly rewritten llvm/llvm-project#100096
  it's tricky in general to determine if a GOT entry points to data or code, and there exists at least one case where they can alias through pointer-to-end-of-array. This can probably be solved well enough heuristically for the specific case seen there (glibc bfd linked static binary crash on startup); but I wonder if the problem could exist more generally.

[maksfb]

• More architectures are adding jump table information into ELF (Jump table annotations for Linux llvm/llvm-project#112606). It will be great to have a standard ELF extension that covers them all. From the BOLT perspective, we need to know jump table boundaries, instructions involved in forming the jump table address, and the indirect jump location(s). Note that it's possible for jump tables to overlap. Additionally, we can expect the jump table address to be stored and loaded from the stack.
• Indirect/computed goto extension for C/C++ also uses indirect jumps and the mechanism deviates from a typical switch/jump table implementation.

[alekuz01]

One of the extension that could be potentially utilized now to identify BB and Funcs from LLVM side, could be Basic Block Address Map:

https://llvm.org/docs/Extensions.html#sht-llvm-bb-addr-map-section-basic-block-address-map

The basic block address map was used in a similar to BOLT(compiler/linker level but non for binary level) tooling to let correctly map profiled sampled information related to Funcs/BBs.
The format of this map and data incorporated into binary should not have a significant impact in terms of the size or perf.
And it could be used as a hint as well. I have been thinking to make it work for the BOLT if the section '.llvm_bb_addr_map' is presented in the binary.

The disadvantage - this BBAddrMap is presented only for LLVM/CLANG.

Regarding jump tables, maybe considering something like: https://llvm.org/docs/Extensions.html#sht-llvm-jt-sizes-section-jump-table-addresses-and-sizes

[ilinpv]

A slightly different topic, but it seems also related to the ABI-like agreement on BOLT binary rewriting and stripping tools expectations. Issues reported on that:
llvm/llvm-project#56738
llvm/llvm-project#89336
llvm/llvm-project#85796
The RFC effort to address some issues with new sections in the end and old sections in place confusing stripping tools https://discourse.llvm.org/t/bolt-rfc-a-new-mode-to-rewrite-entire-binary/68674

[smithp35]

Thank you for all the comments and suggestions. It looks like there is sufficient interest to go forward with this. Most likely in the form of an ABI extension that can be worked on incrementally with an implementation. We'll have more to say next year.

[appujee]

Another reference we can take ideas from: google/android-riscv64#68