gc sections and .eh_frame

gc sections and .eh_frame

[Jonathan Larmour]

After an update to binutils 2.16 from 2.15 I have found that sections 
referenced by .eh_frame with relocs do not get pulled in if linking 
(statically) with --gc-sections. Initially I just put a 
KEEP(*(.gcc_except_table)) in my ldscript to work round this.

But now I'm using the powerpc architecture where the stuff usually in 
.gcc_except_table is placed in .rodata instead. If the object file has 
nothing else in .rodata, then that section is also being GC'd in the final 
link. And Bad Things Happen.

I believe I have tracked this down to a change enclosed in full at the end 
of this mail, made by Eric Botcazou on 2004-04-21. I've looked at the 
mailing list archives, and not found any posting or discussion of the 
patch, or its rationale. Is that right?

Anyway, the most relevant bit in elflink.c:bfd_elf_gc_sections() is:

        for (o = sub->sections; o != NULL; o = o->next)
         {
           if (o->flags & SEC_KEEP)
-           if (!elf_gc_mark (info, o, gc_mark_hook))
-             return FALSE;
+           {
+             /* _bfd_elf_discard_section_eh_frame knows how to discard
+                orphaned FDEs so don't mark sections referenced by the
+                EH frame section.  */
+             if (strcmp (o->name, ".eh_frame") == 0)
+               o->gc_mark = 1;
+             else if (!elf_gc_mark (info, o, gc_mark_hook))
+               return FALSE;
+           }
         }
      }

This change doesn't make sense to me. _bfd_elf_discard_section_eh_frame 
does not set gc_mark on any section. So as a result, I would assume none 
of the reloc dependencies of .eh_frame would ever get marked and that's 
how those sections get GC'd. Am I missing something?

There seems to have been some effort at the time to allow GC of sections 
in dynamically linked programs (I think). Perhaps this was a change which 
is only relevant for dynamic, not static linking? Certainly from my view, 
the correct thing to do is simply revert this part of the change.

Jifl

Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/bfd/ChangeLog,v
retrieving revision 1.2501
retrieving revision 1.2502
diff -u -5 -p -r1.2501 -r1.2502
--- ChangeLog   20 Apr 2004 12:17:12 -0000      1.2501
+++ ChangeLog   21 Apr 2004 07:14:15 -0000      1.2502
@@ -1,5 +1,14 @@
+2004-04-21  Eric Botcazou  <ebotcazou@act-europe.fr>
+
+       * elflink.c (elf_gc_mark_dynamic_ref_symbol): New function.
+       (bfd_elf_gc_sections): Fail if a shared object is being created.
+       Do not fail if dynamic sections have been created.  Instead call
+       elf_gc_mark_dynamic_ref_symbol to mark sections that contain
+       dynamically referenced symbols.  Do not mark the whole graph
+       rooted at .eh_frame, only the section proper.
+
  2004-04-20  DJ Delorie  <dj@redhat.com>

         * reloc.c: Add BFD_RELOC_32_SECREL.
         * bfd-in2.h: Regenerate.
         * libbfd.h: Likewise.
Index: elflink.c
===================================================================
RCS file: /cvs/src/src/bfd/elflink.c,v
retrieving revision 1.65
retrieving revision 1.66
diff -u -5 -p -r1.65 -r1.66
--- elflink.c   15 Apr 2004 02:55:20 -0000      1.65
+++ elflink.c   21 Apr 2004 07:14:15 -0000      1.66
@@ -8410,10 +8410,28 @@ elf_gc_smash_unused_vtentry_relocs (stru
        }

    return TRUE;
  }

+/* Mark sections containing dynamically referenced symbols.  This is called
+   through elf_link_hash_traverse.  */
+
+static bfd_boolean
+elf_gc_mark_dynamic_ref_symbol (struct elf_link_hash_entry *h,
+                               void *okp ATTRIBUTE_UNUSED)
+{
+  if (h->root.type == bfd_link_hash_warning)
+    h = (struct elf_link_hash_entry *) h->root.u.i.link;
+
+  if ((h->root.type == bfd_link_hash_defined
+       || h->root.type == bfd_link_hash_defweak)
+      && (h->elf_link_hash_flags & ELF_LINK_HASH_REF_DYNAMIC))
+    h->root.u.def.section->flags |= SEC_KEEP;
+
+  return TRUE;
+}
+
  /* Do mark and sweep of unused sections.  */

  bfd_boolean
  bfd_elf_gc_sections (bfd *abfd, struct bfd_link_info *info)
  {
@@ -8424,12 +8442,12 @@ bfd_elf_gc_sections (bfd *abfd, struct b
       struct elf_link_hash_entry *h, Elf_Internal_Sym *);

    if (!get_elf_backend_data (abfd)->can_gc_sections
        || info->relocatable
        || info->emitrelocations
-      || !is_elf_hash_table (info->hash)
-      || elf_hash_table (info)->dynamic_sections_created)
+      || info->shared
+      || !is_elf_hash_table (info->hash))
      {
        (*_bfd_error_handler)(_("Warning: gc-sections option ignored"));
        return TRUE;
      }

@@ -8445,12 +8463,19 @@ bfd_elf_gc_sections (bfd *abfd, struct b
                           elf_gc_smash_unused_vtentry_relocs,
                           &ok);
    if (!ok)
      return FALSE;

-  /* Grovel through relocs to find out who stays ...  */
+  /* Mark dynamically referenced symbols.  */
+  if (elf_hash_table (info)->dynamic_sections_created)
+    elf_link_hash_traverse (elf_hash_table (info),
+                           elf_gc_mark_dynamic_ref_symbol,
+                           &ok);
+  if (!ok)
+    return FALSE;

+  /* Grovel through relocs to find out who stays ...  */
    gc_mark_hook = get_elf_backend_data (abfd)->gc_mark_hook;
    for (sub = info->input_bfds; sub != NULL; sub = sub->link_next)
      {
        asection *o;

@@ -8458,12 +8483,19 @@ bfd_elf_gc_sections (bfd *abfd, struct b
         continue;

        for (o = sub->sections; o != NULL; o = o->next)
         {
           if (o->flags & SEC_KEEP)
-           if (!elf_gc_mark (info, o, gc_mark_hook))
-             return FALSE;
+           {
+             /* _bfd_elf_discard_section_eh_frame knows how to discard
+                orphaned FDEs so don't mark sections referenced by the
+                EH frame section.  */
+             if (strcmp (o->name, ".eh_frame") == 0)
+               o->gc_mark = 1;
+             else if (!elf_gc_mark (info, o, gc_mark_hook))
+               return FALSE;
+           }
         }
      }

    /* ... and mark SEC_EXCLUDE for those that go.  */
    if (!elf_gc_sweep (info, get_elf_backend_data (abfd)->gc_sweep_hook))

-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: gc sections and .eh_frame

[Eric Botcazou]

> I believe I have tracked this down to a change enclosed in full at the end
> of this mail, made by Eric Botcazou on 2004-04-21. I've looked at the
> mailing list archives, and not found any posting or discussion of the
> patch, or its rationale. Is that right?

http://sourceware.org/ml/binutils/2004-03/msg00424.html

> Anyway, the most relevant bit in elflink.c:bfd_elf_gc_sections() is:
>
>         for (o = sub->sections; o != NULL; o = o->next)
>          {
>            if (o->flags & SEC_KEEP)
> -           if (!elf_gc_mark (info, o, gc_mark_hook))
> -             return FALSE;
> +           {
> +             /* _bfd_elf_discard_section_eh_frame knows how to discard
> +                orphaned FDEs so don't mark sections referenced by the
> +                EH frame section.  */
> +             if (strcmp (o->name, ".eh_frame") == 0)
> +               o->gc_mark = 1;
> +             else if (!elf_gc_mark (info, o, gc_mark_hook))
> +               return FALSE;
> +           }
>          }
>       }
>
> This change doesn't make sense to me. _bfd_elf_discard_section_eh_frame
> does not set gc_mark on any section. So as a result, I would assume none
> of the reloc dependencies of .eh_frame would ever get marked and that's
> how those sections get GC'd. Am I missing something?

Presumably:

2004-04-21  Eric Botcazou  <ebotcazou@act-europe.fr>

	* scripttempl/elf.sc (.text): Add KEEP for .text.*personality*.
	(.data): Add KEEP for .gnu.linkonce.d.*personality*.
	(.gcc_except_table): Add KEEP for self and accept .gcc_except_table.*.

-- 
Eric Botcazou

Re: gc sections and .eh_frame

[Jonathan Larmour]

Eric Botcazou wrote:
>Jifl wrote:
>>This change doesn't make sense to me. _bfd_elf_discard_section_eh_frame
>>does not set gc_mark on any section. So as a result, I would assume none
>>of the reloc dependencies of .eh_frame would ever get marked and that's
>>how those sections get GC'd. Am I missing something?
> 
> 
> Presumably:
> 
> 2004-04-21  Eric Botcazou  <ebotcazou@act-europe.fr>
> 
> 	* scripttempl/elf.sc (.text): Add KEEP for .text.*personality*.
> 	(.data): Add KEEP for .gnu.linkonce.d.*personality*.
> 	(.gcc_except_table): Add KEEP for self and accept .gcc_except_table.*.
> 

Yes, as I mentioned briefly that doesn't help for powerpc, where the 
referenced data doesn't go in .gcc_except_table, but instead goes in 
.rodata. Don't ask me why it does, but it does. Probably some weird ABI thing.

It's also worth mentioning that even on other architectures, this new 
requirement (the KEEP) would cause a regression with previously working 
builds. And a pretty difficult to diagnose one at that. On embedded 
systems, custom linker scripts are exceptionally common. The default GNU 
ld template stuff isn't very relevant. For example, have a look at 
newlib/libgloss (although I'm using a different runtime). Of course this 
would only affect people using --gc-sections with recent binutils, which 
is why you probably haven't had people jumping up and down yet :-).

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: gc sections and .eh_frame

[Alan Modra]

On Tue, Jun 07, 2005 at 06:49:00PM +0100, Jonathan Larmour wrote:
> But now I'm using the powerpc architecture where the stuff usually in 
> .gcc_except_table is placed in .rodata instead. If the object file has 
> nothing else in .rodata, then that section is also being GC'd in the final 
> link. And Bad Things Happen.

Which powerpc target?  What compiler version?

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: gc sections and .eh_frame

[Jonathan Larmour]

Alan Modra wrote:
> On Tue, Jun 07, 2005 at 06:49:00PM +0100, Jonathan Larmour wrote:
> 
>>But now I'm using the powerpc architecture where the stuff usually in 
>>.gcc_except_table is placed in .rodata instead. If the object file has 
>>nothing else in .rodata, then that section is also being GC'd in the final 
>>link. And Bad Things Happen.
> 
> 
> Which powerpc target?  What compiler version?

powerpc-eabi, gcc 3.4.4.

 From a brief foray into the GCC sources, I believe the use of 
gcc_except_table depends on the existence of TARGET_ASM_NAMED_SECTION, 
which is not defined for any powerpc other than rs6000-xcoff.

There are probably other targets than powerpc that don't have 
TARGET_ASM_NAMED_SECTION too. From a glance, SuperH doesn't either at least.

I still don't have an understanding as to why sections referenced (by 
reloc) from .eh_frame shouldn't be kept safe from GC. Marking them as KEEP 
in the linker script just means that you've got one bit of code trying to 
stop such sections being included, and another bit in the linker script 
forcing them to be. It seems pointless and breaks existing working linker 
scripts, nevermind the powerpc issue.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: gc sections and .eh_frame

