[libc-commits] [PATCH] D71094: [libc] Add implementation of errno and define the other macros of errno.h.

Siva Chandra via Phabricator via libc-commits libc-commits at lists.llvm.org
Fri Dec 6 01:13:31 PST 2019


sivachandra marked 2 inline comments as done.
sivachandra added inline comments.


================
Comment at: libc/config/linux/api.td:34
+  let Defn = [{
+    int *__errno_location() __attribute__((const));
+    #define errno *__errno_location()
----------------
abrachet wrote:
> I don't have a Windows machine to test this, but from godbolt, `__attribute__`'s seem to be unrecognized by MSVC or at least const was not a known one. I see other libcs conditionally defining (on `__GNUC__` according to @MaskRay) an `__attribute_const` or something like that.
> 
> FWIW I don't favor adding this attribute. How useful will this even be really?
We are adding the attribute in a Linux only file so should not be a problem because Clang and GCC on Linux support on this attribute?


================
Comment at: libc/src/errno/llvmlibc_errno.h:14
+// public header.
+extern int &llvmlibc_errno;
+
----------------
MaskRay wrote:
> sivachandra wrote:
> > abrachet wrote:
> > > MaskRay wrote:
> > > > I don't think this will work. In the test translation unit, the compiler does not know that `llvmlibc_errno` is bound to a thread-local variable.
> > > > 
> > > > Even in the definition site, it's not clear to me that a reference to a thread-local variable will guarantee to work.
> > > Right, it must be `thread_local int &`. I've tested it only briefly, if the reference isn't `thread_local` it doesn't work. As far as I can tell `thread_local int &` works.
> > > 
> > > 
> > Sigh yes. This declaration has to include `thread_local` for everything to work correctly. Will update in the next round.
> But why do we need a thread_local reference in the first place? It is represented as a thread_local pointer that is initialized to the return address of a TLS wrapper function under the hood. You can check the codegen. The performance is bad.
I did not consider codegen. So yes, the macro wins over the reference if you look at the codegen.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71094/new/

https://reviews.llvm.org/D71094





More information about the libc-commits mailing list