[llvm-dev] Questions about support __llvm_profile_set_file_object on continuous mode

[Zequan Wu via llvm-dev]

Hi Vedant,

On Tue, Jul 27, 2021 at 10:42 PM Vedant Kumar <vsk at apple.com> wrote:

> Hi Zequan,
>
> On Jul 27, 2021, at 6:50 PM, Zequan Wu <zequanwu at google.com> wrote:
>
> Hi,
>
> When merging is disabled, a possible solution is to unmap the mapped file
> region, copy the old profile file to the new file, and then mmap the
> CounterBegin to the new file region. Does this sound correct?
>
>
> If the instrumented program is multithreaded, it might be possible for a
> thread to racily update a counter in the un-mmap'd region.
>
> I thought that the instrumented program can only update counters in the
mmapped regions which are setup during the initialization. How does it
access un-mmaped regions?

Do you think it's viable to sidestep the issue by restricting
> how/when __llvm_profile_set_file_object can be called, e.g. either by
> documenting or requiring that no other threads are active at the time of
> the call?
>
>  This looks viable.

> When merging is enabled, multiple profile files will be created. I'm not
> sure how to set the file object in this case as only one file descriptor is
> passed to __llvm_profile_set_file_object.
>
>
> Can you share how __llvm_profile_set_file_object(..., EnableMerge = true)
> works in non-continuous mode? It's not something I'm familiar with.
>
> By looking at existing tests, __llvm_profile_set_file_object(...,
EnableMerge = true) allows instrumented programs to accumulate profile
files from different runs. My guess is that when running two instrumented
programs, this function allows them to write to the same profile file in
appending mode, but I'm not sure how it handles the case when multiple
profile files are created during initialization for non-continuous mode.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210728/ebff21c4/attachment.html>