Bug 43341 - pragma pack changes padding in struct gcov_info on 64-bit archs
Summary: pragma pack changes padding in struct gcov_info on 64-bit archs
Status: UNCONFIRMED
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:
: 43825 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-03-12 09:14 UTC by Alexander Monakov
Modified: 2015-04-09 04:50 UTC (History)
4 users (show)

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


Attachments
proposed patch (1.69 KB, patch)
2010-04-21 16:43 UTC, Alexander Monakov
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Monakov 2010-03-12 09:14:52 UTC
cat <<EOF > t.c
int foo(){}
#pragma pack(1)
EOF

gcc -S -fprofile-generate t.c
grep '^\.LPBX' -A 2 t.s

.LPBX0:
	.long	875574314
	.quad	0

The padding ('.zero 4') between .long and .quad that correspond to the first two fields of struct gcov_info (an int and a ptr) is gone.  This makes building Firefox with profile feedback impossible on amd64.  At least gcc-4.[1345] behave this way.
Comment 1 Alexander Monakov 2010-04-21 16:43:38 UTC
Created attachment 20455 [details]
proposed patch
Comment 2 Alexander Monakov 2010-04-21 16:45:12 UTC
*** Bug 43825 has been marked as a duplicate of this bug. ***
Comment 3 Alexander Monakov 2010-04-21 16:54:05 UTC
(In reply to comment #1)
> Created an attachment (id=20455) [edit]
> proposed patch
> 

GCC generates gcov structures at runtime, and #pragma pack(1) in the source file affects their layout.  We probably can reset the alignment in create_coverage to avoid that.  The above patch implements a different approach -- it rearranges structure fields and manually sets alignment so that layout does not depend on current structure packing.
Comment 4 Arthur O'Dwyer 2011-04-26 19:54:28 UTC
For the record, I just noticed the same issue, using -fpack-struct instead of #pragma pack.  Whatever the fix ends up being, please make sure it also handles -fpack-struct.

cat >test.c <<EOF
int main() { return 0; }
EOF
gcc -fpack-struct=4 -fprofile-generate test.c
./a.out
Segmentation fault
Comment 5 Andrew Pinski 2011-04-26 20:04:39 UTC
(In reply to comment #4)
> gcc -fpack-struct=4 -fprofile-generate test.c

-fpack-struct changes the ABI so it is not fully a bug there.
Comment 6 Arthur O'Dwyer 2011-04-26 20:18:42 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > gcc -fpack-struct=4 -fprofile-generate test.c
> 
> -fpack-struct changes the ABI so it is not fully a bug there.

It's a gray area. -fprofile-generate is not documented as relying on "structs", as far as I could tell, so it's not intuitively obvious that it should have any interaction with -fpack-struct= at all. IMHO -fprofile-generate should always produce working code. At the very least, the interaction should be documented in the documentation for -fprofile-generate.

The same pitfalls also apply to -fprofile-arcs.
Comment 7 Andrew Pinski 2011-04-26 20:24:21 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > gcc -fpack-struct=4 -fprofile-generate test.c
> > 
> > -fpack-struct changes the ABI so it is not fully a bug there.
> 
> It's a gray area. -fprofile-generate is not documented as relying on "structs",
> as far as I could tell, so it's not intuitively obvious that it should have any
> interaction with -fpack-struct= at all. IMHO -fprofile-generate should always
> produce working code. At the very least, the interaction should be documented
> in the documentation for -fprofile-generate.

Maybe it does not says it relays on structs but it relays on the current ABI that is used.  This is just like saying the Fortran front-end does say it relays on structs but things go bad when you use that option.  I don't see why this should be documented when it is already documented that -fpack-struct changes the ABI.
Comment 8 Michal Misiaszek 2015-04-09 04:50:14 UTC
Hi,
I was strglign for last 2 night with my aplication which generated coverage files for all source files but one. At the end I found out that C++ file was including .h file. If I commented out .h file then coverage was generated.
Only unusual thing I noticed was #pragma pack(1).
When I removed it the coverage was generated again !
Short search I found this bug. I can reproduce it all the time.
The version of g++ and gcov below
:
michal@ubuntu:~/git/blpr$ g++ --version
g++ (Ubuntu 4.9.1-16ubuntu6) 4.9.1
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

michal@ubuntu:~/git/blpr$ gcov --version
gcov (Ubuntu 4.9.1-16ubuntu6) 4.9.1
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or 
FITNESS FOR A PARTICULAR PURPOSE.

Can you somehow patch it ?
Regards
Michal