[Bug ld/17931] --gc-sections doesn't work on section in a group

[rafael.espindola at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17931



--- Comment #4 from Rafael Ávila de Espíndola <rafael.espindola a
t gmail dot com> ---

(In reply to Alan Modra from comment #3)

> I hear what you're saying, and accept that gc-sections could be made to w
ork

> for the specific case you present here.  However, I'm unconvinced that we

> should do this in the linker, to work around what appears to be a gcc bug.



I agree that this was originally a gcc bug

(https://sourceware.org/bugzilla/show_bug.cgi?id=17931 for reference), bu
t it

is now an odd abi issue we have to live with.



> We've kept groups together under gc-sections right from the initial

> implementation of section group support in 2001.  The major reason for do
ing

> this is to keep on-the-side sections, eg. debug info, when any of their

> grouped code or data sections are kept.  These on-the-side sections don't

> have relocations from other sections that would cause them to be kept by 
the

> usual gc-sections marking process.  For an example of sections that appear

> in a loaded image, exception handling info, .eh_frame and associated

> sections, is another set of on-the-side sections that a compiler could pl
ace

> in a group (and should instead of relying on ld's eh_frame editing!).



Yes, I would love to have the compiler output multiple .eh_frame sections in

the correct comdat. I have implementing that in llvm in my todo list, but i
t is

low priority since every current linker has to handle the magical .eh_frame.



> Are there similar on-the-side code sections that would prevent us making 
an

> exception for code sections in a group?  I don't know of any, but people 
do

> weird things..



In a world where comdats are fully utilized, the only extra logic that is

needed for GC is that some sections have relocations in the opposite direct
ion:



A .eh_frame should be kept if the function it points to is kept. The same g
oes

for debug info.



It would be nice to have the "reverse reloc dependency" marked explicitly in

the .o file (a new SHF_SIDE_TABLE maybe?), but adding it implicitly to a few

well know sections seems a small cost for extra flexibility.



-- 

You are receiving this mail because:

You are on the CC list for the bug.