llvm dev - Dec 2019 - Avoiding function addresses in llvm_prf_data when value profiling is disabled

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191202/37daea6f/attachment.html>

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/dacea444/attachment.html>

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>