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