evilsong / gperftools

Automatically exported from code.google.com/p/gperftools
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

-fomit-frame-pointer is now the default for x86 Linux (32-bit) #480

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Install libunwind
2. Compile tcmalloc from source on Linux on a 32-bit x86 box, with GCC 4.6.0 or 
higher

What is the expected output? What do you see instead?

Expected result is that tcmalloc will include -DNO_FRAME_POINTER in its 
CXXFLAGS during compilation, and will use libunwind for obtaining stack traces. 
 Actual result is that the configure script detects the presence of libunwind, 
but -DNO_FRAME_POINTER is not set in the CXXFLAGS, and tcmalloc tries to use 
its internal implementation for obtaining stack traces (which doesn't work - 
fails heap checker unit tests).

What version of the product are you using? On what operating system?

tcmalloc 2.0, GCC 4.7.1, eglibc 2.13

Please provide any additional information below.

Various comments in configure.ac and Makefile.am hint that the build system 
assumes frame pointers are always enabled on i386, but this is no longer the 
case as of GCC 4.6.0.  See 
http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Optimize-Options.html

"Starting with GCC version 4.6, the default setting (when not optimizing for 
size) for 32-bit Linux x86 and 32-bit Darwin x86 targets has been changed to 
-fomit-frame-pointer. The default can be reverted to -fno-omit-frame-pointer by 
configuring GCC with the --enable-frame-pointer configure option. "

Original issue reported on code.google.com by philip.a...@smoothwall.net on 1 Nov 2012 at 10:43

GoogleCodeExporter commented 9 years ago
This is a duplicate of issue-385 which was fixed in r150.

    issue-385: updates to automake to pick up the explicit setting of the -fno-omit-frame-pointer for i386
    ------------------------------------------------------------------------
    r150 | chappedm@gmail.com | 2012-05-15 21:28:08 -0400 (Tue, 15 May 2012) | 1 line

In quickly reviewing that commit I did find some of the comments to be a bit 
awkward still so I have updated them as necessary. If you pull down the code 
from the current truck and build from that you should find that this issue is 
resolved.

-Dave

Original comment by chapp...@gmail.com on 3 Nov 2012 at 2:09

GoogleCodeExporter commented 9 years ago
r165 | chappedm@gmail.com | 2012-11-03 10:13:21 -0400 (Sat, 03 Nov 2012) | 3 
lines

issue-480: duplicate of issue-385 fixed in r150 however some of the comments in 
the code regarding frame pointers needed to be clarified.

Original comment by chapp...@gmail.com on 3 Nov 2012 at 2:25