unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Update on wip-arm-bootstrap
@ 2021-02-13  9:25 Jan Nieuwenhuizen
  2021-02-18 17:26 ` Ludovic Courtès
  2021-02-18 17:48 ` Vagrant Cascadian
  0 siblings, 2 replies; 15+ messages in thread
From: Jan Nieuwenhuizen @ 2021-02-13  9:25 UTC (permalink / raw)
  To: guix-devel; +Cc: bug-mes

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


^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2021-02-22 17:45 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-02-13  9:25 Update on wip-arm-bootstrap Jan Nieuwenhuizen
2021-02-18 17:26 ` 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

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).