This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gc sections and .eh_frame


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]