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


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


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