From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id UJmrOEGbJ2DaWAAA0tVLHw (envelope-from ) for ; Sat, 13 Feb 2021 09:26:25 +0000 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id IqxvNEGbJ2ABCAAA1q6Kng (envelope-from ) for ; Sat, 13 Feb 2021 09:26:25 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 6230321532 for ; Sat, 13 Feb 2021 10:26:25 +0100 (CET) Received: from localhost ([::1]:57728 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lArC4-0000e4-Gz for larch@yhetil.org; Sat, 13 Feb 2021 04:26:24 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38908) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lArBk-0000da-Lc; Sat, 13 Feb 2021 04:26:05 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:45907) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lArBa-0002Ga-3F; Sat, 13 Feb 2021 04:25:56 -0500 Received: from [2001:980:1b4f:1:42d2:832d:bb59:862] (port=39232 helo=dundal.janneke.lilypond.org) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lArBQ-0007Wy-PY; Sat, 13 Feb 2021 04:25:48 -0500 From: Jan Nieuwenhuizen To: guix-devel@gnu.org Subject: Update on wip-arm-bootstrap Organization: AvatarAcademy.nl X-Url: http://AvatarAcademy.nl Date: Sat, 13 Feb 2021 10:25:39 +0100 Message-ID: <87blco9v58.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: bug-mes@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.86 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: 6230321532 X-Spam-Score: -2.86 X-Migadu-Scanner: scn0.migadu.com X-TUID: 4pvvm/yolku3 Hi, Last month, we found that --8<---------------cut here---------------start------------->8--- // prereq.c #if defined __GNUC__ && defined __GNUC_MINOR__ # define __GNUC_PREREQ(maj, min) \ ((__GNUC__ << 16) + __GNUC_MINOR__ >=3D ((maj) << 16) + (min)) #else # define __GNUC_PREREQ(maj, min) 0 #endif #if __GNUC_PREREQ (3,1) && !defined __GNUG__ #error gcc too new #endif --8<---------------cut here---------------end--------------->8--- compiled wrong with gcc-core-mesboot0: --8<---------------cut here---------------start------------->8--- 16:34:37 janneke@novena:~/src/guix [env] $ /gnu/store/h0v5by5fgvcqi5gkhq0yi7ma6nhyp2ql-gcc-core-mesboot0-2.95.3/bin/= gcc -S prereq.c=20 prereq.c:8: warning: integer constant out of range prereq.c:8: warning: integer constant out of range prereq.c:8: warning: integer constant out of range prereq.c:9: #error gcc too new [1]16:35:27 janneke@novena:~/src/guix [env] --8<---------------cut here---------------end--------------->8--- Well, Danny identified the problem in gcc-core-mesboot0: --8<---------------cut here---------------start------------->8--- //noadd.c #if (1 >=3D 10) #endif --8<---------------cut here---------------end--------------->8--- =3D> --8<---------------cut here---------------start------------->8--- $ /gnu/store/h0v5by5fgvcqi5gkhq0yi7ma6nhyp2ql-gcc-core-mesboot0-2.95.3/bin/= gcc -E noadd.c noadd.c:1: warning: integer constant out of range # 1 "noadd.c" --8<---------------cut here---------------end--------------->8--- which lead to --8<---------------cut here---------------start------------->8--- "#if (5)" works "#if (10)" is broken [13:10] any idea where that code "lives" ? gcc/cppexp.c [13:13] Maybe "case CPP_NUMBER" -> parse_number --8<---------------cut here---------------end--------------->8--- That turned out to be caused by a problems in Mes lib c --8<---------------cut here---------------start------------->8--- janneke: I fixed the __*div* functions in mes a little--commit https://git.savannah.gnu.org/cgit/mes.git/commit/?id=3D33cf5ea5e820e21a8f46= de7df08a8b49bb8f62ee --8<---------------cut here---------------end--------------->8--- functions that used to be stubs on x86, need a working implementation on ARM. Okay, that makes sense. Danny pushes an update for Mes to wip-arm-bootstrap. [13:05:53] And then ../sysdeps/unix/sysv/linux/arm/sigaction.c:139= : `__NR_sigaction' undeclared (first use in this function) [13:07:32] dannym: that's great! [13:08:31] dannym: seems familiar [13:09:04] dannym: when trying to get glibc-mesboot0 built, i was= collecting a number of patches [13:10:10] i didn't share or push these yet (or maybe reverted), = as they became more uninformed and hacky as i went along Okay, Janneke sorts-out glibc patches for ARM and pushes an update to wip-arm-bootstrap. And now, we can build glibc-mesboot0! --8<---------------cut here---------------start------------->8--- [21:39:23] dannym: amazing: /gnu/store/jgkf60r29blzhrg0w3dar3rz06= xwkx5q-glibc-mesboot0-2.2.5 [21:39:37] \o/ [21:40:34] yeah \o/ --8<---------------cut here---------------end--------------->8--- As we were stuck on building the first glibc for quite some time now, this was something to celebrate! Sadly, the gcc-core-mesboot0 + glibc-mesboot0 combo produces executables that "Illegal instruction" upon syscalls. --8<---------------cut here---------------start------------->8--- Program received signal SIGILL, Illegal instruction. 0x000276bc in __writev (fd=3D2, vector=3D0xbeffd010, count=3D10) at ../sysd= eps/unix/sysv/linux/writev.c:51 51 bytes_written =3D INLINE_SYSCALL (writev, 3, fd, CHECK_N (vector, coun= t), count); (gdb) disas /r Dump of assembler code for function __writev: 0x00027698 <+0>: 0d c0 a0 e1 mov r12, sp 0x0002769c <+4>: f0 dd 2d e9 push {r4, r5, r6, r7, r8, r10, r11, r12, lr= , pc} 0x000276a0 <+8>: 04 b0 4c e2 sub r11, r12, #4 0x000276a4 <+12>: 02 50 a0 e1 mov r5, r2 0x000276a8 <+16>: 01 70 a0 e1 mov r7, r1 0x000276ac <+20>: 00 60 a0 e1 mov r6, r0 0x000276b0 <+24>: 6c a0 9f e5 ldr r10, [pc, #108] ; 0x27724 <__writev+14= 0> 0x000276b4 <+28>: 00 80 9a e5 ldr r8, [r10] 0x000276b8 <+32>: 14 00 00 ef svc 0x00000014 =3D> 0x000276bc <+36>: 00 40 a0 e1 mov r4, r0 --8<---------------cut here---------------end--------------->8--- Let's try to bisect where the problem is; we now have tree first candidates: gcc-core-mesboot0, glibc-mesboot0 and binutils-mesboot0. Luckily, Debian "woody" carries an almost compatible set. Doing someting like --8<---------------cut here---------------start------------->8--- guix environment --ad-hoc binutils patchelf wget wget http://archive.debian.org/debian/pool/main/g/glibc/libc6_2.2.5-11.8_ar= m.deb ar x libc6_2.2.5-11.8_arm.deb=20 tar xf data.tar.gz=20 wget http://archive.debian.org/debian/pool/main/g/glibc/libc6-dev_2.2.5-11.= 8_arm.deb ar x libc6-dev_2.2.5-11.8_arm.deb=20 tar xf data.tar.gz=20 wget http://archive.debian.org/debian/pool/main/b/binutils/binutils_2.12.90= .0.1-4_arm.deb ar x binutils_2.12.90.0.1-4_arm.deb=20 tar xf data.tar.gz=20 wget http://archive.debian.org/debian/pool/main/g/gcc-2.95/gcc-2.95_2.95.4-= 27_arm.deb ar x gcc-2.95_2.95.4-27_arm.deb tar xf data.tar.gz=20 patchelf --print-interpreter usr/bin/as /lib/ld-linux.so.2 patchelf --set-interpreter $PWD/lib/ld-linux.so.2 usr/bin/as usr/bin/as Illegal instruction --8<---------------cut here---------------end--------------->8--- Hmm...does it? Using gdb, the problem looks... --8<---------------cut here---------------start------------->8--- Program received signal SIGILL, Illegal instruction. 0xb6ff3b6c in writev () from /home/janneke/src/debian/lib/ld-linux.so.2 (gdb) disas /r Dump of assembler code for function writev: [..] 0xb6ff3b58 <+28>: 05 20 a0 e1 mov r2, r5 0xb6ff3b5c <+32>: 07 10 a0 e1 mov r1, r7 0xb6ff3b60 <+36>: 00 80 90 e5 ldr r8, [r0] 0xb6ff3b64 <+40>: 06 00 a0 e1 mov r0, r6 0xb6ff3b68 <+44>: 92 00 90 ef svc 0x00900092 =3D> 0xb6ff3b6c <+48>: 00 40 a0 e1 mov r4, r0 --8<---------------cut here---------------end--------------->8--- ...pretty familiar. So, what's going on here? Do the "woody" binaries not run on novena? --8<---------------cut here---------------start------------->8--- $ uname -a Linux novena 5.9.11-gnu #1 SMP 1 armv7l GNU/Linux 10:11:54 janneke@novena:~/src/debian [env] $ readelf -h usr/bin/as ELF Header: Magic: 7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00=20 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: ARM ABI Version: 0 Type: EXEC (Executable file) Machine: ARM Version: 0x1 Entry point address: 0x9c34 Start of program headers: 52 (bytes into file) Start of section headers: 267716 (bytes into file) Flags: 0x2, GNU EABI, Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 7 Size of section headers: 40 (bytes) Number of section headers: 25 Section header string table index: 24 --8<---------------cut here---------------end--------------->8--- Overdrive1 seems to think so, and respects "fail early" --8<---------------cut here---------------start------------->8--- $ uname -a Linux overdrive1 5.8.13-gnu #1 SMP 1 aarch64 GNU/Linux 10:18:39 janneke@overdrive1:~/src/debian [env] $ usr/bin/as bash: usr/bin/as: cannot execute binary file: Exec format error --8<---------------cut here---------------end--------------->8--- Hmm? Greetings, Janneke & Danny --=20 Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar=C2=AE http://AvatarAcademy.com