% cat a.cc __attribute__((section("foo"))) void f() {} __attribute__((section("foo"))) void g() {} % g++ -c -ffunction-sections a.cc % readelf -WS a.o | grep foo [ 4] foo PROGBITS 0000000000000000 000040 00000e 00 AX 0 0 1 There is one section named `foo`, with f and g in it (they do not use COMDAT). In ld --gc-sections, f and g are retained or discarded as a unit. If we place f and g in two `foo` sections, --gc-sections can discard them separately. (We need assembler syntax `.section foo,"ax",@progbits,unique,1` which requires binutils>=2.35.) https://reviews.llvm.org/D143745 proposes to add such a feature with an option name like `-ffunction-sections[=(default,all)]`. I feel that the option argument is non-intuitive but do not come up with a better name right now. I raise this feature request to seek feedback from GCC :)
I think an option would be the wrong appoarch because many of the times, you are marking a variable inside a section exactly because you want it to be part of an "array". I think rather section should have a secondary argument which mark as needing to append the function name on it ...
(In reply to Andrew Pinski from comment #1) > I think rather section should have a secondary argument which mark as > needing to append the function name on it ... s/function name/decl assembly name/
New syntax setting the flags will be useful. Also, currently there is no way to customize the section type.
(In reply to Andrew Pinski from comment #1) > I think an option would be the wrong appoarch because many of the times, you > are marking a variable inside a section exactly because you want it to be > part of an "array". I think distinct options for -ffunction-sections and -fdata-sections would be the answer to that. I mean, we _already_ have separation options, so handling code and data independently makes sense. > I think rather section should have a secondary argument which mark as > needing to append the function name on it ... I believe the linker will not take an input with sections "foo.f" and "foo.g" and concatenate them into a single "foo" section in the linked object. That special behavior works only for standard sections like .text AFAIK. The Clang change proposes using section groups instead, so the final section has the name the user specified. I don't know whether this would work for non-ELF object formats. I suspect COFF would be okay, as it has no-deduplicate COMDAT.
Modifying the syntax of the attribute won't help users who are importing code from a third party, but still want to do dead-stripping/deduplication.
(In reply to Paul Robinson from comment #5) > Modifying the syntax of the attribute won't help users who are importing > code from a third party, but still want to do dead-stripping/deduplication. And it might break code from third party with that option, that was my point.
Okay. I'm persuaded this is not a great idea, and I'll solve the customer's problem another way.