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

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

[drow at gcc dot gnu dot org]

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.


-- 
           Summary: [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: debug
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: drow at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu


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

[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

[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

[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

[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]

-- 

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

[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]

------- 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

[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

[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

[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

[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

[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

[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 #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

[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

[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

[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

[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

[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 #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]

------- 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

[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 #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

[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 #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

[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

[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

[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.