readdir misbehaves when running 32-bit user space on a 64-bit-kernel - kernel/userspace interface mismatch in getdents64

Danny Milosavljevic wrote on 19 Sep 2020 17:36

json-c build failure (on armhf-linux) while trying to build u-boot

Recipients:(address . bug-guix@gnu.org)

Message-ID:20200919173628.423331da@scratchpost.org

Hello,

there is a build failure in json-c:

$ guix environment -s armhf-linux --pure u-boot-a20-olinuxino-micro
[...]
running 'cmake' with arguments ("../json-c-0.14" "-DCMAKE_BUILD_TYPE=RelWithDebInfo" "-DCMAKE_INSTALL_PREFIX=/gnu/store/yqaw63n8wmg7f2ncc24019z87m5cwhim-json-c-0.14" "-DCMAKE_INSTALL_LIBDIR=lib" "-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE" "-DCMAKE_INSTALL_RPATH=/gnu/store/yqaw63n8wmg7f2ncc24019z87m5cwhim-json-c-0.14/lib" "-DCMAKE_VERBOSE_MAKEFILE=ON")
CMake Error at /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
  list sub-command REMOVE_ITEM requires two or more arguments.
Call Stack (most recent call first):
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCCompiler.cmake:116 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:10 (project)


CMake Error at /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
  list sub-command REMOVE_ITEM requires two or more arguments.
Call Stack (most recent call first):
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCCompiler.cmake:116 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:10 (project)


CMake Error at /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
  list sub-command REMOVE_ITEM requires two or more arguments.
Call Stack (most recent call first):
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCCompiler.cmake:116 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:10 (project)


CMake Error at /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
  list sub-command REMOVE_ITEM requires two or more arguments.
Call Stack (most recent call first):
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCCompiler.cmake:116 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:10 (project)


CMake Error at /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
  list sub-command REMOVE_ITEM requires two or more arguments.
Call Stack (most recent call first):
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCCompiler.cmake:116 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:10 (project)


CMake Error at /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
  list sub-command REMOVE_ITEM requires two or more arguments.
Call Stack (most recent call first):
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCCompiler.cmake:116 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:10 (project)


CMake Error at /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
  list sub-command REMOVE_ITEM requires two or more arguments.
Call Stack (most recent call first):
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCCompiler.cmake:116 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:10 (project)


CMake Error at /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
  list sub-command REMOVE_ITEM requires two or more arguments.
Call Stack (most recent call first):
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCCompiler.cmake:116 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:10 (project)


CMake Error at /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
  list sub-command REMOVE_ITEM requires two or more arguments.
Call Stack (most recent call first):
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCCompiler.cmake:116 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:10 (project)


CMake Error at /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
  list sub-command REMOVE_ITEM requires two or more arguments.
Call Stack (most recent call first):
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCCompiler.cmake:116 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:10 (project)

-- The C compiler identification is unknown
[...]
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE) 
Warning: doxygen not found, the 'doc' target will not be included
-- Configuring incomplete, errors occurred!
See also "/tmp/guix-build-json-c-0.14.drv-0/build/CMakeFiles/CMakeOutput.log".
See also "/tmp/guix-build-json-c-0.14.drv-0/build/CMakeFiles/CMakeError.log".
command "cmake" "../json-c-0.14" "-DCMAKE_BUILD_TYPE=RelWithDebInfo" "-DCMAKE_INSTALL_PREFIX=/gnu/store/yqaw63n8wmg7f2ncc24019z87m5cwhim-json-c-0.14" "-DCMAKE_INSTALL_LIBDIR=lib" "-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE" "-DCMAKE_INSTALL_RPATH=/gnu/store/yqaw63n8wmg7f2ncc24019z87m5cwhim-json-c-0.14/lib" "-DCMAKE_VERBOSE_MAKEFILE=ON" failed with status 1

Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: /gnu/store/z8954h4nvgxwcyy2in8c1l11g199m2yb-gcc-7.5.0/bin/gcc 
Build flags: 
Id flags:  

The output was:
1
CMakeCCompilerId.c:20:52: error: expected ‘,’ or ‘;’ before ‘COMPILER_ID’
 char const* info_compiler = "INFO" ":" "compiler[" COMPILER_ID "]";
                                                    ^~~~~~~~~~~

[...]

Furthermore, I'd like to ask: Why is json-c a dependency in the first place ?

$ LC_ALL=C guix describe
Generation 124  Sep 18 2020 22:27:08    (current)
  guix e6ba735
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: e6ba735d685886e747a831e43a501488e15d97c7
  heads 50b97d4
    repository URL: https://github.com/daym/heads-guix.git
    branch: wip-musl
    commit: 50b97d446ebafd0be7a0e19d87cd236882093244

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9mJXwACgkQ5xo1VCww

uqXbjAf/XpcklLwZJe7z2T1aFt1hpqYme6wgdHZ9AZJC8vPJIAoFQQ1VzNghMkqi

21D+J4QE9uXSif5Ek5pjOFS5Dat3sGBUASstDWs26DALpCfWjhDcZiU6W7R4v1dA

8QXo0oKsrmePmTV/ZhftygyZzE6JQPwJuLlES4mHoIBR8Hu+AisVXkaCUcOEIKC/

yiargZhYIHmZ2YkSOmjPNT+CeVH8BHi+5g3ZBNDmcBF4s/GrJViG95osuA0RMxZk

qT/0uI9jhfinrYMrxNuO0dwDreOclFOKEfmCQ/ylgMUySPVoHeHF4HFKnkZMJAeQ

hK9u8HTGK3V7iky9RpfGQkEeOuRTrQ==

=IlKf

-----END PGP SIGNATURE-----

Danny Milosavljevic wrote on 19 Sep 2020 23:05

Recipients:(address . 43513@debbugs.gnu.org)

Message-ID:20200919230514.53f0d88a@scratchpost.org

More info:

https://gitlab.kitware.com/cmake/cmake/-/issues/20568

https://gitlab.kitware.com/utils/kwsys/-/merge_requests/187

Toggle quote (2 lines)

> Furthermore, I'd like to ask: Why is json-c a dependency in the first place ?

Because of sdl2. I've removed sdl2 from the native-inputs of u-boot

and added it to the native-inputs of u-boot-tools in guix master

commit 6b1253718d1d660e7a91bd59a96bdb16d7c5e0b3.

So now only this fails:

$ guix build -s armhf-linux u-boot-tools

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9mcooACgkQ5xo1VCww

uqWFrwgAnu0BWfVJXlmf35OE6Z15krkyt4QAjsLMz7mnxSJonL/Itm+4Nm3uGJ8+

qvkYo0YJSGjsSTs9XPkHO+NO6T1c7+UqI/R+Dx9qOSMqW50DZeF5V4E+AOfz/YG+

5CiArR+Kk4P46SduAorDycegs16je/fICsz7K9+nCBxHx6QEXzV0Gst2TjuA3ifo

9dh6WbPY95/0c/kGian4v2+cDcTN/n/g1ENwebKTGXaOx5/0E9dgU+fLYKR5ez6w

UNi3G+8moUvRCl5Md2VwTJU7aU8bZo7l8H0+sO9Y352V05WbRz1On1y7y6uTPbJx

ZHLTZfD9frbWCF9njEJ+l0LllwMyaQ==

=R6xI

-----END PGP SIGNATURE-----

Danny Milosavljevic wrote on 21 Sep 2020 14:22

Recipients:

Message-ID:20200921134855.2ed40eb0@scratchpost.org

Hi,

I found the underlying cause of the problem with qemu transparent emulation:

* qemu transparent emulator has 64 bit registers

* the thing it's emulating has 32 bit registers

* The glibc in the distro that is running in the emulator is using getdents64

(on 32 bits!) and then (rightfully) checking whether d_off and the inode number

fit into their own (32 bits/entry) struct, which they don't (the thing they get

from the kernel is 64 bits/entry).

for an analysis.

