[llvm] [llvm-profgen] Handle perf mmaps with page sizes larger than 4 KiB (PR #217887)

Jinjie Huang via llvm-commits llvm-commits at lists.llvm.org
Fri Aug 21 19:12:37 PDT 2026


================
@@ -362,10 +362,11 @@ template <class ELFT>
 void ProfiledBinary::setPreferredTextSegmentAddresses(const ELFFile<ELFT> &Obj,
                                                       StringRef FileName) {
   const auto &PhdrRange = unwrapOrError(Obj.program_headers(), FileName);
-  // FIXME: This should be the page size of the system running profiling.
-  // However such info isn't available at post-processing time, assuming
-  // 4K page now. Note that we don't use EXEC_PAGESIZE from <linux/param.h>
-  // because we may build the tools on non-linux.
+  // The page size of the profiling system cannot be determined from the ELF
+  // binary alone, and using the page size of the post-processing system would
+  // be incorrect. Use 4 KiB as the binary-side baseline. PerfScriptReader
+  // reconciles executable mmap events whose mappings cover the segment start
+  // due to a larger runtime page size.
   uint64_t PageSize = 0x1000;
----------------
Jinjie-Huang wrote:

My concern here is that the "File offset not found" error is almost inevitable on AArch64. Users might not know they are expected to explicitly collect the PageSize, or we should make it a requirement for llvm-profgen. Also, it seems "--code-page-size" depends on newer kernels (I tested it on some of our older machines running the 5.4 kernel, and it failed to collect this info).

By the way, between using `Phdr.p_align` and calculating the relative mmap offset, the former is essentially a workaround, while the latter serves as a robust and self-contained algorithm. So I feel the deduction-based approach is more user-friendly, and it won't affect the current 4 KiB baseline logic tailored for x86.

https://github.com/llvm/llvm-project/pull/217887


More information about the llvm-commits mailing list