dwblaikie wrote: > This approahc parallels the strategy used for > [-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang](https://reviews.llvm.org/D125142), > albeit a nicer name.
Fair enough - yeah, if we're wordsmithing this. Maybe "allow" would be a good word, rather than "enable" (or no verb at all), as in `-allow-experimental-crel`? > While ELF allows extension space for processor/OS/application-specific > section types, using them introduces challenges since we want linker errors when SHT_CREL is unsupported (see isKnownSpecificSectionType in https://github.com/llvm/llvm-project/pull/85173): > > [SHT_LOUSER,SHT_HIUSER]: Not applicable as static relocation sections do not > have the SHF_ALLOC flag. I missed a step here - why is this range only applicable for SHF_ALLOC sections? Ah, from the patch you linked earlier, linkers don't fail on SHT_*USER range unless it's allocated... that seems a bit tenuous, though. Seems like this the range intended for this kind of experimentation, with the cost that it doesn't produce an error from existing linkers (though it could, but they're trying to be conservative/allow for extensions that don't need linker-awareness). Guess I'll leave that up to other folks to comment on. > [SHT_LOOS,SHT_HIOS]: Requires annoying SHF_OS_NONCONFORMING. We want psABI > documents to be willing to accept CREL when toolchain becomes ready, > especially if their relocatable files are huge due to linker relaxation (e.g. > RISC-V, LoongArch), we want to avoid GNUism / LLVMism. So in this case each OS would have to allocate their own number in in the SHT_*OS range? Yeah, that seems unfortunate. > [SHT_LOPROC,SHT_HIPROC]: Processor-specific and not applicable. Similar to the *OS case above, I guess. > We will unlikely change the format. I think we should start with the theory that the format will change - even if it doesn't, we wouldn't want to introduce this new thing and avoid change because we've made it hard to change if we discover in early testing that there's things we could do better. > Solaris-specific SHF_ORDERED and SHF_EXCLUDE, without a SunOS/Solaris name > infix/prefix/suffix, make them into glibc elf.h. > SHF_EXCLUDE gets picked due to its linker semantics but SHF_ORDERED is never > used. > A generic name SHT_CREL might not be fundamentally different from SHF_EXCLUDE. Got links to the history here, about how SHF_ORDERED/EXCLUDE came to be? https://github.com/llvm/llvm-project/pull/91280 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