See also https://sourceware.org/bugzilla/show_bug.cgi?id=23960for a discussion.

Least-shitty workaround: Use a 32-bit qemu (yes, a qemu compiled on 32 bit)

on a 64 bit machine for transparent emulation of ANOTHER 32-bit machine.

That way, the kernel can know that there's a 32 bit user lurking somewhere up

the call chain that is calling getdents64 and is not actually able to process the

result. "The truth? It can't handle the truth."

The right fix: One could also tell all the packages in the emulated

system to use the large file size API (-D_FILE_OFFSET_BITS=64 and co). In this

case cmake is affected--but it could be any number of things. I think that that

is the only good fix (we could also add a compile-time check whether <dirent.h>

has been included without anyone specifying -D_FILE_OFFSET_BITS=64--that would

make finding these problems a LOT easier; if possible, emit that compile-time

error only if readdir is actually called anywhere).

For the workaround, we could adapt Guix system's gnu/services/virtualization.scm

so it uses a qemu built for the 32-bit variant of the host architecture if it's

emulating a 32 bit system.

So qemu could be compiled for i686 if the host is x86_64 and the emulated

system is armhf,

qemu could be compiled for armhf if the host is aarch64 and the emulated system

is armhf and so on.

That also means that if a host system is 64 bits and DOES NOT HAVE a 32 bit

pendant target, then the emulation of a 32 bit system is going to be imperfect.

One way to fix that would be to fix the kernel to accept an argument on

the getdents64 syscall (and similar ones) that tells it whether the user wants

to have 64 bit offsets or 32 bit offsets[1]. Right now, from user space, that

is only possible via process personality flags. And those would switch the

entire qemu executable over to 32 bits, which we don't want (qemu itself has

to do stuff using kernel syscalls, so it needs to be capable of 64 bits

if it itself is 64 bits). And I think that even that case is not being

handled in the kernel correctly. So this fix cannot be done.

@Ludo:

Anyway, I have a question on how to replicate what "guix build --target=i686..."

does, in the guix service definition. How can I make it use

package-cross-derivation instead of package-derivation ?

See attachment.

With the attachment and the service definition