[Richard Henderson]

On Wed, Jun 08, 2005 at 12:14:07PM +0100, Jonathan Larmour wrote:
> From a brief foray into the GCC sources, I believe the use of 
> gcc_except_table depends on the existence of TARGET_ASM_NAMED_SECTION, 
> which is not defined for any powerpc other than rs6000-xcoff.

You're confused.  All elf have it.


r~

Re: gc sections and .eh_frame

[Jonathan Larmour]

Richard Henderson wrote:
> On Wed, Jun 08, 2005 at 12:14:07PM +0100, Jonathan Larmour wrote:
> 
>From a brief foray into the GCC sources, I believe the use of 
>>gcc_except_table depends on the existence of TARGET_ASM_NAMED_SECTION, 
>>which is not defined for any powerpc other than rs6000-xcoff.
> 
> 
> You're confused.  All elf have it.

Fair enough, it was only a belief, and it's easy for GCC to confuse me ;). 
But empirically, powerpc-eabi does put exception stuff referenced from 
.eh_frame into .rodata:

dargo:/tmp$ cat >e.cxx
extern void foo(void);

int main()
{
     try {
         foo();
     } catch(...) {
         return 1;
     };
     return 0;
}

dargo:/tmp$ powerpc-eabi-g++ -c e.cxx
dargo:/tmp$ powerpc-eabi-objdump -h e.o

e.o:     file format elf32-powerpc

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 .text         00000060  00000000  00000000  00000034  2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
   1 .data         00000000  00000000  00000000  00000094  2**0
                   CONTENTS, ALLOC, LOAD, DATA
   2 .bss          00000000  00000000  00000000  00000094  2**0
                   ALLOC
   3 .rodata       00000014  00000000  00000000  00000094  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
   4 .eh_frame     00000040  00000000  00000000  000000a8  2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
   5 .comment      00000020  00000000  00000000  000000e8  2**0
                   CONTENTS, READONLY

The .rodata there contains the exception info referenced by .eh_frame and 
there is no .gcc_except_table section present at all.

This has been the case for years for powerpc-eabi, I don't know how long.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: gc sections and .eh_frame

[Richard Henderson]

On Wed, Jun 08, 2005 at 08:30:34PM +0100, Jonathan Larmour wrote:
> But empirically, powerpc-eabi does put exception stuff referenced from 
> .eh_frame into .rodata:

Which is correct, that's where it belongs.

> there is no .gcc_except_table section present at all.

This is, and has always been, created by the linker.


r~

Re: gc sections and .eh_frame

[Jonathan Larmour]

Richard Henderson wrote:
> On Wed, Jun 08, 2005 at 08:30:34PM +0100, Jonathan Larmour wrote:
> 
>>But empirically, powerpc-eabi does put exception stuff referenced from 
>>.eh_frame into .rodata:
> 
> 
> Which is correct, that's where it belongs.
> 
> 
>>there is no .gcc_except_table section present at all.
> 
> 
> This is, and has always been, created by the linker.

Now I'm really confused:

dargo:/tmp$ arm-elf-g++ -c e.cxx
dargo:/tmp$ arm-elf-objdump -h e.o

e.o:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 .text         000000a8  00000000  00000000  00000034  2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
   1 .data         00000000  00000000  00000000  000000dc  2**0
                   CONTENTS, ALLOC, LOAD, DATA
   2 .bss          00000000  00000000  00000000  000000dc  2**0
                   ALLOC
   3 .gcc_except_table 00000010  00000000  00000000  000000dc  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
   4 .comment      00000020  00000000  00000000  000000ec  2**0
                   CONTENTS, READONLY
dargo:/tmp$ i386-elf-g++ -c e.cxx
dargo:/tmp$ i386-elf-objdump -h e.o

e.o:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 .text         00000049  00000000  00000000  00000034  2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
   1 .data         00000000  00000000  00000000  00000080  2**2
                   CONTENTS, ALLOC, LOAD, DATA
   2 .bss          00000000  00000000  00000000  00000080  2**2
                   ALLOC
   3 .gcc_except_table 00000014  00000000  00000000  00000080  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
   4 .eh_frame     00000040  00000000  00000000  00000094  2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
   5 .comment      00000020  00000000  00000000  000000d4  2**0
                   CONTENTS, READONLY
dargo:/tmp$ m68k-elf-g++ -c e.cxx
dargo:/tmp$ m68k-elf-objdump -h e.o

e.o:     file format elf32-m68k

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 .text         00000030  00000000  00000000  00000034  2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
   1 .data         00000000  00000000  00000000  00000064  2**2
                   CONTENTS, ALLOC, LOAD, DATA
   2 .bss          00000000  00000000  00000000  00000064  2**2
                   ALLOC
   3 .gcc_except_table 00000014  00000000  00000000  00000064  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
   4 .eh_frame     00000040  00000000  00000000  00000078  2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
   5 .comment      00000020  00000000  00000000  000000b8  2**0
                   CONTENTS, READONLY
dargo:/tmp$ mipsisa32-elf-g++ -c e.cxx
dargo:/tmp$ mipsisa32-elf-objdump -h e.o

e.o:     file format elf32-bigmips

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 .text         00000068  00000000  00000000  00000034  2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
   1 .data         00000000  00000000  00000000  0000009c  2**0
                   CONTENTS, ALLOC, LOAD, DATA
   2 .bss          00000000  00000000  00000000  0000009c  2**0
                   ALLOC
   3 .reginfo      00000018  00000000  00000000  0000009c  2**2
                   CONTENTS, READONLY, LINK_ONCE_SAME_SIZE
   4 .pdr          00000020  00000000  00000000  000000b4  2**2
                   CONTENTS, RELOC, READONLY
   5 .mdebug.eabi32 00000000  00000000  00000000  000000d4  2**0
                   CONTENTS, READONLY
   6 .gcc_except_table 00000014  00000000  00000000  000000d4  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
   7 .eh_frame     00000040  00000000  00000000  000000e8  2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA

and so on.

Are the powerpc-eabi tools the only ones behaving correctly (putting it in 
.rodata) and all the others wrong?

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: gc sections and .eh_frame

[Richard Henderson]

On Wed, Jun 08, 2005 at 10:36:11PM +0100, Jonathan Larmour wrote:
> >>there is no .gcc_except_table section present at all.
> >
> >This is, and has always been, created by the linker.

Sorry, I was thinking of .eh_frame_hdr.

> Are the powerpc-eabi tools the only ones behaving correctly (putting it in 
> .rodata) and all the others wrong?

*shrug* I'm not sure why ppc-eabi is the only one different.
Probably just an oversight somewhere in the rs6000 port.


r~

Re: gc sections and .eh_frame

[Jonathan Larmour]

Richard Henderson wrote:
> On Wed, Jun 08, 2005 at 10:36:11PM +0100, Jonathan Larmour wrote:
>>Are the powerpc-eabi tools the only ones behaving correctly (putting it in 
>>.rodata) and all the others wrong?
> 
> *shrug* I'm not sure why ppc-eabi is the only one different.
> Probably just an oversight somewhere in the rs6000 port.

Or could be an ABI thing. I don't know. But I don't think that's relevant 
as that clearly is the way it has worked for a long time (probably 
forever), and the elflink.c change in question breaks it. Also as I 
mentioned (but I don't care as much about personally as I'm now 
unaffected), the change breaks existing linker scripts much more widely 
than powerpc-eabi.

So far, no-one has given any rationalisation for the change. It wasn't 
posted to this list, so there's no reason given there. To my eye, the 
change doesn't seem right - if a section is a dependency of .eh_frame, it 
needs to be kept. Needing to forcibly KEEP() all .gcc_except_table 
sections should not have been necessary in the first place.

There may well be a very good reason for the change that I'm not aware of 
or am too dumb to see. That's entirely fair enough if so. As soon as I 
know the reason I'm happy to try and fix things to accomodate that reason 
and maintain existing behaviour.

Until then, I'm attaching a patch against current CVS to revert it. I 
have checkin access to /cvs/src if that helps.

Jifl

2005-06-09  Jonathan Larmour  <jifl@eCosCentric.com>

	* elflink.c (bfd_elf_gc_sections): Revert change of 2004-04-21 to
	not mark dependencies of .eh_frame. There is nowhere else such
	marking would happen so they need to be kept.

Index: elflink.c
===================================================================
RCS file: /cvs/src/src/bfd/elflink.c,v
retrieving revision 1.167
diff -u -5 -p -r1.167 elflink.c
--- elflink.c	9 Jun 2005 02:02:17 -0000	1.167
+++ elflink.c	9 Jun 2005 10:25:00 -0000
@@ -9124,16 +9124,11 @@ bfd_elf_gc_sections (bfd *abfd, struct b

        for (o = sub->sections; o != NULL; o = o->next)
  	{
  	  if (o->flags & SEC_KEEP)
  	    {
-	      /* _bfd_elf_discard_section_eh_frame knows how to discard
-		 orphaned FDEs so don't mark sections referenced by the
-		 EH frame section.  */
-	      if (strcmp (o->name, ".eh_frame") == 0)
-		o->gc_mark = 1;
-	      else if (!_bfd_elf_gc_mark (info, o, gc_mark_hook))
+	      if (!_bfd_elf_gc_mark (info, o, gc_mark_hook))
  		return FALSE;
  	    }
  	}
      }


-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: gc sections and .eh_frame

[Eric Botcazou]

> So far, no-one has given any rationalisation for the change. It wasn't
> posted to this list, so there's no reason given there.

Huh... didn't you see the link I posted?  Here is it again:
http://sourceware.org/ml/binutils/2004-03/msg00424.html

> To my eye, the change doesn't seem right - if a section is a dependency
> of .eh_frame, it needs to be kept. Needing to forcibly KEEP()
> all .gcc_except_table sections should not have been necessary in the first
> place. 

Please read the rationale I had given for the change.

-- 
Eric Botcazou

Re: gc sections and .eh_frame

[Jonathan Larmour]

Eric Botcazou wrote:
>>So far, no-one has given any rationalisation for the change. It wasn't
>>posted to this list, so there's no reason given there.
> 
> 
> Huh... didn't you see the link I posted?  Here is it again:
> http://sourceware.org/ml/binutils/2004-03/msg00424.html

I had missed that in your previous reply, my apologies. I also did not 
find it in the archives because it was over a month until the time it was 
committed.

>>To my eye, the change doesn't seem right - if a section is a dependency
>>of .eh_frame, it needs to be kept. Needing to forcibly KEEP()
>>all .gcc_except_table sections should not have been necessary in the first
>>place. 
> 
> 
> Please read the rationale I had given for the change.


