| Message ID | CAAe5K+VYfdqJW_35x+0+B-qd19aOrR4yg7uhbcCy=qW5ZQYLpQ@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
Ok. David On Mon, Mar 10, 2014 at 1:28 PM, Teresa Johnson <tejohnson@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 <tejohnson@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 | tejohnson@google.com | 408-460-2413
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);
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 <tejohnson@google.com> Google ref b/13338320. * libgcov-driver.c: Add dummy references to symbols accessed via weak references.