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. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
