Shared objects which should be PIC aren't

[Loïc Minier]

Binary package hint: gcc-4.4

Hi

Since it's built with gcc-4.4, eglibc isn't PIC anymore; just like almost all shared objects we built.

Debian noticed this issue when considering the gcc-4.4 switch:
http://lists.debian.org/debian-arm/2009/09/msg00062.html
and the eglibc testsuite has test check-textrel.out which fails since it's not PIC anymore.

The issue is in gcc-4.4 which generates the wrong type of ELF data for exception handling (eh_frame).

This prompts for a rebuild of a bunch of packages between beta and final with a fixed toolchain.

A workaround is to build things with -fno-dwarf2-cfi-asm. We should upload eglibc built with this ASAP.

We should also patch gcc-4.4 to default to setting this flag on ARM EABI:
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00071.html
See also PR40521 which is an issue in gas that prevents the proper fix in gcc.

We should include this patch in our gcc-4.4 ASAP and rebuild the toolchain against it.

[Drow-l (drow-l)]

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.

[Drow-l (drow-l)]

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-l (drow-l)]

I've confirmed that older GCC emits both .debug_frame and .eh_frame.

[Jakub-gcc (jakub-gcc)]

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.

[Drow-l (drow-l)]

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.

[Jakub-gcc (jakub-gcc)]

http://sources.redhat.com/ml/binutils/2009-10/msg00028.html

[Loïc Minier (lool)]

Matthias uploaded binutils, gcc-4.4, eglibc already; these are in unapproved.

He describes the plan as follows:
"""
 - the buildds are turned to manual, the archive is still frozen because
   beta is not yet released.
 - once the beta freeze over, we will hint the pending binutils, eglibc
   and gcc-4.4 uploads to the buildds.
     - binutils, fixing a regression on armel in the ld testsuite
     - eglibc, building with -fno-dwarf-cfi-asm (so that it can build
       before the gcc-4.4 build finishes)
     - gcc-4.4, with Ramana's proposed patch
 - once these packages are available we'll turn on the buidds again.
 - OOo will still be built with the workaround linking the libgcc3_uno
   with the old linker, but the ure package will have both versions,
   so that we can test and switch to the other version without
   rebuilding the package. the package will be rebuilt using the new
   toolchain packages. this way we'll have a working OOo in any case.
 - after that I'll rebuild gcc-4.4 against eglibc again.
 - the armel buildds will be turned to automatic mode again, and everything
   updated after beta will be rebuilt with the new toolchain.
"""

[Loïc Minier (lool)]

Proposed binutils upstream patch:
http://sources.redhat.com/ml/binutils/2009-10/msg00028.html

[Loïc Minier (lool)]

AFAIK the binutils upload in unapproved doesn't fix PR40521; it's just a rebuild with fixed gcc-4.4.

[Loïc Minier (lool)]

So AIUI, the gcc patch is also a workaround, the real fix should be to add support for specifying the type of debug sections to gas, and then for gcc to set it. The gcc-4.4 flag will do for karmic though.

[Loïc Minier (lool)]

binutils (2.19.91.20091001-0ubuntu1) karmic; urgency=low

  * Snapshot, taken from the 2.20 release branch 20091001.
    - Fix PR ld/9863, regression in testsuite on armel.
    - Fix regressions seen in the GCC/libjava testsuite.
  * debian/*.shlibs: Update to the version from the branch.
  * No need to build libiberty_pic.a twice.

[Jakub-gcc (jakub-gcc)]

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

[Loïc Minier (lool)]

Sadly, first round of uploads was useless as the gcc patch to set proper defaults on EABI was incorrect.

[Launchpad Janitor (janitor)]

This bug was fixed in the package binutils - 2.19.91.20091005-0ubuntu1

---------------
binutils (2.19.91.20091005-0ubuntu1) karmic; urgency=low

  * Snapshot, taken from the 2.20 release branch 20091005.
    - no changes, bump the soname only.
  * debian/*.shlibs: Update to the version from the branch.
  * Reenable the binutils-gold build on powerpc.
  * Add 129_cfi_sections.dpatch, support for .cfi_sections, taken
    from the trunk. LP: #440172.
  * Add 150_gold_copyrelocs.dpatch, add -z copyrelocs option for gold.

 -- Matthias Klose <email address hidden> Tue, 06 Oct 2009 10:31:58 +0200

[Launchpad Janitor (janitor)]

This bug was fixed in the package gcc-4.4 - 4.4.1-4ubuntu7

---------------
gcc-4.4 (4.4.1-4ubuntu7) karmic; urgency=low

  * PR debug/40521: LP: #440172.
    - Apply patch for PR debug/40521, taken from the trunk.
    - Revert the dwarf2cfi_asm workaround, obsoleted by PR debug/40521.
    - (Build-) depend on binutils (>= 2.19.91.20091005).
  * In the test summary, add more information about package versions
    used for the build.

 -- Matthias Klose <email address hidden> Tue, 06 Oct 2009 23:18:42 +0200

[Launchpad Janitor (janitor)]

This bug was fixed in the package eglibc - 2.10.1-0ubuntu14

---------------
eglibc (2.10.1-0ubuntu14) karmic; urgency=low

  * Tighten build dependencies for binutils and gcc-4.4 with fix
    for PR debug/40521. LP: #440172.
  * On armel, don't explicitely build with -fno-dwarf2-cfi-asm.
  * On armel, remove check-textrel.out test from expected to fail.

 -- Matthias Klose <email address hidden> Tue, 06 Oct 2009 23:48:37 +0200

[Matthias Klose (doko)]

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

[Ramana-gcc (ramana-gcc)]

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

[Mikpelinux (mikpelinux)]

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?

[Jakub-gcc (jakub-gcc)]

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.

[Jakub-gcc (jakub-gcc)]

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

[Jakub-gcc (jakub-gcc)]

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

[Mikpelinux (mikpelinux)]

Thanks for clarifying the !eh_personality_libfunc requirement. I'll do some experiments to see which solution works best in 4.4.

[F-frumento (f-frumento)]

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

[Sebastian Huber (sebastian-huber)]

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

[Mikpelinux (mikpelinux)]

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

[Mikpelinux (mikpelinux)]

Patch with proposed backport to 4.4 posted here:
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00818.html

[Jakub-gcc (jakub-gcc)]

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.

[Ebotcazou (ebotcazou)]

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

[Jakub-gcc (jakub-gcc)]

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

[Jakub-gcc (jakub-gcc)]

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 <email address hidden>

 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 <email address hidden>

 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 <email address hidden>

 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

[Jakub-gcc (jakub-gcc)]

Fixed.

[Mikpelinux (mikpelinux)]

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

[Tschwinge-e (tschwinge-e)]

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>

[Jackie-rosen (jackie-rosen)]

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