Out-of-bounds tracking in unknown regions during user library optimization reached 98.4%. Is this related to Address Space Layout Randomization (ASLR)?

[jiovf]

When processing profile data from user libraries using the perf2bolt tool, a warning "PERF2BOLT: out of range traces involving unknown regions: 15765671 (98.4%) " occurred, causing the profile data to fail to take effect. When ASLR is disabled in the data collection scenario, this metric decreases. Is this coincidental? Has anyone else encountered a similar issue?

The specific process is as follows:

perf2bolt --pa -p=libxx.profdata" -o libxx.fdata libxx.symbol"
BOLT-INFO: shared object or position-independent executable detected
BOLT-INFO: shared object or position-independent executable detected
PERF2BOLT: Starting data aggregation job for libxx.profdata
BOLT-INFO: Target architecture: aarch64
BOLT-INFO: BOLT version: e03a7c124d50fa9449a81fe21cc958a18919a4ea
BOLT-INFO: first alloc address is 0x0
BOLT-INFO: creating new program header table at address 0x200000, offset 0x200000
BOLT-INFO: enabling relocation mode
BOLT-INFO: enabling strict relocation mode for aggregation purposes
BOLT-INFO: pre-processing profile using perf data aggregator
PERF2BOLT: parsing pre-aggregated profile...
PERF2BOLT: read 2116 aggregated LBR entries
PERF2BOLT: processing branch events...
PERF2BOLT: traces mismatching disassembled function contents: 0 (0.0%)
PERF2BOLT: **out of range traces involving unknown regions: 15765671 (98.4%)**
PERF2BOLT: wrote 70 objects and 0 memory objects to libxx.fdata
BOLT-INFO: 0 out of 381 functions in the binary (0.0%) have non-empty execution profile
BOLT-WARNING: the output profile is empty or the --profile-density-cutoff-hot option is set too low. Please check your command.
BOLT-INFO: Functions with density >= 0.0 account for 99.00% total sample counts.

• Result: SUCCESS (took 0 seconds)
• Output size: 4.0K

Out-of-bounds tracking in unknown regions during user library optimization reached 98.4%. Is this related to Address Space Layout Randomization (ASLR)?

[llvmbot]

@llvm/issue-subscribers-bolt

Author: None (jiovf)

When processing profile data from user libraries using the perf2bolt tool, a warning _"PERF2BOLT: out of range traces involving unknown regions: 15765671 (98.4%) "_ occurred, causing the profile data to fail to take effect. When ASLR is disabled in the data collection scenario, this metric decreases. Is this coincidental? Has anyone else encountered a similar issue?

The specific process is as follows:
perf2bolt --pa -p=libxx.profdata" -o libxx.fdata libxx.symbol"
BOLT-INFO: shared object or position-independent executable detected
BOLT-INFO: shared object or position-independent executable detected
PERF2BOLT: Starting data aggregation job for libxx.profdata
BOLT-INFO: Target architecture: aarch64
BOLT-INFO: BOLT version: e03a7c1
BOLT-INFO: first alloc address is 0x0
BOLT-INFO: creating new program header table at address 0x200000, offset 0x200000
BOLT-INFO: enabling relocation mode
BOLT-INFO: enabling strict relocation mode for aggregation purposes
BOLT-INFO: pre-processing profile using perf data aggregator
PERF2BOLT: parsing pre-aggregated profile...
PERF2BOLT: read 2116 aggregated LBR entries
PERF2BOLT: processing branch events...
PERF2BOLT: traces mismatching disassembled function contents: 0 (0.0%)
PERF2BOLT: out of range traces involving unknown regions: 15765671 (98.4%)
PERF2BOLT: wrote 70 objects and 0 memory objects to libxx.fdata
BOLT-INFO: 0 out of 381 functions in the binary (0.0%) have non-empty execution profile
BOLT-WARNING: the output profile is empty or the --profile-density-cutoff-hot option is set too low. Please check your command.
BOLT-INFO: Functions with density >= 0.0 account for 99.00% total sample counts.

• Result: SUCCESS (took 0 seconds)
• Output size: 4.0K

Out-of-bounds tracking in unknown regions during user library optimization reached 98.4%. Is this related to Address Space Layout Randomization (ASLR)?

[paschalis-mpeis]

Was it a substantial decrease without ASLR?

Also, can you share how you collected the profile?
Did you expect libxx to account for a larger % than the rest of the libraries or the main executable?

[aaupov]

How was libxx.profdata produced? For PIE/DSO the addresses in pre-aggregated profile need to be offsets from the base load address (first loadable segment). Please check if it's the case.

For reference, you can use https://github.com/aaupov/ebpf-bolt which supports producing pre-aggregated data for PIE executables.

[jiovf]

Was it a substantial decrease without ASLR?如果没有 ASLR，下降幅度会大幅增加吗？

Also, can you share how you collected the profile?另外，您能分享一下您是如何收集个人资料的吗？ Did you expect libxx to account for a larger % than the rest of the libraries or the main executable?您是否预计 libxx 所占百分比会比其余库或主可执行文件更大？

We used etm to sample arm64 and observed the proportion of out-of-range traces involving unknown regions before and after enabling and disabling ASLR. When setting ASLR to 2 and processing the collected profile with perf2bolt, the aforementioned issue occurs. Disabling ASLR reduces the proportion of out-of-range traces involving unknown regions, but it does not reach zero. Does it meet expectations?

Thank you for your reply. I look forward to further discussion with you.

@paschalis-mpeis

[aaupov]

I used perf record to collect profile and perf inject to generate libxx.profdata.

I assume you're using simpleperf as described here:
https://android.googlesource.com/platform/system/extras/+/refs/heads/main/simpleperf/doc/collect_etm_data_for_autofdo.md#Convert-ETM-data-for-llvm_bolt-experiment

Looking at the code which handles BOLT output 1, seemingly it should take care of the offsets. But looking at the implementation 2, the issue is that it returns the offset from the beginning of the containing segment, not first loadable segment.
cc @yabinc

[jiovf]

Sorry, I'm not very familiar with the details of simpleperf's inject feature either. But I don't think that's the main issue here. If the system enables some mechanism that causes the starting address of runtime files to change, and Bolt relies on the symbol table to obtain the starting address—then uses the starting address plus an offset to locate the corresponding function—that should be the reason for the disproportionately high ratio mentioned above?

This is my humble understanding, and I look forward to discussing it further with you.

@aaupov