Update on wip-arm-bootstrap

[Jan Nieuwenhuizen]

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