Vedant Kumar via llvm-dev
2021-Sep-23 18:31 UTC
[llvm-dev] [cfe-dev] compiler-rt RFE to support creating profraw for each Shared Library
Hi Oza, 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> 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-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210923/7a869e60/attachment.html>
Vedant Kumar via llvm-dev
2021-Sep-23 18:32 UTC
[llvm-dev] [cfe-dev] compiler-rt RFE to support creating profraw for each Shared Library
> 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/llvm-dev/attachments/20210923/6f279af5/attachment-0001.html>
Oza, Hiral via llvm-dev
2021-Sep-28 07:08 UTC
[llvm-dev] [cfe-dev] compiler-rt RFE to support creating profraw for each Shared Library
Hello Vedant,> 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?There were problems when decoding merged profraw files. Couldn’t recall exactly error messages. But symbols in the profraws could not at all be matched to their definitions in the .so files. Also tried %m which worked, except that we had no way to know which .so file corresponded to which .profraw file when decoding them. Hence we added %n. Thank you. -Hiral From: Vedant Kumar <vsk at apple.com> Sent: Friday, 24 September, 2021 00:01 To: Oza, Hiral <Hiral.Oza at netapp.com> Cc: llvm-dev at lists.llvm.org; cfe-dev at lists.llvm.org Subject: Re: [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. Hi Oza, 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): %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 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210928/d994e2cc/attachment-0001.html>