Can anyone shed some light on the origins of the comments...
/* Mach-O doesn't support omitting the frame pointer for now. */
...in gcc/config/i386/i386.c. FSF gcc trunk has enabled the
omit-frame-pointer option as the default for both i386 and x86_64
recently.
* config.gcc: Handle --enable-frame-pointer.
* configure.ac: Add --enable-frame-pointer.
* configure: Regenerated.
* config/i386/i386.c (USE_IX86_FRAME_POINTER): Default to 0.
(override_options): Enable -fomit-frame-pointer for 32bit code
if compiling for TARGET_MACHO and not optimizing for size
unless configured with --enable-frame-pointer. Enable
-fasynchronous-unwind-tables unless configured with
--enable-frame-pointer. Enable -maccumulate-outgoing-args
by default unless configured with --enable-frame-pointer.
After testing on x86_64-appled-darwin10 and i386-apple-darwin10, I
had the same enabled on darwin releases which default to dwarf2
now in FSF gcc trunk using...
--- trunk/gcc/configure.ac 2010/08/13 15:50:40 163226
+++ trunk/gcc/configure.ac 2010/08/13 17:06:42 163227
@@ -1584,8 +1584,9 @@
[ --enable-frame-pointer enable -fno-omit-frame-pointer by default for 32bit x86], ,
[
case $target_os in
-linux*)
- # Enable -fomit-frame-pointer by default for Linux.
+linux* | darwin[[8912]]*)
+ # Enable -fomit-frame-pointer by default for Linux and Darwin with
+ # DWARF2.
enable_frame_pointer=no
;;
*)
--- trunk/gcc/config/i386/i386.c 2010/08/13 15:50:40 163226
+++ trunk/gcc/config/i386/i386.c 2010/08/13 17:06:42 163227
@@ -3276,9 +3276,8 @@
{
if (flag_zee == 2)
flag_zee = 1;
- /* Mach-O doesn't support omitting the frame pointer for now. */
if (flag_omit_frame_pointer == 2)
- flag_omit_frame_pointer = (TARGET_MACHO ? 0 : 1);
+ flag_omit_frame_pointer = 1;
if (flag_asynchronous_unwind_tables == 2)
flag_asynchronous_unwind_tables = 1;
if (flag_pcc_struct_return == 2)
@@ -3288,10 +3287,8 @@
{
if (flag_zee == 2)
flag_zee = 0;
- /* Mach-O doesn't support omitting the frame pointer for now. */
if (flag_omit_frame_pointer == 2)
- flag_omit_frame_pointer =
- (TARGET_MACHO ? 0 : !(USE_IX86_FRAME_POINTER || optimize_size));
+ flag_omit_frame_pointer = !(USE_IX86_FRAME_POINTER || optimize_size);
if (flag_asynchronous_unwind_tables == 2)
flag_asynchronous_unwind_tables = !USE_IX86_FRAME_POINTER;
if (flag_pcc_struct_return == 2)
Despite the absence of testsuite failures at -m32 or -m64 on either
i386-apple-darwin10 or x86_64-apple-darwin10, there are still some concerns
about the origins of the original Mach-O comment above. There also was
a concern that -fomit-frame-pointer would break Shark but my testing in
darwin10 suggests it still can profile code via the dwarf2. Thanks in
advance for any clarifications on the reasoning behind the original code.
Jack
Can anyone shed some light on the origins of the comments...
/* Mach-O doesn't support omitting the frame pointer for now. */
...in gcc/config/i386/i386.c. FSF gcc trunk has enabled the
omit-frame-pointer option as the default for both i386 and x86_64
recently.
* config.gcc: Handle --enable-frame-pointer.
* configure.ac: Add --enable-frame-pointer.
* configure: Regenerated.
* config/i386/i386.c (USE_IX86_FRAME_POINTER): Default to 0.
(override_options): Enable -fomit-frame-pointer for 32bit code
if compiling for TARGET_MACHO and not optimizing for size
unless configured with --enable-frame-pointer. Enable
-fasynchronous-unwind-tables unless configured with
--enable-frame-pointer. Enable -maccumulate-outgoing-args
by default unless configured with --enable-frame-pointer.
After testing on x86_64-appled-darwin10 and i386-apple-darwin10, I
had the same enabled on darwin releases which default to dwarf2
now in FSF gcc trunk using...
--- trunk/gcc/configure.ac 2010/08/13 15:50:40 163226
+++ trunk/gcc/configure.ac 2010/08/13 17:06:42 163227
@@ -1584,8 +1584,9 @@
[ --enable-frame-pointer enable -fno-omit-frame-pointer by default for 32bit x86], ,
[
case $target_os in
-linux*)
- # Enable -fomit-frame-pointer by default for Linux.
+linux* | darwin[[8912]]*)
+ # Enable -fomit-frame-pointer by default for Linux and Darwin with
+ # DWARF2.
enable_frame_pointer=no
;;
*)
--- trunk/gcc/config/i386/i386.c 2010/08/13 15:50:40 163226
+++ trunk/gcc/config/i386/i386.c 2010/08/13 17:06:42 163227
@@ -3276,9 +3276,8 @@
{
if (flag_zee == 2)
flag_zee = 1;
- /* Mach-O doesn't support omitting the frame pointer for now. */
if (flag_omit_frame_pointer == 2)
- flag_omit_frame_pointer = (TARGET_MACHO ? 0 : 1);
+ flag_omit_frame_pointer = 1;
if (flag_asynchronous_unwind_tables == 2)
flag_asynchronous_unwind_tables = 1;
if (flag_pcc_struct_return == 2)
@@ -3288,10 +3287,8 @@
{
if (flag_zee == 2)
flag_zee = 0;
- /* Mach-O doesn't support omitting the frame pointer for now. */
if (flag_omit_frame_pointer == 2)
- flag_omit_frame_pointer =
- (TARGET_MACHO ? 0 : !(USE_IX86_FRAME_POINTER || optimize_size));
+ flag_omit_frame_pointer = !(USE_IX86_FRAME_POINTER || optimize_size);
if (flag_asynchronous_unwind_tables == 2)
flag_asynchronous_unwind_tables = !USE_IX86_FRAME_POINTER;
if (flag_pcc_struct_return == 2)
Despite the absence of testsuite failures at -m32 or -m64 on either
i386-apple-darwin10 or x86_64-apple-darwin10, there are still some concerns
about the origins of the original Mach-O comment above. There also was
a concern that -fomit-frame-pointer would break Shark but my testing in
darwin10 suggests it still can profile code via the dwarf2. Thanks in
advance for any clarifications on the reasoning behind the original code.
Jack
I traced back these changes to Eric Chritopher's commit to FSF gcc 4.2 of...
* config.gcc (i?86-*-darwin): Add 64-bit HWI support.
* config/t-slibgcc-darwin: Support x86_64 multilib.
* config/i386/i386.h (JUMP_TABLES_IN_TEXT_SECTION):
Return 1 for x86_64-darwin.
* config/i386/t-darwin: Add m64 multilib.
(LIB2_SIDITI_CONV_FUNCS): Use.
(LIB2FUNCS_EXTRA): Ditto.
* config/i386/darwin.h: Support x86_64.
* config/i386/i386.c (override_options): Turn on flag_pic
for x86_64-darwin. Disable flag_omit_pointer.
(get_pc_thunk_name): Assert !TARGET_64BIT.
(legitimate_address_p): Disable machopic addressing for
x86_64.
(legitimize_pic_address): Ditto.
(ix86_expand_move): Ditto.
(ix86_expand_call): Ditto.
(machopic_output_stub): Ditto.
* config/darwin.c (machopic_select_section): Support literal16.
(machopic_select_rtx_section): Ditto.
* config/darwin-sections.def: Ditto.
* config/darwin-64.c: New.
* gcc.target/i386/20060512-3.c: Run test on ilp32 only.
* gcc.target/i386/memcpy-1.c: Ditto.
* gcc.target/i386/asm-1.c: Ditto.
* gcc.target/i386/20060512-4.c: Ditto.
* gcc.target/i386/compress-float-387.c: Ditto.
* gcc.target/i386/20060512-1.c: Ditto.
* gcc.target/i386/compress-float-sse.c: Ditto.
* gcc.target/i386/20060512-2.c: Ditto.
* gcc.target/i386/compress-float-sse-pic.c: Ditto.
* gcc.target/i386/stack-prot-kernel.c: Ditto.
* gcc.target/i386/compress-float-387-pic.c: Ditto.
* gcc.dg/pr26449.c: Ditto.
* gcc.dg/attr-ms_struct-2.c: Ditto.
* gcc.dg/attr-ms_struct-1.c: Ditto.
* gcc.misc-tests/linkage.exp: Fix 64-bit darwin support.
* configure.ac: Add 64-bit HWI support for i?86-darwin.
Perhaps he can comment further on the relevance of the...
* config/i386/i386.c (override_options): Turn on flag_pic
for x86_64-darwin. Disable flag_omit_pointer.
change now under dwarf2 in darwin8, darwin9 amd darwin10.
Jack
That's a long time ago 
At the time we needed to use the frame pointer instead of the eh frame information. If it works for you now I don't see any harm in turning it on.
-eric
Eric,
Thanks. Often Apple's patches came out of their own branch without a lot
of discussion in gcc-patches so I just wanted to double check that there wasn't any
obscure reason to avoid enabling omit-frame-pointer (aside from the degraded
profiling experience). We are already a tad bleeding edge anyway. On darwin10
we leveraged the linkers tolerance for omission of the eh labels to allow
-freorder-blocks-and-partition functional on darwin10 and later.
Jack
Thanks. Often Apple's patches came out of their own branch without a lot
of discussion in gcc-patches so I just wanted to double check that there wasn't any
obscure reason to avoid enabling omit-frame-pointer (aside from the degraded
profiling experience). We are already a tad bleeding edge anyway. On darwin10
we leveraged the linkers tolerance for omission of the eh labels to allow
-freorder-blocks-and-partition functional on darwin10 and later.
Probably degraded debugging as well btw.
-eric