[InstrProfiling] Make CountersPtr in __profd_ relative

[MaskRay]

Summary

Change CountersPtr in __profd_ to a label difference, which is a link-time
constant. On ELF, when linking a shared object, this requires that __profc_ is
either private or linkonce/linkonce_odr hidden. On COFF, we need D104564 so that
.quad a-b (64-bit label difference) can lower to a 32-bit PC-relative relocation.

# ELF: R_X86_64_PC64 (PC-relative)
.quad .L__profc_foo-.L__profd_foo

# Mach-O: a pair of 8-byte X86_64_RELOC_UNSIGNED and X86_64_RELOC_SUBTRACTOR
.quad l___profc_foo-l___profd_foo

# COFF: we actually use IMAGE_REL_AMD64_REL32/IMAGE_REL_ARM64_REL32 so
# the high 32-bit value is zero even if .L__profc_foo < .L__profd_foo
# As compensation, we truncate CountersDelta in the header so that
# __llvm_profile_merge_from_buffer and llvm-profdata reader keep working.
.quad .L__profc_foo-.L__profd_foo

(Note: link.exe sorts .lprfc before .lprfd even if the object writer
has .lprfd before .lprfc.)

With this change, a stage 2 (-DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_BUILD_INSTRUMENTED=IR)
ld -pie linked clang is 1.74% smaller due to fewer R_X86_64_RELATIVE relocations.

% readelf -r pie | awk '$3~/R.*/{s[$3]++} END {for (k in s) print k, s[k]}'
R_X86_64_JUMP_SLO 331
R_X86_64_TPOFF64 2
R_X86_64_RELATIVE 476059  # was: 607712
R_X86_64_64 2616
R_X86_64_GLOB_DAT 31

Bump the raw profile format version to 6. (Last bump happened in 2019-10.)

The absolute function address (used by llvm-profdata to collect indirect call
targets) can be converted to relative as well, but is not done in this patch.

[MaskRay]

update

[MaskRay]

make win64 work

[davidxl]

compiler-rt/lib/profile/InstrProfilingMerge.c

114

The code to compute the relative counter offset is pretty confusing. Perhaps add more comments on the math behind it.

[rnk]

On COFF, it would be more traditional to make these image-relative 32-bit offsets, so they would come out as .long __profc_foo@IMGREL. If you grep for IMGREL in test/, you can see various exception handling and RTTI tables use that structure.

I seem to recall this was also an issue for swift, which wanted label difference relocations.

The absolute function address (used by llvm-profdata to collect indirect call
targets) can be converted to relative as well, but is not done in this patch.

If we're doing a format change, we should think about this a bit. Previously I was considering removing this field altogether and trying to store this information in a new section, but I don't think it's worth it after D102818.

[MaskRay]

Add more comments to InstrProfilingMerge.c

[vsk]

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?

[davidxl]

llvm/lib/ProfileData/InstrProfReader.cpp

366

!=5 condition seems weird.

435

See Vedant's comment -- raw profile compatibility is a non-goal.

[MaskRay]

In D104556#2831726, @rnk wrote:

On COFF, it would be more traditional to make these image-relative 32-bit offsets, so they would come out as .long __profc_foo@IMGREL. If you grep for IMGREL in test/, you can see various exception handling and RTTI tables use that structure.

I seem to recall this was also an issue for swift, which wanted label difference relocations.

The absolute function address (used by llvm-profdata to collect indirect call
targets) can be converted to relative as well, but is not done in this patch.

If we're doing a format change, we should think about this a bit. Previously I was considering removing this field altogether and trying to store this information in a new section, but I don't think it's worth it after D102818.

Hmm, IMGREL (IMAGE_REL_AMD64_ADDR32NB) looks useful and is an alternative solution to PC-relative relocations in ELF / relocation subtraction in Mach-O.
But leveraging it seems to need more code in the runtime and will make COFF vs non-COFF different in IR, runtime, and llvm-profdata....

[nickdesaulniers]

In 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.

[davidxl]

In D104556#2831800, @nickdesaulniers wrote:

In 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.

[vsk]

In D104556#2831833, @davidxl wrote:

In D104556#2831800, @nickdesaulniers wrote:

In 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).

[davidxl]

In D104556#2831837, @vsk wrote:

In D104556#2831833, @davidxl wrote:

In D104556#2831800, @nickdesaulniers wrote:

In 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.

[vsk]

In D104556#2831849, @davidxl wrote:

In D104556#2831837, @vsk wrote:

In D104556#2831833, @davidxl wrote:

In D104556#2831800, @nickdesaulniers wrote:

In 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.

I see. Yes, the Darwin kernel uses the buffer API, but not value profiling.

[nickdesaulniers]

In D104556#2831837, @vsk wrote:

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).

The kernel neither links against compiler_rt no libgcc_s, so there's at least precedence for not doing so. Also, I'm not sure of the implications of statically linking the code under two different licenses.

[MaskRay]

Not keeping version compatibility for the raw profile format would actually make my life easier.
But I was CCed on the Linux kernel news https://www.phoronix.com/scan.php?page=news_item&px=Clang-PGO-For-Linux-Next so I paid additional care in this patch.

As we can see the compatibility code is actually minimal: just if (relativeCounterPtr()) and the associated function.
There comments are longer than the code.

How about we making a one-time exception as a courtesy to the initial check-in of the CONFIG_PGO_CLANG feature in the Linux kernel?
There can be a bunch of users testing the PGO functionality.
(Well, you may argue that why I couldn't postpone this patch for some extended time, 1 month? I had this in mind for a while (when I changed XRay and learned a bit about PGO last year I had a plan) but I would probably have postponed this work further if I had not seen that some folks are proposing the MIP profile format.)

The summary can be clarified that this is a one-time exception.
I can set up a calendar reminder for myself to drop the compatibility code in llvm-project after some time (@nickdesaulniers @kees may decide on this).
For example, 2 months?

[davidxl]

One time exception sounds fine to me.

[MaskRay]

Mention the one-time exception for .profraw compatibility

[vsk]

A one-time exception to the .profraw compatibility policy sounds reasonable to me.

A little more context: llvm has historically rev'd the .profraw format with abandon to deliver performance/size improvements (as David & co. did with name compression) and new functionality (value profiling, continuous sync mode, ...). That will keep happening. The freedom to rev the raw format comes from keeping it private between the profile reader library and the runtime. Some alternatives to hardcoding details of a particular version of the .profraw format were mentioned earlier in the thread: if the Linux PGO support can pursue one of these (or find some other solution), I think it will it prevent headaches down the road.

[rnk]

In D104556#2831787, @MaskRay wrote:

Hmm, IMGREL (IMAGE_REL_AMD64_ADDR32NB) looks useful and is an alternative solution to PC-relative relocations in ELF / relocation subtraction in Mach-O.
But leveraging it seems to need more code in the runtime and will make COFF vs non-COFF different in IR, runtime, and llvm-profdata....

We can go forward with what we have, but the signextIfWin64 helper is pretty subtle. In some ways, I think adding __ImageBase is clearer:

#ifdef _WIN32
extern "C" char __ImageBase;
#endif
uintptr_t rebaseRelativePtr(void *D, void *P) {
#ifdef _WIN32
  return (uintptr_t)&__ImageBase + (uintptr_t)P;
#else
  return (uintptr_t)D + (uintptr_t)P;
#endif
}

It's not quite this easy, and the instrumentation side changes have to basically copy or refactor this code:
https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/MicrosoftCXXABI.cpp#L548

We aren't worried about profraw format compatibility on Windows, so I think we can change this later at any time if we like.

[MaskRay]

In D104556#2836900, @rnk wrote:

In D104556#2831787, @MaskRay wrote:

Hmm, IMGREL (IMAGE_REL_AMD64_ADDR32NB) looks useful and is an alternative solution to PC-relative relocations in ELF / relocation subtraction in Mach-O.
But leveraging it seems to need more code in the runtime and will make COFF vs non-COFF different in IR, runtime, and llvm-profdata....

We can go forward with what we have, but the signextIfWin64 helper is pretty subtle. In some ways, I think adding __ImageBase is clearer:

#ifdef _WIN32
extern "C" char __ImageBase;
#endif
uintptr_t rebaseRelativePtr(void *D, void *P) {
#ifdef _WIN32
  return (uintptr_t)&__ImageBase + (uintptr_t)P;
#else
  return (uintptr_t)D + (uintptr_t)P;
#endif
}

It's not quite this easy, and the instrumentation side changes have to basically copy or refactor this code:
https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/MicrosoftCXXABI.cpp#L548

We aren't worried about profraw format compatibility on Windows, so I think we can change this later at any time if we like.

I think you mean that INSTR_PROF_RAW_HEADER(uint64_t, CountersDelta, (uintptr_t)CountersBegin - (uintptr_t)DataBegin) (in InstrProfiling.cpp, so used by both -fprofile-generate and -fprofile-instr-generate) needs to adopt the scheme in https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/MicrosoftCXXABI.cpp#L548
Yes, seems quite a bit of complexity.

Is it possible to ask MSVC to add the 64-bit IMAGE_REL_AMD64_REL64 and IMAGE_REL_ARM64_REL64?
Newer compiler metadata techniques can benefit from using the same mechanism for all three major binary formats (PE-COFF/ELF/Mach-O).

[rnk]

In D104556#2837006, @MaskRay wrote:

Is it possible to ask MSVC to add the 64-bit IMAGE_REL_AMD64_REL64 and IMAGE_REL_ARM64_REL64?
Newer compiler metadata techniques can benefit from using the same mechanism for all three major binary formats (PE-COFF/ELF/Mach-O).

Swift wanted the same thing, so I think the answer is yes, we should ask.

[mstorsjo]

In D104556#2837104, @rnk wrote:

In D104556#2837006, @MaskRay wrote:

Is it possible to ask MSVC to add the 64-bit IMAGE_REL_AMD64_REL64 and IMAGE_REL_ARM64_REL64?
Newer compiler metadata techniques can benefit from using the same mechanism for all three major binary formats (PE-COFF/ELF/Mach-O).

Swift wanted the same thing, so I think the answer is yes, we should ask.

What would the benefit of that be, as the difference itself can only ever be 32 bit? Is it only for consistency with other binary formats? I guess getting the value sign extended to a 64 bit value is a bit useful too.

[MaskRay]

In D104556#2837136, @mstorsjo wrote:

In D104556#2837104, @rnk wrote:

Swift wanted the same thing, so I think the answer is yes, we should ask.

What would the benefit of that be, as the difference itself can only ever be 32 bit? Is it only for consistency with other binary formats? I guess getting the value sign extended to a 64 bit value is a bit useful too.

Yes, consistency among binary formats. A 64-bit label difference .quad A-B is directly expressable on Mach-O and RISC-V (R_RISCV_SUB*) and can be converted to PC-relative on ELF.

For example, mips64 supports 64-bit PC-relative since D80390 (GNU as still doesn't allow it) => this allowed an XRay clean-up D87977.

[MaskRay]

Ping:)

[MaskRay]

Drop version 5 compatibility because the Linux kernel patch is suspended.

[rnk]

I'm happy with this.

compiler-rt/include/profile/InstrProfData.inc

79

I'd suggest moving this into a local variable in the instrumentation code. The less code there is in this header, the better.

[MaskRay]

Move ConstantExpr::getSub from .inc to InstrProfiling.cpp

[MaskRay]

@davidxl @vsk 😃

[MaskRay]

@davidxl @vsk 😃

I am happy to postpone this after 13.0.0 is branched - so that we can adjust the format while only bumping the version once.

[MaskRay]

release/13.x has been created. This if merged will go into 14.x. We have plenty of time making more format changes if needed.

[catenacyber]

This commit has broken oss-fuzz workflow for rust projects.
I do not know if the fix is https://reviews.llvm.org/rG66e2772e4285588ccc3bcdb5f392c8326debbd7d

Scenario is

export RUSTFLAGS="--cfg fuzzing -Cdebuginfo=1 -Cforce-frame-pointers -Zinstrument-coverage -C link-dead-code -C link-arg=-lc++"
git clone https://github.com/ctz/rustls && cd rustls
cargo fuzz build -O
./fuzz/target/x86_64-unknown-linux-gnu/release/client ./fuzz/target/x86_64-unknown-linux-gnu/release/client
llvm-profdata merge -sparse default.profraw -o profdata

Current output is

warning: default.profraw: malformed instrumentation profile data
error: no profile can be merged

Scenario does not output error for in 13.0.0-rc2

Error does not happen on commit 69cdadddecaf97f572c311aa07044f79a5b8329a just previous this integration, if we add git cherry-pick a6c14fba70e170a279f7e77f068368f09d8c5eaf to fix the other pending bug which was fixed in 13.0.0-rc2
Error happens on commit a1532ed27582038e2d9588108ba0fe8237f01844 even if we git cherry-pick a6c14fba70e170a279f7e77f068368f09d8c5eaf and fix the conflict about only llvm/test/tools/llvm-profdata/Inputs/c-general.profraw

[MaskRay]

In D104556#2997674, @catenacyber wrote:

This commit has broken oss-fuzz workflow for rust projects.
I do not know if the fix is https://reviews.llvm.org/rG66e2772e4285588ccc3bcdb5f392c8326debbd7d

Scenario is

export RUSTFLAGS="--cfg fuzzing -Cdebuginfo=1 -Cforce-frame-pointers -Zinstrument-coverage -C link-dead-code -C link-arg=-lc++"
git clone https://github.com/ctz/rustls && cd rustls
cargo fuzz build -O
./fuzz/target/x86_64-unknown-linux-gnu/release/client ./fuzz/target/x86_64-unknown-linux-gnu/release/client
llvm-profdata merge -sparse default.profraw -o profdata

Current output is

warning: default.profraw: malformed instrumentation profile data
error: no profile can be merged

Scenario does not output error for in 13.0.0-rc2

Error does not happen on commit 69cdadddecaf97f572c311aa07044f79a5b8329a just previous this integration, if we add git cherry-pick a6c14fba70e170a279f7e77f068368f09d8c5eaf to fix the other pending bug which was fixed in 13.0.0-rc2
Error happens on commit a1532ed27582038e2d9588108ba0fe8237f01844 even if we git cherry-pick a6c14fba70e170a279f7e77f068368f09d8c5eaf and fix the conflict about only llvm/test/tools/llvm-profdata/Inputs/c-general.profraw

I don't think this change is responsible. This has been tested by many C++ downstream groups.

Rust should use upgrade its lib/ProfileData and compiler-rt/lib/profile, and not mix raw profile files at different commits.
The binary ID change has caused a bit of churn to ProfileData but it is unrelated to this patch.

[catenacyber]

Thanks for the quick reply

I don't think this change is responsible. This has been tested by many C++ downstream groups.

What did I do wrong ?
Adding this only commit makes the scenario fail.

Rust should use upgrade its lib/ProfileData and compiler-rt/lib/profile, and not mix raw profile files at different commits.

I am not sure I understand.
What are raw profiles ?
In my scenario, only llvm-profdata acts on default.profraw
And before that, the linker, not the rust compiler, mixes together the different coverage sections...
So, how would Rust mix raw profiles ?

The binary ID change has caused a bit of churn to ProfileData but it is unrelated to this patch.

Well, there may be other bugs, but this is not a problem in my scenario...

[MaskRay]

In D104556#2998091, @catenacyber wrote:

Thanks for the quick reply

I don't think this change is responsible. This has been tested by many C++ downstream groups.

What did I do wrong ?
Adding this only commit makes the scenario fail.

Rust should use upgrade its lib/ProfileData and compiler-rt/lib/profile, and not mix raw profile files at different commits.

I am not sure I understand.
What are raw profiles ?
In my scenario, only llvm-profdata acts on default.profraw
And before that, the linker, not the rust compiler, mixes together the different coverage sections...
So, how would Rust mix raw profiles ?

.profraw are files with the raw profile format. The compiler-rt/lib/profile runtime and llvm-profdata only support one version at any commit.
Mixing .profraw files produced by different compiler-rt/lib/profile runtimes is unsupported.

I don't know what rustc and https://github.com/ctz/rustls do.

I don't think this change is responsible as the change has been well released/tested by many C++ groups.
If Rust adapts compiler-rt and does something different, I think the investigation responsibility is on Rust's side.

Perhaps you can get some help from rustc folks who do the compiler-rt adaptation in rustc.

The binary ID change has caused a bit of churn to ProfileData but it is unrelated to this patch.

Well, there may be other bugs, but this is not a problem in my scenario...

[catenacyber]

Bump the raw profile format version to 6. (Last bump happened in 2019-10.)

This does not seem to be in the patch, ie no change of INSTR_PROF_RAW_VERSION in compiler-rt/include/profile/InstrProfData.inc
Is that missing ?

[MaskRay]

In D104556#2998137, @catenacyber wrote:

Bump the raw profile format version to 6. (Last bump happened in 2019-10.)

This does not seem to be in the patch, ie no change of INSTR_PROF_RAW_VERSION in compiler-rt/include/profile/InstrProfData.inc
Is that missing ?

INSTR_PROF_RAW_VERSION is not bumped. It was bumped in the first revision of this patch if you looked at the history.

Somehow the binary ID change got pushed before this and it has been rolled back/forward several times in main.
The version is not updated in this patch to not cause unnecessary conflict with that patch.

Even if INSTR_PROF_RAW_VERSION is bumped, I think it is very likely your Rust downstream will observe an if (GET_VERSION(Version) != RawInstrProf::Version) error in llvm-profdata,
because from your description it seems you are likely mixing raw profile files produced by compiler-rt/lib/profile built at different commits.

[catenacyber]

.profraw are files with the raw profile format. The compiler-rt/lib/profile runtime and llvm-profdata only support one version at any commit.

Ok.

Mixing .profraw files produced by different compiler-rt/lib/profile runtimes is unsupported.

I do not think I am mixing profraw files as I have only one profraw file.
If my llvm-profdata is not supporting the profraw file produced by rust + linker, should it not error with
Unsupported instrumentation profile format version instead of malformed instrumentation profile data
As it does with rust nightly and clang 12 ?

I don't know what rustc and https://github.com/ctz/rustls do.

Rustls is just an example rust project, I think we get the same result with every rust project.

I don't think this change is responsible as the change has been well released/tested by many C++ groups.

I guess I did not mean to use the word responsible.
I am just saying that if I git revert a1532ed27582038e2d9588108ba0fe8237f01844 and solve the conflicts on top of main, I get my scenario to work again

If Rust adapts compiler-rt and does something different, I think the investigation responsibility is on Rust's side.

Perhaps you can get some help from rustc folks who do the compiler-rt adaptation in rustc.

I am asking indeed

[MaskRay]

In D104556#2998159, @catenacyber wrote:

.profraw are files with the raw profile format. The compiler-rt/lib/profile runtime and llvm-profdata only support one version at any commit.

Ok.

Mixing .profraw files produced by different compiler-rt/lib/profile runtimes is unsupported.

I do not think I am mixing profraw files as I have only one profraw file.
If my llvm-profdata is not supporting the profraw file produced by rust + linker, should it not error with
Unsupported instrumentation profile format version instead of malformed instrumentation profile data
As it does with rust nightly and clang 12 ?

I don't know what rustc and https://github.com/ctz/rustls do.

Rustls is just an example rust project, I think we get the same result with every rust project.

Wild guess:
this is "Support for older format versions in RawInstrProfReader" https://lists.llvm.org/pipermail/llvm-dev/2021-August/152287.html

Bumping INSTR_PROF_RAW_VERSION will give a better diagnostic but won't address the root cause that only one version is supported, which I totally agree since otherwise this would add too much burden on the upstream LLVM developer side.
The Rust side can do something to make this scenario better supported.

I don't think this change is responsible as the change has been well released/tested by many C++ groups.

I guess I did not mean to use the word responsible.
I am just saying that if I git revert a1532ed27582038e2d9588108ba0fe8237f01844 and solve the conflicts on top of main, I get my scenario to work again

If Rust adapts compiler-rt and does something different, I think the investigation responsibility is on Rust's side.

Perhaps you can get some help from rustc folks who do the compiler-rt adaptation in rustc.

I am asking indeed

The error only happens when you have mix-and-match .profraw files. You'll need to rebuild everything on the Rust side if you want to use git LLVM.
I guess that rustc itself or some prebuilt executable is using an old format.

[catenacyber]

Even if INSTR_PROF_RAW_VERSION is bumped, I think it is very likely your Rust downstream will observe an if (GET_VERSION(Version) != RawInstrProf::Version) error in llvm-profdata,
because from your description it seems you are likely mixing raw profile files produced by compiler-rt/lib/profile built at different commits.

For the record, bumping INSTR_PROF_RAW_VERSION on top of main branch, (or after reverting this commit), in both compiler-rt/include/profile/InstrProfData.inc and llvm/include/llvm/ProfileData/InstrProfData.inc, I indeed get the error message unsupported instrumentation profile format version

The output for file default.profraw is default.profraw: LLVM raw profile data, version 7

Bumping INSTR_PROF_RAW_VERSION will give a better diagnostic but won't address the root cause that only one version is supported, which I totally agree since otherwise this would add too much burden on the upstream LLVM developer side.

Well, now I have my diagnostic :-) (it is not like https://github.com/rust-lang/rust/issues/82875 for instance)

this is "Support for older format versions in RawInstrProfReader" https://lists.llvm.org/pipermail/llvm-dev/2021-August/152287.html

Thanks for the pointer

You'll need to rebuild everything on the Rust side if you want to use git LLVM.

Indeed, I will try to rebuild rust with clang-14

[catenacyber]

Should we still bump INSTR_PROF_RAW_VERSION so that we are able to distinguish profraw files produced by clang13 and the ones produced by clang14 ?

Right now, both produce LLVM raw profile data, version 7

[MaskRay]

In D104556#3001497, @catenacyber wrote:

Should we still bump INSTR_PROF_RAW_VERSION so that we are able to distinguish profraw files produced by clang13 and the ones produced by clang14 ?

Right now, both produce LLVM raw profile data, version 7

Yes. 14.0.0 is far away, so there is plenty of time bumping it.

[catenacyber]

Should I propose a simple patch to bump INSTR_PROF_RAW_VERSION ?
Or will it be part of something bigger, taken care of by someone else ?

[richkadel]

I don't know if this is helpful or not, but we ran into a problem, recently, on Fuchsia when upgrading Clang (I believe to LLVM 14), and realized that the LLVM tools from Clang's version of LLVM were incompatible with the Rust profraw files. Since you're probably using a Rust compiler that's compatible with LLVM 13 (if not earlier), you may need to make sure you're using Rust's bundled LLVM tools (llvm-profdata and llvm-cov) to process those files.

compiler-rt/include/profile/InstrProfData.inc

 #define INSTR_PROF_DATA_DEFINED
 #endif
 INSTR_PROF_DATA(const uint64_t, llvm::Type::getInt64Ty(Ctx), NameRef, \
                 ConstantInt::get(llvm::Type::getInt64Ty(Ctx), \
                 IndexedInstrProf::ComputeHash(getPGOFuncNameVarInitializer(Inc->getName()))))
 INSTR_PROF_DATA(const uint64_t, llvm::Type::getInt64Ty(Ctx), FuncHash, \
                 ConstantInt::get(llvm::Type::getInt64Ty(Ctx), \
                 Inc->getHash()->getZExtValue()))
-INSTR_PROF_DATA(const IntPtrT, llvm::Type::getInt64PtrTy(Ctx), CounterPtr, \
-                ConstantExpr::getBitCast(CounterPtr, \
-                llvm::Type::getInt64PtrTy(Ctx)))
+INSTR_PROF_DATA(const IntPtrT, IntPtrTy, CounterPtr,
+                ConstantExpr::getSub(ConstantExpr::getPtrToInt(CounterPtr,
+                                                               IntPtrTy),
+                                     ConstantExpr::getPtrToInt(Data, IntPtrTy)))
 /* This is used to map function pointers for the indirect call targets to
  * function name hashes during the conversion from raw to merged profile
  * data.
  */
 INSTR_PROF_DATA(const IntPtrT, llvm::Type::getInt8PtrTy(Ctx), FunctionPointer, \
                 FunctionAddr)
 INSTR_PROF_DATA(IntPtrT, llvm::Type::getInt8PtrTy(Ctx), Values, \
                 ValuesPtrExpr)

 #endif
 INSTR_PROF_RAW_HEADER(uint64_t, Magic, __llvm_profile_get_magic())
 INSTR_PROF_RAW_HEADER(uint64_t, Version, __llvm_profile_get_version())
 INSTR_PROF_RAW_HEADER(uint64_t, DataSize, DataSize)
 INSTR_PROF_RAW_HEADER(uint64_t, PaddingBytesBeforeCounters, PaddingBytesBeforeCounters)
 INSTR_PROF_RAW_HEADER(uint64_t, CountersSize, CountersSize)
 INSTR_PROF_RAW_HEADER(uint64_t, PaddingBytesAfterCounters, PaddingBytesAfterCounters)
 INSTR_PROF_RAW_HEADER(uint64_t, NamesSize,  NamesSize)
-INSTR_PROF_RAW_HEADER(uint64_t, CountersDelta, (uintptr_t)CountersBegin)
+INSTR_PROF_RAW_HEADER(uint64_t, CountersDelta, (uintptr_t)CountersBegin-(uintptr_t)DataBegin)
 INSTR_PROF_RAW_HEADER(uint64_t, NamesDelta, (uintptr_t)NamesBegin)
 INSTR_PROF_RAW_HEADER(uint64_t, ValueKindLast, IPVK_Last)
 #undef INSTR_PROF_RAW_HEADER
 /* INSTR_PROF_RAW_HEADER  end */
 
 /* VALUE_PROF_FUNC_PARAM start */
 /* Definition of parameter types of the runtime API used to do value profiling
  * for a given value site.

compiler-rt/lib/profile/InstrProfilingMerge.c

 COMPILER_RT_VISIBILITY
 int __llvm_profile_merge_from_buffer(const char *ProfileData,
                                      uint64_t ProfileSize) {
   __llvm_profile_data *SrcDataStart, *SrcDataEnd, *SrcData, *DstData;
   __llvm_profile_header *Header = (__llvm_profile_header *)ProfileData;
   uint64_t *SrcCountersStart;
   const char *SrcNameStart;
   const char *SrcValueProfDataStart, *SrcValueProfData;
+  uint64_t CountersDelta = Header->CountersDelta;
 
   SrcDataStart =
       (__llvm_profile_data *)(ProfileData + sizeof(__llvm_profile_header));
   SrcDataEnd = SrcDataStart + Header->DataSize;
   SrcCountersStart = (uint64_t *)SrcDataEnd;
   SrcNameStart = (const char *)(SrcCountersStart + Header->CountersSize);
   SrcValueProfDataStart =
       SrcNameStart + Header->NamesSize +
       __llvm_profile_get_num_padding_bytes(Header->NamesSize);
   if (SrcNameStart < (const char *)SrcCountersStart)
     return 1;
 
   for (SrcData = SrcDataStart,
       DstData = (__llvm_profile_data *)__llvm_profile_begin_data(),
       SrcValueProfData = SrcValueProfDataStart;
        SrcData < SrcDataEnd; ++SrcData, ++DstData) {
-    uint64_t *DstCounters = (uint64_t *)DstData->CounterPtr;
+    uint64_t *DstCounters =
+        (uint64_t *)((uintptr_t)DstData + DstData->CounterPtr);
     unsigned NVK = 0;
 
+    uint64_t *SrcCounters =
+        SrcCountersStart +
+        ((uintptr_t)SrcData->CounterPtr - CountersDelta) / sizeof(uint64_t);
+    CountersDelta -= sizeof(*SrcData);
     unsigned NC = SrcData->NumCounters;
     if (NC == 0)
       return 1;
-    uint64_t *SrcCounters = SrcCountersStart + ((size_t)SrcData->CounterPtr -
-                                                Header->CountersDelta) /
-                                                   sizeof(uint64_t);
     if (SrcCounters < SrcCountersStart ||
         (const char *)SrcCounters >= SrcNameStart ||
         (const char *)(SrcCounters + NC) > SrcNameStart)
       return 1;
     for (unsigned I = 0; I < NC; I++)
       DstCounters[I] += SrcCounters[I];
 
     /* Now merge value profile data. */

llvm/include/llvm/ProfileData/InstrProfData.inc

 #define INSTR_PROF_DATA_DEFINED
 #endif
 INSTR_PROF_DATA(const uint64_t, llvm::Type::getInt64Ty(Ctx), NameRef, \
                 ConstantInt::get(llvm::Type::getInt64Ty(Ctx), \
                 IndexedInstrProf::ComputeHash(getPGOFuncNameVarInitializer(Inc->getName()))))
 INSTR_PROF_DATA(const uint64_t, llvm::Type::getInt64Ty(Ctx), FuncHash, \
                 ConstantInt::get(llvm::Type::getInt64Ty(Ctx), \
                 Inc->getHash()->getZExtValue()))
-INSTR_PROF_DATA(const IntPtrT, llvm::Type::getInt64PtrTy(Ctx), CounterPtr, \
-                ConstantExpr::getBitCast(CounterPtr, \
-                llvm::Type::getInt64PtrTy(Ctx)))
+INSTR_PROF_DATA(const IntPtrT, IntPtrTy, CounterPtr,
+                ConstantExpr::getSub(ConstantExpr::getPtrToInt(CounterPtr,
+                                                               IntPtrTy),
+                                     ConstantExpr::getPtrToInt(Data, IntPtrTy)))
 /* This is used to map function pointers for the indirect call targets to
  * function name hashes during the conversion from raw to merged profile
  * data.
  */
 INSTR_PROF_DATA(const IntPtrT, llvm::Type::getInt8PtrTy(Ctx), FunctionPointer, \
                 FunctionAddr)
 INSTR_PROF_DATA(IntPtrT, llvm::Type::getInt8PtrTy(Ctx), Values, \
                 ValuesPtrExpr)

llvm/lib/ProfileData/InstrProfReader.cpp

Error RawInstrProfReader<IntPtrT>::createSymtab(InstrProfSymtab &Symtab) {
   }
   return success();
 }
 
 template <class IntPtrT>
 Error RawInstrProfReader<IntPtrT>::readHeader(
     const RawInstrProf::Header &Header) {
   Version = swap(Header.Version);
   if (GET_VERSION(Version) != RawInstrProf::Version)
     return error(instrprof_error::unsupported_version);
 
   CountersDelta = swap(Header.CountersDelta);
   NamesDelta = swap(Header.NamesDelta);
   auto DataSize = swap(Header.DataSize);
   auto PaddingBytesBeforeCounters = swap(Header.PaddingBytesBeforeCounters);
   auto CountersSize = swap(Header.CountersSize);
   auto PaddingBytesAfterCounters = swap(Header.PaddingBytesAfterCounters);
Error RawInstrProfReader<IntPtrT>::readRawCounts(
   auto *NamesStartAsCounter = reinterpret_cast<const uint64_t *>(NamesStart);
   ptrdiff_t MaxNumCounters = NamesStartAsCounter - CountersStart;
 
   // Check bounds. Note that the counter pointer embedded in the data record
   // may itself be corrupt.
   if (MaxNumCounters < 0 || NumCounters > (uint32_t)MaxNumCounters)
     return error(instrprof_error::malformed);
   ptrdiff_t CounterOffset = getCounterOffset(CounterPtr);
+  CountersDelta -= sizeof(*Data);
   if (CounterOffset < 0 || CounterOffset > MaxNumCounters ||
       ((uint32_t)CounterOffset + NumCounters) > (uint32_t)MaxNumCounters)
     return error(instrprof_error::malformed);
 
   auto RawCounts = makeArrayRef(getCounter(CounterOffset), NumCounters);
 
   if (ShouldSwapBytes) {
     Record.Counts.clear();

llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp

if (NS) {
       ValuesVar->setAlignment(Align(8));
       MaybeSetComdat(ValuesVar);
       ValuesPtrExpr =
           ConstantExpr::getBitCast(ValuesVar, Type::getInt8PtrTy(Ctx));
     }
   }
 
   // Create data variable.
+  auto *IntPtrTy = M->getDataLayout().getIntPtrType(M->getContext());
   auto *Int16Ty = Type::getInt16Ty(Ctx);
   auto *Int16ArrayTy = ArrayType::get(Int16Ty, IPVK_Last + 1);
   Type *DataTypes[] = {
 #define INSTR_PROF_DATA(Type, LLVMType, Name, Init) LLVMType,
 #include "llvm/ProfileData/InstrProfData.inc"
   };
   auto *DataTy = StructType::get(Ctx, makeArrayRef(DataTypes));
 
   Constant *FunctionAddr = shouldRecordFunctionAddr(Fn)
                                ? ConstantExpr::getBitCast(Fn, Int8PtrTy)
                                : ConstantPointerNull::get(Int8PtrTy);
 
   Constant *Int16ArrayVals[IPVK_Last + 1];
   for (uint32_t Kind = IPVK_First; Kind <= IPVK_Last; ++Kind)
     Int16ArrayVals[Kind] = ConstantInt::get(Int16Ty, PD.NumValueSites[Kind]);
 
-  Constant *DataVals[] = {
-#define INSTR_PROF_DATA(Type, LLVMType, Name, Init) Init,
-#include "llvm/ProfileData/InstrProfData.inc"
-  };
   // If the data variable is not referenced by code, and linker GC can retain
   // the data variable if the associated counter is retained, the data variable
   // can be private. This optimization applies on ELF. On COFF, when
   // DataReferencedByCode is false, __profd_ is never a comdat leader, this is
   // applicable as well.
   if ((TT.isOSBinFormatELF() && NS == 0) || (!DataReferencedByCode &&
       TT.isOSBinFormatCOFF())) {
     Linkage = GlobalValue::PrivateLinkage;
     Visibility = GlobalValue::DefaultVisibility;
   }
   auto *Data =
-      new GlobalVariable(*M, DataTy, false, Linkage,
-                         ConstantStruct::get(DataTy, DataVals), DataVarName);
+      new GlobalVariable(*M, DataTy, false, Linkage, nullptr, DataVarName);
+
+  Constant *DataVals[] = {
+#define INSTR_PROF_DATA(Type, LLVMType, Name, Init) Init,
+#include "llvm/ProfileData/InstrProfData.inc"
+  };
+  Data->setInitializer(ConstantStruct::get(DataTy, DataVals));
+
   Data->setVisibility(Visibility);
   Data->setSection(getInstrProfSectionName(IPSK_data, TT.getObjectFormat()));
   Data->setAlignment(Align(INSTR_PROF_DATA_ALIGNMENT));
   MaybeSetComdat(Data);
   Data->setLinkage(Linkage);
 
   PD.RegionCounters = CounterPtr;
   PD.DataVar = Data;

llvm/test/Instrumentation/InstrProfiling/icall.ll

 ; DYN-NOT: @__llvm_prf_vnodes
 
 ;; __llvm_prf_vnodes and __llvm_prf_nm are not referenced by other metadata sections.
 ;; We have to conservatively place them in llvm.used.
 ; STATIC:      @llvm.used = appending global
 ; STATIC-SAME:   @__llvm_prf_vnodes
 ; STATIC-SAME:   @__llvm_prf_nm
 
-; STATIC: call void @__llvm_profile_instrument_target(i64 %3, i8* bitcast ({ i64, i64, i64*, i8*, i8*, i32, [2 x i16] }* @__profd_foo to i8*), i32 0)
-; STATIC-EXT: call void @__llvm_profile_instrument_target(i64 %3, i8* bitcast ({ i64, i64, i64*, i8*, i8*, i32, [2 x i16] }* @__profd_foo to i8*), i32 zeroext 0)
-; STATIC-SEXT: call void @__llvm_profile_instrument_target(i64 %3, i8* bitcast ({ i64, i64, i64*, i8*, i8*, i32, [2 x i16] }* @__profd_foo to i8*), i32 signext 0)
+; STATIC: call void @__llvm_profile_instrument_target(i64 %3, i8* bitcast ({ i64, i64, i64, i8*, i8*, i32, [2 x i16] }* @__profd_foo to i8*), i32 0)
+; STATIC-EXT: call void @__llvm_profile_instrument_target(i64 %3, i8* bitcast ({ i64, i64, i64, i8*, i8*, i32, [2 x i16] }* @__profd_foo to i8*), i32 zeroext 0)
+; STATIC-SEXT: call void @__llvm_profile_instrument_target(i64 %3, i8* bitcast ({ i64, i64, i64, i8*, i8*, i32, [2 x i16] }* @__profd_foo to i8*), i32 signext 0)
 
 ; STATIC: declare void @__llvm_profile_instrument_target(i64, i8*, i32)
 ; STATIC-EXT: declare void @__llvm_profile_instrument_target(i64, i8*, i32 zeroext)
 ; STATIC-SEXT: declare void @__llvm_profile_instrument_target(i64, i8*, i32 signext)

llvm/test/Instrumentation/InstrProfiling/profiling.ll

 @__profn_foo = private constant [3 x i8] c"foo"
 ; CHECK-NOT: __profn_foo
 @__profn_bar = private constant [3 x i8] c"bar"
 ; CHECK-NOT: __profn_bar
 @__profn_baz = private constant [3 x i8] c"baz"
 ; CHECK-NOT: __profn_baz
 
 ; ELF:   @__profc_foo = private global [1 x i64] zeroinitializer, section "__llvm_prf_cnts", comdat, align 8
-; ELF:   @__profd_foo = private {{.*}}, section "__llvm_prf_data", comdat($__profc_foo), align 8
+; ELF:   @__profd_foo = private global { i64, i64, i64, i8*, i8*, i32, [2 x i16] } { i64 [[#]], i64 0, i64 sub (i64 ptrtoint ([1 x i64]* @__profc_foo to i64), i64 ptrtoint ({ i64, i64, i64, i8*, i8*, i32, [2 x i16] }* @__profd_foo to i64)), i8* null, i8* null, i32 1, [2 x i16] zeroinitializer }, section "__llvm_prf_data", comdat($__profc_foo), align 8
 ; MACHO: @__profc_foo = private global [1 x i64] zeroinitializer, section "__DATA,__llvm_prf_cnts", align 8
 ; MACHO: @__profd_foo = private {{.*}}, section "__DATA,__llvm_prf_data,regular,live_support", align 8
 ; WIN:   @__profc_foo = private global [1 x i64] zeroinitializer, section ".lprfc$M", align 8
 ; WIN:   @__profd_foo = private {{.*}}, section ".lprfd$M", align 8
 define void @foo() {
   call void @llvm.instrprof.increment(i8* getelementptr inbounds ([3 x i8], [3 x i8]* @__profn_foo, i32 0, i32 0), i64 0, i32 1, i32 0)
   ret void
 }

 
 declare void @llvm.instrprof.increment(i8*, i64, i32, i32)
 
 ; ELF:   @llvm.compiler.used = appending global {{.*}} @__llvm_profile_runtime_user {{.*}} @__profd_foo {{.*}} @__profd_bar {{.*}} @__profd_baz
 ; MACHO: @llvm.used = appending global {{.*}} @__llvm_profile_runtime_user {{.*}} @__profd_foo {{.*}} @__profd_bar {{.*}} @__profd_baz
 ; WIN:   @llvm.compiler.used = appending global {{.*}} @__llvm_profile_runtime_user {{.*}} @__profd_foo {{.*}} @__profd_bar {{.*}} @__profd_baz
 
 ; ELF_GENERIC:      define internal void @__llvm_profile_register_functions() unnamed_addr {
-; ELF_GENERIC-NEXT:   call void @__llvm_profile_register_function(i8* bitcast ({ i64, i64, i64*, i8*, i8*, i32, [2 x i16] }* @__profd_foo to i8*))
-; ELF_GENERIC-NEXT:   call void @__llvm_profile_register_function(i8* bitcast ({ i64, i64, i64*, i8*, i8*, i32, [2 x i16] }* @__profd_bar to i8*))
-; ELF_GENERIC-NEXT:   call void @__llvm_profile_register_function(i8* bitcast ({ i64, i64, i64*, i8*, i8*, i32, [2 x i16] }* @__profd_baz to i8*))
+; ELF_GENERIC-NEXT:   call void @__llvm_profile_register_function(i8* bitcast ({ i64, i64, i64, i8*, i8*, i32, [2 x i16] }* @__profd_foo to i8*))
+; ELF_GENERIC-NEXT:   call void @__llvm_profile_register_function(i8* bitcast ({ i64, i64, i64, i8*, i8*, i32, [2 x i16] }* @__profd_bar to i8*))
+; ELF_GENERIC-NEXT:   call void @__llvm_profile_register_function(i8* bitcast ({ i64, i64, i64, i8*, i8*, i32, [2 x i16] }* @__profd_baz to i8*))
 ; ELF_GENERIC-NEXT:   call void @__llvm_profile_register_names_function(i8* getelementptr inbounds {{.*}} @__llvm_prf_nm
 ; ELF_GENERIC-NEXT:   ret void
 ; ELF_GENERIC-NEXT: }
 
 ; ELF_LINUX-NOT: @__llvm_profile_register_functions()

llvm/test/Transforms/PGOProfile/comdat_internal.ll

 ; RUN: opt < %s -pgo-instr-gen -instrprof -S | FileCheck %s
 ; RUN: opt < %s -passes=pgo-instr-gen,instrprof -S | FileCheck %s
 target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-unknown-linux-gnu"
 
 $foo = comdat any
 ; CHECK: $foo = comdat any
 
 ; CHECK: $__llvm_profile_raw_version = comdat any
 ; CHECK: $__profc__stdin__foo.[[#FOO_HASH:]] = comdat any
 
 @bar = global i32 ()* @foo, align 8
 
 ; CHECK: @__llvm_profile_raw_version = constant i64 {{[0-9]+}}, comdat
 ; CHECK-NOT: __profn__stdin__foo
 ; CHECK: @__profc__stdin__foo.[[#FOO_HASH]] = private global [1 x i64] zeroinitializer, section "__llvm_prf_cnts", comdat, align 8
-; CHECK: @__profd__stdin__foo.[[#FOO_HASH]] = private global { i64, i64, i64*, i8*, i8*, i32, [2 x i16] } { i64 -5640069336071256030, i64 [[#FOO_HASH]], i64* getelementptr inbounds ([1 x i64], [1 x i64]* @__profc__stdin__foo.[[#FOO_HASH]], i32 0, i32 0), i8* null
+; CHECK: @__profd__stdin__foo.[[#FOO_HASH]] = private global { i64, i64, i64, i8*, i8*, i32, [2 x i16] } { i64 -5640069336071256030, i64 [[#FOO_HASH]], i64 sub (i64 ptrtoint ([1 x i64]* @__profc__stdin__foo.742261418966908927 to i64), i64 ptrtoint ({ i64, i64, i64, i8*, i8*, i32, [2 x i16] }* @__profd__stdin__foo.742261418966908927 to i64)), i8* null
 ; CHECK-NOT: bitcast (i32 ()* @foo to i8*)
 ; CHECK-SAME: , i8* null, i32 1, [2 x i16] zeroinitializer }, section "__llvm_prf_data", comdat($__profc__stdin__foo.[[#FOO_HASH]]), align 8
 ; CHECK: @__llvm_prf_nm
 ; CHECK: @llvm.compiler.used
 
 define internal i32 @foo() comdat {
 entry:
   ret i32 1
 }

llvm/test/Transforms/PGOProfile/memcpy.ll

for.cond1:
   %add.ptr = getelementptr inbounds i32, i32* %a, i64 %idx.ext
   %0 = load i32, i32* %add.ptr, align 4
   %cmp2 = icmp slt i32 %j.0, %0
   %add = add nsw i32 %i.0, 1
   br i1 %cmp2, label %for.body3, label %for.cond
 
 for.body3:
   %conv = sext i32 %add to i64
-; CHECK: call void @__llvm_profile_instrument_memop(i64 %conv, i8* bitcast ({ i64, i64, i64*, i8*, i8*, i32, [2 x i16] }* @__profd_foo to i8*), i32 0)
+; CHECK: call void @__llvm_profile_instrument_memop(i64 %conv, i8* bitcast ({ i64, i64, i64, i8*, i8*, i32, [2 x i16] }* @__profd_foo to i8*), i32 0)
   call void @llvm.memcpy.p0i8.p0i8.i64(i8* %dst, i8* %src, i64 %conv, i1 false)
   %inc = add nsw i32 %j.0, 1
   br label %for.cond1
 
 for.end6:
   ret void
 }
 
 declare void @llvm.memcpy.p0i8.p0i8.i64(i8* nocapture writeonly, i8* nocapture readonly, i64, i1)

llvm/test/tools/llvm-profdata/raw-32-bits-be.test

 RUN: printf '\1\0\0\0' >> %t
 RUN: printf '\0\0\0\0' >> %t
 RUN: printf '\0\0\0\0' >> %t
 RUN: printf '\0\0\0\1' >> %t
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t
 
 RUN: printf '\344\023\165\112\031\035\265\067' >> %t
 RUN: printf '\0\0\0\0\0\0\0\2' >> %t
-RUN: printf '\1\0\0\10' >> %t
+RUN: printf '\0\xff\xff\xe0' >> %t
 RUN: printf '\0\0\0\0' >> %t
 RUN: printf '\0\0\0\0' >> %t
 RUN: printf '\0\0\0\2' >> %t
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t
 
 RUN: printf '\0\0\0\0\0\0\0\023' >> %t
 RUN: printf '\0\0\0\0\0\0\0\067' >> %t
 RUN: printf '\0\0\0\0\0\0\0\101' >> %t

llvm/test/tools/llvm-profdata/raw-32-bits-le.test

 RUN: printf '\0\0\0\1' >> %t
 RUN: printf '\0\0\0\0' >> %t
 RUN: printf '\0\0\0\0' >> %t
 RUN: printf '\1\0\0\0' >> %t
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t
 
 RUN: printf '\067\265\035\031\112\165\023\344' >> %t
 RUN: printf '\02\0\0\0\0\0\0\0' >> %t
-RUN: printf '\10\0\0\1' >> %t
+RUN: printf '\xe0\xff\xff\0' >> %t
 RUN: printf '\0\0\0\0' >> %t
 RUN: printf '\0\0\0\0' >> %t
 RUN: printf '\2\0\0\0' >> %t
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t
 
 RUN: printf '\023\0\0\0\0\0\0\0' >> %t
 RUN: printf '\067\0\0\0\0\0\0\0' >> %t
 RUN: printf '\101\0\0\0\0\0\0\0' >> %t

llvm/test/tools/llvm-profdata/raw-64-bits-be.test

 RUN: printf '\0\0\0\0\0\0\0\1' >> %t
 RUN: printf '\0\0\0\1\0\4\0\0' >> %t
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t
 RUN: printf '\0\0\0\1\0\0\0\0' >> %t
 
 RUN: printf '\344\023\165\112\031\035\265\067' >> %t
 RUN: printf '\0\0\0\0\0\0\0\02' >> %t
-RUN: printf '\0\0\0\1\0\4\0\10' >> %t
+RUN: printf '\0\0\0\1\0\3\xff\xd8' >> %t
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t
 RUN: printf '\0\0\0\02\0\0\0\0' >> %t
 
 RUN: printf '\0\0\0\0\0\0\0\023' >> %t
 RUN: printf '\0\0\0\0\0\0\0\067' >> %t
 RUN: printf '\0\0\0\0\0\0\0\101' >> %t
 RUN: printf '\7\0foo\1bar\0\0\0\0\0\0\0' >> %t

llvm/test/tools/llvm-profdata/raw-64-bits-le.test

 RUN: printf '\1\0\0\0\0\0\0\0' >> %t
 RUN: printf '\0\0\4\0\1\0\0\0' >> %t
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t
 RUN: printf '\1\0\0\0\0\0\0\0' >> %t
 
 RUN: printf '\067\265\035\031\112\165\023\344' >> %t
 RUN: printf '\02\0\0\0\0\0\0\0' >> %t
-RUN: printf '\10\0\4\0\1\0\0\0' >> %t
+RUN: printf '\xd8\xff\3\0\1\0\0\0' >> %t
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t
 RUN: printf '\02\0\0\0\0\0\0\0' >> %t
 
 RUN: printf '\023\0\0\0\0\0\0\0' >> %t
 RUN: printf '\067\0\0\0\0\0\0\0' >> %t
 RUN: printf '\101\0\0\0\0\0\0\0' >> %t
 RUN: printf '\7\0foo\1bar\0\0\0\0\0\0\0' >> %t