We are trying to get PGO working for our embedded out-of-tree target, but the utility ‘llvm-profdata’ does not like the data we are giving it.
Because this is not a hosted environment, we have to off-chip the profiling data ourselves, and although the data looks okay, ‘llvm-profdata’ reports the following error:
llvm-profdata show -all-functions -counts -detailed-summary -text -static-func-full-module-prefix ~/Downloads/default.profraw
error: ~/Downloads/default.profraw: Failed to uncompress data (zlib)
But even for a hosted system, it is not clear to me where ‘zlib’ gets involved in compressing the data. The start of our data looks like:
Can we improve the error message here? We should be able to check
zlib::isAvailable and give an error like "profile uses zlib compression
but the profile reader was built without zlib support" or so in this
case.
Xinliang David Li via llvm-dev <llvm-dev@lists.llvm.org> writes:
How can I build the profile reader with ZLIB support enabled? I configure and build all the tools together with 'clang', so I would have expected that all or none support ZLIB, or is this a cross-compiler configuration specific issue?
Thanks. Yes, I build ‘clang’ and all the other tools and utilities together, so I am surprised that ‘clang’ would have ‘zlib’ enabled but not ‘llvm-profdata’. I will get back to this when I return on Monday, and I have a suspicion I may be doing something else wrong that I will formulate and ask next week.
When I use CMake to configure, ‘zlib’ and its header are detected - I build on CentOS 6.5 or CentOS 7. Since I run CMake from the command-line, I tried added ‘-DLLVM_ENABLE_ZLIB=0’ and ‘-DLLVM_ENABLE_ZLIB=1’ (using ‘-DLLVM_ENABLE_ZLIB=ON’ does not seem to work). Both ‘clang’ and ‘llvm-profdata’ (and all other tools and utilities) are configured and built together, in any event, they are both built with ‘zlib’ enabled or ‘zlib’ disabled.
On Windows with VS2015 there is no ‘zlib’.
But I think that there is something different causing the problem, possibly in the linking. When profiling instrumentation is enabled, there are 4 new sections introduced:
__llvm_prf_cnts
__llvm_prf_data
__llvm_prf_names
__llvm_prf_vnds
Since our target is an heterogeneous multi-core embedded system, it requires the use of some elaborate linking techniques, and the LD scripts are carefully crafted for this purpose. We use ‘ld’ from Binutils v2.28. However, I do not know what these new sections mean to ‘llvm-profdata’ or how they should be laid out. I cannot find any reference to these sections in any of the in-tree targets for Binutils or for LLVM-LLD, so there is no guidance or examples on how they should be collated and ordered, or how they should be placed in the memory-map.
What I did is added a very simple line to my existing LD script’s rule for collating ‘.data’ as:
SECTIONS
{
…
.data:
{
…
(_llvm_prf)
…
}
…
}
I’m guessing that this is too naïve and simplistic, and that something else is required, but I can’t find any sample LD scripts in either the LLD (v5.0) or Binutils (v2.28) sources. I was considering replacing the line:
(_llvm_prf)
with:
*(__llvm_prf_cnts)
*(__llvm_prf_data)
*(__llvm_prf_names)
*(__llvm_prf_vnds)
but without knowing what is required, this is still just a wild guess.
Any thoughts or recommendations on how these sections should be linked, and whether they need any special “PROVIDE” declarations? Or “SORT” clauses?
The order of those sections in memory does not matter. What needed is a way to tell the profile runtime where to find the start and end of the sections. On Linux, the linker defines symbols _start<section_name> and _stop<section_name>. If your linker does not do that, you can use linker script to provide the start and end:
Perfect, thanks David, this is exactly the kind of information I need.
Is this stated anywhere in the documentation? I have not been able to find such an explanation. I am also not getting unresolved symbols for ‘_start___llvm_prf<name>’ or ‘_stop___llvm_prf<name>’ - does the library use “weak” references to these? How does ‘llvm-profdata’ locate the ELF file for the program when it only has ‘default.profraw’ as input? on an embedded system with no file-system “paths” don’t make a lot of sense.
My guess is that the profile library is not really used much by embedded targets, nor indeed the other instrumentation libraries.
Thanks again for your help and I will define these symbols during linking and let you know how things pan out.
Perfect, thanks David, this is exactly the kind of information I need.
Is this stated anywhere in the documentation? I have not been able to
find such an explanation.
No, the implementation details like this is not documented. The best
source of information is the the source code in profiler runtime in
projects/compiler-rt/lib/profile directory.
The start/stop symbol mechanism is supported for Linux, FreeBSD and
Darwin. Other platforms rely runtime registration of section start and end
on a per module basis. This also requires the instrumentation pass to emit
the registration code.
I am also not getting unresolved symbols for ‘__start___llvm_prf_<*name*>’
or ‘__stop___llvm_prf_<*name*>’ - does the library use “weak” references
to these?
The references are from one platform specific file in profile runtime. If
that file is not linked in, the generic implementation (which relies on
runtime registration) will be linked in (InstrProfilingPlatformOther.c).
See CMakeLists.txt for details. In your case, what likely happens is that
the registration code is not emitted so the profiler runtime dumps empty
data.
How does ‘llvm-profdata’ locate the ELF file for the program when it only
has ‘default.profraw’ as input?
llvm-profdata does not need to locate ELF file. llvm-cov tool, on the
hand, requires it to locate the covmap section in the executable file.