(service qemu-binfmt-service-type

(qemu-binfmt-configuration

(platforms (lookup-qemu-platforms "arm"))

(guix-support? #t)))

in order to emulate ARM on x86_64 I eventually get:

Toggle quote (2 lines)

>Building qemu-minimal for i686

(That's what I want!)

Toggle quote (5 lines)

>[...]

>starting phase `configure'

>ERROR: pkg-config binary 'i686-unknown-linux-gnu-pkg-config' not found

pkg-config has not been cross-compiled...

That's because it's not using package-cross-derivation, I guess.

Toggle quote (2 lines)

>command "./configure" "--cc=/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/bin/gcc" "--host-cc=/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/bin/gcc" "--disable-debug-info" "--enable-virtfs" "--prefix=/gnu/store/80ljf47lrh8arrzjmkrrqxghc0k67b3s-qemu-minimal-5.1.0" "--sysconfdir=/etc" "--cross-prefix=i686-unknown-linux-gnu-" "--target-list=i386-softmmu,x86_64-softmmu" failed with status 1

I think that "--cc" should use ,(cc-for-target) at all times.

Better this:

Toggle diff (58 lines)diff --git a/gnu/packages/virtualization.scm b/gnu/packages/virtualization.scm
index 53e9dde125..bf712afd4a 100644
--- a/gnu/packages/virtualization.scm
+++ b/gnu/packages/virtualization.scm
@@ -227,7 +227,7 @@
                (setenv "LDFLAGS" "-lrt")
                (apply invoke
                       `("./configure"
-                        ,(string-append "--cc=" (which "gcc"))
+                        ,(string-append "--cc=" ,(cc-for-target))
                         ;; Some architectures insist on using HOST_CC
                         ,(string-append "--host-cc=" (which "gcc"))
                         "--disable-debug-info" ; save build space

[1] A way for userspace to tell the kernel that is to use getdents instad of
getdents64 on 32 bits, like it used to.  But they don't want to do that anymore.

Another way would be for qemu to translate a syscall getdents64 from the guest
to getdents on the host if the machine they are emulating is 32 bits.  But that
would mean that getdents on a 64 bit host would still have to act like it's
32 bits and translate the d_off accordingly.  That's not guaranteed[2].

Or even using the old readdir syscall.

[2] Linux-5.8.8:

[... CONFIG_COMPAT ...]
SYSCALL_DEFINE3(getdents, unsigned int, fd,
                struct linux_dirent __user *, dirent, unsigned int, count)
{
        struct fd f;
        struct getdents_callback buf = {
                .ctx.actor = filldir,
                .count = count,
                .current_dir = dirent
        };
        int error;

        f = fdget_pos(fd);
        if (!f.file)
                return -EBADF;

        error = iterate_dir(f.file, &buf.ctx);
        if (error >= 0)
                error = buf.error;
        if (buf.prev_reclen) {
                struct linux_dirent __user * lastdirent;
                lastdirent = (void __user *)buf.current_dir - buf.prev_reclen;

                if (put_user(buf.ctx.pos, &lastdirent->d_off))
                        error = -EFAULT;
                else
                        error = count - buf.count;
        }
        fdput_pos(f);
        return error;
}
It's not guaranteed.

Toggle diff (244 lines)diff --git a/gnu/services/virtualization.scm b/gnu/services/virtualization.scm
index 20e104f48c..77f15ba07b 100644
--- a/gnu/services/virtualization.scm
+++ b/gnu/services/virtualization.scm
@@ -23,6 +23,7 @@
   #:use-module (gnu bootloader grub)
   #:use-module (gnu image)
   #:use-module (gnu packages admin)
+  #:use-module (gnu packages cross-base)
   #:use-module (gnu packages ssh)
   #:use-module (gnu packages virtualization)
   #:use-module (gnu services base)
@@ -554,12 +555,13 @@ potential infinite waits blocking libvirt."))
 
 ;; Platforms that QEMU can emulate.
 (define-record-type <qemu-platform>
-  (qemu-platform name family magic mask)
+  (qemu-platform name family register-width magic mask)
   qemu-platform?
-  (name     qemu-platform-name)                   ;string
-  (family   qemu-platform-family)                 ;string
-  (magic    qemu-platform-magic)                  ;bytevector
-  (mask     qemu-platform-mask))                  ;bytevector
+  (name     qemu-platform-name)                                 ;string
+  (family   qemu-platform-family)                               ;string
+  (register-width    qemu-platform-register-width)              ;int, in bits
+  (magic    qemu-platform-magic)                                ;bytevector
+  (mask     qemu-platform-mask))                                ;bytevector
 
 (define-syntax bv
   (lambda (s)
@@ -576,123 +578,123 @@ potential infinite waits blocking libvirt."))
 ;;; 'scripts/qemu-binfmt-conf.sh' in QEMU.
 
 (define %i386
-  (qemu-platform "i386" "i386"
+  (qemu-platform "i386" "i386" 32
                  (bv "\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00")
                  (bv "\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff")))
 
 (define %i486
-  (qemu-platform "i486" "i386"
+  (qemu-platform "i486" "i386" 32
                  (bv "\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x06\x00")
                  (bv "\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff")))
 
 (define %alpha
-  (qemu-platform "alpha" "alpha"
+  (qemu-platform "alpha" "alpha" 64
                  (bv "\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x26\x90")
                  (bv "\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff")))
 
 (define %arm
-  (qemu-platform "arm" "arm"
+  (qemu-platform "arm" "arm" 32
                  (bv "\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff")))
 
 (define %armeb
-  (qemu-platform "armeb" "arm"
+  (qemu-platform "armeb" "arm" 32
                  (bv "\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff")))
 
 (define %sparc
-  (qemu-platform "sparc" "sparc"
+  (qemu-platform "sparc" "sparc" 32 ; FIXME check
                  (bv "\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x02")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff")))
 
 (define %sparc32plus
-  (qemu-platform "sparc32plus" "sparc"
+  (qemu-platform "sparc32plus" "sparc" 32 ; FIXME check
                  (bv "\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x12")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff")))
 
 (define %ppc
-  (qemu-platform "ppc" "ppc"
+  (qemu-platform "ppc" "ppc" 32
                  (bv "\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x14")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff")))
 
 (define %ppc64
-  (qemu-platform "ppc64" "ppc"
+  (qemu-platform "ppc64" "ppc" 64
                  (bv "\x7fELF\x02\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x15")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff")))
 
 (define %ppc64le
-  (qemu-platform "ppc64le" "ppcle"
+  (qemu-platform "ppc64le" "ppcle" 64
                  (bv "\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x15\x00")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\x00")))
 
 (define %m68k
-  (qemu-platform "m68k" "m68k"
+  (qemu-platform "m68k" "m68k" 32
                  (bv "\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x04")
                  (bv "\xff\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff")))
 
 ;; XXX: We could use the other endianness on a MIPS host.
 (define %mips
-  (qemu-platform "mips" "mips"
+  (qemu-platform "mips" "mips" 32
                  (bv "\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff")))
 
 (define %mipsel
-  (qemu-platform "mipsel" "mips"
+  (qemu-platform "mipsel" "mips" 32
                  (bv "\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08\x00")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff")))
 
 (define %mipsn32
-  (qemu-platform "mipsn32" "mips"
+  (qemu-platform "mipsn32" "mips" 32 ; FIXME check
                  (bv "\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff")))
 
 (define %mipsn32el
-  (qemu-platform "mipsn32el" "mips"
+  (qemu-platform "mipsn32el" "mips" 32 ; FIXME check
                  (bv "\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08\x00")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff")))
 
 (define %mips64
-  (qemu-platform "mips64" "mips"
+  (qemu-platform "mips64" "mips" 64
                  (bv "\x7fELF\x02\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff")))
 
 (define %mips64el
-  (qemu-platform "mips64el" "mips"
+  (qemu-platform "mips64el" "mips" 64
                  (bv "\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08\x00")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff")))
 
 (define %riscv32
-  (qemu-platform "riscv32" "riscv"
+  (qemu-platform "riscv32" "riscv" 32 ; FIXME
                  (bv "\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xf3\x00")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff")))
 
 (define %riscv64
-  (qemu-platform "riscv64" "riscv"
+  (qemu-platform "riscv64" "riscv" 64
                  (bv "\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xf3\x00")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff")))
 
 (define %sh4
-  (qemu-platform "sh4" "sh4"
+  (qemu-platform "sh4" "sh4" 32
                  (bv "\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x2a\x00")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff")))
 
 (define %sh4eb
-  (qemu-platform "sh4eb" "sh4"
+  (qemu-platform "sh4eb" "sh4" 32
                  (bv "\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x2a")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff")))
 
 (define %s390x
-  (qemu-platform "s390x" "s390x"
+  (qemu-platform "s390x" "s390x" 64
                  (bv "\x7fELF\x02\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x16")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff")))
 
 (define %aarch64
-  (qemu-platform "aarch64" "arm"
+  (qemu-platform "aarch64" "arm" 64
                  (bv "\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7\x00")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff")))
 
 (define %hppa
-  (qemu-platform "hppa" "hppa"
+  (qemu-platform "hppa" "hppa" 32
                  (bv "\x7f\x45\x4c\x46\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x0f")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff")))
 
@@ -712,12 +714,48 @@ potential infinite waits blocking libvirt."))
   qemu-binfmt-configuration make-qemu-binfmt-configuration
   qemu-binfmt-configuration?
   (qemu        qemu-binfmt-configuration-qemu
-               (default qemu))
+               (default qemu-minimal))
   (platforms   qemu-binfmt-configuration-platforms
                (default '()))                     ;safest default
   (guix-support? qemu-binfmt-configuration-guix-support?
                  (default #f)))
 
+(define (register-width system)
+  (match (%current-system)
+   ("i686-linux" 32)
+   ("armhf-linux" 32)
+   ("aarch64-linux" 64)
+   ("x86_64-linux" 64)))
+
+(define (closest-cross-compiled-qemu qemu target-bits)
+  "Cross-compile QEMU for the given TARGET-BITS platform that is closest to
+the actual host architecture, if possible.  This is in order to prevent
+https://lore.kernel.org/lkml/20181229015453.GA6310@bombadil.infradead.org/T/"
+  (define (cross-compiled-qemu target)
+    (package
+      (inherit qemu)
+      (arguments
+       (substitute-keyword-arguments (package-arguments qemu)
+        ((#:configure-flags flags)
+         `(cons ,(string-append "--cross-prefix=" target "-")
+                ,flags))))
+      (native-inputs
+        `(("cross-gcc" ,(cross-gcc target))
+          ("cross-binutils" ,(cross-binutils target))
+          ,@(package-native-inputs qemu)))))
+  (match target-bits
+   (64 qemu)
+   (32 (match (register-width (%current-system))
+        (32 qemu)
+        (64 (match (%current-system)
+             ("x86_64-linux"
+              (cross-compiled-qemu (nix-system->gnu-triplet "i686-linux")))
+             ("aarch64-linux"
+              (cross-compiled-qemu "arm-linux-gnueabihf"))
+             (_ (begin
+                   ;; TODO: Print warning
+                   qemu))))))))
+
 (define (qemu-platform->binfmt qemu platform)
   "Return a gexp that evaluates to a binfmt string for PLATFORM, using the
 given QEMU package."
@@ -732,12 +770,13 @@ given QEMU package."
           (bytevector->u8-list bv))))
 
   (match platform
-    (($ <qemu-platform> name family magic mask)
+    (($ <qemu-platform> name family register-width magic mask)
      ;; See 'Documentation/binfmt_misc.txt' in the kernel.
      #~(string-append ":qemu-" #$name ":M::"
                       #$(bytevector->binfmt-string magic)
                       ":" #$(bytevector->binfmt-string mask)
-                      ":" #$(file-append qemu "/bin/qemu-" name)
+                      ":" #$(file-append (closest-cross-compiled-qemu qemu register-width)
+                                         "/bin/qemu-" name)
                       ":"                         ;FLAGS go here
                       ))))

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9omwIACgkQ5xo1VCww

uqUOEAf/f5fivmpMwTEJus4fOX94uPxsd0BYqyeXJ4TKJDlnyxQ3Fn9Ev8H56hb2

CN5ywUbG0bB8yiVvRJmPJxvuCFf4/873wWVgp9U2cBZRwsaHRV6PHcTcyUZ2ERhs

ptY9SjNzuNYwOnyjPh/+mUpm6KrK8strQt8FJSYRj/vPFZ2HUhiwE4wWatRRqxlX

0ic3If+tDIF2Y/wNEZgg03PX73ncjOZ+0syABFt6iyYC7HwVf1tEer9ogL3KQX9E

DbUteMlYy8veppFalQt1pILyRS9hbEJas3nWyfWy3DgXZb2kujIzixJpoUHEpf3z

RY97rNeURQEBgkVACHR2kUOwWiAipg==

=beSN

-----END PGP SIGNATURE-----

Danny Milosavljevic wrote on 21 Sep 2020 14:23

Recipients:(address . 43513@debbugs.gnu.org)

Message-ID:20200921142359.37a60189@scratchpost.org

Kernel side: https://bugzilla.kernel.org/show_bug.cgi?id=205957

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9om18ACgkQ5xo1VCww

uqVyuwgAjRUKQmnnS3xzdOhQZf155cu2I0o8Gmh7agRjSQbqmXcpTuaQ1rhFvml9

2B5WXWrFxPf0eG/vwOL9mLsw6naC/YyUfC+yF3BUODJqNjIkj33DZWNKETXNQHuR

4ZHpMrFp+75iH1tKFXq3gfTunlCcmcvtG2wx3X5u8q8ZyMBvhESyclBlK2xFKYvG

4GWnK5JGGT9c0GsnSfHR40AWuPq5FXIt3gqVpe7oVk60FkJjO411hVuodRWTfADV

PKLC4LqDiPkj36uT1olXKVhcQCQ5BT+LmAPmH3GqxDkapI/Q9NmBfMXUXK8OYxiP

sLGU6fDcc+a7dPDYf4u3yql9IET+DQ==

=0of2

-----END PGP SIGNATURE-----

Danny Milosavljevic wrote on 21 Sep 2020 14:44

Recipients:(address . 43513@debbugs.gnu.org)

Message-ID:20200921144441.4b58d775@scratchpost.org

Toggle quote (3 lines)

> to have 64 bit offsets or 32 bit offsets[1]. Right now, from user space, that

> is only possible via process personality flags.

Or via CONFIG_X86_X32, which exposes extra syscalls ON x86_64 ONLY.

I guess that would be better than nothing--although glibc would have to look
seriously strange to use those:  Even on ARM, it would have to try this syscall
first, and then the normal one.  I don't think that that is reasonable to add
to glibc.

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9ooDkACgkQ5xo1VCww

uqUIOAf9ESCd+on4RNsqrv6/EGlu39MMapytX5Vz/GxIKC6yQGD+Y+yuIqsU7Pm3

Y7jDvoAolLRxYBSlAQqxuRz7apud8jl83xiVdPL7w40EJxvPu5z9ofNpcLg2ZqgE

aB18RGkt679HAJ0hjEMJFJ3tlAEoXNk25xhlRFzSpazJwPHk9yRz4Hf8N58dOk6h

zDOxThOBIJu7o7xwc/Wc2GnLQkZk020mKwwXMH2Iz8Q+tkcRMrXvYcOytHLFGuPV

SBliyxMkXsJ2Z0mYFoZd8l4N1UOY99bz8XnVIcjEN7vv5mcgrU5KEKir32zFqq2G

dl15Dmr0vpRNxiRH2lTixhYikTXw4g==

=oAi2

-----END PGP SIGNATURE-----

Ludovic Courtès wrote on 25 Sep 2020 11:57

control message for bug #43513

Recipients:(address . control@debbugs.gnu.org)

Message-ID:87eemq2n7g.fsf@gnu.org

merge 43513 42448

quit

Ludovic Courtès wrote on 25 Sep 2020 12:13

Re: bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot

Recipients:(name . Danny Milosavljevic)(address . dannym@scratchpost.org)(address . 43513@debbugs.gnu.org)

Message-ID:87wo0i17vv.fsf@gnu.org

Hi Danny!

Danny Milosavljevic <dannym@scratchpost.org> skribis:

Toggle quote (9 lines)

> I found the underlying cause of the problem with qemu transparent emulation:

> * qemu transparent emulator has 64 bit registers

> * the thing it's emulating has 32 bit registers

> * The glibc in the distro that is running in the emulator is using getdents64

> (on 32 bits!) and then (rightfully) checking whether d_off and the inode number

> fit into their own (32 bits/entry) struct, which they don't (the thing they get

> from the kernel is 64 bits/entry).

Looks very much like the CMake-on-emulated-hardware issue several of us

encountered before:

https://issues.guix.gnu.org/38454#3

https://issues.guix.gnu.org/42448

Glad you found an explanation!

(I see you also posted https://issues.guix.gnu.org/43591.)

Toggle quote (5 lines)

> for an analysis.

> See also https://sourceware.org/bugzilla/show_bug.cgi?id=23960 for a discussion.

Woow.

Toggle quote (6 lines)

> Least-shitty workaround: Use a 32-bit qemu (yes, a qemu compiled on 32 bit)

> on a 64 bit machine for transparent emulation of ANOTHER 32-bit machine.

> That way, the kernel can know that there's a 32 bit user lurking somewhere up

> the call chain that is calling getdents64 and is not actually able to process the

> result. "The truth? It can't handle the truth."

OK.

Toggle quote (8 lines)

> The right fix: One could also tell all the packages in the emulated

> system to use the large file size API (-D_FILE_OFFSET_BITS=64 and co). In this

> case cmake is affected--but it could be any number of things. I think that that

> is the only good fix (we could also add a compile-time check whether <dirent.h>

> has been included without anyone specifying -D_FILE_OFFSET_BITS=64--that would

> make finding these problems a LOT easier; if possible, emit that compile-time

> error only if readdir is actually called anywhere).

Yes; that user-space should be built with -D_FILE_OFFSET_BITS=64 is also

the conclusion at

https://sourceware.org/bugzilla/show_bug.cgi?id=23960#c32.

Let’s fix CMake (and JSON-C?) in ‘core-updates’ or ‘staging’ (using a

graft for CMake wouldn’t help because CMake is used at build time.)

Toggle quote (29 lines)> +(define (closest-cross-compiled-qemu qemu target-bits)
> +  "Cross-compile QEMU for the given TARGET-BITS platform that is closest to
> +the actual host architecture, if possible.  This is in order to prevent
> +https://lore.kernel.org/lkml/20181229015453.GA6310@bombadil.infradead.org/T/"
> +  (define (cross-compiled-qemu target)
> +    (package
> +      (inherit qemu)
> +      (arguments
> +       (substitute-keyword-arguments (package-arguments qemu)
> +        ((#:configure-flags flags)
> +         `(cons ,(string-append "--cross-prefix=" target "-")
> +                ,flags))))
> +      (native-inputs
> +        `(("cross-gcc" ,(cross-gcc target))
> +          ("cross-binutils" ,(cross-binutils target))
> +          ,@(package-native-inputs qemu)))))
> +  (match target-bits
> +   (64 qemu)
> +   (32 (match (register-width (%current-system))
> +        (32 qemu)
> +        (64 (match (%current-system)
> +             ("x86_64-linux"
> +              (cross-compiled-qemu (nix-system->gnu-triplet "i686-linux")))
> +             ("aarch64-linux"
> +              (cross-compiled-qemu "arm-linux-gnueabihf"))
> +             (_ (begin
> +                   ;; TODO: Print warning
> +                   qemu))))))))

It doesn’t make sense to cross-compile from x86_64 to i686. Instead we

should use a native build, but an i686 one:

(package/inherit qemu

(arguments `(#:system "i686-linux" ,@(package-arguments qemu))))

Likewise for AArch64/ARMv7.

How does that sound?

Thanks,

Ludo’.

Ludovic Courtès wrote on 25 Sep 2020 12:14

control message for bug #43513

Recipients:(address . control@debbugs.gnu.org)

Message-ID:87v9g217uk.fsf@gnu.org

retitle 43513 'getdents' misbehaves when emulating 32-bit code on a 64-bit-kernel host

quit

Ludovic Courtès wrote on 25 Sep 2020 12:14

Recipients:(address . control@debbugs.gnu.org)

Message-ID:87tuvm17uf.fsf@gnu.org

severity 43513 important

quit

Danny Milosavljevic wrote on 25 Sep 2020 13:13

Re: bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 43513@debbugs.gnu.org)

Message-ID:20200925131237.32fc61e9@scratchpost.org

Hi Ludo,

On Fri, 25 Sep 2020 12:13:40 +0200

Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (3 lines)

> Let’s fix CMake (and JSON-C?) in ‘core-updates’ or ‘staging’ (using a

> graft for CMake wouldn’t help because CMake is used at build time.)

Sure--cmake upstream will fix it anyway and make a new release.

But I now opened bug# 43591 on guix-patches in order to find all the OTHER

problems this causes we didn't see yet. I already ran it on my laptop in

order to find all the users trying to stick a 64-bit value into a 32-bit

slot and it looks very bad--there are instances of this problem in libstdc++,

binutils bfd etcetc.

I suggest to delete all ARM substitutes that were built on x86_64 machines

and disable the builders using x86_64 to build ARM stuff in the mean time.

What that has built is VERY MUCH not reliable since readdir() was broken

sporadically--and compilers need that :P

Toggle quote (6 lines)

> It doesn’t make sense to cross-compile from x86_64 to i686. Instead we

> should use a native build, but an i686 one:

> (package/inherit qemu

> (arguments `(#:system "i686-linux" ,@(package-arguments qemu))))

Sure.

I'm still hoping we can skip the workaround and do the right thing instead

(compiling everything with -D_FILE_OFFSET_BITS=64 regardless of architecture).

I thought this matter with making everyone use LFS was settled in about

2007--but no, here we go again :(

Even if we did the workaround with qemu here, that still means the kernel

(via a compatibility layer) is going to lie to qemu about file offsets and

directory entry hashes. That doesn't sound good for reproducibility.

Also, I want to be clear that qemu is not at fault here.

It's fundamentally unsound to call getdents64 and expect a value with less

than 64 bits back. But that is what glibc does.

Users (other packages) who use _FILE_OFFSET_BITS=32 (by not setting

_FILE_OFFSET_BITS at all) in 2020, those are at fault.

Toggle quote (2 lines)

> Likewise for AArch64/ARMv7.

I do not think the X86_32 compatibility layer works on aarch64, so now we have
a problem.  That means building stuff for ARMv7 on aarch64 is not reliable at
all.

The right fix is to always use "-D_FILE_OFFSET_BITS=64" in user space.  Then
none of this weird stuff needs to be done.

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9t0NIACgkQ5xo1VCww

uqVZFQf7ByjxtzbOpP5VuFBPsuWRsXJvHOYhpTJLXkgLv0/sDx7Xp0PDvlE7Ec99

Scd7US21nTu1z7SKJoI1RcKJ4vPZQYefobr9a6NYUaXz99J+4rp2x77U+IT+DzIN

k+3Z/4kMv6rHZ8iJkB5tVM9H3MJSY8CIxGBPdVlLyi1Uap2eY2r/B3Yi+59wz2jD

R3Mz4OBUg5jlqIJwcW7/0LRLxU2PGny42pPlX7DukVUExhoGNiGSMgkt9W/GludP

op/9wOKaKFk48vdsUbsLgal9p/bfSn0qKnKXkju2B6T1iD5HFJ0XOpsA9OTcnTbr

qO1EZEuUuUZLbfU0Pz8Ovoooe7f2tg==

=6a2J

-----END PGP SIGNATURE-----

Danny Milosavljevic wrote on 25 Sep 2020 13:18

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 43513@debbugs.gnu.org)

Message-ID:20200925131856.4a1d4a1c@scratchpost.org

On Fri, 25 Sep 2020 13:13:22 +0200

Danny Milosavljevic <dannym@scratchpost.org> wrote:

Toggle quote (4 lines)

> I do not think the X86_32 compatibility layer works on aarch64, so now we have

> a problem. That means building stuff for ARMv7 on aarch64 is not reliable at

> all.

Hmm.

Could I have access to a aarch64 build machine? Or am I able to cause

a aarch64 build machine to evaluate a new wip branch?

I want to find out what it actually does in the case that aarch64 is used to

run armv7 stuff. Does it have a compat layer in the kernel or not?

How about all the other 64 bit architectures that have a 32 bit compat

fallback in hardware? Do those have a compat layer in the kernel or not?

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9t0iAACgkQ5xo1VCww

uqWRhAgAiK9kxke/Y5MRBMMip3RNCRplrWBFwN1bR3TOM0aCTkwW80J674ByTVom

iY8wzBxZnqWU3KJ4TboL5Sm0TsgnRum7b7WpZRq1uEnwPs2nYpJWxWfStL0zzSrM

F0Et1nqzJ2N6dk57UTQgDFwTuGCiEx2D1DuV2j6HkqO52wN5MqhuefoP4EgS5bOU

t2cDnkol3+x40QvY7t0Z/pEOOiXHY90xLrCbf/zEEEK8XZ9GOFkx9C2Ieo6PM4r0

cT8TMC1WSA6b5ubpLrZPIr6k2H3L6sBMf+UZKUO6hof0o3KwgliLEsXI7WFR1Xl8

V76v+LHZkzOPLN9PK0+for6M+S3j3Q==

=Jzv8

-----END PGP SIGNATURE-----

Ludovic Courtès wrote on 25 Sep 2020 18:00

Recipients:(name . Danny Milosavljevic)(address . dannym@scratchpost.org)(address . 43513@debbugs.gnu.org)

Message-ID:874knlkfsq.fsf@gnu.org

Danny Milosavljevic <dannym@scratchpost.org> skribis:

Toggle quote (11 lines)> On Fri, 25 Sep 2020 13:13:22 +0200
> Danny Milosavljevic <dannym@scratchpost.org> wrote:
>
>> I do not think the X86_32 compatibility layer works on aarch64, so now we have
>> a problem.  That means building stuff for ARMv7 on aarch64 is not reliable at
>> all.
>
> Hmm.
>
> Could I have access to a aarch64 build machine?

You’re listed in overdrive.scm in maintenance.git, so you must have

access to overdrive1.guixsd.org:52522.

Ludo’.

Ludovic Courtès wrote on 25 Sep 2020 18:02

Recipients:(name . Danny Milosavljevic)(address . dannym@scratchpost.org)(address . 43513@debbugs.gnu.org)

Message-ID:87wo0hj13l.fsf@gnu.org

Danny Milosavljevic <dannym@scratchpost.org> skribis:

Toggle quote (14 lines)> On Fri, 25 Sep 2020 12:13:40 +0200
> Ludovic Courtès <ludo@gnu.org> wrote:
>
>> Let’s fix CMake (and JSON-C?) in ‘core-updates’ or ‘staging’ (using a
>> graft for CMake wouldn’t help because CMake is used at build time.)
>
> Sure--cmake upstream will fix it anyway and make a new release.
>
> But I now opened bug# 43591 on guix-patches in order to find all the OTHER
> problems this causes we didn't see yet.  I already ran it on my laptop in
> order to find all the users trying to stick a 64-bit value into a 32-bit
> slot and it looks very bad--there are instances of this problem in libstdc++,
> binutils bfd etcetc.

Hmm, it’s this bad?

Toggle quote (5 lines)

> I suggest to delete all ARM substitutes that were built on x86_64 machines

> and disable the builders using x86_64 to build ARM stuff in the mean time.

> What that has built is VERY MUCH not reliable since readdir() was broken

> sporadically--and compilers need that :P

What are the odds of a build succeeding in the presence of broken

getdents/readdir? Wouldn’t such builds simply fail (as in the CMake

case), as opposed to succeeding but somehow producing invalid binaries?

We can still disabled emulated builds on ci.guix.gnu.org, but let’s

first make sure we understand the practical impact of this bug.

Toggle quote (3 lines)

> I thought this matter with making everyone use LFS was settled in about

> 2007--but no, here we go again :(

Yeah. :-/

Ludo’.

Danny Milosavljevic wrote on 25 Sep 2020 18:23

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 43513@debbugs.gnu.org)

Message-ID:20200925182326.402aa6f2@scratchpost.org

Hi Ludo,

On Fri, 25 Sep 2020 18:02:54 +0200

Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (4 lines)

> What are the odds of a build succeeding in the presence of broken

> getdents/readdir? Wouldn’t such builds simply fail (as in the CMake

> case), as opposed to succeeding but somehow producing invalid binaries?

I don't know what hashing mechanism ext4 uses, but I guess the odds are not
that high IF THE DIRECTORY IS RANDOM.  If it's crafted by a malicious person,
all bets are off.

However, notice that glibc can only fail out of readdir once it gets an *actual*
value >= 2**32.  It's totally possible in principle to have a directory with
200 entries, the first 100 of which have d_off < 2**32, and the 101st has
d_off >= 2**32.  Readdir will only stop after having given back 100 entries
to the caller.  The caller most likely will process those 100 entries.
That's it, you've just forgotten to install/copy/read/whatever half the files.

Technically the caller could examine errno to find out that something bad
happened while using readdir, but odds are that they don't (I haven't seen
anyone do that in my entire career)--and also the error code they are using
is undocumented[1].  So even a person who would check wouldn't expect this
error value (errno == EOVERFLOW).  In short, it won't work in practice.

Toggle quote (3 lines)

> We can still disabled emulated builds on ci.guix.gnu.org, but let’s

> first make sure we understand the practical impact of this bug.

We need non-emulated builds to compare.

If a real ARM machine uses substitutes for anything, it probably picks up

now-untrustworthy builds made by x86_64 for ARM and builds on top of those.

Or don't they use substitutes?

In that case everything would be OK-ish.

Otherwise huge mess...

[1] "man getdents64" does not list EOVERFLOW--at least not for me.

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9uGX4ACgkQ5xo1VCww

uqWi9wgAm4mQhsA+mCqSiaPLDJr7y7QuqAZ/xU9WjKqIbGCQHZJZyveeOr64B2OV

xDuVXzn2yc/P4Ot3mMm1+EuW85FXKcIG3y7xwd5kA0+d0oSfHBQOrBru2Xw7ezMD

734V3Fh79KzHSjhL/rBrdl3dJ+nwRas5Ap5jKJpgtB15HKDqyPS1F6+Sooxmxr/J

SKuEd8vwsKrS+WmDpTWJoWh1BJkcqQsIOl9rA1kk1WlYU25buysKHSdFzUmZ1EBN

d/F8+O5B1/jBQM8EpEkYjG2LvgWX1oqizP9UZ9G3OZ8lM1NaYF+13hdtWtJhJMNn

OwHKPnuFRI4lzqpUzMyM35MCPhHE3A==

=E3hj

-----END PGP SIGNATURE-----

Danny Milosavljevic wrote on 25 Sep 2020 18:25

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 43513@debbugs.gnu.org)

Message-ID:20200925182542.72f556d2@scratchpost.org

Hi Ludo,

On Fri, 25 Sep 2020 18:00:05 +0200

Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (3 lines)

> You’re listed in overdrive.scm in maintenance.git, so you must have

> access to overdrive1.guixsd.org:52522.

Indeed, I do.

Thanks!

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9uGgYACgkQ5xo1VCww

uqVtjQf/fvkjp0Dpk+qXGVyCj52AwXSMQHw9DjM4jGM1WMusae6SZj7jJqHVpwsm

E8s+3FLRtw3F3b2e05Ofpsl69/EBjtU1zIFw93WBQE83wny/qc95zzEBsh7PZrNA

tN3/g4R96qUDCCP9iS5xk2en61swStoWINWr7mNd9Oarm5HYanZ5Se/uJZJLQwHf

/Zcyom/LoNXB4uc6W0hyBve957wD8vjexdxTa/RrfoxawCZtzCgFKNXEEVWi025V

Ok+tjC/3VSLVkN6qi/kmjAhk7rkFj7DFQY01xUuhEFRixYbI/rwbtJ0pkGh+PSM4

aHfOdoE12WbkqITS2GGsez6lD1IXKg==

=WltV

-----END PGP SIGNATURE-----

Danny Milosavljevic wrote on 25 Sep 2020 18:37

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 43513@debbugs.gnu.org)

Message-ID:20200925183720.472220de@scratchpost.org

Toggle quote (2 lines)

> [1] "man getdents64" does not list EOVERFLOW--at least not for me.

I meant "man readdir"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9uHMAACgkQ5xo1VCww

uqWPgwgAlEg9jMLx/WDB7tbrQuwH2EzkGU/Kd+XaWmezgmcBenkbR/E2gQIquN8m

8SubKQWmMpBEi0sEJe7Xm4t2AgsDXTIwoYFEWGz3Ob6d724RCaiY5vAhwhdcEKMS

ZOusM++HAD3afRdfW0RUU7LjdWy3X3sM04sO39+M6fU8OBfrd+kJmb7l81NCGt/o

FPal1q7ntzmsyaDnjGA9eo1P3GV9Tid+WW5jn9pqmBqvK4jwaJstZo7F2TYpzFe6

K7F66kcZe5iJvsJawFgJWZePGwhdZBuohbgR0AtQdp05H5WA7wSg8nhJcG+BWkib

1LYIW66/9gdqeOWV8n6dGretG5DK/A==

=Cvxp

-----END PGP SIGNATURE-----

Danny Milosavljevic wrote on 26 Sep 2020 12:53

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 43513@debbugs.gnu.org)

Message-ID:20200926125320.11b8f4be@scratchpost.org

Hi Ludo,

On Fri, 25 Sep 2020 18:25:42 +0200

Danny Milosavljevic <dannym@scratchpost.org> wrote:

Toggle quote (10 lines)> On Fri, 25 Sep 2020 18:00:05 +0200
> Ludovic Courtès <ludo@gnu.org> wrote:
> 
> > You’re listed in overdrive.scm in maintenance.git, so you must have
> > access to overdrive1.guixsd.org:52522.  
> 
> Indeed, I do.
> 
> Thanks!

I'd like to test what happens if one builds json-c on an aarch64 host

for i686.

Could we enable qemu-binfmt for i686 on an aarch64 host for me to test it?

One machine is enough--I'd just run

guix environment -s i686-linux gcc-toolchain -- gcc -o a00 -D_FILE_OFFSET_BITS=xxx a00.c

and then later

guix build -s i686-linux json-c

on it.

a00.c:

#include <stdio.h>

#include <errno.h>

#include <assert.h>

#include <dirent.h>

#if defined( __ILP32__ )

#warning ILP32

#endif

int main() {

DIR* d;

struct dirent* ent;

d = opendir("tmp");

errno = 0;

assert(sizeof(ent->d_off) == sizeof(off_t));

while ((ent = readdir(d)) != NULL) {

printf("off=%llX, ino=%llX\n", (unsigned long long) ent->d_off, (unsigned long long) ent->d_ino);

}

if (errno)

perror("readdir");

return sizeof(off_t);

}

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9vHaAACgkQ5xo1VCww

uqXtogf+Nsm7FF9rNtoFKQU6QQS0q9cOTYmSlcmgbVifSTgf82aObAGBP9XeQnS3

i/IhZj22IcLYbvNCrryR1+qhyR+e29fqCQhHzUBPxBDH8NarCag4URFfZyAE0k4X

qL4YfRs8KEQgd2DOBzGbvbNAQyYS1fKN1SONNiYs/lXn2lfwPrFVildy7E1XuZ23

CsTFrxCsPDHZI2NkfImuh13ucKLoXd56eU3xqNNNAHbilIohBZU1gmA052TZ4rhN

3YBbA3VvZ5OM/2Dy1X4wR8aWO1pENaqOUaZXsceQmkqpAYlWn1XAcfCYGodg3vMa

xJfFVgFbeALCanzBm3fGmD78Nl7W7Q==

=adFG

-----END PGP SIGNATURE-----

Andreas Enge wrote on 26 Sep 2020 19:20

Recipients:(name . Danny Milosavljevic)(address . dannym@scratchpost.org)

Message-ID:20200926172029.GA9866@jurong

Hello Danny,

On Sat, Sep 26, 2020 at 12:53:20PM +0200, Danny Milosavljevic wrote:

Toggle quote (2 lines)

> Could we enable qemu-binfmt for i686 on an aarch64 host for me to test it?

I am working (or rather, the machine is compiling) to set it up on dover.

When it is finished, I will keep you updated (it may take a while, since

I did a "guix pull", and now it will also compile a new kernel).

Andreas

Andreas Enge wrote on 27 Sep 2020 11:50

Recipients:(name . Danny Milosavljevic)(address . dannym@scratchpost.org)

Message-ID:20200927095027.GA4962@jurong

Hello Danny,

On Sat, Sep 26, 2020 at 12:53:20PM +0200, Danny Milosavljevic wrote:

Toggle quote (8 lines)

> I'd like to test what happens if one builds json-c on an aarch64 host

> for i686.

> Could we enable qemu-binfmt for i686 on an aarch64 host for me to test it?

> One machine is enough--I'd just run

> guix environment -s i686-linux gcc-toolchain -- gcc -o a00 -D_FILE_OFFSET_BITS=xxx a00.c

> and then later

> guix build -s i686-linux json-c

you can give it a try on dover.guix.info, but you should be ready for

a wait: As other build machines, it does not use substitutes, so everything

will be built locally using qemu-binfmt. Maybe you could import what

is needed for the "guix environment" from an i686 machine?

I would suggest to do a "guix pull --commit=0939462e3f81bc98b38bdb7610e6a80ca1cbaa1b",

since this is the version already available on the machine.

Andreas

Danny Milosavljevic wrote on 27 Sep 2020 13:32

Recipients:(name . Andreas Enge)(address . andreas@enge.fr)

Message-ID:20200927133259.6e7b1421@scratchpost.org

Hmm, /home/dannym is missing there. I can log in but not pull.

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9weGsACgkQ5xo1VCww

uqUPhggAl3WZajX0fTSW6g/A5mjeOm7SSajiYvfB/Db/nCkt5EWWCGB9dNR3ga6Q

SHfkXl50rRb1Z9IOM5KgRSccn+02DYMwuuFjx+M2bM1UobQENBYol3sYT2ONPVvV

DrdkhrVIw2So57InLnL9kbwQYlJ+5Ee6UTyDuAwoqEmzDGKE34NiQ6I1i0MGqRTX

X6Be/slhUFBQC9c4H5T+C9wUYFf13j0AltTh7E6yoNArI2+7vmSSyl2NpV0lMofb

EZ5LGs1qXPPVTU+BQd2lA3g73y6SmtBT/go48pJ9kH9Fvj+h1ySYjR67Oo5Cpj47

NjcUUsWSnWLyUN2CxMNAyGpU6hCtBw==

=HDkZ

-----END PGP SIGNATURE-----

Ludovic Courtès wrote on 29 Sep 2020 12:25

Recipients:(name . Danny Milosavljevic)(address . dannym@scratchpost.org)(address . 43513@debbugs.gnu.org)

Message-ID:87a6x87ubx.fsf@gnu.org

Hi,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

Toggle quote (5 lines)

> I'd like to test what happens if one builds json-c on an aarch64 host

> for i686.

> Could we enable qemu-binfmt for i686 on an aarch64 host for me to test it?

I think you can just run ‘qemu-i386 /path/to/your/program’; no need for

the whole binfmt_misc shebang.

HTH,

Ludo’.

Danny Milosavljevic wrote on 29 Sep 2020 12:43

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:20200929124308.419282f2@scratchpost.org

Hi Ludo,

On Tue, 29 Sep 2020 12:25:54 +0200

Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (8 lines)

> > I'd like to test what happens if one builds json-c on an aarch64 host

> > for i686.

> >

> > Could we enable qemu-binfmt for i686 on an aarch64 host for me to test it?

> I think you can just run ‘qemu-i386 /path/to/your/program’; no need for

> the whole binfmt_misc shebang.

Sure, but I want to know what happens to json-c. That sounds like a lot of

manual invocations (like about 20000--for invocations of "configure", "gcc",

including all the dependencies etcetc).

Andreas Enge already tried to configure dover.guix.info to uses qemu-binfmt

to emulate i686-linux, but apparently it doesn't work (on dover.guix.info):

building /gnu/store/7wz8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv...

\builder for `/gnu/store/7wz8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv' failed with exit code 1

build of /gnu/store/7wz8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv failed

View build log at '/var/log/guix/drvs/7w/z8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv.bz2'.

bash-5.0$ bzless /var/log/guix/drvs/7w/z8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv.bz2

------> /var/log/guix/drvs/7w/z8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv.bz2 <------

while setting up the build environment: executing `/gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash': No such file or directory

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9zD7wACgkQ5xo1VCww

uqXxOQgAnzYeIszNvkOwEVAx96x6JBXDB1ZHXv+3QTYFN7qb0nn/griHPTzO+q0M

CWyhqRQ4K0oU3JKV4Msud1aTsLjPLECebHavShn1t5ZMb18DCKOCWLvZ5PDCdeC6

VXoMAtwVTIlblpFtvLJ4B2q09B8lQwKuL9LdEFTHLFFbUMy7IPdkgcVPYudnatgH

RdwqIqB7KFfoDqUUHCexbcGuKeVgr1tuPS+Z+zTEUmepXIcApVHu7qGI9LD6ziUE

QIL9x/aw3AT6XzQBCWg116ZZKj1DoGZpaEfyK6Rvb0Y6gGwCLt2bs+mGmt2bfrrb

rqBP7yXe6LwAyRm0BeLilVw1T3hsng==

=V10v

-----END PGP SIGNATURE-----

Danny Milosavljevic wrote on 29 Sep 2020 13:05

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 43513@debbugs.gnu.org)

Message-ID:20200929130511.4573c01f@scratchpost.org

On Tue, 29 Sep 2020 12:43:08 +0200

Danny Milosavljevic <dannym@scratchpost.org> wrote:

Toggle quote (2 lines)

> /gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash

Also, this file exists, and is for i686, and if I invoke it using

/gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash -c "echo foo"

then it works (which means the qemu transparent emulation picks it us).

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9zFOcACgkQ5xo1VCww

uqWIOggAodueuItVyBGluXBGH/oC96g2r4/kRNPx6+Sd9i0p1AMgw34F8oxIohDd

sX8QqkYNPY77l1oKKZjpMhbuKRBgxyID/uF3v9a/aIe1uwK0wsHTds0TU36juxmh

Twjwwr4FlnVojNvC3lHCHo9WR3zRsA8QxS7YewgCL3ZT3aUMOGcjSXNmBjxgS+7g

EPm3tz58UvxGGjgVy5EX2IbF64ltEYs//quE+JuoGzjHCL/37acFnz2phkiHbgsw

nEpR+GrPAVDq5E6IPvtWDmuTeH0720qClji17VNcxUxies/E86FLmXGktw/6q5zw

J+kk/0MyBiWAPrM1ePZKS7vo1HErLA==

=zZOQ

-----END PGP SIGNATURE-----

Danny Milosavljevic wrote on 29 Sep 2020 16:33

(no subject)

Recipients:(address . control@debbugs.gnu.org)

Message-ID:20200929163351.5f4aaaef@scratchpost.org

retitle 43513 Kernel/userspace interface mismatch between 32 bit user space and 64 bit kernel - readdir

severity 43513 critical

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9zRc8ACgkQ5xo1VCww

uqXoQwf9E71eEjVgRLRop9FEB21gtLzhbqDSDq3llhh1BTPgOezXvD4F0YcdxTCe

ToecJ5KazcNeNa1TPTOMLGQpXiygARS6ChkHKdDBNwS9X0K6tLw1ISqdAauZywor

nQcwlHPXB728388oYdueR3HMhqyOiEOaDeG4dBBQsvG90zbW2CtqeI4IV4BKzW0d

m2MLF6D8cc686en5VQQJ9k/M5p5tIOF32zsiXJA87r26eUuJgJ35gNM6dDrtfpeQ

1w2Iq2fAkPJlC8EcsxeD6/wkLb/l9Yq8GjnZUoH/VS6qcHBtsFzjDH0OoqDHY81K

6PJSsoP1Chrods0rPMfkeBAIqom+Nw==

=0ldn

-----END PGP SIGNATURE-----

Danny Milosavljevic wrote on 29 Sep 2020 16:36

Recipients:(address . control@debbugs.gnu.org)

Message-ID:20200929163651.7919a847@scratchpost.org

retitle 43513 readdir misbehaves when running 32-bit user space on a 64-bit-kernel - kernel/userspace interface mismatch in getdents

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9zRoMACgkQ5xo1VCww

uqVIngf/V/5uxj7DVEyvzqDiikzSoMTebV2zJF8h7PlFsGG7qPrd9tXodGJ5sMek

oFVK5vZr5zcmOjrJ14ofj8jJrqzDwUzUVTwecacrGhJElhm7DAbZ9P6zaK2v9IQk

RfR9A6snXsfkeoXtXwfFJOvTIi1jYJdw6UaXfdFRLPQfeMriworyLTFisNKlHa7i

BdjdHLO2Yarozn0k0pYwKmGp/x08sUIeybJA2LcDXnKePftSjl8iKIiciswdecsF

BM13psk+0UXmdspTNRBRLPacv4Bqcr+QZcXmVlmA9FvxsDlX+inF6zZa1zCO4d7G

LGmMovzAKDllnIFUe7T5OnW/MQaD0w==

=NHr1

-----END PGP SIGNATURE-----

Danny Milosavljevic wrote on 29 Sep 2020 16:39

Re:

Recipients:(address . control@debbugs.gnu.org)

Message-ID:20200929163953.184425f1@scratchpost.org

retitle 43513 readdir misbehaves when running 32-bit user space on a 64-bit-kernel - kernel/userspace interface mismatch in getdents64

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9zRzkACgkQ5xo1VCww

uqU5Zwf9Hhmuk712W2fHePU8CZxCbn6DbMvVRstCiCwY9D3c8ZhFZUlG8SgY4ana

XpppykP6ORCteMqFQwGIN1e3PS2jet6J954t7MqmrrSYWjFkObdr2L/PNd6iH/8w

NJtbgfA8oM56yYiguqh5CWD5XcG9AcYFunKPIqUnWTtl5i6+kUGK9coUAln1H1ny

9753eRTHXNQcobZWTsXHzPmm8Q0YYXEzeTkTy/3oFoMp3zdWnvV7Q22WugYwAqgE

nlgTJdxheIYPz1z9wBE9ZnAvvCGYWu3eJ+hvn/UAluXKt1jC6MSy1htaCgoqG5zL

WVj46zPEluPcDDg9EqNRLGwW+rTixw==

=JleQ

-----END PGP SIGNATURE-----

Ludovic Courtès wrote on 30 Sep 2020 11:10

Re: bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot

Recipients:(name . Danny Milosavljevic)(address . dannym@scratchpost.org)

Message-ID:87k0wb3a12.fsf@gnu.org

Hi,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

Toggle quote (15 lines)> On Tue, 29 Sep 2020 12:25:54 +0200
> Ludovic Courtès <ludo@gnu.org> wrote:
>
>> > I'd like to test what happens if one builds json-c on an aarch64 host
>> > for i686.
>> >
>> > Could we enable qemu-binfmt for i686 on an aarch64 host for me to test it?  
>> 
>> I think you can just run ‘qemu-i386 /path/to/your/program’; no need for
>> the whole binfmt_misc shebang.
>
> Sure, but I want to know what happens to json-c.  That sounds like a lot of
> manual invocations (like about 20000--for invocations of "configure", "gcc",
> including all the dependencies etcetc).

Do we know which bit of json-c’s ‘configure’ draws an incorrect

conclusion?

Toggle quote (12 lines)> Andreas Enge already tried to configure dover.guix.info to uses qemu-binfmt
> to emulate i686-linux, but apparently it doesn't work (on dover.guix.info):
>
> building /gnu/store/7wz8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv...
> \builder for `/gnu/store/7wz8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv' failed with exit code 1
> build of /gnu/store/7wz8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv failed
> View build log at '/var/log/guix/drvs/7w/z8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv.bz2'.
>
> bash-5.0$ bzless /var/log/guix/drvs/7w/z8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv.bz2
> ------> /var/log/guix/drvs/7w/z8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv.bz2 <------
> while setting up the build environment: executing `/gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash': No such file or directory

That’s to little context for me to say much (I’d need to see the command

at least) but it could be that it’s trying to run i686 code on ARM or

similar.

Ludo’.

Danny Milosavljevic wrote on 30 Sep 2020 13:27

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:20200930132754.1d88c9e2@scratchpost.org

Hi Ludo,

On Wed, 30 Sep 2020 11:10:17 +0200

Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (12 lines)

> Danny Milosavljevic <dannym@scratchpost.org> skribis:

> > On Tue, 29 Sep 2020 12:25:54 +0200

> > Ludovic Courtès <ludo@gnu.org> wrote:

> > Sure, but I want to know what happens to json-c. That sounds like a lot of

> > manual invocations (like about 20000--for invocations of "configure", "gcc",

> > including all the dependencies etcetc).

> Do we know which bit of json-c’s ‘configure’ draws an incorrect

> conclusion?

At least I don't. I don't even have a homedir on dover.guix.info, so I cannot

run guix pull, guix describe, or really anything that is interesting on there.

Andreas knows maybe--it works for him.

Toggle quote (6 lines)

> > while setting up the build environment: executing `/gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash': No such file or directory

> That’s to little context for me to say much (I’d need to see the command

> at least) but it could be that it’s trying to run i686 code on ARM or

> similar.

Note that /gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash is an i686 executable

on dover.

Running it just like this

/gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash

it works there on dover!

In order to reproduce the problem, you can log into dover.guix.info and then

run

guix build -s i686-linux json-c

Andreas knows more and can do much more on that machine.

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl90a7oACgkQ5xo1VCww

uqVqAAf/Z6BV36FrHOP04WNhLmgtoTtrV4FlVa6GAL//+ZCt5AClXWxxaj7wPOwJ

dd28/ygiXt41fcu8+7tYx8FDjzs2Xc7TE590JbvxjVIwsGEQZHLf/daAuHDTiM6M

HvMBM2GCEQeBYP/ZjxulwulN10vhZk5dj6/VZlLbi17VKemZ2NM21DvqJyC/+kzH

IiJELmFvlzXa8nUuEDQyh0R4lDlUFASjMl82vzAe0Ju2L6i+hKXz0JrySK2BtGze

Y5do8Cofc3Gou54bWUgq1AXcG/76JMN/0aA9vqN7k9CCRcMHSz0+dpzC5xFdv+FN

ew45vtGkbQg/jp0BKqyjTplZr+/xTw==

=FDcY

-----END PGP SIGNATURE-----

Andreas Enge wrote on 30 Sep 2020 14:17

Recipients:(name . Danny Milosavljevic)(address . dannym@scratchpost.org)

Message-ID:20200930121731.GB1632@jurong

Hello,

On Wed, Sep 30, 2020 at 01:27:54PM +0200, Danny Milosavljevic wrote:

Toggle quote (3 lines)

> At least I don't. I don't even have a homedir on dover.guix.info, so I cannot

> run guix pull, guix describe, or really anything that is interesting on there.

this is a problem I have now seen at least three times, so I have opened

its own bug:

https://issues.guix.gnu.org/43720

Andreas

Bengt Richter wrote on 1 Oct 2020 18:18

Recipients:(name . Andreas Enge)(address . andreas@enge.fr)

Message-ID:20201001161859.GA3342@LionPure

Hi,

On +2020-09-30 14:17:31 +0200, Andreas Enge wrote:

Toggle quote (13 lines)> Hello,
> 
> On Wed, Sep 30, 2020 at 01:27:54PM +0200, Danny Milosavljevic wrote:
> > At least I don't.  I don't even have a homedir on dover.guix.info, so I cannot
> > run guix pull, guix describe, or really anything that is interesting on there.
> 
> this is a problem I have now seen at least three times, so I have opened
> its own bug:
>    https://issues.guix.gnu.org/43720
> 
> Andreas
>

At https://issues.guix.gnu.org/43720it says

Toggle snippet (3 lines)

Your may also send email to 43720@debbugs.gnu.org to comment.

(Nit: s/Your/You/ :)

I am wondering what the difference is besides the browser interface,

in regards to how the submission gets logged, stored, and re-distributed.

Regards,

Bengt Richter

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date