Should we have two versions of `__gcov_flush`? One version is visible outside a .so file, we use dlsym to find and call it to dump profile data of .so files, like Android.
One version is hidden and must be called from another wrapper function in a .so file. An application that wants to flush .so file profile data will need to call those wrapper functions. On Wed, Apr 11, 2018 at 12:31 PM, Xinliang David Li <xinlian...@gmail.com> wrote: > > > On Wed, Apr 11, 2018 at 11:31 AM, Chih-Hung Hsieh via Phabricator via > llvm-commits <llvm-comm...@lists.llvm.org> wrote: > >> chh added a comment. >> >> Yes, calling `__gcov_flush` within .so files are different, >> but it's a revert of https://reviews.llvm.org/D38124. >> I think https://bugs.llvm.org/show_bug.cgi?id=27224 >> can be fixed by hiding only llvm_gcda_* functions, >> without any change to `__gcov_flush`. >> >> > The coverage dumping behavior for shared libraries (not dlopened) was also > wrong before D38124. D38124 fixed the crash as well as the dumping bug. > > David > > > > > >> (1) Before https://reviews.llvm.org/D38124: >> >> - Calling `__gcov_flush` within .so or main function dumps to main gcda >> file. >> - Android's dlsym() lookup/call of `__gcov_flush` dumps to .so file >> specific gcda files. >> >> (2) After https://reviews.llvm.org/D38124: >> >> - Android's dlsym() cannot find/call `__gcov_flush`. >> - Calling `__gcov_flush` from main works as in (1). >> - Calling `__gcov_flush` from .so works differently; it will dump to .so >> specific gcda file, not the main one. >> >> (3) With this change, we revert `__gcov_flush` behavior back to (1). >> >> Is there any application that needs to call `__gcov_flush` within .so >> and expects the output to .so specific gcda file like in (2)? >> I think the behavior of (1) is more desirable. >> If a main program wants to dump to .so specific gcda file, like Android, >> it can use dlsym() to look up .so specific `__gcov_flush`. >> >> >> https://reviews.llvm.org/D45454 >> >> >> >> _______________________________________________ >> llvm-commits mailing list >> llvm-comm...@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits >> > >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
