[PATCH] D104556: [InstrProfiling] Make CountersPtr in __profd_ relative

[David Li via Phabricator via llvm-commits]

davidxl added a comment.

In D104556#2831837 <https://reviews.llvm.org/D104556#2831837>, @vsk wrote:

> In D104556#2831833 <https://reviews.llvm.org/D104556#2831833>, @davidxl wrote:
>
>> In D104556#2831800 <https://reviews.llvm.org/D104556#2831800>, @nickdesaulniers wrote:
>>
>>> In D104556#2831757 <https://reviews.llvm.org/D104556#2831757>, @vsk wrote:
>>>
>>>> llvm has had a long-standing policy of keeping details of the .profraw format private between libprofile and InstrProfReader, opting to only commit to backwards-compat for the indexed .profdata format. I'm concerned that breaking with that practice would send the wrong message and commit llvm to maintaining an extra compat layer for a long time.
>>>>
>>>> Why/how does the Linux PGO patch "care" about the .profraw format?
>>>
>>> Because the Linux kernel cannot statically link against compiler-rt; we MUST emulate the interfaces provided by compiler-rt within the Linux kernel's runtime.
>>
>> One way to solve this is to use a matching version of llvm-profdata tool and export indexed profile data only.
>
> I don't have much experience with the Linux build system, so apologies if this is naive, but why is it exactly that it can't statically link libprofile? This is something we do for the Darwin kernel (there's a stripped-down runtime target called libclang_rt.cc_kext_x86_64_osx.a the kernel links).

Does it use buffer API? It does not support value profiling.

There may be other reasons.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D104556/new/

https://reviews.llvm.org/D104556