Summary: | Add option to produce a unique section for non-COMDAT __attribute__((section("foo"))) object | ||
---|---|---|---|
Product: | gcc | Reporter: | Fangrui Song <i> |
Component: | c++ | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | paul_robinson, webrown.cpp |
Priority: | P3 | ||
Version: | unknown | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Known to work: | ||
Known to fail: | Last reconfirmed: |
Description
Fangrui Song
2023-02-11 07:33:08 UTC
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. |