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