[Bug gcov-profile/51113] [4.7 regression] rev. 181105 causes Firefox profiledbuild failure

[nathan at acm dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51113

--- Comment #8 from Nathan Sidwell <nathan at acm dot org> 2011-11-15 20:12:33 UTC ---
On 11/15/11 10:03, markus at trippelsdorf dot de wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51113
>

> With your patch:
>   % c++ -shared -w -o /dev/null -fPIC -fno-rtti -pthread -pipe
> -fprofile-generate -O0 test.ii
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
> error: /tmp/cciGbsuB.o: requires dynamic R_X86_64_PC32 reloc against
> '__gcov0__ZnwmPv' which may overflow at runtime; recompile with -fPIC

Ok, I think I understand what's going on here.  Here's a piece of code to
explain:

inline int *Foo ()
{
   static int x = 2;

   return &x;
}

int *(*Bar ()) ()
{
   return Foo;
}

although Foo::x is in the same comdat group as Foo, it is separately
overridable 
at load time by another shared object.  (of course such overriding completely 
breaks language semantics, but not ELF semantics).  The linker's adhering to
ELF 
semantics, and in this example the compiler emits:
    movq    _ZZ3FoovE1x@GOTPCREL(%rip), %rax
to get Foo::x's address.  In the gcov case, it's emitting:
    movq    __gcov0_js_malloc(%rip), %rax
to access the first counter value.  Although I think that's ok in a well-formed 
program, it's confusing the linker.  that's unfortunate. (If you compile the 
above example with -fprofile-generate you'll see different access sequences for 
_ZZ3FoovE1x and __gcov0__Z3Foov.)

I'm going to have to figure out why the right PIC sequence isn't being emitted.