Thank you. However I still fail to understand (my fault I'm sure) why 
dependencies of .eh_frame. should not be marked. Surely if the 
.gcc_except_table section has been split up into multiple sections, 
courtesy of -ffunction-sections, then that's all the more reason to mark 
.eh_frame's dependencies?

Can I ask where the used .gcc_except_table.* sections _are_ meant to be 
marked?  I cannot see anywhere that _bfd_elf_discard_section_eh_frame does 
it, for example. Why would .gcc_except_table.* get marked, but .rodata not 
get marked for powerpc?

Separately, I still consider it an issue to break existing linker scripts 
(and the failure mode is very obscure and difficult to track down when you 
encounter it, I can tell you!). That doesn't bother me personally since 
I've fixed mine (other than ppc), but for others it doesn't seem like a 
good idea to do casually.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: gc sections and .eh_frame

[Alan Modra]

On Thu, Jun 09, 2005 at 01:07:58PM +0100, Jonathan Larmour wrote:
> Can I ask where the used .gcc_except_table.* sections _are_ meant to be 
> marked?  I cannot see anywhere that _bfd_elf_discard_section_eh_frame does 
> it, for example. Why would .gcc_except_table.* get marked, but .rodata not 
> get marked for powerpc?

I think Eric cheated, and put a KEEP in the linker script.

As far as .eh_frame is concerned, the problem is that gcc doesn't emit
eh info to uniquely named sections for each function when compiling with
-ffunction-sections -fdata-sections.  Instead, you get it all lumped
into one section.  Since ld's --gc-sections option works by looking at
relocs on a section by section basis, if .eh_frame is kept, then all
sections referred to by .eh_frame will be kept.  And .eh_frame typically
references function code sections..

Relocation section '.rela.eh_frame' at offset 0x1293c contains 15 entries:
 Offset     Info    Type                Sym. Value  Symbol's Name + Addend
00000012  0000b901 R_PPC_ADDR32           00000000   __gxx_personality_v0 + 0
00000024  00000801 R_PPC_ADDR32           00000000   .text._ZNSt8ios_base17_M_call_callbacksENS_5eventE + 0
0000002d  00000901 R_PPC_ADDR32           00000000   .rodata + 0
00000048  00000a01 R_PPC_ADDR32           00000000   .text._ZNSt8ios_base20_M_dispose_callbacksEv + 0
00000068  00000b01 R_PPC_ADDR32           00000000   .text._ZNSt8ios_baseD2Ev + 0
00000071  00000901 R_PPC_ADDR32           00000000   .rodata + 1d
00000088  00000c01 R_PPC_ADDR32           00000000   .text._ZNSt8ios_baseD1Ev + 0
00000091  00000901 R_PPC_ADDR32           00000000   .rodata + 2a
000000a8  00000d01 R_PPC_ADDR32           00000000   .text._ZNSt8ios_baseD0Ev + 0
000000b1  00000901 R_PPC_ADDR32           00000000   .rodata + 37
000000c8  00001001 R_PPC_ADDR32           00000000   .text._ZNSt8ios_base6xallocEv + 0
000000d1  00000901 R_PPC_ADDR32           00000000   .rodata + 48
000000e4  00001101 R_PPC_ADDR32           00000000   .text._ZNSt8ios_base17register_callbackEPFvNS_5eventERS_iEi + 0
0000010c  00001501 R_PPC_ADDR32           00000000   .text._ZNSt8ios_base13_M_grow_wordsEib + 0
00000115  00000901 R_PPC_ADDR32           00000000   .rodata + 5c


-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: gc sections and .eh_frame

[Eric Botcazou]

> Can I ask where the used .gcc_except_table.* sections _are_ meant to be
> marked?  I cannot see anywhere that _bfd_elf_discard_section_eh_frame does
> it, for example.

The (patched) compiler will mark them.

> Why would .gcc_except_table.* get marked, but .rodata not get marked for
> powerpc? 

Clearly .rodata needs to be explicitly KEEPed for your powerpc target, the 
same way .gcc_except_table has been marked as KEEP for generic ELF.

> Separately, I still consider it an issue to break existing linker scripts
> (and the failure mode is very obscure and difficult to track down when you
> encounter it, I can tell you!).

The alternative is a useless -function-sections --gc-sections with DWARF-2 EH.

-- 
Eric Botcazou

Re: gc sections and .eh_frame

[Jonathan Larmour]

Eric Botcazou wrote:
>>Can I ask where the used .gcc_except_table.* sections _are_ meant to be
>>marked?  I cannot see anywhere that _bfd_elf_discard_section_eh_frame does
>>it, for example.
> 
> 
> The (patched) compiler will mark them.

I can't see the changes in GCC CVS, so I guess they are not even in the 
4.0.0 release. So it will be a long time before powerpc-eabi can start 
working again courtesy of that.

>>Why would .gcc_except_table.* get marked, but .rodata not get marked for
>>powerpc? 
> 
> 
> Clearly .rodata needs to be explicitly KEEPed for your powerpc target, the 
> same way .gcc_except_table has been marked as KEEP for generic ELF.

That's quite a sledgehammer approach! The overhead of garbage collectable 
stuff in .rodata is substantially more than .gcc_except_table. For my own 
use, right now, I've just reverted the patch.

But how do we fix this in binutils for other powerpc-eabi users?

Is it possible that instead of just immediately going ahead with not 
marking .eh_frame dependencies, we only do that if there _is_ a section 
named .gcc_except_table in the object? That would both catch the case of 
powerpc-eabi and any others we don't yet know about (there's no reason to 
think powerpc-eabi is definitely the only one).

In other words, something like the following?

       for (o = sub->sections; o != NULL; o = o->next)
	{
	  if (o->flags & SEC_KEEP)
	    {
	      /* _bfd_elf_discard_section_eh_frame knows how to discard
		 orphaned FDEs so don't mark sections referenced by the
		 EH frame section.  */
	      if ((strcmp (o->name, ".eh_frame") == 0) &&
                   (bfd_get_section_by_name (abfd, ".gcc_except_table") != 
NULL))
		o->gc_mark = 1;
	      else if (!_bfd_elf_gc_mark (info, o, gc_mark_hook))
		return FALSE;
	    }
	}
     }

If you think this looks right and you agree with the principle, I can try 
it out.

>>Separately, I still consider it an issue to break existing linker scripts
>>(and the failure mode is very obscure and difficult to track down when you
>>encounter it, I can tell you!).
> 
> 
> The alternative is a useless -function-sections --gc-sections with DWARF-2 EH.

Not quite useless, just more limited. And if it's a choice between not 
working and limited, I'd choose the latter! :-)

Seriously, if it's a conscious decision to break existing linker scripts 
in this case, that's fine. I just want to make sure people are aware that 
that's the effect.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: gc sections and .eh_frame

[Eric Botcazou]

> That's quite a sledgehammer approach! The overhead of garbage collectable
> stuff in .rodata is substantially more than .gcc_except_table. For my own
> use, right now, I've just reverted the patch.

Since -function-sections --gc-sections doesn't work in presence of DWARF-2 EH, 
you could simply not pass -function-sections to the compiler.

> Is it possible that instead of just immediately going ahead with not
> marking .eh_frame dependencies, we only do that if there _is_ a section
> named .gcc_except_table in the object? That would both catch the case of
> powerpc-eabi and any others we don't yet know about (there's no reason to
> think powerpc-eabi is definitely the only one).
>
> In other words, something like the following?
>
>        for (o = sub->sections; o != NULL; o = o->next)
> 	{
> 	  if (o->flags & SEC_KEEP)
> 	    {
> 	      /* _bfd_elf_discard_section_eh_frame knows how to discard
> 		 orphaned FDEs so don't mark sections referenced by the
> 		 EH frame section.  */
> 	      if ((strcmp (o->name, ".eh_frame") == 0) &&
>                    (bfd_get_section_by_name (abfd, ".gcc_except_table") !=
> NULL))
> 		o->gc_mark = 1;
> 	      else if (!_bfd_elf_gc_mark (info, o, gc_mark_hook))
> 		return FALSE;
> 	    }
> 	}
>      }
>
> If you think this looks right and you agree with the principle, I can try
> it out.

I'm not sure the .gcc_except_table section has already been created by the 
time bfd_elf_gc_sections is invoked.  I'm looking into it.

-- 
Eric Botcazou

Re: gc sections and .eh_frame

[Jonathan Larmour]

Eric Botcazou wrote:
>>That's quite a sledgehammer approach! The overhead of garbage collectable
>>stuff in .rodata is substantially more than .gcc_except_table. For my own
>>use, right now, I've just reverted the patch.
> 
> 
> Since -function-sections --gc-sections doesn't work in presence of DWARF-2 EH, 
> you could simply not pass -function-sections to the compiler.

Ah, the issue being on embedded targets (as powerpc-eabi is implicitly), 
people are normally selective about what they allow to be compiled without 
-fno-exceptions. In the case of eCos, the OS is fully linked to the 
application, and almost none of the OS wants to use C++ exceptions. This 
translates to large savings with gc sections.

I expect anyone else using eCos or their own embedded OS would be 
similarly selective.

> I'm not sure the .gcc_except_table section has already been created by the 
> time bfd_elf_gc_sections is invoked.  I'm looking into it.

Great, thanks. I guess looping over the input BFDs would be better.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: gc sections and .eh_frame

[Alan Modra]

On Thu, Jun 09, 2005 at 03:34:20PM +0100, Jonathan Larmour wrote:
> Eric Botcazou wrote:
> >>That's quite a sledgehammer approach! The overhead of garbage collectable
> >>stuff in .rodata is substantially more than .gcc_except_table. For my own
> >>use, right now, I've just reverted the patch.
> >
> >Since -function-sections --gc-sections doesn't work in presence of DWARF-2 
> >EH, you could simply not pass -function-sections to the compiler.
> 
> Ah, the issue being on embedded targets (as powerpc-eabi is implicitly), 
> people are normally selective about what they allow to be compiled without 
> -fno-exceptions. In the case of eCos, the OS is fully linked to the 
> application, and almost none of the OS wants to use C++ exceptions. This 
> translates to large savings with gc sections.

Actually, it's not just eabi that is affected by this problem, but all
sysv4 abi powerpc targets, which includes powerpc-linux.  I've done some
digging through gcc CVS to see why this problem occurred, and found:

Geoff introduced #define EXCEPTION_SECTION readonly_data_section
here: http://gcc.gnu.org/ml/gcc-patches/2001-05/msg00812.html
All well and good, it was an improvement over using data_section

Over time though, we eventually had a default_exception_section that
could generate a read-only .gcc_except_table, so there is now no need
for the define in rs6000/sysv4.h, and of course using .rodata can result
in ld --gc-sections deleting needed exception information.  I'll be
committing a gcc patch soon to fix this on all active gcc branches,
pre-approved by David Edelsohn.

	* config/rs6000/sysv4.h (TARGET_ASM_EXCEPTION_SECTION): Delete.

Index: gcc/config/rs6000/sysv4.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/rs6000/sysv4.h,v
retrieving revision 1.163
diff -u -p -r1.163 sysv4.h
--- gcc/config/rs6000/sysv4.h	1 Jun 2005 00:30:22 -0000	1.163
+++ gcc/config/rs6000/sysv4.h	10 Jun 2005 04:19:39 -0000
@@ -1284,8 +1284,6 @@ ncrtn.o%s"
    ? (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_pcrel | DW_EH_PE_sdata4) \
    : DW_EH_PE_absptr)
 
-#define TARGET_ASM_EXCEPTION_SECTION readonly_data_section
-
 #define DOUBLE_INT_ASM_OP "\t.quad\t"
 
 /* Generate entries in .fixup for relocatable addresses.  */

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: gc sections and .eh_frame

[Eric Botcazou]

> I'll be committing a gcc patch soon to fix this on all active gcc branches,
> pre-approved by David Edelsohn.
>
> 	* config/rs6000/sysv4.h (TARGET_ASM_EXCEPTION_SECTION): Delete.

