[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: rafael.espindola at gmail dot com
Subject: [Bug ld/17931] --gc-sections doesn't work on section in a group
Date: Thu, 12 Feb 2015 15:41:09 +0000


--- 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

> 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

> 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 

> 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

> 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 

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

> 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

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]