[llvm-dev] Avoiding function addresses in llvm_prf_data when value profiling is disabled

[Xinliang David Li via llvm-dev]

That sounds like a good idea.  Or when VP is disabled, avoid recording the
function addresses.

David

On Mon, Dec 2, 2019 at 2:53 PM Reid Kleckner <rnk at google.com> wrote:

> 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
>> -enable-value-profiling`.
>>
>> 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.
>>
>> Question:
>>
>> 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?
>>
>> Thanks,
>> -Pirama
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191202/63a2b859/attachment.html>