[profile] Add binary id into profiles

[gulfem]

Summary

This patch adds binary id into profiles to easily associate binaries
with the corresponding profiles. There is also an RFC that
discusses the motivation, design and implementation in more detail:
https://lists.llvm.org/pipermail/llvm-dev/2021-June/151154.html

[phosek]

compiler-rt/include/profile/InstrProfData.inc

132

Instead of HasBuildId as a boolean, I think it might be better to use BuildIdSize to allow multiple ids. While raw profiles should have either 0 or 1 in practice, indexed profiles created by merging multiple raw profiles could have multiple ids, so using BuildIdSize would allow using the same header format for both raw and indexed format.

compiler-rt/lib/profile/InstrProfilingWriter.c

36

I'm not sure if we should be using the term BuildId since it can be interpreted as ELF-specific. We want this to generalize to other binary formats like Mach-O and COFF. In Mach-O, it's called LC_UUID. In COFF, it's usually referred to as GUID.

When searching online, I noticed that lld also build ID for COFF, see D36758, but I'm not sure if that's official name or if they just copied the name from the ELF implementation. So one option would be to just use BuildId but make it clear that it's a generic term. Another option would be a new name, for example BinaryId.

263

This function implements ELF-specific logic so it cannot be in InstrProfilingWriter.c which is platform agnostic. It should be InstrProfilingPlatformLinux.c and we'll need COFF and Mach-O equivalents in InstrProfilingPlatformWindows.c and InstrProfilingPlatformDarwin.c respectively (which could be empty in the initial implementation).

291

