From: Jan Nieuwenhuizen <janneke@gnu.org>
To: guix-devel@gnu.org
Cc: bug-mes@gnu.org
Subject: Update on wip-arm-bootstrap
Date: Sat, 13 Feb 2021 10:25:39 +0100 [thread overview]
Message-ID: <87blco9v58.fsf@gnu.org> (raw)
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__ >= ((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
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 >= 10)
#endif
--8<---------------cut here---------------end--------------->8---
=>
--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---
<dannym> "#if (5)" works
<dannym> "#if (10)" is broken [13:10]
<janneke> any idea where that code "lives"
<janneke> ?
<dannym> gcc/cppexp.c [13:13]
<dannym> Maybe "case CPP_NUMBER"
<dannym> -> 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---
<dannym> janneke: I fixed the __*div* functions in mes a little--commit
https://git.savannah.gnu.org/cgit/mes.git/commit/?id=33cf5ea5e820e21a8f46de7df08a8b49bb8f62ee
--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] <dannym> And then ../sysdeps/unix/sysv/linux/arm/sigaction.c:139: `__NR_sigaction' undeclared (first use in this function)
[13:07:32] <janneke> dannym: that's great!
[13:08:31] <janneke> dannym: seems familiar
[13:09:04] <janneke> dannym: when trying to get glibc-mesboot0 built, i was collecting a number of patches
[13:10:10] <janneke> 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] <janneke> dannym: amazing: /gnu/store/jgkf60r29blzhrg0w3dar3rz06xwkx5q-glibc-mesboot0-2.2.5
[21:39:37] <dannym> \o/
[21:40:34] <janneke> 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=2, vector=0xbeffd010, count=10) at ../sysdeps/unix/sysv/linux/writev.c:51
51 bytes_written = INLINE_SYSCALL (writev, 3, fd, CHECK_N (vector, count), 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+140>
0x000276b4 <+28>: 00 80 9a e5 ldr r8, [r10]
0x000276b8 <+32>: 14 00 00 ef svc 0x00000014
=> 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_arm.deb
ar x libc6_2.2.5-11.8_arm.deb
tar xf data.tar.gz
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
tar xf data.tar.gz
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
tar xf data.tar.gz
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
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
=> 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
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, <unknown>
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
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
next reply other threads:[~2021-02-13 9:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-13 9:25 Jan Nieuwenhuizen [this message]
2021-02-18 17:26 ` Update on wip-arm-bootstrap Ludovic Courtès
2021-02-21 18:17 ` Jan Nieuwenhuizen
2021-02-22 1:03 ` Danny Milosavljevic
2021-02-18 17:48 ` Vagrant Cascadian
2021-02-18 21:52 ` Jan Nieuwenhuizen
2021-02-19 4:23 ` Danny Milosavljevic
2021-02-19 6:17 ` Jan Nieuwenhuizen
2021-02-21 18:28 ` Jan Nieuwenhuizen
2021-02-22 1:03 ` Danny Milosavljevic
2021-02-22 1:50 ` Danny Milosavljevic
2021-02-22 6:01 ` Jan Nieuwenhuizen
2021-02-22 17:09 ` Danny Milosavljevic
2021-02-22 17:34 ` Danny Milosavljevic
2021-02-22 6:14 ` Jan Nieuwenhuizen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87blco9v58.fsf@gnu.org \
--to=janneke@gnu.org \
--cc=bug-mes@gnu.org \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.