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

[Joerg Sonnenberger via cfe-commits]

joerg added a subscriber: joerg.

================
Comment at: include/clang/Basic/AttrDocs.td:2066
@@ -2065,3 +2065,3 @@
   let Content = [{
 Clang supports the GNU style ``__attribute__((interrupt))`` attribute on
 x86/x86-64 targets.The compiler generates function entry and exit sequences
----------------
I'd really prefer such checks to be more strict, meaning:


  # It can return a `void *` pointer, no further signature checks are done
  # It can be a function pointer. In that case, it must match the signature of the function declaration the attribute is on.

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


http://reviews.llvm.org/D15524