I think that we should avoid allocating the BuildId struct on the heap which could cause an issue when allocator itself is instrumented. Two solutions I can think of is to either allocate the struct as static (it's 8-16 bytes which is not so bad) or alternatively this function could use ProfDataWriter to directly write out the struct in which case it could be allocated on stack.

[gulfem]

1. Move elf specific details into InstrProfilingPlatformLinux.c
2. Remove build id struct
3. Use binary id instead of build id

[gulfem]

compiler-rt/include/profile/InstrProfData.inc

132

Can a raw profile with build id and another raw profile without a build id be merged and create indexed profiled?

compiler-rt/lib/profile/InstrProfilingWriter.c

36

I renamed it to binary id, and I will briefly explain other ids used in other platforms in the RFC.

291

It seems like ValueProfiling already uses heap allocation compiler-rt/lib/profile/InstrProfilingValue.c, but we don't really need heap allocation for build id.
So, I removed build id struct.
Please let me know what you think about the new implementation.

[gulfem]

compiler-rt/include/profile/InstrProfData.inc

132

@phosek, it seems to me like raw and indexed profile do not share the same profile format.
For ex, raw profile header is defined in:
https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/ProfileData/InstrProfData.inc#L130

Whereas, indexed profile header is defined in:
https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/ProfileData/InstrProf.h#L999

I think, we might need to extend both formats with binary id then.
Please let me know if I'm missing anything.

[phosek]

compiler-rt/include/profile/InstrProfData.inc

132

Yes, looks like we'll need to extend both formats but I still think it'd be preferable to support arbitrary number of binary id's in both formats since at least in ELF, you can have more than one build ID. The format of should also be the same in both the raw and indexed format, that is a sequence of tuples where each tuple is a length and a sequence of bytes of that length.

compiler-rt/lib/profile/InstrProfiling.h

101 ↗

(On Diff #344474)

I'd slightly prefer returning both the data and the size as output parameters for consistency. We might also consider having a boolean/int return argument to signal an error.

compiler-rt/lib/profile/InstrProfilingWriter.c

287–288

You shouldn't need an extra variable for the pointer.

291

That's true but it's also possible to allocate counter for value profiling statically if you use -mllvm -vp-static-alloc in which case you can avoid malloc which may be desirable on some platforms (this is what we would likely use on Fuchsia for example).

llvm/tools/llvm-profdata/llvm-profdata.cpp

2256

I think we'll want this functionality even in the final version but we should introduce additional flag, for example -show-binary-id, and only print the binary id if that flag is set.

[gulfem]

1. Support multiple binary ids
2. Extend indexed profile format to include binary ids
3. Add tests

[gulfem]

Use clang-format to correctly format the code

[mcgrathr]

compiler-rt/lib/profile/InstrProfilingPlatformLinux.c

102

This is insufficient. The note "name" determines the space of n_type values. You must verify that the n_namesz=4 and the name bytes are "GNU\0" as well, or else this is some unrelated note that happens to use n_type=3 where 3 does not mean NT_GNU_BUILD_ID.

105

This arithmetic is not right since Note has a type with sizeof>1. An example of correct arithmetic is:

Note = (const ElfW(Nhdr)*)((const char *)(Note + 1) + RoundUp(Note->n_namesz, 4) + RoundUp(Note->n_descsz, 4));

120

Can you abstract this logic into a subroutine so the code is not repeated in the two functions?
A simple approach would be a subroutine that takes a maybe-null ProfDataWriter pointer and when called with a null pointer just returns the size instead of calling the writer.

compiler-rt/test/profile/binary-id.c

2

You may need to pass explicit -Wl,--build-id=none through the compiler here since it's sometimes on by default.

llvm/include/llvm/ProfileData/InstrProfReader.h

85

Is this the number of distinct IDs, or the byte size of the total block? (AIUI the total block is a sequence of {uint64_t n, uint8_t[n]} blocks.) If it's the number of distinct IDs, then I don't understand how a single uint8_t* from getBinaryIds() is meant to be used. For a number like that, I think Count is a clearer name to use than Size.

91

Should these really be two separate methods? Or should it just be one method that returns both the size and the data in a span-style data structure?

484

I don't understand the commented-out declaration.

llvm/lib/ProfileData/InstrProfReader.cpp

541

This is wildly susceptible to bad data.

[gulfem]

Addressed Roland's comments

[gulfem]

compiler-rt/lib/profile/InstrProfilingPlatformLinux.c

105

My understanding is that each note in notes section starts with a struct which includes n_namesz, n_descsz, and n_type members.
It is followed by the name (whose length is defined in n_namesz) and then by the descriptor (whose length is defined in n_descsz).
So, type is already part of the struct. The arithmetic I have increases Note by struct size, and name data, and descriptor data.
Am I missing anything?

llvm/include/llvm/ProfileData/InstrProfReader.h

85

Is this the number of distinct IDs, or the byte size of the total block?

It is the number of binary IDs. That file consistently uses Size to refer to number of elements like DataSize, CounterSize, NamesSize, etc.
I don't like that either, but I just used Size to be consistent with the rest of the implementation.
I think Count or NumOf is more self-explanatory.

llvm/lib/ProfileData/InstrProfReader.cpp

541

This is wildly susceptible to bad data.

541

How can I improve that? I need to somehow increment the pointer by binary id length.

[phosek]

compiler-rt/include/profile/InstrProfData.inc

132

I'd prefer to put this field at the end of the header to match the position of binary ID in the profile.

compiler-rt/lib/profile/InstrProfilingInternal.h

202

This name is a bit of a mouthful. I'd consider calling it just __llvm_write_binary_ids and say in the comment that the function always returns the number of binary ids even if writer is NULL.

compiler-rt/lib/profile/InstrProfilingPlatformLinux.c

105

I think we should be returning the number of binary ids in every case, even if writer != NULL.

105

When you increment a pointer, the address is moved by the size of the underlying type:

char* c = ...;
c++; // c increments by 1 == sizeof(char)
uint64_t* l = ...;
l++; // l increments by 8 == sizeof(uint64_t)

In this case sizeof(Note) > 1 so you first need to cast it to const char *.

llvm/lib/ProfileData/InstrProfReader.cpp

517

Where is this deallocated? It seems like this memory gets leaked. BinaryIdTy is just a plain struct with just two 8 byte fields (on a 64-bit machine), can we avoid allocating it on the heap and return/pass it by value to simplify lifetime management?

541

I think at minimum, you need to check that you aren't reading past the end of the file in the case the length is incorrect.

[gulfem]

Addressed Petr's comments

[gulfem]

llvm/lib/ProfileData/InstrProfReader.cpp

517

I used unique_ptr, so memory will be released after BinaryIdTy goes out of scope.

[phosek]

llvm/lib/ProfileData/InstrProfReader.cpp

517

I'd still prefer passing these by value, heap allocation in this case seems unnecessary and is going to be less efficient.

[gulfem]

Here's the link to the RFC:
https://lists.llvm.org/pipermail/llvm-dev/2021-June/151154.html

[phosek]

@vsk @davidxl Do you have any thoughts on this? We've already done a few rounds of reviews, but we'd like to get your opinion as well.

[davidxl]

Repeating the same question asked in RFC: the profile data has builtin fine grained matching mechanism. For the top level stamping, is it enough to embed the build id in the file name of the profile data?

[gulfem]

In D102039#2841108, @davidxl wrote:

Repeating the same question asked in RFC: the profile data has builtin fine grained matching mechanism. For the top level stamping, is it enough to embed the build id in the file name of the profile data?

Just to clarify: we are suggesting to embed build in the profile file itself, not in the profile file name.
This will also allow us to embed multiple build ids if profiles are merged together.
Can you please elaborate on the builtin fine grained matching mechanism and why do you think it will be a problem?

[phosek]

In D102039#2841108, @davidxl wrote:

Repeating the same question asked in RFC: the profile data has builtin fine grained matching mechanism. For the top level stamping, is it enough to embed the build id in the file name of the profile data?

We need to be able to match the profile back to the corresponding binary when generating coverage. Embedding build ID in filename doesn't work for us because on Fuchsia, most processes don't have access to filesystem (it's a capability that most processes shouldn't need). Rather the profile is exported via IPC as a memory object that doesn't have any name.

There might be a Fuchsia-specific solution, like wrapping the profile in an envelope that contains he build ID, but that solution would be Fuchsia-specific and we thought that making profiles more self-descriptive could be generally useful.

One idea we would like to pursue in the future is implementing support for the debuginfod protocol in LLVM, including llvm-cov, you could then use llvm-cov --instr-profile default.profraw and llvm-cov would fetch both the binary and the source from debuginfod server using the build ID inside the profile. In our case, this would not only simplify our infrastructure but also make it easy for developers to generate coverage reports from profiles fetched directly from our CI to reproduce results.

[davidxl]

I am less concerned about raw profile format change (the version still needs to be bumped), but for the indexed format, the version needs to be bumped and it needs to guarantee that format is backward compatible. The patch does not seem to handle it.

Is it necessary to have binary id support in the indexed format?

[gulfem]

In D102039#2841389, @davidxl wrote:

I am less concerned about raw profile format change (the version still needs to be bumped), but for the indexed format, the version needs to be bumped and it needs to guarantee that format is backward compatible. The patch does not seem to handle it.

Is it necessary to have binary id support in the indexed format?

Yes, we need to bump the version. There is still some work that needs to be done in this patch like bumping the version, adjusting some of the tests, and adding more tests, etc.
We would like to get early feedback to see whether there is any fundamental issue about the approach.
@phosek can correct me, but I think we need to have binary id support in the indexed format.
We merge raw profiles into indexed profiles before generating source code coverage reports, and in order to associate binaries while generating coverage, we need to have binary id in the indexed profiles.

[davidxl]

In D102039#2841703, @gulfem wrote:

In D102039#2841389, @davidxl wrote:

I am less concerned about raw profile format change (the version still needs to be bumped), but for the indexed format, the version needs to be bumped and it needs to guarantee that format is backward compatible. The patch does not seem to handle it.

Is it necessary to have binary id support in the indexed format?

Yes, we need to bump the version. There is still some work that needs to be done in this patch like bumping the version, adjusting some of the tests, and adding more tests, etc.
We would like to get early feedback to see whether there is any fundamental issue about the approach.
@phosek can correct me, but I think we need to have binary id support in the indexed format.
We merge raw profiles into indexed profiles before generating source code coverage reports, and in order to associate binaries while generating coverage, we need to have binary id in the indexed profiles.

Is the merging done in process or offline? Assuming it is offline, it seems possible to use name base approach.

[phosek]

In D102039#2841709, @davidxl wrote:

Is the merging done in process or offline? Assuming it is offline, it seems possible to use name base approach.

It's done offline but since the profiles published via IPC don't have any names, we cannot rely or filenames, we would need to introduce a custom Fuchsia wrapper format (see my previous comment about the "envelope" idea).

We don't necessarily need binary ID in the indexed format, what we could do is:

llvm-profdata show --binary-id a.profraw >a.buildid
# fetch a binary with a.buildid as a.out
llvm-profdata show --binary-id b.profraw >b.buildid
# fetch a binary with b.buildid as b.out
...
llvm-profdata merge -o merged.profdata a.profraw b.profraw ...
llvm-cov show --instr-profile=merged.profdata a.out b.out ...

If we also stored binary IDs inside the indexed format, we could simplify this and do:

llvm-profdata show --binary-ids merged.profdata >merged.buildids
# fetch all binaries

This is more efficient but either would be fine with us for now.

Storing binary IDs inside the indexed profile would become really valuable if/once we have support debuginfod support at which point we should be able to just do:

llvm-profdata merge -o merged.profdata a.profraw b.profraw ...
llvm-cov show --instr-profile=merged.profdata

and llvm-cov would fetch binaries directly from the debuginfod server using binary IDs stored inside the indexed profile. It'll take a while before we have debuginfod support available in LLVM though so this is not critical for now, we're just trying to plan ahead.

Is extending the indexed format a problem? Is there some way to make it less of an issue?

[davidxl]

In D102039#2845002, @phosek wrote:

In D102039#2841709, @davidxl wrote:

Is the merging done in process or offline? Assuming it is offline, it seems possible to use name base approach.

It's done offline but since the profiles published via IPC don't have any names, we cannot rely or filenames, we would need to introduce a custom Fuchsia wrapper format (see my previous comment about the "envelope" idea).

We don't necessarily need binary ID in the indexed format, what we could do is:

llvm-profdata show --binary-id a.profraw >a.buildid
# fetch a binary with a.buildid as a.out
llvm-profdata show --binary-id b.profraw >b.buildid
# fetch a binary with b.buildid as b.out
...
llvm-profdata merge -o merged.profdata a.profraw b.profraw ...
llvm-cov show --instr-profile=merged.profdata a.out b.out ...

If we also stored binary IDs inside the indexed format, we could simplify this and do:

llvm-profdata show --binary-ids merged.profdata >merged.buildids
# fetch all binaries

This is more efficient but either would be fine with us for now.

Storing binary IDs inside the indexed profile would become really valuable if/once we have support debuginfod support at which point we should be able to just do:

llvm-profdata merge -o merged.profdata a.profraw b.profraw ...
llvm-cov show --instr-profile=merged.profdata

and llvm-cov would fetch binaries directly from the debuginfod server using binary IDs stored inside the indexed profile. It'll take a while before we have debuginfod support available in LLVM though so this is not critical for now, we're just trying to plan ahead.

I suppose this workflow can also be done with

llvm-cov show --instr-profile=merged.profdata --buildids=<file of list of ids> without the need to fetch the binaries.

Is extending the indexed format a problem? Is there some way to make it less of an issue?

It is not an issue, but I think it is preferable minimize version bumps for indexed format to reduce longer term churns. Given this restriction, it is better to make version change tied to functionalities that can do without a format change. Scripts, wrappers etc. are better for non-essential changes -- especially for workflows that can be mostly automated (which minimizes human inconveniences).

[gulfem]

1. Add binary id between profile header and data
2. Raw profile version bump
3. Only add binary id into raw profiles

[aeubanks]

I'm not familiar enough with this code

[gulfem]

In D102039#2880917, @aeubanks wrote:

I'm not familiar enough with this code

@aeubanks I just added you because I modified a test file (corrupted-profile.c), and you are the author of that test file.

[aeubanks]

that test change seems fine
I remember I copied the structure from another existing test though, somewhere in llvm/test/tools/llvm-profdata IIRC

[gulfem]

In D102039#2881096, @aeubanks wrote:

that test change seems fine
I remember I copied the structure from another existing test though, somewhere in llvm/test/tools/llvm-profdata IIRC

Thanks!

[phosek]

@davidxl we split the indexed profile change out of this change since it's not necessary for us right now, would it be possible to take a look again?

compiler-rt/include/profile/InstrProfData.inc

140

I'd prefer to move this field just after Version before DataSize to match the order of data inside the profile.

[davidxl]

compiler-rt/lib/profile/InstrProfilingPlatformLinux.c

92

Is it possible to extract this into a common helper function like

void ForEachNote(int note_type, .. note_start, .. note_end, ... call_back ) {

...

}

[gulfem]

1. Break WriteBinaryIds into multiple functions to increase readibility
2. Rebase

[gulfem]

compiler-rt/lib/profile/InstrProfilingPlatformLinux.c

92

I think your concern was about the readability of that function, so I broke that function into multiple functions to increase readability.
Please let me know if you other concerns.

[davidxl]

LGTM

llvm/lib/ProfileData/InstrProfReader.cpp

537

When there is no binary ids to be print, perhaps output a line with 'None' instead of empty (which looks like the output is truncated.

[gulfem]

llvm/lib/ProfileData/InstrProfReader.cpp

537

When there is no binary id, we don't print anything at all.
At line 517, we check the binary id size, and if there is no binary id, just return without printing anything.

if (BinaryIdsSize == 0)
  return success();

[gulfem]

Modified some raw profile test files to include the new profile version (version 6) and new header element (BinaryIdsSize).

[vitalybuka]

compiler-rt/test/profile/binary-id.c

12

Hi @gulfem,
Do you have some ideas why this fails on this bot?
https://lab.llvm.org/staging/#/builders/97/builds/840

[gulfem]

compiler-rt/test/profile/binary-id.c

12

Hi @vitalybuka,
I tried looking into that, but I am not able to access that bot at the moment.
I'm getting 502 Bad Gateway error, but I'll try to reproduce it later.
Hopefully, I can give your more info then!

[vitalybuka]

Yes, looks like both LLVM servers are down https://lab.llvm.org/
FYI The special about that staging bot is that it is Ubuntu with recent
glibc 2.34. Our primary bot runs exactly the same build on Debian with
glibc 2.28 and the test passes there. It can be glibc or other dependencies.

[gulfem]

In D102039#3171276, @vitalybuka wrote:

Yes, looks like both LLVM servers are down https://lab.llvm.org/
FYI The special about that staging bot is that it is Ubuntu with recent
glibc 2.34. Our primary bot runs exactly the same build on Debian with
glibc 2.28 and the test passes there. It can be glibc or other dependencies.

I tried to reproduce it on my machine, but I it uses Debian (not Ubuntu), so the issue did not reproduce.
With that patch, we started embedding build id (a unique identifier) into llvm profiles.
That test basically enables build id in the binary by using -Wl,--build-id -O2 option.
It then generates a llvm profile, and tries to read embedded build id from the profile.
What is the output of the following command?

/b/sanitizer-x86_64-linux/build/llvm_build64/bin/clang   -m64  -ldl  -fprofile-instr-generate -Wl,--build-id -O2 -o /b/sanitizer-x86_64-linux/build/compiler_rt_build/test/profile/Profile-x86_64/Linux/Output/binary-id.c.tmp /b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/profile/Linux/binary-id.c
readelf -n /b/sanitizer-x86_64-linux/build/compiler_rt_build/test/profile/Profile-x86_64/Linux/Output/binary-id.c.tmp

If we have build id in the binary, readelf (you can also use llvm-readelf instead) should have some output like that:

Displaying notes found in: .note.gnu.build-id
  Owner                Data size        Description
  GNU                  0x00000014       NT_GNU_BUILD_ID (unique build ID bitstring)
    Build ID: 8699f6e0c4e12b872aae7e1f37fa6ba2564e9702

If we have build id in the binary, we should then check whether build id is embedded in the profile:

env LLVM_PROFILE_FILE=/b/sanitizer-x86_64-linux/build/compiler_rt_build/test/profile/Profile-x86_64/Linux/Output/binary-id.c.tmp.profraw  /b/sanitizer-x86_64-linux/build/compiler_rt_build/test/profile/Profile-x86_64/Linux/Output/binary-id.c.tmp
llvm-profdata show --binary-ids  /b/sanitizer-x86_64-linux/build/compiler_rt_build/test/profile/Profile-x86_64/Linux/Output/binary-id.c.tmp.profraw

What is the output of the above command?

[vitalybuka]

buildbot@sanitizer-buildbot-vb-wlz1:/b/sanitizer-x86_64-linux/build/compiler_rt_build$
/b/sanitizer-x86_64-linux/build/llvm_build64/bin/clang   -m64  -ldl
 -fprofile-instr-generate -Wl,--build-id=none -O2 -o
/b/sanitizer-x86_64-linux/build/compiler_rt_build/test/profile/Profile-x86_64/Linux/Output/binary-id.c.tmp
/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/profile/Linux/binary-id.c
buildbot@sanitizer-buildbot-vb-wlz1:/b/sanitizer-x86_64-linux/build/compiler_rt_build$
env
LLVM_PROFILE_FILE=/b/sanitizer-x86_64-linux/build/compiler_rt_build/test/profile/Profile-x86_64/Linux/Output/binary-id.c.tmp.profraw
 /b/sanitizer-x86_64-linux/build/compiler_rt_build/test/profile/Profile-x86_64/Linux/Output/binary-id.c.tmp
buildbot@sanitizer-buildbot-vb-wlz1:/b/sanitizer-x86_64-linux/build/compiler_rt_build$
../llvm_build64/bin/llvm-profdata show --binary-ids
 /b/sanitizer-x86_64-linux/build/compiler_rt_build/test/profile/Profile-x86_64/Linux/Output/binary-id.c.tmp.profraw
>
/b/sanitizer-x86_64-linux/build/compiler_rt_build/test/profile/Profile-x86_64/Linux/Output/binary-id.c.tmp.out
buildbot@sanitizer-buildbot-vb-wlz1:/b/sanitizer-x86_64-linux/build/compiler_rt_build$
../llvm_build64/bin/llvm-profdata show --binary-ids
 /b/sanitizer-x86_64-linux/build/compiler_rt_build/test/profile/Profile-x86_64/Linux/Output/binary-id.c.tmp.profraw

Instrumentation level: Front-end
Total functions: 3
Maximum function count: 1
Maximum internal block count: 0
buildbot@sanitizer-buildbot-vb-wlz1:/b/sanitizer-x86_64-linux/build/compiler_rt_build$
../llvm_build64/bin/llvm-profdata merge -o
/b/sanitizer-x86_64-linux/build/compiler_rt_build/test/profile/Profile-x86_64/Linux/Output/binary-id.c.tmp.profdata
/b/sanitizer-x86_64-linux/build/compiler_rt_build/test/profile/Profile-x86_64/Linux/Output/binary-id.c.tmp.profraw
buildbot@sanitizer-buildbot-vb-wlz1:/b/sanitizer-x86_64-linux/build/compiler_rt_build$
/b/sanitizer-x86_64-linux/build/llvm_build64/bin/clang   -m64  -ldl
 -fprofile-instr-generate -Wl,--build-id -O2 -o
/b/sanitizer-x86_64-linux/build/compiler_rt_build/test/profile/Profile-x86_64/Linux/Output/binary-id.c.tmp
/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/profile/Linux/binary-id.c
buildbot@sanitizer-buildbot-vb-wlz1:/b/sanitizer-x86_64-linux/build/compiler_rt_build$
env
LLVM_PROFILE_FILE=/b/sanitizer-x86_64-linux/build/compiler_rt_build/test/profile/Profile-x86_64/Linux/Output/binary-id.c.tmp.profraw
 /b/sanitizer-x86_64-linux/build/compiler_rt_build/test/profile/Profile-x86_64/Linux/Output/binary-id.c.tmp
buildbot@sanitizer-buildbot-vb-wlz1:/b/sanitizer-x86_64-linux/build/compiler_rt_build$
../llvm_build64/bin/llvm-profdata show --binary-ids
 /b/sanitizer-x86_64-linux/build/compiler_rt_build/test/profile/Profile-x86_64/Linux/Output/binary-id.c.tmp.profraw

Instrumentation level: Front-end
Total functions: 3
Maximum function count: 1
Maximum internal block count: 0

And no Binary IDs

[vitalybuka]

../llvm_build64/bin/llvm-readelf -n test/profile/Profile-x86_64/Linux/Output/binary-id.c.tmp
Displaying notes found in: .note.ABI-tag
  Owner                Data size 	Description
  GNU                  0x00000010	NT_GNU_ABI_TAG (ABI version tag)
    OS: Linux, ABI: 3.2.0

Displaying notes found in: .note.gnu.property
  Owner                Data size 	Description
  GNU                  0x00000010	NT_GNU_PROPERTY_TYPE_0 (property note)
    Properties:    x86 ISA needed: x86-64-baseline


Displaying notes found in: .note.gnu.build-id
  Owner                Data size 	Description
  GNU                  0x00000014	NT_GNU_BUILD_ID (unique build ID bitstring)
    Build ID: 3dff2793618e5a04cbfef83483bc82d7d63b807d

Displaying notes found in: .note.gnu.gold-version
  Owner                Data size 	Description
  GNU                  0x00000009	NT_GNU_GOLD_VERSION (gold version)
    Version: gold 1.16

../llvm_build64/bin/llvm-profdata show --binary-ids test/profile/Profile-x86_64/Linux/Output/binary-id.c.tmp.profraw
Instrumentation level: Front-end
Total functions: 3
Maximum function count: 1
Maximum internal block count: 0

[vitalybuka]

compiler-rt/lib/profile/InstrProfilingPlatformLinux.c

178

Here is the problem
This loop stops on the first PT_NOTE, even if it's not build-id
e.g. .note.ABI-tag, check my log in the message above

[gulfem]

compiler-rt/lib/profile/InstrProfilingPlatformLinux.c

178

PT_NOTE is the note segment in the program header, and that segment can have multiple notes (https://man7.org/linux/man-pages/man5/elf.5.html).
Like, the first note is .note.ABI-tag, and the second note is .note.gnu.build-id in your log.
When I run that locally, there are still two notes, but just the order is swapped.

gulfem@gulfem:~/llvm-release-build$ bin/llvm-readelf -n /usr/local/google/home/gulfem/llvm-release-build/projects/compiler-rt/test/profile/Profile-x86_64/Linux/Output/binary-id.c.tmp
Displaying notes found in: .note.gnu.build-id
  Owner                Data size        Description
  GNU                  0x00000014       NT_GNU_BUILD_ID (unique build ID bitstring)
    Build ID: 56559dcdb2c5b111e7e875c183ca2e0a1f433c96

Displaying notes found in: .note.ABI-tag
  Owner                Data size        Description
  GNU                  0x00000010       NT_GNU_ABI_TAG (ABI version tag)
    OS: Linux, ABI: 3.2.0

Here, we iterate through all the notes.
https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/profile/InstrProfilingPlatformLinux.c#L155
This should be iterating through all the notes in your case, too.
I'm looking at that code to see whether we are missing something else.

[gulfem]

@vitalybuka, it looks like we can have have multiple note segments in the program header, and each note segment can contain multiple notes.
Thank you @mcgrathr for pointing that out.
I think your case is like that, and I'll push a fix for that.

[gulfem]

I uploaded https://reviews.llvm.org/D115830 to fix the issue.

compiler-rt/include/profile/InstrProfData.inc

 /* Definition of member fields of the raw profile header data structure. */
 #ifndef INSTR_PROF_RAW_HEADER
 #define INSTR_PROF_RAW_HEADER(Type, Name, Initializer)
 #else
 #define INSTR_PROF_DATA_DEFINED
 #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, NamesDelta, (uintptr_t)NamesBegin)
 INSTR_PROF_RAW_HEADER(uint64_t, ValueKindLast, IPVK_Last)
+INSTR_PROF_RAW_HEADER(uint64_t, BinaryIdsSize, __llvm_write_binary_ids(NULL))
 #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.
  */
 #ifndef VALUE_PROF_FUNC_PARAM

 #define INSTR_PROF_RAW_MAGIC_64 (uint64_t)255 << 56 | (uint64_t)'l' << 48 | \
        (uint64_t)'p' << 40 | (uint64_t)'r' << 32 | (uint64_t)'o' << 24 |  \
         (uint64_t)'f' << 16 | (uint64_t)'r' << 8 | (uint64_t)129
 #define INSTR_PROF_RAW_MAGIC_32 (uint64_t)255 << 56 | (uint64_t)'l' << 48 | \
        (uint64_t)'p' << 40 | (uint64_t)'r' << 32 | (uint64_t)'o' << 24 |  \
         (uint64_t)'f' << 16 | (uint64_t)'R' << 8 | (uint64_t)129
 
 /* Raw profile format version (start from 1). */
-#define INSTR_PROF_RAW_VERSION 5
+#define INSTR_PROF_RAW_VERSION 6
 /* Indexed profile format version (start from 1). */
 #define INSTR_PROF_INDEX_VERSION 7
 /* Coverage mapping format version (start from 0). */
 #define INSTR_PROF_COVMAP_VERSION 5
 
 /* Profile version is always of type uint64_t. Reserve the upper 8 bits in the
  * version for other variants of profile. We set the lowest bit of the upper 8
  * bits (i.e. bit 56) to 1 to indicate if this is an IR-level instrumentaiton

compiler-rt/lib/profile/InstrProfilingInternal.h

 COMPILER_RT_VISIBILITY extern uint8_t *DynamicBufferIOBuffer;
 COMPILER_RT_VISIBILITY extern uint32_t VPBufferSize;
 COMPILER_RT_VISIBILITY extern uint32_t VPMaxNumValsPerSite;
 /* Pointer to the start of static value counters to be allocted. */
 COMPILER_RT_VISIBILITY extern ValueProfNode *CurrentVNode;
 COMPILER_RT_VISIBILITY extern ValueProfNode *EndVNode;
 extern void (*VPMergeHook)(struct ValueProfData *, __llvm_profile_data *);
 
+/*
+ * Write binary ids into profiles if writer is given.
+ * Return -1 if an error occurs, otherwise, return total size of binary ids.
+ */
+COMPILER_RT_VISIBILITY COMPILER_RT_WEAK int
+__llvm_write_binary_ids(ProfDataWriter *Writer);
+
 #endif

compiler-rt/lib/profile/InstrProfilingInternal.c

 COMPILER_RT_VISIBILITY unsigned lprofProfileDumped() {
   return ProfileDumped;
 }
 
 COMPILER_RT_VISIBILITY void lprofSetProfileDumped(unsigned Value) {
   ProfileDumped = Value;
 }
 
+static unsigned RuntimeCounterRelocation = 0;
+
+COMPILER_RT_VISIBILITY unsigned lprofRuntimeCounterRelocation(void) {
+  return RuntimeCounterRelocation;
+}
+
+COMPILER_RT_VISIBILITY void lprofSetRuntimeCounterRelocation(unsigned Value) {
+  RuntimeCounterRelocation = Value;
+}
+
+/*
+ * The runtime provides the default definition of this function
+ * for the platforms that do not support binary id.
+ */
+COMPILER_RT_VISIBILITY COMPILER_RT_WEAK int
+__llvm_write_binary_ids(ProfDataWriter *Writer) {
+  return 0;
+}
+
 #endif

compiler-rt/lib/profile/InstrProfilingPlatformLinux.c

 /*===- InstrProfilingPlatformLinux.c - Profile data Linux platform ------===*\
 |*
 |* Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 |* See https://llvm.org/LICENSE.txt for license information.
 |* SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 |*
 \*===----------------------------------------------------------------------===*/
 
 #if defined(__linux__) || defined(__FreeBSD__) || defined(__Fuchsia__) || \
     (defined(__sun__) && defined(__svr4__)) || defined(__NetBSD__)
 
+#include <elf.h>
+#include <link.h>
 #include <stdlib.h>
+#include <string.h>
 
 #include "InstrProfiling.h"
+#include "InstrProfilingInternal.h"
 
 #define PROF_DATA_START INSTR_PROF_SECT_START(INSTR_PROF_DATA_COMMON)
 #define PROF_DATA_STOP INSTR_PROF_SECT_STOP(INSTR_PROF_DATA_COMMON)
 #define PROF_NAME_START INSTR_PROF_SECT_START(INSTR_PROF_NAME_COMMON)
 #define PROF_NAME_STOP INSTR_PROF_SECT_STOP(INSTR_PROF_NAME_COMMON)
 #define PROF_CNTS_START INSTR_PROF_SECT_START(INSTR_PROF_CNTS_COMMON)
 #define PROF_CNTS_STOP INSTR_PROF_SECT_STOP(INSTR_PROF_CNTS_COMMON)
 #define PROF_ORDERFILE_START INSTR_PROF_SECT_START(INSTR_PROF_ORDERFILE_COMMON)
__llvm_profile_begin_vnodes(void) {
   return &PROF_VNODES_START;
 }
 COMPILER_RT_VISIBILITY ValueProfNode *__llvm_profile_end_vnodes(void) {
   return &PROF_VNODES_STOP;
 }
 COMPILER_RT_VISIBILITY ValueProfNode *CurrentVNode = &PROF_VNODES_START;
 COMPILER_RT_VISIBILITY ValueProfNode *EndVNode = &PROF_VNODES_STOP;
 
+static size_t RoundUp(size_t size, size_t align) {
+  return (size + align - 1) & ~(align - 1);
+}
+
+/*
+ * Write binary id length and then its data, because binary id does not
+ * have a fixed length.
+ */
+int WriteOneBinaryId(ProfDataWriter *Writer, uint64_t BinaryIdLen,
+                     const uint8_t *BinaryIdData) {
+  ProfDataIOVec BinaryIdIOVec[] = {
+      {&BinaryIdLen, sizeof(uint64_t), 1, 0},
+      {BinaryIdData, sizeof(uint8_t), BinaryIdLen, 0}};
+  if (Writer->Write(Writer, BinaryIdIOVec,
+                    sizeof(BinaryIdIOVec) / sizeof(*BinaryIdIOVec)))
+    return -1;
+
+  /* Successfully wrote binary id, report success. */
+  return 0;
+}
+
+/*
+ * Look for the note that has the name "GNU\0" and type NT_GNU_BUILD_ID
+ * that contains build id. If build id exists, write binary id.
+ *
+ * Each note in notes section starts with a struct which includes
+ * n_namesz, n_descsz, and n_type members. It is followed by the name
+ * (whose length is defined in n_namesz) and then by the descriptor
+ * (whose length is defined in n_descsz).
+ *
+ * Note sections like .note.ABI-tag and .note.gnu.build-id are aligned
+ * to 4 bytes, so round n_namesz and n_descsz to the nearest 4 bytes.
+ */
+int WriteBinaryIdForNote(ProfDataWriter *Writer, const ElfW(Nhdr) * Note) {
+  int BinaryIdSize = 0;
+
+  const char *NoteName = (const char *)Note + sizeof(ElfW(Nhdr));
+  if (Note->n_type == NT_GNU_BUILD_ID && Note->n_namesz == 4 &&
+      memcmp(NoteName, "GNU\0", 4) == 0) {
+
+    uint64_t BinaryIdLen = Note->n_descsz;
+    const uint8_t *BinaryIdData =
+        (const uint8_t *)(NoteName + RoundUp(Note->n_namesz, 4));
+    if (Writer != NULL &&
+        WriteOneBinaryId(Writer, BinaryIdLen, BinaryIdData) == -1)
+      return -1;
+
+    BinaryIdSize = sizeof(BinaryIdLen) + BinaryIdLen;
+  }
+
+  return BinaryIdSize;
+}
+
+/*
+ * Helper function that iterates through notes section and find build ids.
+ * If writer is given, write binary ids into profiles.
+ * If an error happens while writing, return -1.
+ */
+int WriteBinaryIds(ProfDataWriter *Writer, const ElfW(Nhdr) * Note,
+                   const ElfW(Nhdr) * NotesEnd) {
+  int TotalBinaryIdsSize = 0;
+  while (Note < NotesEnd) {
+    int Result = WriteBinaryIdForNote(Writer, Note);
+    if (Result == -1)
+      return -1;
+    TotalBinaryIdsSize += Result;
+
+    /* Calculate the offset of the next note in notes section. */
+    size_t NoteOffset = sizeof(ElfW(Nhdr)) + RoundUp(Note->n_namesz, 4) +
+                        RoundUp(Note->n_descsz, 4);
+    Note = (const ElfW(Nhdr) *)((const char *)(Note) + NoteOffset);
+  }
+
+  return TotalBinaryIdsSize;
+}
+
+/*
+ * Write binary ids into profiles if writer is given.
+ * Return the total size of binary ids.
+ * If an error happens while writing, return -1.
+ */
+COMPILER_RT_VISIBILITY COMPILER_RT_WEAK int
+__llvm_write_binary_ids(ProfDataWriter *Writer) {
+  extern const ElfW(Ehdr) __ehdr_start __attribute__((visibility("hidden")));
+  const ElfW(Ehdr) *ElfHeader = &__ehdr_start;
+  const ElfW(Phdr) *ProgramHeader =
+      (const ElfW(Phdr) *)((uintptr_t)ElfHeader + ElfHeader->e_phoff);
+
+  uint32_t I;
+  /* Iterate through entries in the program header. */
+  for (I = 0; I < ElfHeader->e_phnum; I++) {
+    /* Look for the notes section in program header entries. */
+    if (ProgramHeader[I].p_type != PT_NOTE)
+      continue;
+
+    const ElfW(Nhdr) *Note =
+        (const ElfW(Nhdr) *)((uintptr_t)ElfHeader + ProgramHeader[I].p_offset);
+    const ElfW(Nhdr) *NotesEnd =
+        (const ElfW(Nhdr) *)((const char *)(Note) + ProgramHeader[I].p_filesz);
+    return WriteBinaryIds(Writer, Note, NotesEnd);
+  }
+
+  return 0;
+}
+
 #endif

compiler-rt/lib/profile/InstrProfilingWriter.c

 static uint8_t BufferIOBuffer[VP_BUFFER_SIZE];
 static InstrProfValueData VPDataArray[16];
 static uint32_t VPDataArraySize = sizeof(VPDataArray) / sizeof(*VPDataArray);
 
 COMPILER_RT_VISIBILITY uint8_t *DynamicBufferIOBuffer = 0;
 COMPILER_RT_VISIBILITY uint32_t VPBufferSize = 0;
 
 /* The buffer writer is reponsponsible in keeping writer state
  * across the call.
  */
 COMPILER_RT_VISIBILITY uint32_t lprofBufferWriter(ProfDataWriter *This,
                                                   ProfDataIOVec *IOVecs,
                                                   uint32_t NumIOVecs) {
   uint32_t I;
   char **Buffer = (char **)&This->WriterCtx;
   for (I = 0; I < NumIOVecs; I++) {
     size_t Length = IOVecs[I].ElmSize * IOVecs[I].NumElm;

 
 COMPILER_RT_VISIBILITY int
 lprofWriteDataImpl(ProfDataWriter *Writer, const __llvm_profile_data *DataBegin,
                    const __llvm_profile_data *DataEnd,
                    const uint64_t *CountersBegin, const uint64_t *CountersEnd,
                    VPDataReaderType *VPDataReader, const char *NamesBegin,
                    const char *NamesEnd, int SkipNameDataWrite) {
 
   /* Calculate size of sections. */
   const uint64_t DataSize = __llvm_profile_get_data_size(DataBegin, DataEnd);
   const uint64_t CountersSize = CountersEnd - CountersBegin;
   const uint64_t NamesSize = NamesEnd - NamesBegin;
 
   /* Create the header. */
   __llvm_profile_header Header;
 
   if (!DataSize)
     return 0;
 
   /* Determine how much padding is needed before/after the counters and after
    * the names. */
   uint64_t PaddingBytesBeforeCounters, PaddingBytesAfterCounters,
       PaddingBytesAfterNames;
   __llvm_profile_get_padding_sizes_for_counters(
       DataSize, CountersSize, NamesSize, &PaddingBytesBeforeCounters,
       &PaddingBytesAfterCounters, &PaddingBytesAfterNames);
 
 /* Initialize header structure.  */
 #define INSTR_PROF_RAW_HEADER(Type, Name, Init) Header.Name = Init;
 #include "profile/InstrProfData.inc"
 
-  /* Write the data. */
-  ProfDataIOVec IOVec[] = {
-      {&Header, sizeof(__llvm_profile_header), 1, 0},
+  /* Write the profile header. */
+  ProfDataIOVec IOVec[] = {{&Header, sizeof(__llvm_profile_header), 1, 0}};
+  if (Writer->Write(Writer, IOVec, sizeof(IOVec) / sizeof(*IOVec)))
+    return -1;
+
+  /* Write the binary id lengths and data. */
+  if (__llvm_write_binary_ids(Writer) == -1)
+    return -1;
+
+  /* Write the profile data. */
+  ProfDataIOVec IOVecData[] = {
       {DataBegin, sizeof(__llvm_profile_data), DataSize, 0},
       {NULL, sizeof(uint8_t), PaddingBytesBeforeCounters, 1},
       {CountersBegin, sizeof(uint64_t), CountersSize, 0},
       {NULL, sizeof(uint8_t), PaddingBytesAfterCounters, 1},
       {SkipNameDataWrite ? NULL : NamesBegin, sizeof(uint8_t), NamesSize, 0},
       {NULL, sizeof(uint8_t), PaddingBytesAfterNames, 1}};
-  if (Writer->Write(Writer, IOVec, sizeof(IOVec) / sizeof(*IOVec)))
+  if (Writer->Write(Writer, IOVecData, sizeof(IOVecData) / sizeof(*IOVecData)))
     return -1;
 
   /* Value profiling is not yet supported in continuous mode. */
   if (__llvm_profile_is_continuous_mode_enabled())
     return 0;
 
   return writeValueProfData(Writer, VPDataReader, DataBegin, DataEnd);
 }

compiler-rt/test/profile/Linux/corrupted-profile.c

if (stat(argv[1], &st))
       bail("stat");
     uint64_t FileSize = st.st_size;
 
     char* Buf = (char *) mmap(NULL, FileSize, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
     if (Buf == MAP_FAILED)
       bail("mmap");
 
     // We're trying to make the first CounterPtr invalid.
-    // 10 64-bit words as header.
+    // 11 64-bit words as header.
     // CounterPtr is the third 64-bit word field.
-    memset(&Buf[10 * 8 + 2 * 8], 0xAB, 8);
+    memset(&Buf[11 * 8 + 2 * 8], 0xAB, 8);
 
     if (munmap(Buf, FileSize))
       bail("munmap");
 
     if (close(fd))
       bail("close");
   } else {
     FILE* f = fopen(argv[1], "r+b");
     if (!f)
       bail("fopen");
     __llvm_profile_set_file_object(f, 1);
   }
 }

compiler-rt/test/profile/binary-id.c

+// RUN: %clang_profgen -Wl,--build-id=none -O2 -o %t %s
+// RUN: env LLVM_PROFILE_FILE=%t.profraw %run %t
+// RUN: llvm-profdata show --binary-ids  %t.profraw > %t.out
+// RUN: FileCheck %s --check-prefix=NO-BINARY-ID < %t.out
+// RUN: llvm-profdata merge -o %t.profdata %t.profraw
+
+// RUN: %clang_profgen -Wl,--build-id -O2 -o %t %s
+// RUN: env LLVM_PROFILE_FILE=%t.profraw %run %t
+// RUN: llvm-profdata show --binary-ids  %t.profraw > %t.profraw.out
+// RUN: FileCheck %s --check-prefix=BINARY-ID-RAW-PROF < %t.profraw.out
+
+void foo() {
+}
+
+void bar() {
+}
+
+int main() {
+  foo();
+  bar();
+  return 0;
+}
+
+// NO-BINARY-ID: Instrumentation level: Front-end
+// NO-BINARY-ID-NEXT: Total functions: 3
+// NO-BINARY-ID-NEXT: Maximum function count: 1
+// NO-BINARY-ID-NEXT: Maximum internal block count: 0
+// NO-BINARY-ID-NOT: Binary IDs:
+
+// BINARY-ID-RAW-PROF: Instrumentation level: Front-end
+// BINARY-ID-RAW-PROF-NEXT: Total functions: 3
+// BINARY-ID-RAW-PROF-NEXT: Maximum function count: 1
+// BINARY-ID-RAW-PROF-NEXT: Maximum internal block count: 0
+// BINARY-ID-RAW-PROF-NEXT: Binary IDs:
+// BINARY-ID-RAW-PROF-NEXT: {{[0-9a-f]+}}

llvm/include/llvm/ProfileData/InstrProf.h

 // Version 2: Added value profile data section. Per-function control data
 // struct has more fields to describe value profile information.
 // Version 3: Compressed name section support. Function PGO name reference
 // from control data struct is changed from raw pointer to Name's MD5 value.
 // Version 4: ValueDataBegin and ValueDataSizes fields are removed from the
 // raw header.
 // Version 5: Bit 60 of FuncHash is reserved for the flag for the context
 // sensitive records.
+// Version 6: Added binary id.
 const uint64_t Version = INSTR_PROF_RAW_VERSION;
 
 template <class IntPtrT> inline uint64_t getMagic();
 template <> inline uint64_t getMagic<uint64_t>() {
   return INSTR_PROF_RAW_MAGIC_64;
 }
 
 template <> inline uint64_t getMagic<uint32_t>() {

llvm/include/llvm/ProfileData/InstrProfData.inc

 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, NamesDelta, (uintptr_t)NamesBegin)
 INSTR_PROF_RAW_HEADER(uint64_t, ValueKindLast, IPVK_Last)
+INSTR_PROF_RAW_HEADER(uint64_t, BinaryIdsSize, __llvm_write_binary_ids(NULL))
 #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.
  */
 #ifndef VALUE_PROF_FUNC_PARAM

 #define INSTR_PROF_RAW_MAGIC_64 (uint64_t)255 << 56 | (uint64_t)'l' << 48 | \
        (uint64_t)'p' << 40 | (uint64_t)'r' << 32 | (uint64_t)'o' << 24 |  \
         (uint64_t)'f' << 16 | (uint64_t)'r' << 8 | (uint64_t)129
 #define INSTR_PROF_RAW_MAGIC_32 (uint64_t)255 << 56 | (uint64_t)'l' << 48 | \
        (uint64_t)'p' << 40 | (uint64_t)'r' << 32 | (uint64_t)'o' << 24 |  \
         (uint64_t)'f' << 16 | (uint64_t)'R' << 8 | (uint64_t)129
 
 /* Raw profile format version (start from 1). */
-#define INSTR_PROF_RAW_VERSION 5
+#define INSTR_PROF_RAW_VERSION 6
 /* Indexed profile format version (start from 1). */
 #define INSTR_PROF_INDEX_VERSION 7
 /* Coverage mapping format version (start from 0). */
 #define INSTR_PROF_COVMAP_VERSION 5
 
 /* Profile version is always of type uint64_t. Reserve the upper 8 bits in the
  * version for other variants of profile. We set the lowest bit of the upper 8
  * bits (i.e. bit 56) to 1 to indicate if this is an IR-level instrumentaiton

llvm/include/llvm/ProfileData/InstrProfReader.h

public:
   virtual ~InstrProfReader() = default;
 
   /// Read the header.  Required before reading first record.
   virtual Error readHeader() = 0;
 
   /// Read a single record.
   virtual Error readNextRecord(NamedInstrProfRecord &Record) = 0;
 
+  /// Print binary ids on stream OS.
+  virtual Error printBinaryIds(raw_ostream &OS) { return success(); };
+
   /// Iterator over profile data.
   InstrProfIterator begin() { return InstrProfIterator(this); }
   InstrProfIterator end() { return InstrProfIterator(); }
 
   virtual bool isIRLevelProfile() const = 0;
 
   virtual bool hasCSIRLevelProfile() const = 0;
 
   virtual bool instrEntryBBEnabled() const = 0;
 
   /// Return the PGO symtab. There are three different readers:
   /// Raw, Text, and Indexed profile readers. The first two types
private:
   const char *NamesStart;
   uint64_t NamesSize;
   // After value profile is all read, this pointer points to
   // the header of next profile data (if exists)
   const uint8_t *ValueDataStart;
   uint32_t ValueKindLast;
   uint32_t CurValueDataSize;
 
+  uint64_t BinaryIdsSize;
+  const uint8_t *BinaryIdsStart;
+
 public:
   RawInstrProfReader(std::unique_ptr<MemoryBuffer> DataBuffer)
       : DataBuffer(std::move(DataBuffer)) {}
   RawInstrProfReader(const RawInstrProfReader &) = delete;
   RawInstrProfReader &operator=(const RawInstrProfReader &) = delete;
 
   static bool hasFormat(const MemoryBuffer &DataBuffer);
   Error readHeader() override;
   Error readNextRecord(NamedInstrProfRecord &Record) override;
+  Error printBinaryIds(raw_ostream &OS) override;
 
   bool isIRLevelProfile() const override {
     return (Version & VARIANT_MASK_IR_PROF) != 0;
   }
 
   bool hasCSIRLevelProfile() const override {
     return (Version & VARIANT_MASK_CSIR_PROF) != 0;
   }
private:
   // end of the summary data if it exists or the input \c Cur.
   // \c UseCS indicates whether to use the context-sensitive profile summary.
   const unsigned char *readSummary(IndexedInstrProf::ProfVersion Version,
                                    const unsigned char *Cur, bool UseCS);
 
 public:
   IndexedInstrProfReader(
       std::unique_ptr<MemoryBuffer> DataBuffer,
       std::unique_ptr<MemoryBuffer> RemappingBuffer = nullptr)
       : DataBuffer(std::move(DataBuffer)),
         RemappingBuffer(std::move(RemappingBuffer)), RecordIndex(0) {}
   IndexedInstrProfReader(const IndexedInstrProfReader &) = delete;
   IndexedInstrProfReader &operator=(const IndexedInstrProfReader &) = delete;
 
   /// Return the profile version.
   uint64_t getVersion() const { return Index->getVersion(); }
   bool isIRLevelProfile() const override { return Index->isIRLevelProfile(); }

llvm/lib/ProfileData/InstrProfReader.cpp

 #include "llvm/ADT/StringRef.h"
 #include "llvm/IR/ProfileSummary.h"
 #include "llvm/ProfileData/InstrProf.h"
 #include "llvm/ProfileData/ProfileCommon.h"
 #include "llvm/Support/Endian.h"
 #include "llvm/Support/Error.h"
 #include "llvm/Support/ErrorOr.h"
 #include "llvm/Support/MemoryBuffer.h"
-#include "llvm/Support/SymbolRemappingReader.h"
 #include "llvm/Support/SwapByteOrder.h"
+#include "llvm/Support/SymbolRemappingReader.h"
 #include <algorithm>
 #include <cctype>
 #include <cstddef>
 #include <cstdint>
 #include <limits>
 #include <memory>
 #include <system_error>
 #include <utility>
Error RawInstrProfReader<IntPtrT>::readHeader(
   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);
   NamesSize = swap(Header.NamesSize);
   ValueKindLast = swap(Header.ValueKindLast);
+  BinaryIdsSize = swap(Header.BinaryIdsSize);
 
   auto DataSizeInBytes = DataSize * sizeof(RawInstrProf::ProfileData<IntPtrT>);
   auto PaddingSize = getNumPaddingBytes(NamesSize);
 
-  ptrdiff_t DataOffset = sizeof(RawInstrProf::Header);
+  // Profile data starts after profile header and binary ids if exist.
+  ptrdiff_t DataOffset = sizeof(RawInstrProf::Header) + BinaryIdsSize;
   ptrdiff_t CountersOffset =
       DataOffset + DataSizeInBytes + PaddingBytesBeforeCounters;
   ptrdiff_t NamesOffset = CountersOffset + (sizeof(uint64_t) * CountersSize) +
                           PaddingBytesAfterCounters;
   ptrdiff_t ValueDataOffset = NamesOffset + NamesSize + PaddingSize;
 
   auto *Start = reinterpret_cast<const char *>(&Header);
   if (Start + ValueDataOffset > DataBuffer->getBufferEnd())
     return error(instrprof_error::bad_header);
 
   Data = reinterpret_cast<const RawInstrProf::ProfileData<IntPtrT> *>(
       Start + DataOffset);
   DataEnd = Data + DataSize;
+
+  // Binary ids start just after the header.
+  BinaryIdsStart =
+      reinterpret_cast<const uint8_t *>(&Header) + sizeof(RawInstrProf::Header);
   CountersStart = reinterpret_cast<const uint64_t *>(Start + CountersOffset);
   NamesStart = Start + NamesOffset;
   ValueDataStart = reinterpret_cast<const uint8_t *>(Start + ValueDataOffset);
 
   std::unique_ptr<InstrProfSymtab> NewSymtab = std::make_unique<InstrProfSymtab>();
   if (Error E = createSymtab(*NewSymtab.get()))
     return E;
 
Error RawInstrProfReader<IntPtrT>::readNextRecord(NamedInstrProfRecord &Record) {
   if (Error E = readValueProfilingData(Record))
     return error(std::move(E));
 
   // Iterate.
   advanceData();
   return success();
 }
 
+template <class IntPtrT>
+Error RawInstrProfReader<IntPtrT>::printBinaryIds(raw_ostream &OS) {
+  if (BinaryIdsSize == 0)
+    return success();
+
+  OS << "Binary IDs: \n";
+  const uint8_t *BI = BinaryIdsStart;
+  while (BI < BinaryIdsStart + BinaryIdsSize) {
+    uint64_t BinaryIdLen = swap(*reinterpret_cast<const uint64_t *>(BI));
+    // Increment by binary id length data type size.
+    BI += sizeof(BinaryIdLen);
+    if (BI > (const uint8_t *)DataBuffer->getBufferEnd())
+      return make_error<InstrProfError>(instrprof_error::malformed);
+
+    for (uint64_t I = 0; I < BinaryIdLen; I++)
+      OS << format("%02x", BI[I]);
+    OS << "\n";
+
+    // Increment by binary id data length.
+    BI += BinaryIdLen;
+    if (BI > (const uint8_t *)DataBuffer->getBufferEnd())
+      return make_error<InstrProfError>(instrprof_error::malformed);
+  }
+
+  return success();
+}
+
 namespace llvm {
 
 template class RawInstrProfReader<uint32_t>;
 template class RawInstrProfReader<uint64_t>;
 
 } // end namespace llvm
 
 InstrProfLookupTrait::hash_value_type

llvm/test/tools/llvm-profdata/c-general.test

 You need a checkout of clang with compiler-rt to generate the
 binary file here.  These shell commands can be used to regenerate
 it.
 $ SRC=path/to/llvm
 $ CFE=$SRC/tools/clang
 $ TESTDIR=$SRC/test/tools/llvm-profdata
 $ CFE_TESTDIR=$CFE/test/Profile
 $ clang -o a.out -fprofile-instr-generate $CFE_TESTDIR/c-general.c -mllvm -enable-name-compression=false
 $ LLVM_PROFILE_FILE=$TESTDIR/Inputs/c-general.profraw ./a.out
 
 RUN: llvm-profdata show %p/Inputs/c-general.profraw -o - | FileCheck %s
 RUN: llvm-profdata show %p/Inputs/c-general.profraw --topn=3 -o - | FileCheck %s --check-prefix=TOPN
 RUN: llvm-profdata show %p/Inputs/c-general.profraw -o - --function=switches | FileCheck %s -check-prefixes=SWITCHES,CHECK
 
 SWITCHES-LABEL: Counters:
 SWITCHES-NEXT:   switches:
-SWITCHES-NEXT:     Hash: 0xa50a07f391ae4be5
+SWITCHES-NEXT:     Hash: 0x0099a0c98383683e
 SWITCHES-NEXT:     Counters: 19
 SWITCHES-NEXT:     Function count: 1
 SWITCHES-LABEL: Functions shown: 1
 
 CHECK-LABEL: Total functions: 12
 CHECK-NEXT: Maximum function count: 1
 CHECK-NEXT: Maximum internal block count: 100
 TOPN: boolean_operators, max count = 100
 TOPN-NEXT: simple_loops, max count = 100
 TOPN-NEXT:  conditionals, max count = 100

llvm/test/tools/llvm-profdata/malformed-ptr-to-counter-array.test

 // Header
 //
 // 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, CountersSize, CountersSize)
 // INSTR_PROF_RAW_HEADER(uint64_t, NamesSize,  NamesSize)
 // INSTR_PROF_RAW_HEADER(uint64_t, CountersDelta, (uintptr_t)CountersBegin)
 // INSTR_PROF_RAW_HEADER(uint64_t, NamesDelta, (uintptr_t)NamesBegin)
 // INSTR_PROF_RAW_HEADER(uint64_t, ValueKindLast, IPVK_Last)
+// INSTR_PROF_RAW_HEADER(uint64_t, BinaryIdsSize, __llvm_write_binary_ids(NULL))
 
 RUN: printf '\201rforpl\377' > %t.profraw
-RUN: printf '\5\0\0\0\0\0\0\0' >> %t.profraw
+RUN: printf '\6\0\0\0\0\0\0\0' >> %t.profraw
 RUN: printf '\1\0\0\0\0\0\0\0' >> %t.profraw
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t.profraw
 RUN: printf '\2\0\0\0\0\0\0\0' >> %t.profraw
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t.profraw
 RUN: printf '\10\0\0\0\0\0\0\0' >> %t.profraw
 RUN: printf '\0\0\6\0\1\0\0\0' >> %t.profraw
 RUN: printf '\0\0\6\0\2\0\0\0' >> %t.profraw
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t.profraw
+RUN: printf '\0\0\0\0\0\0\0\0' >> %t.profraw
 
 // Data Section
 //
 // struct ProfData {
 // #define INSTR_PROF_DATA(Type, LLVMType, Name, Initializer) \
 //    Type Name;
 // #include "llvm/ProfileData/InstrProfData.inc"
 // };

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

 RUN: printf '\377lprofR\201' > %t
-RUN: printf '\0\0\0\0\0\0\0\5' >> %t
+RUN: printf '\0\0\0\0\0\0\0\6' >> %t
 RUN: printf '\0\0\0\0\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\3' >> %t
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t
 RUN: printf '\0\0\0\0\0\0\0\20' >> %t
 RUN: printf '\0\0\0\0\1\0\0\0' >> %t
 RUN: printf '\0\0\0\0\2\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 '\134\370\302\114\333\030\275\254' >> %t
 RUN: printf '\0\0\0\0\0\0\0\1' >> %t
 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

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

 RUN: printf '\201Rforpl\377' > %t
-RUN: printf '\5\0\0\0\0\0\0\0' >> %t
+RUN: printf '\6\0\0\0\0\0\0\0' >> %t
 RUN: printf '\2\0\0\0\0\0\0\0' >> %t
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t
 RUN: printf '\3\0\0\0\0\0\0\0' >> %t
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t
 RUN: printf '\20\0\0\0\0\0\0\0' >> %t
 RUN: printf '\0\0\0\1\0\0\0\0' >> %t
 RUN: printf '\0\0\0\2\0\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 '\254\275\030\333\114\302\370\134' >> %t
 RUN: printf '\1\0\0\0\0\0\0\0' >> %t
 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

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

 RUN: printf '\377lprofr\201' > %t
-RUN: printf '\0\0\0\0\0\0\0\5' >> %t
+RUN: printf '\0\0\0\0\0\0\0\6' >> %t
 RUN: printf '\0\0\0\0\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\3' >> %t
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t
 RUN: printf '\0\0\0\0\0\0\0\20' >> %t
 RUN: printf '\0\0\0\1\0\4\0\0' >> %t
 RUN: printf '\0\0\0\2\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 '\134\370\302\114\333\030\275\254' >> %t
 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
 

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

 RUN: printf '\201rforpl\377' > %t
-RUN: printf '\5\0\0\0\0\0\0\0' >> %t
+RUN: printf '\6\0\0\0\0\0\0\0' >> %t
 RUN: printf '\2\0\0\0\0\0\0\0' >> %t
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t
 RUN: printf '\3\0\0\0\0\0\0\0' >> %t
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t
 RUN: printf '\20\0\0\0\0\0\0\0' >> %t
 RUN: printf '\0\0\4\0\1\0\0\0' >> %t
 RUN: printf '\0\0\4\0\2\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 '\254\275\030\333\114\302\370\134' >> %t
 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
 

llvm/test/tools/llvm-profdata/raw-two-profiles.test

 RUN: printf '\201rforpl\377' > %t-foo.profraw
-RUN: printf '\5\0\0\0\0\0\0\0' >> %t-foo.profraw
+RUN: printf '\6\0\0\0\0\0\0\0' >> %t-foo.profraw
 RUN: printf '\1\0\0\0\0\0\0\0' >> %t-foo.profraw
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t-foo.profraw
 RUN: printf '\1\0\0\0\0\0\0\0' >> %t-foo.profraw
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t-foo.profraw
 RUN: printf '\10\0\0\0\0\0\0\0' >> %t-foo.profraw
 RUN: printf '\0\0\4\0\1\0\0\0' >> %t-foo.profraw
 RUN: printf '\0\0\4\0\2\0\0\0' >> %t-foo.profraw
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t-foo.profraw
+RUN: printf '\0\0\0\0\0\0\0\0' >> %t-foo.profraw
 
 RUN: printf '\254\275\030\333\114\302\370\134' >> %t-foo.profraw
 RUN: printf '\1\0\0\0\0\0\0\0' >> %t-foo.profraw
 RUN: printf '\0\0\4\0\1\0\0\0' >> %t-foo.profraw
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t-foo.profraw
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t-foo.profraw
 RUN: printf '\1\0\0\0\0\0\0\0' >> %t-foo.profraw
 
 RUN: printf '\023\0\0\0\0\0\0\0' >> %t-foo.profraw
 RUN: printf '\3\0foo\0\0\0' >> %t-foo.profraw
 
 RUN: printf '\201rforpl\377' > %t-bar.profraw
-RUN: printf '\5\0\0\0\0\0\0\0' >> %t-bar.profraw
+RUN: printf '\6\0\0\0\0\0\0\0' >> %t-bar.profraw
 RUN: printf '\1\0\0\0\0\0\0\0' >> %t-bar.profraw
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t-bar.profraw
 RUN: printf '\2\0\0\0\0\0\0\0' >> %t-bar.profraw
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t-bar.profraw
 RUN: printf '\10\0\0\0\0\0\0\0' >> %t-bar.profraw
 RUN: printf '\0\0\6\0\1\0\0\0' >> %t-bar.profraw
 RUN: printf '\0\0\6\0\2\0\0\0' >> %t-bar.profraw
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t-bar.profraw
+RUN: printf '\0\0\0\0\0\0\0\0' >> %t-bar.profraw
 
 RUN: printf '\067\265\035\031\112\165\023\344' >> %t-bar.profraw
 RUN: printf '\02\0\0\0\0\0\0\0' >> %t-bar.profraw
 RUN: printf '\0\0\6\0\1\0\0\0' >> %t-bar.profraw
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t-bar.profraw
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t-bar.profraw
 RUN: printf '\02\0\0\0\0\0\0\0' >> %t-bar.profraw
 

llvm/tools/llvm-profdata/llvm-profdata.cpp

 
 static int showInstrProfile(const std::string &Filename, bool ShowCounts,
                             uint32_t TopN, bool ShowIndirectCallTargets,
                             bool ShowMemOPSizes, bool ShowDetailedSummary,
                             std::vector<uint32_t> DetailedSummaryCutoffs,
                             bool ShowAllFunctions, bool ShowCS,
                             uint64_t ValueCutoff, bool OnlyListBelow,
                             const std::string &ShowFunction, bool TextFormat,
-                            raw_fd_ostream &OS) {
+                            bool ShowBinaryIds, raw_fd_ostream &OS) {
   auto ReaderOrErr = InstrProfReader::create(Filename);
   std::vector<uint32_t> Cutoffs = std::move(DetailedSummaryCutoffs);
   if (ShowDetailedSummary && Cutoffs.empty()) {
     Cutoffs = {800000, 900000, 950000, 990000, 999000, 999900, 999990};
   }
   InstrProfSummaryBuilder Builder(std::move(Cutoffs));
   if (Error E = ReaderOrErr.takeError())
     exitWithError(std::move(E), Filename);
if (ShownFunctions && ShowMemOPSizes) {
     showValueSitesStats(OS, IPVK_MemOPSize, VPStats[IPVK_MemOPSize]);
   }
 
   if (ShowDetailedSummary) {
     OS << "Total number of blocks: " << PS->getNumCounts() << "\n";
     OS << "Total count: " << PS->getTotalCount() << "\n";
     PS->printDetailedSummary(OS);
   }
+
+  if (ShowBinaryIds)
+    if (Error E = Reader->printBinaryIds(OS))
+      exitWithError(std::move(E), Filename);
+
   return 0;
 }
 
 static void showSectionInfo(sampleprof::SampleProfileReader *Reader,
                             raw_fd_ostream &OS) {
   if (!Reader->dumpSectionInfo(OS)) {
     WithColor::warning() << "-show-sec-info-only is only supported for "
                          << "sample profile in extbinary format and is "
static int show_main(int argc, const char *argv[]) {
   cl::opt<bool> ShowProfileSymbolList(
       "show-prof-sym-list", cl::init(false),
       cl::desc("Show profile symbol list if it exists in the profile. "));
   cl::opt<bool> ShowSectionInfoOnly(
       "show-sec-info-only", cl::init(false),
       cl::desc("Show the information of each section in the sample profile. "
                "The flag is only usable when the sample profile is in "
                "extbinary format"));
+  cl::opt<bool> ShowBinaryIds("binary-ids", cl::init(false),
+                              cl::desc("Show binary ids in the profile. "));
 
   cl::ParseCommandLineOptions(argc, argv, "LLVM profile data summary\n");
 
   if (Filename == OutputFilename) {
     errs() << sys::path::filename(argv[0])
            << ": Input file name cannot be the same as the output file name!\n";
     return 1;
   }
 
   std::error_code EC;
   raw_fd_ostream OS(OutputFilename.data(), EC, sys::fs::OF_TextWithCRLF);
   if (EC)
     exitWithErrorCode(EC, OutputFilename);
 
   if (ShowAllFunctions && !ShowFunction.empty())
     WithColor::warning() << "-function argument ignored: showing all functions\n";
 
   if (ProfileKind == instr)
-    return showInstrProfile(Filename, ShowCounts, TopNFunctions,
-                            ShowIndirectCallTargets, ShowMemOPSizes,
-                            ShowDetailedSummary, DetailedSummaryCutoffs,
-                            ShowAllFunctions, ShowCS, ValueCutoff,
-                            OnlyListBelow, ShowFunction, TextFormat, OS);
+    return showInstrProfile(
+        Filename, ShowCounts, TopNFunctions, ShowIndirectCallTargets,
+        ShowMemOPSizes, ShowDetailedSummary, DetailedSummaryCutoffs,
+        ShowAllFunctions, ShowCS, ValueCutoff, OnlyListBelow, ShowFunction,
+        TextFormat, ShowBinaryIds, OS);
   else
     return showSampleProfile(Filename, ShowCounts, ShowAllFunctions,
                              ShowDetailedSummary, ShowFunction,
                              ShowProfileSymbolList, ShowSectionInfoOnly,
                              ShowHotFuncList, OS);
 }
 
 int main(int argc, const char *argv[]) {