Does debug info correlation works when a profile file contains multiple raw profiles?


$ cat a.c
void dso1(void);

int main(int argc, char** argv) {
  if (argc > 1)
  return 0;
$ cat dso1.c
void dso1(void) {}
$ clang -fprofile-generate -mllvm -debug-info-correlate=true -mllvm -enable-value-profiling=false -fpic -shared -g -o dso1.c && clang -fprofile-generate -mllvm -debug-info-correlate=true -mllvm -enable-value-profiling=false -g -o a.exe a.c $PWD/
$ env LLVM_PROFILE_FILE=default.proflite ./a.exe
$ llvm-profdata merge --debug-info=a.exe default.proflite -o profdata
warning: default.proflite: malformed instrumentation profile data: number of counters 2 is greater than the maximum number of counters 1
error: no profile can be merged

In this example, the default.proflite contains lightweight raw profiles for two binaries. So, it contains the following:

raw profile header for a.exe
counters for a.exe
raw profile header for
counters for

When llvm-profdata takes a.exe as debug info, it can only construct profile data and name for a.exe. It mistakenly used a.exe’s profile data when iterating to counters for, so this warning shows up.

Though default profile name for -debug-info-correlate is default_%m.proflite, running a.exe will give two separate profile files. How could the user know the correspondence between the profile file and debug info file when invoking llvm-profdata merge?

The thing comes to my mind is to use binary id to help llvm-profdata find the correct raw profiles for the given debug info file. I wonder, did Meta encounter this issue before?

I came across a raw profile with two headers once when I accidentally dumped a raw profile twice for the same binary. Other than that, we don’t use this feature of multiple headers in a profile. Instead, we manually dump profiles using __llvm_profile_set_filename() and __llvm_profile_write_file() [docs]. I believe this fixes this problem since each profile has a distinct name.

Thanks. That explains it.