MaskRay added a comment. In D96838#2578097 <https://reviews.llvm.org/D96838#2578097>, @rjmccall wrote:
> In D96838#2578083 <https://reviews.llvm.org/D96838#2578083>, @MaskRay wrote: > >> In D96838#2578073 <https://reviews.llvm.org/D96838#2578073>, @rjmccall wrote: >> >>> GCC 11 hasn't been released yet, so can we still engage with GCC about the >>> semantics of this attribute? This is a very low-level attribute, and I >>> don't understand why it was made separate instead of just having `used` add >>> the appropriate section flag on targets that support it. >> >> GCC did overload `used` with the linker garbage collection semantics. Then >> after discussions (e.g. >> https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565478.html) they >> decided to pick the earliest suggestion: add `retain`. >> >> This makes sense to me: `used` can emit a function which is only used by >> inline assembly, but the user intention can still be that the whole thing >> can be GCable. > > There's definitely some merit to distinguishing the cases here — `used` > doesn't just force the object to be emitted, it also forces the compiler to > treat it as if there might be accesses to the variable / function that it > can't see. Thus, for example, a non-const `used` variable has to be assumed > to be potentially mutated in arbitrary ways. I guess my concern is that this > new attribute still doesn't feel like it covers the use cases very well, > especially because `used` does have long-established semantics of affecting > the linker on non-ELF targets. Basically, to get "full strength" semantics > that affect the compiler and linker on all targets, you have to add a new > attribute; Yes. > to get "partial strength" semantics that only affect the compiler, you can > use the old attribute on ELF, but there's no way to spell it on non-ELF; and > if you wanted to get "weak" semantics (e.g. to force the symbol to be > preserved through linking without broadly disabling the optimizer), there's > no way to spell that anywhere. The semantics can be represented on non-ELF, as long as the binary format supports multiple sections of the same name. Garbage collection is done at section level on both ELF and PE-COFF. On ELF, GCC developers decided that a single `used` making the monolithic `.data`/`.text` retained loses GC preciseness and is not a good tradeoff. (I agree) So they let the `used` object be placed in a separate section. There may be multiple sections of the same name, even in -fno-function-sections -fno-data-sections mode. .section .text,"ax",@progbits ... .section .text,"axR",@progbits,unique,1 ... This uncovered a Linux kernel problem (I'd say it is that the Linux kernel's linker scripts relies on too much on a not-entirely-guaranteed behavior) http://gcc.gnu.org/PR99113 Their later discussion revealed that separation of concerns is good. So they re-picked the `retain` idea. If PE-COFF wants to pick up the idea, it can do that for external linkage symbols: it can let `retain` create a separate section with `/INCLUDE:foo` in `.drectve`. For an internal linkage symbol, I think that is likely non-representable in the binary format. (maybe rnk can correct me:) ) If PE-COFF decides to do this, perhaps it should revisit whether `used` should set `/INCLUDE:foo` as well, as it can nearly match ELF semantics. For macOS, it can make `retain` pick up the `N_NO_DEAD_STRIP` behavior if it wants to match ELF. Though the current `uses` already retains the subsection. > Seems like if we're going to the trouble of adding an attribute, that's not > the situation we want to end up in. >> IIUC macOS's always enabled `.subsections_via_symbols` means always >> -ffunction-sections/-fdata-sections, so there is no GC preciseness concern. > > Yes, the MachO linker will aggressively dead-strip, and `used` prevents that. > >> However, the current Windows behavior (`.drectve` include a linker option to >> force retaining the whole section) can unnecessarily retain the full >> section, in -fno-function-sections or -fno-data-sections mode. > > But that Windows behavior is a limitation of the format rather than an intent > to provide different semantics on different targets, I'd say. It is a limitation for internal symbols. But for external symbols it can fully match ELF. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D96838/new/ https://reviews.llvm.org/D96838 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
