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