[llvm-dev] Avoiding function addresses in llvm_prf_data when value profiling is disabled
Reid Kleckner via llvm-dev
llvm-dev at lists.llvm.org
Mon Dec 2 14:52:48 PST 2019
Could we use !associated metadata and SHF_LINK_ORDER to make instr
profiling work with gc-sections, as has been done for ASan global metadata?
On Mon, Dec 2, 2019 at 2:35 PM Pirama Arumuga Nainar via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I encountered an issue when enabling code coverage for Android and would
> like to confirm my findings and ask for suggestions.
> Here is my finding:
> When -fprofile-instr-generate, an llvm_prf_data section gets created that
> has entries for each function in the TU. One of the entries is
> FunctionAddr which holds the address of the function. Underneath, it is a
> relocation so it gets patched with the runtime, in-memory address of the
> function. The whole llvm_prf_data section, or at least the FunctionAddr
> entry, is used only when value profiling is enabled.
> Value profiling is disabled by default and can be enabled with `-mllvm
> My problem is below:
> The FunctionAddr entries create references to all functions in the TU.
> This causes an issue with -ffunction-sections and -Wl,--gc-sections (which
> Android uses by default). The reference to functions causes the linker to
> retain all of these functions.
> This causes build errors when enabling code coverage for Android because
> the build rules are written assuming --gc-sections is passed to the linker
> and do not specify all necessary libraries to ensure proper linking of the
> discarded sections.
> I'm considering setting FunctionAddr to 0 if value profiling is disabled
> (or omitting llvm_prf_data altogether if it exists solely for value
> profiling). Does that sound reasonable?
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev