echristo 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. + }]; ---------------- probinson wrote: > 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. Cool. So in summary: "Ignore this entire thread" :)
http://reviews.llvm.org/D15524 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
