Changed to using std::min

In D70200#1745743, @Dor1s wrote:

Ha, nice! LGTM. Is there any test you could easily update or add to reproduce this corner case?

• Added comment to clamp function.

Discovered this because we were getting negative numbers in some of our coverage data when we had counter overflows.

In D68351#1691969, @vsk wrote:

In D68351#1691934, @sajjadm wrote:

In D68351#1691915, @vsk wrote:

In D68351#1691883, @sajjadm wrote:

Not sure it belongs in this CL specifically, but would it be possible to later add a mode that defers the initialization of the mmap'd file until specifically requested by the process?

This sounds tricky to me, as the initialization requires some work to be done in each copy of the profile runtime linked into the process.

Could you clarify whether you're referring to processes which use the profiling runtime's static initializer, or not? My understanding is that for processes which do use the runtime's static initializer, it's always desirable to set up the mmap'd file in that initializer. If that's not true, I'd appreciate a counterexample. For processes that don't use the runtime's static initializer, the situation (at Apple, at least) is typically that it's a kernel extension or bare-metal piece of firmware, and the continuous mode isn't really applicable anyway.

We do use the static initializer, but in our use case the process doesn't necessarily know where to write coverage data until some other application-specific code has run.

I see, thanks for explaining.

Ideally, I would like to be able to have the instrumented process receive a shared memory buffer from another process, do continuous profile sync into that memory region, and not care whether it is file-backed or anonymous mapping. So it would be great if application code could give the runtime some sort of handle to that object [1] and tell the runtime to use that space for profiling.

I see. Is the lack of support for value profiling a concern, or would this just be for code coverage?

In D68351#1691915, @vsk wrote:

In D68351#1691883, @sajjadm wrote:

Not sure it belongs in this CL specifically, but would it be possible to later add a mode that defers the initialization of the mmap'd file until specifically requested by the process?

This sounds tricky to me, as the initialization requires some work to be done in each copy of the profile runtime linked into the process.

Could you clarify whether you're referring to processes which use the profiling runtime's static initializer, or not? My understanding is that for processes which do use the runtime's static initializer, it's always desirable to set up the mmap'd file in that initializer. If that's not true, I'd appreciate a counterexample. For processes that don't use the runtime's static initializer, the situation (at Apple, at least) is typically that it's a kernel extension or bare-metal piece of firmware, and the continuous mode isn't really applicable anyway.

Not sure it belongs in this CL specifically, but would it be possible to later add a mode that defers the initialization of the mmap'd file until specifically requested by the process?

Ran clang-format.

In D62541#1532508, @Dor1s wrote:

LGTM (was OOO), thanks a lot David for Sajjad for multiple iterations here. One question: was the test landed? I see it in the latest patchset (https://reviews.llvm.org/D62541?id=203034), but not in the code that was committed.

Thank you! I did apply for committer status today but I don't know how long it takes to get it.

Could you be more specific about your concerns? I'm happy to fix any problems in this change.

Could someone please commit for me?

Extracted lock/unlock code to util file, combined __llvm functions.

Ran clang-format.

Forgot to declare a variable.

Fixed lock/unlock code.

Added explicit merging API and test.

On further thought, I don't think having a boolean that tells the runtime "user code is controlling locking so it is safe to merge" is a good idea, because typically __llvm_profile_write_file is invoked at exit. User code would have to ensure that it locks the file at the very end of its execution, when it has collected the desired profiling data, but before __lvm_profile_write_file is invoked. Also, in the current implementation, whether or not merging happens is controlled by the pattern of the profiling file name (whether or not it has a %m in it).

@davidxl We could also have the openFileForMerging function invoke lprofLockFd on the user-provided file, rather than putting the onus for locking on the user. How would you feel about that?

Updated test.

Cleaned up logic and added safe-for-merge bool to API.

Added support for merging, docs, and test case.

I was debating whether I should pull -num-threads out of the docs for show and move it to the top-level options section, or make a copy of it in the export options section. I went with putting a copy of it in export because only show and export use it and the behavior is subtly different (show only uses it if -output-dir is set, export uses it unconditionally).

• Changed how -num-threads is documented.

• Added docs for new llvm-cov flags.

Thanks for all the feedback, Max and Vedant!

• Added tests for the -skip-* flags.
• Minor changes in response to code review.