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



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to