[PATCH] D15524: [GCC] Attribute ifunc support in clang

[Eric Christopher via cfe-commits]

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:
> 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.


http://reviews.llvm.org/D15524