Example:
$ cat a.c
void dso1(void);
int main(int argc, char** argv) {
if (argc > 1)
dso1();
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.so dso1.c && clang -fprofile-generate -mllvm -debug-info-correlate=true -mllvm -enable-value-profiling=false -g -o a.exe a.c $PWD/dso1.so
$ 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 dso1.so
counters for dso1.so
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 dso1.so
, 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?
@ellishg