Hi Danny! Danny Milosavljevic <dan...@scratchpost.org> skribis:
> 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>.) > See also > https://lore.kernel.org/lkml/20181229015453.ga6...@bombadil.infradead.org/T/ > for an analysis. > > See also https://sourceware.org/bugzilla/show_bug.cgi?id=23960 for a > discussion. Woow. > 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. > 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.) > +(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.ga6...@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’.
