ZequanWu wrote:
> If you omit the data and names sections from the object files, then
> __llvm_profile_end_data() - __llvm_profile_begin_data() and
> __llvm_profile_end_names() - __llvm_profile_begin_names() are both 0 and
> there's no need for [special casing this in the
> runtime](https://github.com/llvm/llvm-project/blob/24b11ba24da3e65f718391ccc85d4d22a081e893/compiler-rt/lib/profile/InstrProfilingBuffer.c#L59).
>From my experiments, I found that for debug info correlation
>`__llvm_profile_end_data()` - `__llvm_profile_begin_data()` and
>`__llvm_profile_end_names()` - `__llvm_profile_begin_names()` are both 0 at
>runtime because `{__start_/__stop_}{__llvm_prf_names/data}` symbols are null
>if there is no `__llvm_prf_names/data`.
But for binary correlation, even though `__llvm_prf_names/data` don't have
`SHF_ALLOC` flag so they are not loaded into memory,
`__llvm_profile_end_data()` - `__llvm_profile_begin_data()` and
`__llvm_profile_end_names()` - `__llvm_profile_begin_names()` still produces
the size of name and data sections, that's why we need a bit in the global
profile version variable to indicate they are empty at runtime. I feel like
this is a bug in lld as __start_/__stop_ symbols for non allocated sections
should be null. Even if we have a way to fix that, we still need the mode bit
at llvm-profile merging step to indicate if the raw profile need debug
info/binary to correlate. However, we can get ride of the runtime checking
`__llvm_profile_has_correlation` to allow code compiled w/wo debug-info linked
together works well.
https://github.com/llvm/llvm-project/pull/70856
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
