[llvm-dev] Mapping virtual block addresses to IR blocks at runtime

Edd Barrett via llvm-dev llvm-dev at lists.llvm.org
Mon Jun 7 03:12:00 PDT 2021


Hi everyone,

We are currently building a tracing JIT based on LLVM and are trying to map
virtual block addresses back to IR basic blocks (we are using ExecutionEngine
to emit code at runtime).

We have experimented with several flags, for example:
clang++ -fbasic-block-sections=labels -fno-discard-value-names -O0 main.cpp

This gives a binary with a `.llvm_bb_addr_map` section, containing the offsets
of machine basic blocks. However, we seem to lack sufficient information to
map the machine basic block address back to the corresponding IR block.

The documentation at
https://llvm.org/docs/Extensions.html#sht-llvm-bb-addr-map-section-basic-block-address-map
seems to suggest that this is possible:

> This section stores the binary address of basic blocks along with other related
> metadata. This information can be used to map binary profiles (like perf
> profiles) directly to machine basic blocks.

Furthermore, a comment in BasicBlockSections.cpp says:
 
> With -fbasic-block-sections=labels, we emit the offsets of BB addresses of
> every function into the .llvm_bb_addr_map section. Along with the function
> symbols, this allows for mapping of virtual addresses in PMU profiles back to
> the corresponding basic blocks. This logic is implemented in AsmPrinter. This
> pass only assigns the BBSectionType of every function to ``labels``.

If we use `-fbasic-block-sections=all` LLVM puts each basic block into its own
section and gives it a symbol which we believe can be used to map them back to
IR basic blocks. However, putting basic blocks in separate sections likely
leads to worse performance due to the extra jumps (falling thru sections isn't
possible).

In summary, what we'd like LLVM to annotate basic blocks in the binary with
symbol names which can be mapped back to their corresponding IR blocks, but
without changing the section structure of the binary. Is this possible?

Thanks

-- 
Best Regards
Edd Barrett and Lukas Diekmann


More information about the llvm-dev mailing list