Hello! This is a combined report for both week 3 and 4.<\/p>\n
In these two weeks I’ve fixed several issues in LLVM libc, but quite a
\nlot of time has also been spent purely learning things. I will start
\nby going over what I’ve learned, and then refer to related issues.<\/p>\n
<\/p>\n
To start with I have gotten quite comfortable with CVise, how to use
\nit and general tricks about writing the test script for determining
\nwhether the issue is still there after reducing a source file. For
\nexample, I had an issue about a the print format macro PRId64 not
\nbeing defined on LLVM libc<\/p>\n
This caused an error that looked like this:<\/p>\n
So my first attempt of reducing was to grep for “expected ‘)'”. This To actually fix this issue I filed a bug https:\/\/reviews.llvm.org\/D152979<\/a> The next thing I’ve learned a lot about is C++ and standard C header I first ran into this when pulling new commits from master and rebuilt This time it was an error about wint_t not being defined:<\/p>\n The issue here arrises because LLVM libc’s llvm-libc-types\/wint_t.h This depends on internal behaviour of the stddef.h header. Because glibc uses __need_wint_t to make stddef.h define wint_t, while musl However, somehow \/usr\/include is higher up in the include order than —<\/p>\n Another thing I have worked on is to replace some __unix__ ifdef I have fixed this here: https:\/\/reviews.llvm.org\/D153729#4447435<\/a>, but I will therefore go back and define these for macOS later.<\/p>\n I have also done some work on upstreaming things needed for Python As fopen is already implemented the hard part was not the function This is not upstreamed yet but I am working on it here The other thing I want to get upstreamed is the limits.h header, in my —<\/p>\n That’s all the big things, I also continued work on Python, fixed some —<\/p>\n Next week I will work on getting Clang\/LLVM supported in – — Hello! This is a combined report for both week 3 and 4. In these two weeks I’ve fixed several issues in LLVM libc, but quite a lot of time has also been spent purely learning things. I will start by … Continue reading \/home\/cat\/c\/llvm-project\/compiler-rt\/lib\/scudo\/standalone\/timing.h:182:22: error: expected ')'
\n Str.append(\"%14\" PRId64 \".%\" PRId64 \"(ns) %-11s\", Integral, Fraction, \" \");<\/code><\/p>\n
\nwent on to reduce the source file to simply: “(“. Maybe not the most
\ninteresting thing, but it was the “aha-moment” for me with regards to
\nCVise, because what it did with the test script became clear.<\/p>\n
\nhttps:\/\/github.com\/llvm\/llvm-project\/issues\/63317<\/a> and got told by a
\ncompiler-rt developer that the timing.cpp file is only used for
\nperformance evaluation. So the temporary fix I made was to exclude it
\nfrom the build by checking for LLVM_LIBC_INCLUDE_SCUDO=ON in CMake
\nuntil the print format macros are added to LLVM libc.<\/p>\n
\nhttps:\/\/github.com\/llvm\/llvm-project\/commit\/63eb7c4e6620279c63bd42d13177a94928cabb3c<\/a><\/p>\n
\ninteroperability, or “include hell”. I learned about the differences
\nbetween C++ standard headers like “cwhatever” and “whatever.h”, also
\nwhat #include_next did, and also that compilers ship their own header
\nfiles like stddef.h and inttypes.h.<\/p>\n
\nLLVM libc, thinking that the errors were related to this. Weirdly
\nenough the original error just went away, and I couldn’t reproduce it
\nat all. But I quickly ran in to a similar issue when compiling LLVM
\nlibc in fullbuild mode on a llvm\/musl system.<\/p>\n> \/llvm-project\/build-libc-full\/projects\/libc\/include\/wchar.h:21:11: error: unknown type name 'wint_t'
\n> int wctob(wint_t) __NOEXCEPT;<\/code><\/p>\n
\ngets the wint_t type using:<\/p>\n> #define __need_wint_t
\n> #include
\n> #undef __need_wint_t<\/code><\/p>\n
\nthis is C++ it will include in this case libc++’s stddef.h, but this
\n#include_next’s the second stddef.h in the include search path.<\/p>\n
\nuses __NEED_wint_t. No one is wrong here, as it is libc internals that
\nshould not be used by end users, instead something like wchar.h should
\nbe included. However, as this is a libc implementation too it does not
\nmake sense to include all of that stuff, so something else must be
\ndone. I then grepped the whole llvm checkout for stddef.h and realized
\nthat Clang shipped its own stddef.h too. This header, like glibc, uses
\n__need_wint_t to define wint_t, which is exactly what I want. I posted
\na bug report and got told that the internal Clang headers are to be
\nused, not the system libc’s headers, because of issues like these.
\nhttps:\/\/github.com\/llvm\/llvm-project\/issues\/63510<\/code><\/p>\n
\n\/usr\/lib\/clang\/* even when using -ffreestanding, so I assume this is a
\nbug with the Gentoo llvm\/musl stage actually.<\/p>\n
\nchecks in LLVM libc with __linux__. When looking through the source
\ncode there are quite a lot of places where these are mixed up
\nbizarrely enough. The most obvious ones are __unix__ check followed by
\nan #include . This is caused by “cargo cult” meaning that
\nthey once did it that way and stuck with it for no reason.<\/p>\n
\nI will revisit this because there’s a chance that macOS users could
\nhave used the typedefs pthread_once_t and once_flag, even though the
\nunderlying type __futex_word was supposed to be Linux only, because
\nfutexes here are Linux kernel specific. This would’ve
\npreviously not have errored out on macOS (__APPLE__) since __unix__ is
\ndefined, and __futex_word is just defined as an aligned 32 bit uint,
\nno unconditional kernel headers used that would’ve broken the build.<\/p>\n
\ninto LLVM libc instead of just mashing everything into my Python
\nsource dir. The first one being the POSIX extension fdopen().<\/p>\n
\nitself, but actually figuring out where everything in LLVM libc was
\nplaced. Apart from the obvious declaration in the internal headers,
\nand corresponding source file, I also needed to make sure it was
\nusable in the libc. In total I needed to edit 7 files, like the
\nTableGen specifications, config\/$arch\/entrypoints.txt, libc
\nexposed internal header file, and of course CMakeLists.txt.<\/p>\n
\nhttps:\/\/reviews.llvm.org\/D153396<\/a>.<\/p>\n
\ncase needed for SSIZE_MAX. I have successfully made a tiny version in
\nmy libc tree that exposes some macros, and I will try to upstream what
\nI have and then work on things one by one. Similarly here, the hard
\npart was actually getting the header and macros to be exposed in the
\nlibc by editing build system code and specification files. I could
\nhave temporarily just jammed in a limits.h header file but I think
\nit’s important to get to know how LLVM libc does things\/”how the
\nboilerplate works” early in my project.<\/p>\n
\nsmall stuff like a typo fix
\n(https:\/\/reviews.llvm.org\/rGc32ba7d5e00869de05d798ec8eb791bd1d7fb585<\/a>),
\nadding Emacs support in llvm-common
\n(https:\/\/github.com\/gentoo\/gentoo\/pull\/31635<\/a>)
\nand other “Gentoo but not really GSoC work”:
\nhttps:\/\/github.com\/gentoo\/gentoo\/pull\/31560<\/a> (license fix, soju).
\nhttps:\/\/github.com\/gentoo\/gentoo\/pull\/30933<\/a> (new package, senpai).<\/p>\n
\nCrossdev. This will be done by first making sure that the hosts LLVM
\ntoolchain supports the target architecture via the LLVM_TARGETS
\nUSE-flag. Currently Clang on Gentoo can compile things like the
\nkernel, but anything that relies on runtime libraries, like libc,
\nfails due to compiler-rt not being compiled for the target triple, so
\nI will also make sure that Crossdev compiles compiler-rt for the
\nspecified target triple.<\/p>\n
\ncatcream<\/p>\n","protected":false},"excerpt":{"rendered":"