[cfe-dev] [llvm-dev] compiler-rt RFE to support creating profraw for each Shared Library

[Vedant Kumar via cfe-dev]

> On Sep 23, 2021, at 11:31 AM, Vedant Kumar via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hi Oza,

Apologies, I meant to write Hiral here -- sorry for getting this wrong.

> 
> The mechanics of the patch are clear. What's not clear to me is why dso-specific .profraw files are helpful for code coverage, since merged .profraw's should work just as well.
> 
> Have you encountered issues using merged .profraws? Could you clarify what's meant by backtracking and instrumenting [the] final binary?
> 
> thanks,
> vedant
> 
>> On Sep 22, 2021, at 9:36 PM, Oza, Hiral <Hiral.Oza at netapp.com <mailto:Hiral.Oza at netapp.com>> wrote:
>> 
>> Hello Vedant,
>>  
>> > could you share some of the use cases for this feature? > What were the pros/cons of any alternatives you considered (e.g. the %m/%c modes)?
>>  
>> We are taking coverage of shared libraries (i.e. Linux .so) and dumping coverage into files corresponding to SO’s filename.
>> With this proposed patch, will get coverage as below for sample code (pls refer compiler-rt/test/profile/Linux/instrprof-shared-nProfraws.test):
>> libhi.so  -> will dump into libhi.so.profraw
>> libhello.so -> will dump into libhellp.so.profraw
>> main.out -> will dump into main.out.profraw
>>  
>> Regarding ‘%m or %c: (from https://clang.llvm.org/docs/SourceBasedCodeCoverage.html <https://clang.llvm.org/docs/SourceBasedCodeCoverage.html>): %m is expands instrumented binary’s signature (and with “%Nm” dumps into poll of N profraws) and %c seems very different from proposed “%n”.
>>  
>> Basically with proposed patch (i.e. using “%n”) one can get one-to-one mapping of Shared Library and generated .profraw.
>> This makes backtracking and instrumenting final-binary based on feedback easy.
>>  
>> Please let me know in case of further queries or any changes in proposed patch.
>>  
>> Thank you.
>> -Hiral
>>  
>> From: cfe-dev <cfe-dev-bounces at lists.llvm.org <mailto:cfe-dev-bounces at lists.llvm.org>> On Behalf Of Oza, Hiral via cfe-dev
>> Sent: Wednesday, 22 September, 2021 18:56
>> To: cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>; llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
>> Subject: [cfe-dev] compiler-rt RFE to support creating profraw for each Shared Library
>>  
>> NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>> 
>> 
>> 
>> Greetings!
>>  
>> Please review our patch compiler-rt RFE patch here -- https://reviews.llvm.org/D110232 <https://reviews.llvm.org/D110232>
>>  
>> This patch is about creating profraw for each Shared Library.
>>  
>> <patch_info>
>> SBCC RFE: Support SBCC for Shared Library
>>  
>> SBCC RFE: Support SBCC for Shared Library
>> Using '%n' format parameter for profile name templates, to insert the full
>> path of the current shared object into profile file names.
>>  
>> Internally using a linked list to gather all profile dumping functions
>> (there is one defined in each shared object) so they can be invoked with a
>> single function call.  Ensure the resulting directory paths are created
>> prior to dumping.
>> </patch_info>
>>  
>> Thank you in advance for your kind review.
>> -Hiral
> 
> _______________________________________________
> 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/cfe-dev/attachments/20210923/6f279af5/attachment.html>