Ok. David
On Mon, Mar 10, 2014 at 1:28 PM, Teresa Johnson <tejohn...@google.com> wrote: > This patch adds dummy references to libgcov for the symbols accessed > via weak references from application code to ensure they are resolved > at link time. Passes regression tests. Ok for google-4_8? > > Thanks, > Teresa > > 2014-03-10 Teresa Johnson <tejohn...@google.com> > > Google ref b/13338320. > > * libgcov-driver.c: Add dummy references to symbols accessed > via weak references. > > Index: libgcov-driver.c > =================================================================== > --- libgcov-driver.c (revision 208402) > +++ libgcov-driver.c (working copy) > @@ -57,19 +57,28 @@ extern struct gcov_info *get_gcov_list (void) ATTR > /* Create a strong reference to these symbols so that they are > unconditionally pulled into the instrumented binary, even when > the only reference is a weak reference. This is necessary because > - we are using weak references to handle older compilers that > - pre-date these new functions. A subtlety of the linker is that > - it will only resolve weak references defined within archive libraries > - when there is a string reference to something else defined within > - the same object file. Since these two functions are defined within > - their own object files (using L_gcov_reset and L_gcov_dump), they > - would not get resolved. Since there are symbols within the main L_gcov > - section that are strongly referenced during -fprofile-generate builds, > - these symbols will always need to be resolved. */ > + we are using weak references to enable references from code that > + may not be linked with libgcov. These are the only symbols that > + should be accessed via link references from application code! > + > + A subtlety of the linker is that it will only resolve weak references > + defined within archive libraries when there is a strong reference to > + something else defined within the same object file. Since these functions > + are defined within their own object files, they would not automatically > + get resolved. Since there are symbols within the main L_gcov > + section that are strongly referenced during -fprofile-generate and > + -ftest-coverage builds, these dummy symbols will always need to be > + resolved. */ > void (*__gcov_dummy_ref1)(void) = &__gcov_reset; > void (*__gcov_dummy_ref2)(void) = &__gcov_dump; > extern char *__gcov_get_profile_prefix (void); > char *(*__gcov_dummy_ref3)(void) = &__gcov_get_profile_prefix; > +extern void __gcov_set_sampling_period (unsigned int period); > +char *(*__gcov_dummy_ref4)(void) = &__gcov_set_sampling_period; > +extern unsigned int __gcov_sampling_enabled (void); > +char *(*__gcov_dummy_ref5)(void) = &__gcov_sampling_enabled; > +extern void __gcov_flush (void); > +char *(*__gcov_dummy_ref6)(void) = &__gcov_flush; > > /* Default callback function for profile instrumentation callback. */ > extern void __coverage_callback (gcov_type, int); > > > -- > Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
