Re: gc sections and .eh_frame

[Jonathan Larmour <jifl@eCosCentric.com>]

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