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
