[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[jackie.rosen at hushmail dot com]

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

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #25 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[tschwinge at gcc dot gnu dot org]

------- Comment #24 from tschwinge at gcc dot gnu dot org  2010-03-31 15:49 -------
Regression report for arm-none-linux-gnueabi:
<http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01188.html>
Patch: <http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01505.html>


-- 

tschwinge at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tschwinge at gcc dot gnu dot
                   |                            |org


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[mikpe at it dot uu dot se]

------- Comment #23 from mikpe at it dot uu dot se  2009-10-21 10:48 -------
(In reply to comment #8)
> (In reply to comment #7)
> > With binutils from the 2.20 branch, and gcc from the 4.4 branch, including
> > Jakub's patch, and excluding the current workaround from Ramana, I get:
> > 
> 
> IIUC and to make things explicit, the work-around is needed for any binutils
> prior to the 2.20 branch until the backport is done. If the backport is
> committed we should pull out my work around as well. 

The backport has been committed now, so your PR41533 workaround should not be
needed any more.


-- 


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[jakub at gcc dot gnu dot org]

------- Comment #22 from jakub at gcc dot gnu dot org  2009-10-19 12:21 -------
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[jakub at gcc dot gnu dot org]

------- Comment #21 from jakub at gcc dot gnu dot org  2009-10-19 12:15 -------
Subject: Bug 40521

Author: jakub
Date: Mon Oct 19 12:15:27 2009
New Revision: 152974

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152974
Log:
        Backport from mainline:
        2009-10-16  Jakub Jelinek  <jakub@redhat.com>

        PR debug/40521
        * debug.h (struct gcc_debug_hooks): Add assembly_start hook.
        * cgraphunit.c (cgraph_optimize): Call it.
        * dwarf2out.c (dwarf2out_init): Move .cfi_sections printing into...
        (dwarf2out_assembly_start): ... here.  New hook.
        (dwarf2out_debug_hooks): Add dwarf2out_assembly_start.
        * debug.c (do_nothing_debug_hooks): Do nothing for assembly_start
        hook.
        * dbxout.c (dbx_debug_hooks, xcoff_debug_hooks): Likewise.
        * sdbout.c (sdb_debug_hooks): Likewise.
        * vmsdbgout.c (vmsdbg_debug_hooks): Add vmsdbgout_assembly_start.
        (vmsdbgout_assembly_start): New hook.

        2009-10-09  Jakub Jelinek  <jakub@redhat.com>

        PR debug/40521
        * dwarf2out.c (dwarf2out_init): Test whether
        HAVE_GAS_CFI_SECTIONS_DIRECTIVE is non-zero instead of checking
        it is defined.

        2009-10-02  Jakub Jelinek  <jakub@redhat.com>

        PR debug/40521
        * configure.ac (HAVE_GAS_CFI_SECTIONS_DIRECTIVE): New test.
        * configure: Regenerated.
        * config.in: Regenerated.
        * dwarf2out.c (dwarf2out_do_cfi_asm): Return false if
        !HAVE_GAS_CFI_SECTIONS_DIRECTIVE and not emitting .eh_frame.
        (dwarf2out_init): If HAVE_GAS_CFI_SECTIONS_DIRECTIVE and
        not emitting .eh_frame, emit .cfi_sections .debug_frame
        directive.

Modified:
    branches/gcc-4_4-branch/gcc/ChangeLog
    branches/gcc-4_4-branch/gcc/cgraphunit.c
    branches/gcc-4_4-branch/gcc/config.in
    branches/gcc-4_4-branch/gcc/configure
    branches/gcc-4_4-branch/gcc/configure.ac
    branches/gcc-4_4-branch/gcc/dbxout.c
    branches/gcc-4_4-branch/gcc/debug.c
    branches/gcc-4_4-branch/gcc/debug.h
    branches/gcc-4_4-branch/gcc/dwarf2out.c
    branches/gcc-4_4-branch/gcc/sdbout.c
    branches/gcc-4_4-branch/gcc/vmsdbgout.c


-- 


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[jakub at gcc dot gnu dot org]

------- Comment #20 from jakub at gcc dot gnu dot org  2009-10-17 07:28 -------
Subject: Bug 40521

Author: jakub
Date: Sat Oct 17 07:28:13 2009
New Revision: 152930

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152930
Log:
        PR debug/40521
        * debug.h (struct gcc_debug_hooks): Add assembly_start hook.
        * cgraphunit.c (cgraph_optimize): Call it.
        * dwarf2out.c (dwarf2out_init): Move .cfi_sections printing into...
        (dwarf2out_assembly_start): ... here.  New hook.
        (dwarf2out_debug_hooks): Add dwarf2out_assembly_start.
        * debug.c (do_nothing_debug_hooks): Do nothing for assembly_start
        hook.
        * dbxout.c (dbx_debug_hooks, xcoff_debug_hooks): Likewise.
        * sdbout.c (sdb_debug_hooks): Likewise.
        * vmsdbgout.c (vmsdbg_debug_hooks): Add vmsdbgout_assembly_start.
        (vmsdbgout_assembly_start): New hook.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cgraphunit.c
    trunk/gcc/dbxout.c
    trunk/gcc/debug.c
    trunk/gcc/debug.h
    trunk/gcc/dwarf2out.c
    trunk/gcc/sdbout.c
    trunk/gcc/vmsdbgout.c


-- 


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[ebotcazou at gcc dot gnu dot org]

------- Comment #19 from ebotcazou at gcc dot gnu dot org  2009-10-16 17:35 -------
> When testing this, I've noticed a major problem with Ada, supposedly on the
> trunk as well when using latest binutils.

Thanks for the heads up.

> The problem is that gnat_init_gcc_eh which can change flag_exceptions is
> called way too late, not from lang_hooks.init, but far after it.  This means
> by the time dwarf2out_init is called flag_exceptions might be still 0 and
> thus .cfi_sections .dwarf_frame is emitted.  But then gnat_init_gcc_eh
> changes flag_exception to 1 and excepts .eh_frame to be generated.

Can we arrange for making it safe to set flag_exceptions from lang_hooks.init
and then clear it in gnat_init_gcc_eh?


-- 


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[jakub at gcc dot gnu dot org]

------- Comment #18 from jakub at gcc dot gnu dot org  2009-10-16 14:55 -------
When testing this, I've noticed a major problem with Ada, supposedly on the
trunk as well when using latest binutils.

The problem is that gnat_init_gcc_eh which can change flag_exceptions is called
way too late, not from lang_hooks.init, but far after it.  This means by the
time dwarf2out_init is called flag_exceptions might be still 0 and thus
.cfi_sections .dwarf_frame is emitted.  But then gnat_init_gcc_eh changes
flag_exception to 1 and excepts .eh_frame to be generated.
The reason I've put .cfi_sections directive addition to dwarf2out.c is to allow
the user to override it within inline assembly, so I don't want to emit it at
the end of the file.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu dot
                   |                            |org


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[mikpe at it dot uu dot se]

------- Comment #17 from mikpe at it dot uu dot se  2009-10-13 12:52 -------
Patch with proposed backport to 4.4 posted here:
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00818.html


-- 


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.2                       |4.4.3


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[mikpe at it dot uu dot se]

------- Comment #16 from mikpe at it dot uu dot se  2009-10-12 12:33 -------
(In reply to comment #15)
> Is the target milestone 4.4.2 still true? In 4.4.2 20091008 the problem is
> still present.

I have a patch for 4.4 which bootstraps and passes regression testing on
i686-linux and powerpc64-linux. It also bootstraps on armv5tel-linux-gnueabi
(the platform for which I want this fix) with Ramana's workaround reverted, but
the test suite is not yet finished; it should be done around midnight today. I
plan to submit the patch tomorrow.


-- 


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[sebastian dot huber at embedded-brains dot de]

------- Comment #15 from sebastian dot huber at embedded-brains dot de  2009-10-12 11:36 -------
(In reply to comment #13)
> Thanks for clarifying the !eh_personality_libfunc requirement. I'll do some
> experiments to see which solution works best in 4.4.
> 

Is the target milestone 4.4.2 still true? In 4.4.2 20091008 the problem is
still present.


-- 


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[f dot frumento at ngi dot it]

------- Comment #14 from f dot frumento at ngi dot it  2009-10-11 22:52 -------
(In reply to comment #0)
> Put this in main.c and build it with a 4.4-branch compiler using recent
> binutils:
> 
> int main ()
> {
>   return 0;
> }
> 
> Versions:
> 
> GNU assembler (GNU Binutils) 2.19.51.20090611
> i686-pc-linux-gnu-gcc (GCC) 4.4.1 20090611 (prerelease)
> 
> % i686-pc-linux-gnu-gcc -c main.c; objdump --wide -h main.o | grep ALLOC
>   0 .text         0000000a  00000000  00000000  00000034  2**2  CONTENTS,
> ALLOC, LOAD, READONLY, CODE
>   1 .data         00000000  00000000  00000000  00000040  2**2  CONTENTS,
> ALLOC, LOAD, DATA
>   2 .bss          00000000  00000000  00000000  00000040  2**2  ALLOC
> 
> % i686-pc-linux-gnu-gcc -c -g main.c; objdump --wide -h main.o | grep ALLOC
>   0 .text         0000000a  00000000  00000000  00000034  2**2  CONTENTS,
> ALLOC, LOAD, READONLY, CODE
>   1 .data         00000000  00000000  00000000  00000040  2**2  CONTENTS,
> ALLOC, LOAD, DATA
>   2 .bss          00000000  00000000  00000000  00000040  2**2  ALLOC
>  12 .eh_frame     00000034  00000000  00000000  000001c0  2**2  CONTENTS,
> ALLOC, LOAD, RELOC, READONLY, DATA
> 
> We're using GAS's .cfi_startproc et cetera directives to generate debug
> information.  But they only generate .eh_frame, not .debug_frame.
> 
> I also noticed this problem on an ARM EABI target.  ARM EABI does not use
> .eh_frame, only .debug_frame and .ARM.exidx.
> 
> The easiest fix is to disable use of the CFI directives when we are trying to
> generate .debug_frame.  I believe GCC used to generate both .debug_frame and
> .eh_frame for the same function.  If we want both to gain the advantages of
> using CFI directives (e.g. potentially accurate across inline asm), then we
> need to teach gas to emit .debug_frame/.eh_frame/both as requested.
> 

Hi all,

I've noticed ther behaviour differs for some platform

I've tested a cross compiler Gcc 4.4.1 on Cygwin and on Mac OSX 1.6,I've built
it from vanilla sources (gcc.gnu.org), the final target is M68K/Coldfire

on mac no problem at all while on cygwin i've got a "no memory region
...omissis... for .eh_frame" error message, i've built the same files just
checked out from svn repository. While i've solved disabling debug options i
can't use this setup for long, I've also modified the linker script as follow:

MEMORY
{
        flash  : ORIGIN = 0x0000000, LENGTH = 0x100000
        dpram  : ORIGIN = 0x0FFFE000, LENGTH = 0x1000
}

SECTIONS {
        .text : {*(boot) *(text) *(eh_frame)} > flash
        .data : {} > dpram
        .bss : {} > dpram
        eh_frame :{} > flash
        /DISCARD/ : { *(eh_*)}
}

but it seems that on cygwin the /DISCARD/ special command doesn't work so my
binary files is larger than the mac generated one.

Any idea ?


-- 

f dot frumento at ngi dot it changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |f dot frumento at ngi dot it


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[mikpe at it dot uu dot se]

------- Comment #13 from mikpe at it dot uu dot se  2009-10-09 19:51 -------
Thanks for clarifying the !eh_personality_libfunc requirement. I'll do some
experiments to see which solution works best in 4.4.


-- 

mikpe at it dot uu dot se changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpe at it dot uu dot se


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[jakub at gcc dot gnu dot org]

------- Comment #12 from jakub at gcc dot gnu dot org  2009-10-09 19:17 -------
Ah, now I see it in the 4.4 version.  Your backport is wrong then, you must not
return true from dwarf2out_do_cfi_asm when !eh_personality_libfunc, but
HAVE_GAS_CFI_SECTIONS_DIRECTIVE is 0 and not emitting normal unwind info.

Either you want:
int
dwarf2out_do_cfi_asm (void)
{
  int enc;

#ifdef MIPS_DEBUGGING_INFO
  return false;
#endif
  if (!flag_dwarf2_cfi_asm || !dwarf2out_do_frame ())
    return false;
  if (saved_do_cfi_asm)
    return true;
  if (eh_personality_libfunc)
    {
      if (!HAVE_GAS_CFI_PERSONALITY_DIRECTIVE)
        return false;

      /* Make sure the personality encoding is one the assembler can support.
         In particular, aligned addresses can't be handled.  */
      enc = ASM_PREFERRED_EH_DATA_FORMAT (/*code=*/2,/*global=*/1);
      if ((enc & 0x70) != 0 && (enc & 0x70) != DW_EH_PE_pcrel)
        return false;
      enc = ASM_PREFERRED_EH_DATA_FORMAT (/*code=*/0,/*global=*/0);
      if ((enc & 0x70) != 0 && (enc & 0x70) != DW_EH_PE_pcrel)
        return false;
    }

  if (!HAVE_GAS_CFI_SECTIONS_DIRECTIVE)
    {
#ifdef TARGET_UNWIND_INFO
      return false;
#else
      if (USING_SJLJ_EXCEPTIONS || (!flag_unwind_tables && !flag_exceptions))
        return false;
#endif
    }

  saved_do_cfi_asm = true;
  return true;
}

or move the !HAVE_GAS_CFI_SECTIONS_DIRECTIVE tests in between if
(saved_do_cfi_asm) return true; and if (!eh_personality_libfunc) return true;.


-- 


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[jakub at gcc dot gnu dot org]

------- Comment #11 from jakub at gcc dot gnu dot org  2009-10-09 19:07 -------
Subject: Bug 40521

Author: jakub
Date: Fri Oct  9 19:07:23 2009
New Revision: 152598

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152598
Log:
        PR debug/40521
        * dwarf2out.c (dwarf2out_init): Test whether
        HAVE_GAS_CFI_SECTIONS_DIRECTIVE is non-zero instead of checking
        it is defined.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/dwarf2out.c


-- 


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[jakub at gcc dot gnu dot org]

------- Comment #10 from jakub at gcc dot gnu dot org  2009-10-09 18:54 -------
Yes, it is a bug and I'll change it, but I wonder why it makes a difference
(unless you're using PCH).  .cfi_sections is only emitted if:
  if (dwarf2out_do_cfi_asm ())
    {
#ifndef TARGET_UNWIND_INFO
      if (USING_SJLJ_EXCEPTIONS || (!flag_unwind_tables && !flag_exceptions))
#endif
        fprintf (asm_out_file, "\t.cfi_sections\t.debug_frame\n");
    }
#endif
but if !HAVE_CFI_SECTIONS_DIRECTIVE, dwarf2out_do_cfi_asm () has:
  if (!HAVE_GAS_CFI_SECTIONS_DIRECTIVE)
    {
#ifdef TARGET_UNWIND_INFO
      return false;
#else
      if (USING_SJLJ_EXCEPTIONS || (!flag_unwind_tables && !flag_exceptions))
        return false;
#endif
    }

i.e. will return false under the exact same condition that dwarf2_init would
allow it.  The only exception is when using PCH, you could create PCH with
saved_do_cfi_asm true and then load it.


-- 


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[mikpe at it dot uu dot se]

------- Comment #9 from mikpe at it dot uu dot se  2009-10-09 18:28 -------
I've been testing a backport of Jakub's patch to gcc-4.4, but it breaks
bootstrap on i686-linux with binutils-2.18.50.0.6 (Fedora 9) because stage1 gcc
outputs .cfi_sections directives even though the assembler doesn't support
them.
Current gcc-4.5 bootstraps Ok on the same machine.

The configure test correctly detects that cfi sections don't work with this as,
and records that with "#define HAVE_GAS_CFI_SECTIONS_DIRECTIVE 0".

In gcc-4.5 dwarf2out_do_cfi_asm() returns true. The code in dwarf2out_init()
inside #ifdef HAVE_GAS_CFI_SECTIONS_DIRECTIVE finds that USING_SJLJ_EXCEPTIONS
is false and !flag_exceptions is also false, so the call to emit a
.cfi_sections directive is not made. (!flag_unwind_tables varies, but it does
not matter since it's && with !flag_exceptions which always is false.)

In gcc-4.4 dwarf2out_do_cfi_asm() also returns true. The code in
dwarf2out_init() finds that USING_SJLJ_EXCEPTIONS is false but both
!flag_unwind_tables and !flag_exceptions are true, so a .cfi_sections directive
is emitted, causing the assembler to signal an error.

One thing that I find strange is that dwarf2out_do_cfi_asm() unconditionally
tests HAVE_GAS_CFI_SECTIONS_DIRECTIVE in an "if (!...)", which works since that
symbol is #defined as 0 or 1, while dwarf2out_init() instead has an #ifdef
HAVE_GAS_CFI_SECTIONS_DIRECTIVE around the conditional output of the directive.
Shouldn't that #ifdef be an #if?


-- 


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[ramana at gcc dot gnu dot org]

------- Comment #8 from ramana at gcc dot gnu dot org  2009-10-08 15:36 -------
(In reply to comment #7)
> With binutils from the 2.20 branch, and gcc from the 4.4 branch, including
> Jakub's patch, and excluding the current workaround from Ramana, I get:
> 

IIUC and to make things explicit, the work-around is needed for any binutils
prior to the 2.20 branch until the backport is done. If the backport is
committed we should pull out my work around as well. 


-- 


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[doko at ubuntu dot com]

------- Comment #7 from doko at ubuntu dot com  2009-10-08 15:17 -------
With binutils from the 2.20 branch, and gcc from the 4.4 branch, including
Jakub's patch, and excluding the current workaround from Ramana, I get:

$ gcc -c main.c 
$ objdump --wide -h main.o | grep ALLOC
  0 .text         0000001c  00000000  00000000  00000034  2**2  CONTENTS,
ALLOC, LOAD, READONLY, CODE
  1 .data         00000000  00000000  00000000  00000050  2**0  CONTENTS,
ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  00000050  2**0  ALLOC
$ gcc -c -g main.c 
$ objdump --wide -h main.o | grep ALLOC
  0 .text         0000001c  00000000  00000000  00000034  2**2  CONTENTS,
ALLOC, LOAD, READONLY, CODE
  1 .data         00000000  00000000  00000000  00000050  2**0  CONTENTS,
ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  00000050  2**0  ALLOC

OpenOffice rebuilt with these tools doesn't crash anymore. See PR ld/10695 and
http://qa.openoffice.org/issues/show_bug.cgi?id=105359


-- 


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[jakub at gcc dot gnu dot org]

------- Comment #6 from jakub at gcc dot gnu dot org  2009-10-02 18:52 -------
Subject: Bug 40521

Author: jakub
Date: Fri Oct  2 18:52:15 2009
New Revision: 152414

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152414
Log:
        PR debug/40521
        * configure.ac (HAVE_GAS_CFI_SECTIONS_DIRECTIVE): New test.
        * configure: Regenerated.
        * config.in: Regenerated.
        * dwarf2out.c (dwarf2out_do_cfi_asm): Return false if
        !HAVE_GAS_CFI_SECTIONS_DIRECTIVE and not emitting .eh_frame.
        (dwarf2out_init): If HAVE_GAS_CFI_SECTIONS_DIRECTIVE and
        not emitting .eh_frame, emit .cfi_sections .debug_frame
        directive.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config.in
    trunk/gcc/configure
    trunk/gcc/configure.ac
    trunk/gcc/dwarf2out.c


-- 


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[jakub at gcc dot gnu dot org]

------- Comment #5 from jakub at gcc dot gnu dot org  2009-10-01 15:44 -------
http://sources.redhat.com/ml/binutils/2009-10/msg00028.html


-- 


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[jsm28 at gcc dot gnu dot org]

-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.1                       |4.4.2


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[drow at gcc dot gnu dot org]

------- Comment #4 from drow at gcc dot gnu dot org  2009-06-23 12:24 -------
Subject: Re:  [4.4/4.5 Regression] -g causes GCC to
        generate .eh_frame

On Tue, Jun 23, 2009 at 11:09:48AM -0000, jakub at gcc dot gnu dot org wrote:
> I think if we don't want to emit .eh_frame, we should just default to
> -fno-dwarf2-cfi-asm.  But if we do want to generate it, I fail to see what do
> we gain by also generating .debug_frame.  Duplicating the same info, in one
> case in a more compat form, doesn't look like a good idea.

That sounds reasonable.  At one point there was a proposal to emit
completely accurate unwind information for .debug_frame, and skip some
prologue/epilogue information in .eh_frame; if we do that, obviously
we need both sets of output, but otherwise we don't.

We should make this be consistent though, not depend on
-fno-dwarf2-cfi-asm.


-- 


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[jakub at gcc dot gnu dot org]

------- Comment #3 from jakub at gcc dot gnu dot org  2009-06-23 11:09 -------
I think if we don't want to emit .eh_frame, we should just default to
-fno-dwarf2-cfi-asm.  But if we do want to generate it, I fail to see what do
we gain by also generating .debug_frame.  Duplicating the same info, in one
case in a more compat form, doesn't look like a good idea.

If we decide to teach gas to emit both .eh_frame and .debug_frame, or just
.eh_frame, or just .debug_frame from CFI directives (controlled using some
directive or option?), then one thing that needs solving is that gas will have
to hardcode a register mapping table for ppc*, because on ppc .eh_frame uses
a different register numbering from .debug_frame.


-- 


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.4.1


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[drow at gcc dot gnu dot org]

------- Comment #2 from drow at gcc dot gnu dot org  2009-06-22 15:22 -------
I've confirmed that older GCC emits both .debug_frame and .eh_frame.


-- 


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[drow at gcc dot gnu dot org]

------- Comment #1 from drow at gcc dot gnu dot org  2009-06-22 15:20 -------
CC'ing some people who know about CFI for opinions on the best resolution.  Do
we need a new gas option and/or CFI directive for this?


-- 

drow at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rth at gcc dot gnu dot org,
                   |                            |aoliva at gcc dot gnu dot
                   |                            |org, jakub at gcc dot gnu
                   |                            |dot org


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