Thanks for tracking this down!

-- 
Eric Botcazou

Re: gc sections and .eh_frame

[Jonathan Larmour]

Eric Botcazou wrote:
>>I'll be committing a gcc patch soon to fix this on all active gcc branches,
>>pre-approved by David Edelsohn.
>>
>>	* config/rs6000/sysv4.h (TARGET_ASM_EXCEPTION_SECTION): Delete.
> 
> 
> Thanks for tracking this down!

Agreed, thanks! And hopefully that does mean it won't affect other 
architectures after all.

But that still leaves us with a huge time gap between now, and when GCC 
CVS after the patch finally reaches gcc 4.1.0.

So I would still be keen on pursuing a workaround in binutils, perhaps 
along the lines of what I suggested (seeing if .gcc_except_table is in the 
input sections), or anything else anyone thinks would work. Adding a 
special case for powerpc probably wouldn't be wise as it wouldn't be 
appropriate for gcc 4.1.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: gc sections and .eh_frame

[Eric Botcazou]

[-- Attachment #1: Type: text/plain, Size: 309 bytes --]

> Great, thanks. I guess looping over the input BFDs would be better.

Right, I think it's the best approach.  Not very pretty but it works for me.


	* elflink.c (bfd_elf_gc_sections): Mark again the sections rooted
	at .eh_frame if the EH tables are not in .gcc_except_table.* sections.


-- 
Eric Botcazou

[-- Attachment #2: d106-019_linker-2.diff --]
[-- Type: text/x-diff, Size: 1785 bytes --]

Index: elflink.c
===================================================================
RCS file: /cvs/src/src/bfd/elflink.c,v
retrieving revision 1.136.2.3
diff -u -p -r1.136.2.3 elflink.c
--- elflink.c	27 Apr 2005 16:47:24 -0000	1.136.2.3
+++ elflink.c	10 Jun 2005 11:43:48 -0000
@@ -9031,6 +9031,8 @@ bfd_elf_gc_sections (bfd *abfd, struct b
   asection * (*gc_mark_hook)
     (asection *, struct bfd_link_info *, Elf_Internal_Rela *,
      struct elf_link_hash_entry *h, Elf_Internal_Sym *);
+  bfd_boolean has_gcc_except_table = FALSE;
+  asection *eh_frame = NULL;
 
   if (!get_elf_backend_data (abfd)->can_gc_sections
       || info->relocatable
@@ -9081,13 +9083,31 @@ bfd_elf_gc_sections (bfd *abfd, struct b
 		 orphaned FDEs so don't mark sections referenced by the
 		 EH frame section.  */  
 	      if (strcmp (o->name, ".eh_frame") == 0)
-		o->gc_mark = 1;
+	        {
+		  o->gc_mark = 1;
+		  eh_frame = o;
+		}
 	      else if (!_bfd_elf_gc_mark (info, o, gc_mark_hook))
 		return FALSE;
 	    }
+
+	  /* Detect .gcc_except_table.* sections in the input files.  */
+	  if (!has_gcc_except_table
+	      && strncmp (o->name, ".gcc_except_table", 17) == 0)
+	    has_gcc_except_table = TRUE;
 	}
     }
 
+  /* If we have not detected .gcc_except_table.* sections in the input files,
+     that probably means the target uses a specific section for the EH tables.
+     Play safe and let .eh_frame mark the sections it really needs, since we
+     will not be able to do it explicitly.  */
+  if (eh_frame && !has_gcc_except_table)
+    {
+      if (!_bfd_elf_gc_mark (info, eh_frame, gc_mark_hook))
+	return FALSE;
+    }
+
   /* ... and mark SEC_EXCLUDE for those that go.  */
   if (!elf_gc_sweep (info, get_elf_backend_data (abfd)->gc_sweep_hook))
     return FALSE;

Re: gc sections and .eh_frame

[Alan Modra]

On Fri, Jun 10, 2005 at 01:54:36PM +0200, Eric Botcazou wrote:
> > Great, thanks. I guess looping over the input BFDs would be better.
> 
> Right, I think it's the best approach.  Not very pretty but it works for me.
> 
> 
> 	* elflink.c (bfd_elf_gc_sections): Mark again the sections rooted
> 	at .eh_frame if the EH tables are not in .gcc_except_table.* sections.

Won't that mark all the function text sections too?

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: gc sections and .eh_frame

[Jonathan Larmour]

Alan Modra wrote:
> On Fri, Jun 10, 2005 at 01:54:36PM +0200, Eric Botcazou wrote:
> 
>>>Great, thanks. I guess looping over the input BFDs would be better.
>>
>>Right, I think it's the best approach.  Not very pretty but it works for me.
>>
>>
>>	* elflink.c (bfd_elf_gc_sections): Mark again the sections rooted
>>	at .eh_frame if the EH tables are not in .gcc_except_table.* sections.
> 
> 
> Won't that mark all the function text sections too?

Only if there aren't any .gcc_except_table* sections surely? In which case 
that's no worse than previous behaviour.

Anyway, unfortunately the patch doesn't quite work. There are multiple 
input .eh_frame sections, and only the most recently seen one will get its 
dependencies marked.

While it would be good to reuse the loop, I think we're going to have to 
do a separate loop to search for .gcc_except_table*. I'll rework the patch.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: gc sections and .eh_frame

[Eric Botcazou]

> > 	* elflink.c (bfd_elf_gc_sections): Mark again the sections rooted
> > 	at .eh_frame if the EH tables are not in .gcc_except_table.* sections.
>
> Won't that mark all the function text sections too?

Aren't they automatically marked if the EH tables are?

-- 
Eric Botcazou

Re: gc sections and .eh_frame

[Eric Botcazou]

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

> Anyway, unfortunately the patch doesn't quite work. There are multiple
> input .eh_frame sections, and only the most recently seen one will get its
> dependencies marked.

Oops.  Totally broken would be the right wording. :-)

> While it would be good to reuse the loop, I think we're going to have to
> do a separate loop to search for .gcc_except_table*.

Could we not simply move the invocation of _bfd_elf_gc_mark inside the loop?
A new revision is attached.

-- 
Eric Botcazou

[-- Attachment #2: d106-019_linker-2b.diff --]
[-- Type: text/x-diff, Size: 1691 bytes --]

Index: elflink.c
===================================================================
RCS file: /cvs/src/src/bfd/elflink.c,v
retrieving revision 1.136.2.3
diff -u -p -r1.136.2.3 elflink.c
--- elflink.c	27 Apr 2005 16:47:24 -0000	1.136.2.3
+++ elflink.c	10 Jun 2005 13:42:38 -0000
@@ -9068,6 +9068,8 @@ bfd_elf_gc_sections (bfd *abfd, struct b
   gc_mark_hook = get_elf_backend_data (abfd)->gc_mark_hook;
   for (sub = info->input_bfds; sub != NULL; sub = sub->link_next)
     {
+      bfd_boolean has_gcc_except_table = FALSE;
+      asection *eh_frame = NULL;
       asection *o;
 
       if (bfd_get_flavour (sub) != bfd_target_elf_flavour)
@@ -9081,11 +9083,29 @@ bfd_elf_gc_sections (bfd *abfd, struct b
 		 orphaned FDEs so don't mark sections referenced by the
 		 EH frame section.  */  
 	      if (strcmp (o->name, ".eh_frame") == 0)
-		o->gc_mark = 1;
+	        {
+		  o->gc_mark = 1;
+		  eh_frame = o;
+		}
 	      else if (!_bfd_elf_gc_mark (info, o, gc_mark_hook))
 		return FALSE;
 	    }
+
+	  /* Detect .gcc_except_table.* sections in the input file.  */
+	  if (!has_gcc_except_table
+	      && strncmp (o->name, ".gcc_except_table", 17) == 0)
+	    has_gcc_except_table = TRUE;
 	}
+
+      /* If we have not detected .gcc_except_table.* sections in the input
+	 file, that probably means the target uses a specific section for
+	 the EH tables.  Play safe and let .eh_frame mark the sections it
+	 really needs, since we will not be able to do it explicitly.  */
+      if (eh_frame && !has_gcc_except_table)
+        {
+	  if (!_bfd_elf_gc_mark (info, eh_frame, gc_mark_hook))
+	    return FALSE;
+        }
     }
 
   /* ... and mark SEC_EXCLUDE for those that go.  */

Re: gc sections and .eh_frame

[Jonathan Larmour]

Eric Botcazou wrote:
> Could we not simply move the invocation of _bfd_elf_gc_mark inside the loop?
> A new revision is attached.

Indeed so, well thought! I've tested it with powerpc-eabi and it works 
fine. I'm happy with that, great work, thanks!

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: gc sections and .eh_frame

[Eric Botcazou]

> Indeed so, well thought! I've tested it with powerpc-eabi and it works
> fine. I'm happy with that, great work, thanks!

Thanks for confirming.  However I think I've grasped Alan's remark and we 
indeed risk marking all the functions in a given input file if it happens to 
contain no EH tables because its functions don't need them.

I can think of 2 solutions: a second loop as you initially suggested or to add 
a new parameter 'skip_code' to _bfd_elf_gc_mark to skip SEC_CODE sections 
when it is invoked on .eh_frame.  Alan will decide whether the latter approach 
is easily implementable.

-- 
Eric Botcazou

Re: gc sections and .eh_frame

[Jonathan Larmour]

Eric Botcazou wrote:
>>Indeed so, well thought! I've tested it with powerpc-eabi and it works
>>fine. I'm happy with that, great work, thanks!
> 
> 
> Thanks for confirming.  However I think I've grasped Alan's remark and we 
> indeed risk marking all the functions in a given input file if it happens to 
> contain no EH tables because its functions don't need them.

Can that really happen in practice? Doesn't that mean having a .eh_frame 
input section present and (on non-powerpc targets) no .gcc_except_frame?

> I can think of 2 solutions: a second loop as you initially suggested or to add 
> a new parameter 'skip_code' to _bfd_elf_gc_mark to skip SEC_CODE sections 
> when it is invoked on .eh_frame.  Alan will decide whether the latter approach 
> is easily implementable.

Since I'm not sure I understand the issue, I'll certainly leave it to you 
two to decide.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: gc sections and .eh_frame

[Eric Botcazou]

> > Thanks for confirming.  However I think I've grasped Alan's remark and we
> > indeed risk marking all the functions in a given input file if it happens
> > to contain no EH tables because its functions don't need them.
>
> Can that really happen in practice? Doesn't that mean having a .eh_frame
> input section present and (on non-powerpc targets) no .gcc_except_frame?

Yes, that can happen if no functions in the file use EH constructs, which is 
not uncommon I think.  For example in Ada:

with U;
procedure Ma is
i : Integer := 10;
begin
   U.Used (i);
end Ma;


        .file   "ma.adb"
        .section        .rodata
.LC0:
        .string "ma.adb"
        .zero   1
        .section        .text._ada_ma,"ax",@progbits
.globl _ada_ma
        .type   _ada_ma, @function
_ada_ma:
.LFB2:
        pushl   %ebp
.LCFI0:
        movl    %esp, %ebp
.LCFI1:
        subl    $8, %esp
.LCFI2:
        movl    $10, -4(%ebp)
        subl    $12, %esp
        cmpl    $0, -4(%ebp)
        js      .L4
        cmpl    $10, -4(%ebp)
        jg      .L4
        jmp     .L2
.L4:
        subl    $12, %esp
        pushl   $5
        pushl   $.LC0
.LCFI3:
        call    __gnat_rcheck_11
.L2:
        movl    -4(%ebp), %eax
        pushl   %eax
.LCFI4:
        call    u__used
        addl    $16, %esp
        movl    %eax, -4(%ebp)
        leave
        ret
.LFE2:
        .size   _ada_ma, .-_ada_ma
        .section        .eh_frame,"a",@progbits
.Lframe1:
        .long   .LECIE1-.LSCIE1
.LSCIE1:
        .long   0x0
        .byte   0x1
        .string "zP"
        .uleb128 0x1
        .sleb128 -4
        .byte   0x8
        .uleb128 0x5
        .byte   0x0
        .long   __gnat_eh_personality
        .byte   0xc
        .uleb128 0x4
        .uleb128 0x4
        .byte   0x88
        .uleb128 0x1
        .align 4
.LECIE1:
.LSFDE1:
        .long   .LEFDE1-.LASFDE1
.LASFDE1:
        .long   .LASFDE1-.Lframe1
        .long   .LFB2
        .long   .LFE2-.LFB2
        .uleb128 0x0
        .byte   0x4
        .long   .LCFI0-.LFB2
        .byte   0xe
        .uleb128 0x8
        .byte   0x85
        .uleb128 0x2
        .byte   0x4
        .long   .LCFI1-.LCFI0
        .byte   0xd
        .uleb128 0x5
        .byte   0x4
        .long   .LCFI3-.LCFI1
        .byte   0x2e
        .uleb128 0x14
        .byte   0x4
        .long   .LCFI4-.LCFI3
        .byte   0x2e
        .uleb128 0x10
        .align 4
.LEFDE1:
        .section        .note.GNU-stack,"",@progbits
        .ident  "GCC: (GNU) 3.4.5 20050607 (prerelease)"

-- 
Eric Botcazou

Re: gc sections and .eh_frame

[Jonathan Larmour]

Eric Botcazou wrote:
>>Indeed so, well thought! I've tested it with powerpc-eabi and it works
>>fine. I'm happy with that, great work, thanks!
> 
> 
> Thanks for confirming.  However I think I've grasped Alan's remark and we 
> indeed risk marking all the functions in a given input file if it happens to 
> contain no EH tables because its functions don't need them.
> 
> I can think of 2 solutions: a second loop as you initially suggested or to add 
> a new parameter 'skip_code' to _bfd_elf_gc_mark to skip SEC_CODE sections 
> when it is invoked on .eh_frame.  Alan will decide whether the latter approach 
> is easily implementable.

I think Alan maybe didn't notice his name being mentioned :). Alan, do you 
have any guidance on the best approach?

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: gc sections and .eh_frame

[Alan Modra]

On Wed, Jun 22, 2005 at 12:46:21PM +0100, Jonathan Larmour wrote:
> I think Alan maybe didn't notice his name being mentioned :). Alan, do you 
> have any guidance on the best approach?

None of the proposed solutions is right.  If you take a look at a
typical .eh_frame, you'll see relocs pointing at text sections and
.gcc_except_table (or .rodata for broken ppc compilers).  Changing
garbage collection to process .rela.eh_frame thus runs into the problem
of distinguishing the two types of reloc:  You need to ignore the
former, and mark sections for the latter.

Try the following totally untested patch.

	* elflink.c (_bfd_elf_gc_mark): Handle .eh_frame relocs specially..
	(bfd_elf_gc_sections): ..rather than totally ignoring .eh_frame.
	Don't recheck sections we have already marked.

--- bfd/elflink.c~	2005-06-16 12:18:15.000000000 +0930
+++ bfd/elflink.c	2005-06-26 02:17:09.464213143 +0930
@@ -8733,6 +8733,7 @@
 		  gc_mark_hook_fn gc_mark_hook)
 {
   bfd_boolean ret;
+  bfd_boolean is_eh;
   asection *group_sec;
 
   sec->gc_mark = 1;
@@ -8745,6 +8746,7 @@
 
   /* Look through the section relocs.  */
   ret = TRUE;
+  is_eh = strcmp (sec->name, ".eh_frame") == 0;
   if ((sec->flags & SEC_RELOC) != 0 && sec->reloc_count > 0)
     {
       Elf_Internal_Rela *relstart, *rel, *relend;
@@ -8817,7 +8819,10 @@
 	      rsec = (*gc_mark_hook) (sec, info, rel, NULL, &isym[r_symndx]);
 	    }
 
-	  if (rsec && !rsec->gc_mark)
+	  if (rsec && !rsec->gc_mark
+	      /* Don't mark code sections referenced by .eh_frame,
+		 otherwise we'll mark all code sections in this file.  */
+	      && !(is_eh && (rsec->flags & SEC_CODE) != 0))
 	    {
 	      if (bfd_get_flavour (rsec->owner) != bfd_target_elf_flavour)
 		rsec->gc_mark = 1;
@@ -9123,18 +9128,9 @@
 	continue;
 
       for (o = sub->sections; o != NULL; o = o->next)
-	{
-	  if (o->flags & SEC_KEEP)
-	    {
-	      /* _bfd_elf_discard_section_eh_frame knows how to discard
-		 orphaned FDEs so don't mark sections referenced by the
-		 EH frame section.  */
-	      if (strcmp (o->name, ".eh_frame") == 0)
-		o->gc_mark = 1;
-	      else if (!_bfd_elf_gc_mark (info, o, gc_mark_hook))
-		return FALSE;
-	    }
-	}
+	if ((o->flags & SEC_KEEP) != 0 && !o->gc_mark)
+	  if (!_bfd_elf_gc_mark (info, o, gc_mark_hook))
+	    return FALSE;
     }
 
   /* ... and mark SEC_EXCLUDE for those that go.  */

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: gc sections and .eh_frame

[Eric Botcazou]

[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]

> None of the proposed solutions is right.  If you take a look at a
> typical .eh_frame, you'll see relocs pointing at text sections and
> .gcc_except_table (or .rodata for broken ppc compilers).  Changing
> garbage collection to process .rela.eh_frame thus runs into the problem
> of distinguishing the two types of reloc:  You need to ignore the
> former, and mark sections for the latter.

That's exactly what I proposed in my last message, but I suggested passing a 
parameter to _bfd_elf_gc_mark to make it "forget" code sections.  It seems 
autodetecting .eh_frame is more straightforward.

> Try the following totally untested patch.
>
> 	* elflink.c (_bfd_elf_gc_mark): Handle .eh_frame relocs specially..
> 	(bfd_elf_gc_sections): ..rather than totally ignoring .eh_frame.
> 	Don't recheck sections we have already marked.

I think it doesn't work (alone) either, because you unconditionally mark 
all .gcc_except_table* sections, which themselves point to the functions.

In normal mode (i.e. with a non broken ppc compiler), we really need avoid 
marking any sections referenced by .eh_frame, them being code or data.  So I 
think that, before invoking _bfd_elf_gc_mark on .eh_frame, we need to make 
sure that it doesn't reference .gcc_except_table* sections.  Hence the 
attached patch.


	* elflink.c (_bfd_elf_gc_mark): Don't mark code sections referenced
	by .eh_frame.
	(bfd_elf_gc_sections): Mark again the sections referenced by .eh_frame
	if the EH tables are not in .gcc_except_table* sections.


-- 
Eric Botcazou

[-- Attachment #2: d106-019_linker-3.diff --]
[-- Type: text/x-diff, Size: 3311 bytes --]

Index: elflink.c
===================================================================
RCS file: /cvs/src/src/bfd/elflink.c,v
retrieving revision 1.136.2.3
diff -u -p -r1.136.2.3 elflink.c
--- elflink.c	27 Apr 2005 16:47:24 -0000	1.136.2.3
+++ elflink.c	27 Jun 2005 11:47:06 -0000
@@ -8687,6 +8687,7 @@ _bfd_elf_gc_mark (struct bfd_link_info *
 		  gc_mark_hook_fn gc_mark_hook)
 {
   bfd_boolean ret;
+  bfd_boolean is_eh;
   asection *group_sec;
 
   sec->gc_mark = 1;
@@ -8699,6 +8700,7 @@ _bfd_elf_gc_mark (struct bfd_link_info *
 
   /* Look through the section relocs.  */
   ret = TRUE;
+  is_eh = strcmp (sec->name, ".eh_frame") == 0;
   if ((sec->flags & SEC_RELOC) != 0 && sec->reloc_count > 0)
     {
       Elf_Internal_Rela *relstart, *rel, *relend;
@@ -8771,7 +8773,11 @@ _bfd_elf_gc_mark (struct bfd_link_info *
 	      rsec = (*gc_mark_hook) (sec, info, rel, NULL, &isym[r_symndx]);
 	    }
 
-	  if (rsec && !rsec->gc_mark)
+	  if (rsec
+	      && !rsec->gc_mark
+	      /* elf-eh-frame.c knows how to discard orphaned FDEs so don't
+		 mark code sections referenced by the .eh_frame section.  */  
+	      && !(is_eh && (rsec->flags & SEC_CODE) != 0))
 	    {
 	      if (bfd_get_flavour (rsec->owner) != bfd_target_elf_flavour)
 		rsec->gc_mark = 1;
@@ -9068,6 +9074,8 @@ bfd_elf_gc_sections (bfd *abfd, struct b
   gc_mark_hook = get_elf_backend_data (abfd)->gc_mark_hook;
   for (sub = info->input_bfds; sub != NULL; sub = sub->link_next)
     {
+      bfd_boolean has_gcc_except_table = FALSE;
+      asection *eh_frame = NULL;
       asection *o;
 
       if (bfd_get_flavour (sub) != bfd_target_elf_flavour)
@@ -9077,15 +9085,41 @@ bfd_elf_gc_sections (bfd *abfd, struct b
 	{
 	  if (o->flags & SEC_KEEP)
 	    {
-	      /* _bfd_elf_discard_section_eh_frame knows how to discard
-		 orphaned FDEs so don't mark sections referenced by the
-		 EH frame section.  */  
+	      /* Marking all sections referenced by .eh_frame effectively
+		 disables GC because FDEs contain relocs against both the
+		 functions' code and exception table.  So we mark none,
+		 relying on elf-eh-frame.c to deal with the former type of
+		 relocs (it will discard orphaned FDEs) and on the linker
+		 script to deal with the latter type if necessary.  */
 	      if (strcmp (o->name, ".eh_frame") == 0)
-		o->gc_mark = 1;
+	        {
+		  o->gc_mark = 1;
+		  eh_frame = o;
+		}
 	      else if (!_bfd_elf_gc_mark (info, o, gc_mark_hook))
 		return FALSE;
 	    }
-	}
+
+#define GCC_EXCEPT_TABLE_PREFIX  ".gcc_except_table"
+
+	  /* Detect .gcc_except_table* sections in the input file.  */
+	  if (!has_gcc_except_table
+	      && strncmp (o->name,
+			  GCC_EXCEPT_TABLE_PREFIX,
+			  strlen (GCC_EXCEPT_TABLE_PREFIX)) == 0)
+	    has_gcc_except_table = TRUE;
+	}
+
+      /* If we have not detected .gcc_except_table* sections in the input
+	 file, that can mean the target uses a specific section for the
+	 EH tables.  Play safe and let .eh_frame mark the non-code
+	 sections it really needs, since we will presumably not be able
+	 to do so explicitly via the linker script if necessary.  */
+      if (eh_frame && !has_gcc_except_table)
+        {
+	  if (!_bfd_elf_gc_mark (info, eh_frame, gc_mark_hook))
+	    return FALSE;
+        }
     }
 
   /* ... and mark SEC_EXCLUDE for those that go.  */

Re: gc sections and .eh_frame

[Alan Modra]

On Mon, Jun 27, 2005 at 01:55:49PM +0200, Eric Botcazou wrote:
> > None of the proposed solutions is right.  If you take a look at a
> > typical .eh_frame, you'll see relocs pointing at text sections and
> > .gcc_except_table (or .rodata for broken ppc compilers).  Changing
> > garbage collection to process .rela.eh_frame thus runs into the problem
> > of distinguishing the two types of reloc:  You need to ignore the
> > former, and mark sections for the latter.
> 
> That's exactly what I proposed in my last message, but I suggested passing a 

Sorry, I was just going by memory.

> parameter to _bfd_elf_gc_mark to make it "forget" code sections.  It seems 
> autodetecting .eh_frame is more straightforward.
> 
> > Try the following totally untested patch.
> >
> > 	* elflink.c (_bfd_elf_gc_mark): Handle .eh_frame relocs specially..
> > 	(bfd_elf_gc_sections): ..rather than totally ignoring .eh_frame.
> > 	Don't recheck sections we have already marked.
> 
> I think it doesn't work (alone) either, because you unconditionally mark 
> all .gcc_except_table* sections, which themselves point to the functions.

That doesn't make any difference, because .gcc_except_table* is marked
via KEEP() in the linker script.  So I don't think you need anything
more than the patch I posted.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: gc sections and .eh_frame

[Eric Botcazou]

> > I think it doesn't work (alone) either, because you unconditionally mark
> > all .gcc_except_table* sections, which themselves point to the functions.
>
> That doesn't make any difference, because .gcc_except_table* is marked
> via KEEP() in the linker script.  So I don't think you need anything
> more than the patch I posted.

That's not quite true, .gcc_except_table is indeed marked as KEEP, but 
not .gcc_except_table.* :-)

That's the crux of the mechanism: an unpatched (non broken) compiler will only 
emit .gcc_except_table.  But a patched compiler (i.e. the AdaCore compiler or 
the FSF compiler + http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01433.html) 
will emit .gcc_except_table.* with -ffunction-sections, making it possible to 
have a working --gc-sections for languages with EH.

-- 
Eric Botcazou

Re: gc sections and .eh_frame

[Alan Modra]

On Tue, Jun 28, 2005 at 09:40:28AM +0200, Eric Botcazou wrote:
> That's not quite true, .gcc_except_table is indeed marked as KEEP, but 
> not .gcc_except_table.* :-)

So how do you ensure .gcc_except_table.* is marked, if not by looking
through .eh_frame relocs?

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: gc sections and .eh_frame

[Eric Botcazou]

> So how do you ensure .gcc_except_table.* is marked, if not by looking
> through .eh_frame relocs?

Take a look at the change to output_function_exception_table in the 
aforementioned GCC patch. :-)

-- 
Eric Botcazou

Re: gc sections and .eh_frame

[Alan Modra]

On Tue, Jun 28, 2005 at 01:57:58PM +0200, Eric Botcazou wrote:
> > So how do you ensure .gcc_except_table.* is marked, if not by looking
> > through .eh_frame relocs?
> 
> Take a look at the change to output_function_exception_table in the 
> aforementioned GCC patch. :-)

I see.  That extra word emitted just to tie .gcc_except_table.* to the
function code is no doubt one reason why the gcc patch hasn't been
approved.  Hmm, I think we can do without it by marking sections
referenced from .eh_frame specially, and keeping them iff the associated
.text section is marked.  Patch in progress.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: gc sections and .eh_frame

[Eric Botcazou]

> I see.  That extra word emitted just to tie .gcc_except_table.* to the
> function code is no doubt one reason why the gcc patch hasn't been
> approved.

The official reason was that COMDAT groups had been introduced in-between and 
that the patch should be rewritten to use them.  On my list, but very, very 
low-priority given the very, very low interest for this stuff outside the Ada 
world.

> Hmm, I think we can do without it by marking sections referenced
> from .eh_frame specially, and keeping them iff the associated 
> .text section is marked.  Patch in progress.

That would be a nice improvement.  I could try to propose an updated version 
of the GCC patch before the end of Stage 2 if you came up with something for 
the linker.

In the meantime, do you want me to apply the patch on Binutils mainline?  On 
Binutils 2.16 branch?

-- 
Eric Botcazou

Re: gc sections and .eh_frame

[Jonathan Larmour]

Eric Botcazou wrote:
> 
> In the meantime, do you want me to apply the patch on Binutils mainline?  On 
> Binutils 2.16 branch?

So should I try out the patch Eric sent on the 27th 12:55 to check it 
works as expected? Is that the final version?

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: gc sections and .eh_frame

[Alan Modra]

On Wed, Jun 29, 2005 at 10:54:01AM +0930, Alan Modra wrote:
> I think we can do without it by marking sections
> referenced from .eh_frame specially, and keeping them iff the associated
> .text section is marked.

Committing mainline.

bfd/
	* elflink.c (_bfd_elf_gc_mark): Mark sections referenced by
	.eh_frame specially..
	(bfd_elf_gc_sections): ..rather than totally ignoring .eh_frame.
	Don't recheck sections we have already marked.
	(elf_gc_sweep): Keep non-code sections referenced from .eh_frame.
	* section.c (struct bfd_section): Add gc_mark_from_eh.
	(STD_SECTION): Adjust.
	* ecoff.c (bfd_debug_section): Adjust.
	* bfd-in2.h: Regenerate.

ld/
	* scripttempl/elf.sc (.gcc_except_table): Don't KEEP.

Index: bfd/elflink.c
===================================================================
RCS file: /cvs/src/src/bfd/elflink.c,v
retrieving revision 1.168
diff -u -p -r1.168 elflink.c
--- bfd/elflink.c	14 Jun 2005 19:25:45 -0000	1.168
+++ bfd/elflink.c	29 Jun 2005 13:02:15 -0000
@@ -8733,6 +8733,7 @@ _bfd_elf_gc_mark (struct bfd_link_info *
 		  gc_mark_hook_fn gc_mark_hook)
 {
   bfd_boolean ret;
+  bfd_boolean is_eh;
   asection *group_sec;
 
   sec->gc_mark = 1;
@@ -8745,6 +8746,7 @@ _bfd_elf_gc_mark (struct bfd_link_info *
 
   /* Look through the section relocs.  */
   ret = TRUE;
+  is_eh = strcmp (sec->name, ".eh_frame") == 0;
   if ((sec->flags & SEC_RELOC) != 0 && sec->reloc_count > 0)
     {
       Elf_Internal_Rela *relstart, *rel, *relend;
@@ -8821,6 +8823,8 @@ _bfd_elf_gc_mark (struct bfd_link_info *
 	    {
 	      if (bfd_get_flavour (rsec->owner) != bfd_target_elf_flavour)
 		rsec->gc_mark = 1;
+	      else if (is_eh)
+		rsec->gc_mark_from_eh = 1;
 	      else if (!_bfd_elf_gc_mark (info, rsec, gc_mark_hook))
 		{
 		  ret = FALSE;
@@ -8891,6 +8895,41 @@ elf_gc_sweep (struct bfd_link_info *info
 	  if (o->gc_mark)
 	    continue;
 
+	  /* Keep .gcc_except_table.* if the associated .text.* is
+	     marked.  This isn't very nice, but the proper solution,
+	     splitting .eh_frame up and using comdat doesn't pan out 
+	     easily due to needing special relocs to handle the
+	     difference of two symbols in separate sections.
+	     Don't keep code sections referenced by .eh_frame.  */
+	  if (o->gc_mark_from_eh && (o->flags & SEC_CODE) == 0)
+	    {
+	      if (strncmp (o->name, ".gcc_except_table.", 18) == 0)
+		{
+		  unsigned long len;
+		  char *fn_name;
+		  asection *fn_text;
+
+		  len = strlen (o->name + 18) + 1;
+		  fn_name = bfd_malloc (len + 6);
+		  if (fn_name == NULL)
+		    return FALSE;
+		  memcpy (fn_name, ".text.", 6);
+		  memcpy (fn_name + 6, o->name + 18, len);
+		  fn_text = bfd_get_section_by_name (sub, fn_name);
+		  free (fn_name);
+		  if (fn_text != NULL && fn_text->gc_mark)
+		    o->gc_mark = 1;
+		}
+
+	      /* If not using specially named exception table section,
+		 then keep whatever we are using.  */
+	      else
+		o->gc_mark = 1;
+
+	      if (o->gc_mark)
+		continue;
+	    }
+
 	  /* Skip sweeping sections already excluded.  */
 	  if (o->flags & SEC_EXCLUDE)
 	    continue;
@@ -9123,18 +9164,9 @@ bfd_elf_gc_sections (bfd *abfd, struct b
 	continue;
 
       for (o = sub->sections; o != NULL; o = o->next)
-	{
-	  if (o->flags & SEC_KEEP)
-	    {
-	      /* _bfd_elf_discard_section_eh_frame knows how to discard
-		 orphaned FDEs so don't mark sections referenced by the
-		 EH frame section.  */
-	      if (strcmp (o->name, ".eh_frame") == 0)
-		o->gc_mark = 1;
-	      else if (!_bfd_elf_gc_mark (info, o, gc_mark_hook))
-		return FALSE;
-	    }
-	}
+	if ((o->flags & SEC_KEEP) != 0 && !o->gc_mark)
+	  if (!_bfd_elf_gc_mark (info, o, gc_mark_hook))
+	    return FALSE;
     }
 
   /* ... and mark SEC_EXCLUDE for those that go.  */
Index: bfd/section.c
===================================================================
RCS file: /cvs/src/src/bfd/section.c,v
retrieving revision 1.88
diff -u -p -r1.88 section.c
--- bfd/section.c	17 May 2005 19:44:55 -0000	1.88
+++ bfd/section.c	29 Jun 2005 13:02:16 -0000
@@ -354,8 +354,9 @@ CODE_FRAGMENT
 .     output sections that have an input section.  *}
 .  unsigned int linker_has_input : 1;
 .
-.  {* A mark flag used by some linker backends for garbage collection.  *}
+.  {* Mark flags used by some linker backends for garbage collection.  *}
 .  unsigned int gc_mark : 1;
+.  unsigned int gc_mark_from_eh : 1;
 .
 .  {* The following flags are used by the ELF linker. *}
 .
@@ -661,18 +662,18 @@ static const asymbol global_syms[] =
 
 #define STD_SECTION(SEC, FLAGS, SYM, NAME, IDX)				\
   const asymbol * const SYM = (asymbol *) &global_syms[IDX]; 		\
-  asection SEC = 							\
+  asection SEC =							\
     /* name, id,  index, next, prev, flags, user_set_vma,            */	\
     { NAME,  IDX, 0,     NULL, NULL, FLAGS, 0,				\
 									\
-    /* linker_mark, linker_has_input, gc_mark, segment_mark,         */	\
+    /* linker_mark, linker_has_input, gc_mark, gc_mark_from_eh,      */	\
        0,           0,                1,       0,			\
 									\
-    /* sec_info_type, use_rela_p, has_tls_reloc, has_gp_reloc,       */ \
-       0,	      0,	  0,		 0,			\
+    /* segment_mark, sec_info_type, use_rela_p, has_tls_reloc,       */	\
+       0,            0,             0,          0,			\
 									\
-    /* need_finalize_relax, reloc_done,                              */ \
-       0,		    0,						\
+    /* has_gp_reloc, need_finalize_relax, reloc_done,                */	\
+       0,            0,                   0,				\
 									\
     /* vma, lma, size, rawsize                                       */	\
        0,   0,   0,    0,						\
@@ -686,8 +687,8 @@ static const asymbol global_syms[] =
     /* line_filepos, userdata, contents, lineno, lineno_count,       */	\
        0,            NULL,     NULL,     NULL,   0,			\
 									\
-    /* entsize, kept_section, moving_line_filepos,	           */	\
-       0,       NULL,	      0,					\
+    /* entsize, kept_section, moving_line_filepos,                   */	\
+       0,       NULL,         0,					\
 									\
     /* target_index, used_by_bfd, constructor_chain, owner,          */	\
        0,            NULL,        NULL,              NULL,		\
Index: bfd/ecoff.c
===================================================================
RCS file: /cvs/src/src/bfd/ecoff.c,v
retrieving revision 1.45
diff -u -p -r1.45 ecoff.c
--- bfd/ecoff.c	4 May 2005 15:53:07 -0000	1.45
+++ bfd/ecoff.c	29 Jun 2005 13:02:04 -0000
@@ -54,12 +54,12 @@ static asection bfd_debug_section =
 {
   /* name,      id,  index, next, prev, flags, user_set_vma,       */
      "*DEBUG*", 0,   0,     NULL, NULL, 0,     0,
-  /* linker_mark, linker_has_input, gc_mark, segment_mark,         */
-     0,           0,                0,       0,
-  /* sec_info_type, use_rela_p, has_tls_reloc, has_gp_reloc,       */
-     0,		    0,		0,	       0,
-  /* need_finalize_relax, reloc_done,                              */
-     0,			  0,
+  /* linker_mark, linker_has_input, gc_mark, gc_mark_from_eh,      */
+     0,           0,                1,       0,
+  /* segment_mark, sec_info_type, use_rela_p, has_tls_reloc,       */
+     0,            0,             0,          0,
+  /* has_gp_reloc, need_finalize_relax, reloc_done,                */
+     0,            0,                   0,
   /* vma, lma, size, rawsize,                                      */
      0,   0,   0,    0,
   /* output_offset, output_section, alignment_power,               */
@@ -68,7 +68,7 @@ static asection bfd_debug_section =
      NULL,       NULL,        0,           0,       0,
   /* line_filepos, userdata, contents, lineno, lineno_count,       */
      0,            NULL,     NULL,     NULL,   0,
-  /* entsize, kept_section, moving_line_filepos,	           */
+  /* entsize, kept_section, moving_line_filepos,                   */
      0,       NULL,         0,
   /* target_index, used_by_bfd, constructor_chain, owner,          */
      0,            NULL,        NULL,              NULL,
Index: ld/scripttempl/elf.sc
===================================================================
RCS file: /cvs/src/src/ld/scripttempl/elf.sc,v
retrieving revision 1.59
diff -u -p -r1.59 elf.sc
--- ld/scripttempl/elf.sc	10 Jun 2005 00:39:56 -0000	1.59
+++ ld/scripttempl/elf.sc	29 Jun 2005 13:02:21 -0000
@@ -329,7 +329,7 @@ cat <<EOF
   ${OTHER_READONLY_SECTIONS}
   .eh_frame_hdr : { *(.eh_frame_hdr) }
   .eh_frame     ${RELOCATING-0} : ONLY_IF_RO { KEEP (*(.eh_frame)) }
-  .gcc_except_table ${RELOCATING-0} : ONLY_IF_RO { KEEP (*(.gcc_except_table)) *(.gcc_except_table.*) }
+  .gcc_except_table ${RELOCATING-0} : ONLY_IF_RO { *(.gcc_except_table .gcc_except_table.*) }
 
   /* Adjust the address for the data segment.  We want to adjust up to
      the same address within the page on the next page up.  */
@@ -339,7 +339,7 @@ cat <<EOF
 
   /* Exception handling  */
   .eh_frame     ${RELOCATING-0} : ONLY_IF_RW { KEEP (*(.eh_frame)) }
-  .gcc_except_table ${RELOCATING-0} : ONLY_IF_RW { KEEP (*(.gcc_except_table)) *(.gcc_except_table.*) }
+  .gcc_except_table ${RELOCATING-0} : ONLY_IF_RW { *(.gcc_except_table .gcc_except_table.*) }
 
   /* Thread Local Storage sections  */
   .tdata	${RELOCATING-0} : { *(.tdata${RELOCATING+ .tdata.* .gnu.linkonce.td.*}) }

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: gc sections and .eh_frame

[Jonathan Larmour]

Alan Modra wrote:
> On Wed, Jun 29, 2005 at 10:54:01AM +0930, Alan Modra wrote:
> 
>>I think we can do without it by marking sections
>>referenced from .eh_frame specially, and keeping them iff the associated
>>.text section is marked.
> 
> 
> Committing mainline.
> 
> bfd/
> 	* elflink.c (_bfd_elf_gc_mark): Mark sections referenced by
> 	.eh_frame specially..
> 	(bfd_elf_gc_sections): ..rather than totally ignoring .eh_frame.
> 	Don't recheck sections we have already marked.
> 	(elf_gc_sweep): Keep non-code sections referenced from .eh_frame.
> 	* section.c (struct bfd_section): Add gc_mark_from_eh.
> 	(STD_SECTION): Adjust.
> 	* ecoff.c (bfd_debug_section): Adjust.
> 	* bfd-in2.h: Regenerate.
> 
> ld/
> 	* scripttempl/elf.sc (.gcc_except_table): Don't KEEP.

I updated my sources to current binutils CVS and rebuuilt my 
powerpc-eabi-ld. Unfortunately I now get the following when linking an 
application that uses C++ exceptions:
`DW.ref._ZTISt9exception' referenced in section `.rodata' of 
/local/builds/toolchains/powerpc-eabi/tools/lib/gcc/powerpc-eabi/3.4.4/../../../../powerpc-eabi/lib/nof/libsupc++.a(vterminate.o): 
defined in discarded section `.gnu.linkonce.s.DW.ref._ZTISt9exception' of 
/local/builds/toolchains/powerpc-eabi/tools/lib/gcc/powerpc-eabi/3.4.4/../../../../powerpc-eabi/lib/nof/libsupc++.a(vterminate.o)collect2: 
ld returned 1 exit status

I'll have a closer look tomorrow, although my hunch is that it's something 
to do with being a .gnu.linkonce section specifically - possibly there are 
multiple instances of that section name, and only one is marked to be 
kept, but when duplicate .gnu.linkonce sections are removed, it is the 
other instance that is kept, and later when GC happens, even that one is 
removed.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: gc sections and .eh_frame

[Alan Modra]

On Wed, Jun 29, 2005 at 11:31:02PM +0100, Jonathan Larmour wrote:
> I updated my sources to current binutils CVS and rebuuilt my 
> powerpc-eabi-ld. Unfortunately I now get the following when linking an 
> application that uses C++ exceptions:
> `DW.ref._ZTISt9exception' referenced in section `.rodata' of 
> /local/builds/toolchains/powerpc-eabi/tools/lib/gcc/powerpc-eabi/3.4.4/../../../../powerpc-eabi/lib/nof/libsupc++.a(vterminate.o): 
> defined in discarded section `.gnu.linkonce.s.DW.ref._ZTISt9exception' of 
> /local/builds/toolchains/powerpc-eabi/tools/lib/gcc/powerpc-eabi/3.4.4/../../../../powerpc-eabi/lib/nof/libsupc++.a(vterminate.o)collect2: 
> ld returned 1 exit status
> 
> I'll have a closer look tomorrow, although my hunch is that it's something 
> to do with being a .gnu.linkonce section specifically - possibly there are 

Yes.

> multiple instances of that section name, and only one is marked to be 
> kept, but when duplicate .gnu.linkonce sections are removed, it is the 
> other instance that is kept, and later when GC happens, even that one is 
> removed.

No, GC isn't removing too many sections.  The problem is that .eh_frame,
.gcc_exception_table, debug sections, and other sections on some targets
are not split per-function.  When linkonce sections are removed, you are
left with references from these sections to the removed sections.  The
linker knows this happens for certain section names, so doesn't warn,
but powerpc has been using .rodata instead of .gcc_exception_table..
A workaround is to link with --noinhibit-exec.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: gc sections and .eh_frame

[Jonathan Larmour]

Alan Modra wrote:
> On Wed, Jun 29, 2005 at 11:31:02PM +0100, Jonathan Larmour wrote:
> 
>>I updated my sources to current binutils CVS and rebuuilt my 
>>powerpc-eabi-ld. Unfortunately I now get the following when linking an 
>>application that uses C++ exceptions:
>>`DW.ref._ZTISt9exception' referenced in section `.rodata' of 
>>/local/builds/toolchains/powerpc-eabi/tools/lib/gcc/powerpc-eabi/3.4.4/../../../../powerpc-eabi/lib/nof/libsupc++.a(vterminate.o): 
>>defined in discarded section `.gnu.linkonce.s.DW.ref._ZTISt9exception' of 
>>/local/builds/toolchains/powerpc-eabi/tools/lib/gcc/powerpc-eabi/3.4.4/../../../../powerpc-eabi/lib/nof/libsupc++.a(vterminate.o)collect2: 
>>ld returned 1 exit status
[snip]
>>multiple instances of that section name, and only one is marked to be 
>>kept, but when duplicate .gnu.linkonce sections are removed, it is the 
>>other instance that is kept, and later when GC happens, even that one is 
>>removed.
> 
> 
> No, GC isn't removing too many sections.  The problem is that .eh_frame,
> .gcc_exception_table, debug sections, and other sections on some targets
> are not split per-function.  When linkonce sections are removed, you are
> left with references from these sections to the removed sections.  The
> linker knows this happens for certain section names, so doesn't warn,
> but powerpc has been using .rodata instead of .gcc_exception_table..

Thanks for the explanation. I see that now.

Unfortunately it doesn't leave any sysv4 powerpc target users (including 
powerpc-linux as you said before) much better off, since the GCC change to 
stop using .rodata hasn't even been committed to the trunk yet, nevermind 
any current release branches, and won't be widely disseminated until a 
while after that. Well, they're slightly better off since at least they 
now get an error rather than silent failure :-).

But I've even less of an idea of how this could be addressed in binutils. 
The only way I can think of to identify the problematic powerpc GCC is the 
presence of .eh_frame with an absence of .gcc_except_table, and putting 
that knowledge in place in elf_link_input_bfd is a bit of a kludge. Any 
other ideas?

> A workaround is to link with --noinhibit-exec.

Ick. I'm sure we should be recommending something better than that.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: gc sections and .eh_frame

[Alan Modra]

On Fri, Jul 01, 2005 at 02:31:44PM +0100, Jonathan Larmour wrote:
> >A workaround is to link with --noinhibit-exec.
> 
> Ick. I'm sure we should be recommending something better than that.

The reason I haven't worried too much is that --gc-sections doing
anything on dynamic executables is a relatively new feature.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: gc sections and .eh_frame

[Jonathan Larmour]

Alan Modra wrote:
> On Fri, Jul 01, 2005 at 02:31:44PM +0100, Jonathan Larmour wrote:
> 
>>>A workaround is to link with --noinhibit-exec.
>>
>>Ick. I'm sure we should be recommending something better than that.
> 
> 
> The reason I haven't worried too much is that --gc-sections doing
> anything on dynamic executables is a relatively new feature.

Ah well, we (the eCos project), have been using it on static builds for 
embedded targets since before it was publically released (it was written 
for us) :-). 1998 I think. powerpc-eabi was one of the first.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: gc sections and .eh_frame

[Alan Modra]

I've been playing with enabling gc-sections for shared libs, and hit
a problem with the way .gcc_except_table is handled.  We were keeping
.gcc_except_table itself, but not sections referenced from there.

	* elflink.c (elf_gc_sweep): Move gcc_except_table code..
	(bfd_elf_gc_sections): ..to here.

Index: bfd/elflink.c
===================================================================
RCS file: /cvs/src/src/bfd/elflink.c,v
retrieving revision 1.179
diff -u -p -r1.179 elflink.c
--- bfd/elflink.c	25 Jul 2005 15:35:37 -0000	1.179
+++ bfd/elflink.c	26 Jul 2005 10:58:51 -0000
@@ -8912,41 +8912,6 @@ elf_gc_sweep (struct bfd_link_info *info
 	  if (o->gc_mark)
 	    continue;
 
-	  /* Keep .gcc_except_table.* if the associated .text.* is
-	     marked.  This isn't very nice, but the proper solution,
-	     splitting .eh_frame up and using comdat doesn't pan out 
-	     easily due to needing special relocs to handle the
-	     difference of two symbols in separate sections.
-	     Don't keep code sections referenced by .eh_frame.  */
-	  if (o->gc_mark_from_eh && (o->flags & SEC_CODE) == 0)
-	    {
-	      if (strncmp (o->name, ".gcc_except_table.", 18) == 0)
-		{
-		  unsigned long len;
-		  char *fn_name;
-		  asection *fn_text;
-
-		  len = strlen (o->name + 18) + 1;
-		  fn_name = bfd_malloc (len + 6);
-		  if (fn_name == NULL)
-		    return FALSE;
-		  memcpy (fn_name, ".text.", 6);
-		  memcpy (fn_name + 6, o->name + 18, len);
-		  fn_text = bfd_get_section_by_name (sub, fn_name);
-		  free (fn_name);
-		  if (fn_text != NULL && fn_text->gc_mark)
-		    o->gc_mark = 1;
-		}
-
-	      /* If not using specially named exception table section,
-		 then keep whatever we are using.  */
-	      else
-		o->gc_mark = 1;
-
-	      if (o->gc_mark)
-		continue;
-	    }
-
 	  /* Skip sweeping sections already excluded.  */
 	  if (o->flags & SEC_EXCLUDE)
 	    continue;
@@ -9183,6 +9151,48 @@ bfd_elf_gc_sections (bfd *abfd, struct b
 	    return FALSE;
     }
 
+  /* ... again for sections marked from eh_frame.  */
+  for (sub = info->input_bfds; sub != NULL; sub = sub->link_next)
+    {
+      asection *o;
+
+      if (bfd_get_flavour (sub) != bfd_target_elf_flavour)
+	continue;
+
+      /* Keep .gcc_except_table.* if the associated .text.* is
+	 marked.  This isn't very nice, but the proper solution,
+	 splitting .eh_frame up and using comdat doesn't pan out 
+	 easily due to needing special relocs to handle the
+	 difference of two symbols in separate sections.
+	 Don't keep code sections referenced by .eh_frame.  */
+      for (o = sub->sections; o != NULL; o = o->next)
+	if (!o->gc_mark && o->gc_mark_from_eh && (o->flags & SEC_CODE) == 0)
+	  {
+	    if (strncmp (o->name, ".gcc_except_table.", 18) == 0)
+	      {
+		unsigned long len;
+		char *fn_name;
+		asection *fn_text;
+
+		len = strlen (o->name + 18) + 1;
+		fn_name = bfd_malloc (len + 6);
+		if (fn_name == NULL)
+		  return FALSE;
+		memcpy (fn_name, ".text.", 6);
+		memcpy (fn_name + 6, o->name + 18, len);
+		fn_text = bfd_get_section_by_name (sub, fn_name);
+		free (fn_name);
+		if (fn_text == NULL || !fn_text->gc_mark)
+		  continue;
+	      }
+
+	    /* If not using specially named exception table section,
+	       then keep whatever we are using.  */
+	    if (!_bfd_elf_gc_mark (info, o, gc_mark_hook))
+	      return FALSE;
+	  }
+    }
+
   /* ... and mark SEC_EXCLUDE for those that go.  */
   if (!elf_gc_sweep (info, get_elf_backend_data (abfd)->gc_sweep_hook))
     return FALSE;

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: gc sections and .eh_frame

[Alan Modra]

On Tue, Jul 26, 2005 at 08:59:47PM +0930, Alan Modra wrote:
> I've been playing with enabling gc-sections for shared libs, and hit
> a problem with the way .gcc_except_table is handled.  We were keeping
> .gcc_except_table itself, but not sections referenced from there.

I should have said that this problem likely affects dynamic apps too.
The code to do gc-sections when building shared libs is like this:

	* elflink.c (elf_gc_mark_dynamic_ref_symbol): Handle -shared.
	(bfd_elf_gc_sections): Allow -gc-sections when -shared.
	* elf32-ppc.c (ppc_elf_gc_sweep_hook): Correct for -shared.

Index: bfd/elflink.c
===================================================================
RCS file: /cvs/src/src/bfd/elflink.c,v
retrieving revision 1.179
diff -u -p -r1.179 elflink.c
--- bfd/elflink.c	25 Jul 2005 15:35:37 -0000	1.179
+++ bfd/elflink.c	26 Jul 2005 10:58:51 -0000
@@ -9107,19 +9072,25 @@ elf_gc_smash_unused_vtentry_relocs (stru
   return TRUE;
 }
 
-/* Mark sections containing dynamically referenced symbols.  This is called
-   through elf_link_hash_traverse.  */
+/* Mark sections containing dynamically referenced symbols.  When
+   building shared libraries, we must assume that any visible symbol is
+   referenced.  */
 
 static bfd_boolean
-elf_gc_mark_dynamic_ref_symbol (struct elf_link_hash_entry *h,
-				void *okp ATTRIBUTE_UNUSED)
+elf_gc_mark_dynamic_ref_symbol (struct elf_link_hash_entry *h, void *inf)
 {
+  struct bfd_link_info *info = (struct bfd_link_info *) inf;
+
   if (h->root.type == bfd_link_hash_warning)
     h = (struct elf_link_hash_entry *) h->root.u.i.link;
 
   if ((h->root.type == bfd_link_hash_defined
        || h->root.type == bfd_link_hash_defweak)
-      && h->ref_dynamic)
+      && (h->ref_dynamic
+	  || (info->shared
+	      && h->def_regular
+	      && ELF_ST_VISIBILITY (h->other) != STV_INTERNAL
+	      && ELF_ST_VISIBILITY (h->other) != STV_HIDDEN)))
     h->root.u.def.section->flags |= SEC_KEEP;
 
   return TRUE;
@@ -9139,7 +9110,6 @@ bfd_elf_gc_sections (bfd *abfd, struct b
   if (!get_elf_backend_data (abfd)->can_gc_sections
       || info->relocatable
       || info->emitrelocations
-      || info->shared
       || !is_elf_hash_table (info->hash))
     {
       (*_bfd_error_handler)(_("Warning: gc-sections option ignored"));
@@ -9164,9 +9134,7 @@ bfd_elf_gc_sections (bfd *abfd, struct b
   if (elf_hash_table (info)->dynamic_sections_created)
     elf_link_hash_traverse (elf_hash_table (info),
 			    elf_gc_mark_dynamic_ref_symbol,
-			    &ok);
-  if (!ok)
-    return FALSE;
+			    info);
 
   /* Grovel through relocs to find out who stays ...  */
   gc_mark_hook = get_elf_backend_data (abfd)->gc_mark_hook;
Index: bfd/elf32-ppc.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-ppc.c,v
retrieving revision 1.174
diff -u -p -r1.174 elf32-ppc.c
--- bfd/elf32-ppc.c	16 Jul 2005 03:30:23 -0000	1.174
+++ bfd/elf32-ppc.c	26 Jul 2005 10:58:46 -0000
@@ -3728,8 +3778,12 @@ ppc_elf_gc_sweep_hook (bfd *abfd,
 	case R_PPC_ADDR14_BRNTAKEN:
 	case R_PPC_UADDR32:
 	case R_PPC_UADDR16:
+	  if (info->shared)
+	    break;
+
 	case R_PPC_PLT32:
 	case R_PPC_PLTREL24:
+	case R_PPC_PLTREL32:
 	case R_PPC_PLT16_LO:
 	case R_PPC_PLT16_HI:
 	case R_PPC_PLT16_HA:


-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: gc sections and .eh_frame

[Jim Blandy]

Alan Modra <amodra@bigpond.net.au> writes:
> I've been playing with enabling gc-sections for shared libs, and hit
> a problem with the way .gcc_except_table is handled.  We were keeping
> .gcc_except_table itself, but not sections referenced from there.

If I'm understanding the whole saga here correctly, then one way of
describing what makes section GC interact with exception tables so
oddly is that the relocs point backwards from the way they normally
do.

That is, normally, if the GC keeps some section A, and A has relocs
referring to (symbols defined in) some section B, then the GC should
also keep B.  Conversely, if there are no kept sections with relocs
referring to B, then B should be dropped.

For exception handling tables, however, the relocs point in the
opposite direction: if the GC keeps some code section A, and some
exception table B has relocs referring to A, then the GC should also
keep B.  Conversely, if there are no kept code sections that an
exception table B has relocs referring to, then B should be dropped.

Not that folks don't already know this; I just thought it was a
helpfully clear way to describe things.

Re: gc sections and .eh_frame

[Alan Modra]

On Wed, Aug 24, 2005 at 05:04:48PM -0700, Jim Blandy wrote:
> That is, normally, if the GC keeps some section A, and A has relocs
> referring to (symbols defined in) some section B, then the GC should
> also keep B.  Conversely, if there are no kept sections with relocs
> referring to B, then B should be dropped.

Yes, and yes.

> For exception handling tables, however, the relocs point in the
> opposite direction: if the GC keeps some code section A, and some
> exception table B has relocs referring to A, then the GC should also
> keep B.  Conversely, if there are no kept code sections that an
> exception table B has relocs referring to, then B should be dropped.

No.  gc marking of sections referenced from .gcc_except_table* should be
as for any other section.  If we had per-function .eh_frame sections
then there wouldn't be anything special at all about .eh_frame* and
.gcc_except_table*.  ie. relocs in .eh_frame* would reference
.gcc_except_table*.  The trouble is that we have a monolithic .eh_frame,
so we can't treat its relocs normally (and we can't break up .eh_frame
easily, but that's another story).

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre