On 4/14/22 4:41 PM, Ammar Faizi wrote: > Hi, > > This series adds nolibc support for x86 32-bit. There are 3 patches in > this series: > > 1) Use `__NR_mmap2` instead of `__NR_mmap` for x86 32-bit. > 2) Provide `get_page_size()` function for x86 32-bit. > 3) Add x86 32-bit native syscall support. > > The most noticeable changes is the patch 3. Unlike x86-64, only > use native syscall from the __do_syscall macros when CONFIG_NOLIBC is > enabled for 32-bit build. The reason is because the libc syscall > wrapper can do better in 32-bit. The libc syscall wrapper can dispatch > the best syscall instruction that the environment is supported, there > are at least two variants syscall instruction for x86 32-bit, they are: > `int $0x80` and `sysenter`. The `int $0x80` instruction is always > available, but `sysenter` is not, it relies on VDSO. liburing always > uses `int $0x80` for syscall if it's compiled with CONFIG_NOLIBC, > otherwise it uses whatever the libc provides. > > Extra notes for __do_syscall6() macro: > On i386, the 6th argument of syscall goes in %ebp. However, both Clang > and GCC cannot use %ebp in the clobber list and in the "r" constraint > without using -fomit-frame-pointer. To make it always available for > any kind of compilation, the below workaround is implemented: > > 1) Push the 6-th argument. > 2) Push %ebp. > 3) Load the 6-th argument from 4(%esp) to %ebp. > 4) Do the syscall (int $0x80). > 5) Pop %ebp (restore the old value of %ebp). > 6) Add %esp by 4 (undo the stack pointer). > > WARNING: > Don't use register variables for __do_syscall6(), there is a known > GCC bug that results in an endless loop. > > BugLink: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032 > > > ===== How is this tested? ===== > > This has been tested on x86-64 Linux (compiled with 32-bit bin support) > with the following commands: > > sudo apt-get install gcc-i686-linux-gnu g++-i686-linux-gnu -y; > ./configure --cc=i686-linux-gnu-gcc --cxx=i686-linux-gnu-g++ --nolibc; > sudo make -j8 runtests; Looks reasonable to me, even with the warts. I keep threatening to do a 2.2 release, and I do want to do that soon, so question is if we defer this patchset until after that has happened? I'm looking for a gauge of confidence on the series. -- Jens Axboe
