Bug 43825 - gcov is initialized wrong on x86_64
Summary: gcov is initialized wrong on x86_64
Status: RESOLVED DUPLICATE of bug 43341
Alias: None
Product: gcc
Classification: Unclassified
Component: gcov-profile (show other bugs)
Version: 4.5.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-20 23:42 UTC by Taras Glek
Modified: 2010-04-21 17:48 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Taras Glek 2010-04-20 23:42:28 UTC 
Building Mozilla with pgo results in a binary that can't even start to generate profiling data. Turns out that even CXX="g++ --coverage" and CC="gcc --coverage" resulting a binary that segfaults on start.

The crash looks like 
 #0  0x00007ffff40807c1 in strlen () from /lib/libc.so.6
#1  0x00007ffff6823a92 in __gcov_init () from /tmp/xulrunner/dist/bin/libxul.so
#2  0x00007ffff6824f56 in __do_global_ctors_aux () from
/tmp/xulrunner/dist/bin/libxul.so
#3  0x00007ffff51888ab in _init () from /tmp/xulrunner/dist/bin/libxul.so
#4  0x00007fffffffe908 in ?? ()
#5  0x00007ffff7dee429 in ?? () from /lib64/ld-linux-x86-64.so.2
#6  0x00007ffff7dee5af in ?? () from /lib64/ld-linux-x86-64.so.2
#7  0x00007ffff7de1b2a in ?? () from /lib64/ld-linux-x86-64.so.2
#8  0x0000000000000001 in ?? ()
#9  0x00007fffffffeb8c in ?? ()
#10 0x0000000000000000 in ?? ()

Looks like the info parameter passed to __gcov_init is buggered. This broken in gcc 4.4-trunk, didn't test on prior releases.
Comment 1 H.J. Lu 2010-04-21 00:04:33 UTC 
Do you have a small testcase?
Comment 2 Taras Glek 2010-04-21 00:05:36 UTC 
(In reply to comment #1)
> Do you have a small testcase?
> 

I wish. A minimal testcase works, but mozilla doesn't. Any suggestions on how to reduce this?
Comment 3 H.J. Lu 2010-04-21 00:14:05 UTC 
I have Fedora 12 and Fedora 13. Is there a way to reproduce it with only executable and leave libraries alone?
Comment 4 Taras Glek 2010-04-21 00:15:04 UTC 
(In reply to comment #3)
> I have Fedora 12 and Fedora 13. Is there a way to reproduce it with only
> executable and leave libraries alone?
> 

I'm not sure what you mean.
Comment 5 H.J. Lu 2010-04-21 00:17:21 UTC 
(In reply to comment #4)
> (In reply to comment #3)
> > I have Fedora 12 and Fedora 13. Is there a way to reproduce it with only
> > executable and leave libraries alone?
> > 
> 
> I'm not sure what you mean.
> 

Fedora comes with Firefox. If I recompile /usr/lib64/firefox-3.5/firefox
with --coverage, will I see the problem?
Comment 6 Taras Glek 2010-04-21 00:19:51 UTC 
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > I have Fedora 12 and Fedora 13. Is there a way to reproduce it with only
> > > executable and leave libraries alone?
> > > 
> > 
> > I'm not sure what you mean.
> > 
> 
> Fedora comes with Firefox. If I recompile /usr/lib64/firefox-3.5/firefox
> with --coverage, will I see the problem?
> 

I presume you'd recompile the whole firefox rpm. I think you should be able to reproduce the problem there.
Comment 7 Alexander Monakov 2010-04-21 16:45:12 UTC 

*** This bug has been marked as a duplicate of 43341 ***
Comment 8 Alexander Monakov 2010-04-21 16:48:28 UTC 
Taras, to avoid triggering the problem from firefox you can search for the file (as I remember there is only one in xulrunner) with #pragma pack(1) and does not reset it, and add #pragma pack() in the end of that file.
Comment 9 Taras Glek 2010-04-21 17:48:36 UTC 
(In reply to comment #8)
> Taras, to avoid triggering the problem from firefox you can search for the file
> (as I remember there is only one in xulrunner) with #pragma pack(1) and does
> not reset it, and add #pragma pack() in the end of that file.
> 

This wouldn't have even crossed my mind. Works great, thanks for debugging this.