probinson added inline comments. ================ Comment at: include/clang/Basic/AttrDocs.td:2371 @@ +2370,3 @@ + +Not all targets support this attribute. ELF targets support this attribute when using binutils v2.20.1 or higher and glibc v2.11.1 or higher. Non-ELF targets currently do not support this attribute. + }]; ---------------- echristo wrote: > probinson wrote: > > joerg wrote: > > > probinson wrote: > > > > echristo wrote: > > > > > rjmccall wrote: > > > > > > echristo wrote: > > > > > > > Probably better to say linux fwiw and not ELF. > > > > > > The validation code in Sema is checking for an ELF target. If the > > > > > > restriction is more precise than that, then we should make a > > > > > > TargetInfo callback. Do the BSDs and other ELF targets not use > > > > > > binutils/glibc? > > > > > We should make a TargetInfo callback. BSDs and other ELF targets > > > > > aren't guaranteed to use binutils/glibc (some of them have even > > > > > switched to llvm already) - and I don't know what the state of ifunc > > > > > support on those architectures is. > > > > Hear hear. PS4 is ELF but we don't use glibc. > > > The attribute is not Linux specific, so ELF is a reasonable first > > > approximation. Most BSDs have some ifunc support at least. I'm not in > > > favor of doing any checks beyond ELF -- even on Linux the availability of > > > working ifunc support depends on other factors like whether the binary is > > > dynamically linked. > > What's the failure mode if the target doesn't actually support it? > The failure mode is an unknown relocation if your linker doesn't support it. > If your linker supports it but your libc doesn't that'll be an unknown > dynamic relocation at program start up. > > In retrospect I think we can leave it just as an ELF check here and go. There > are similar features in Mach-O that we might want this to use at some point > as well so we can leave it as general as possible and rely on downstream > tools to provide more errors? > > I honestly don't have a strong opinion here given the current vaguely broad > platform support and future possibilities. Yeah, we can live with that.
http://reviews.llvm.org/D15524 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
