> Hmm, I'm not seeing this (I did see something like this before). You > *are* on > > e44b6b7eed squash! commencement: binutils-mesboot0: Support ARM. > > right? Yes, but your gcc-mesboot.sh hardcoded a specific (older) path. Sorry. With updated gcc-mesboot.sh I get: Program terminated with signal SIGSEGV, Segmentation fault. (gdb) bt #0 _IO_setb (f=0x4, b=0x4b , eb=0x4c , a=0) at genops.c:387 #1 0x00008f1c in _IO_doallocbuf (fp=0x4) at genops.c:406 #2 0x0002409c in _IO_new_file_overflow (f=0x6cde0 <_IO_2_1_stdout_>, ch=0) at fileops.c:576 #3 0x000249b0 in _IO_new_file_xsputn (f=0x6cde0 <_IO_2_1_stdout_>, data=0xbecfd313, n=1) at fileops.c:962 #4 0x0001a09c in _IO_vfprintf (s=0x6cde0 <_IO_2_1_stdout_>, format=0xbecfd313 "2\224\323ΟΎ\001", ap=) at vfprintf.c:1523 #5 0x00008828 in printf (format=0x525f0 "%d\n") at printf.c:33 #6 0x00008214 in main (argc=, argv=) at test.c:6 Looks like a NULL pointer for a FILE* ? Or is gdb just weird? glibc-2.2.5/libio/genops.c: void _IO_setb (f, b, eb, a) _IO_FILE *f; char *b; char *eb; int a; { if (f->_IO_buf_base && !(f->_flags & _IO_USER_BUF)) <---------------- here FREE_BUF (f->_IO_buf_base, _IO_blen (f)); f->_IO_buf_base = b; f->_IO_buf_end = eb; if (a) f->_flags &= ~_IO_USER_BUF; else f->_flags |= _IO_USER_BUF; } int _IO_new_file_overflow (f, ch) _IO_FILE *f; int ch; { if (f->_flags & _IO_NO_WRITES) /* SET ERROR */ { f->_flags |= _IO_ERR_SEEN; __set_errno (EBADF); return EOF; } /* If currently reading or no buffer allocated. */ if ((f->_flags & _IO_CURRENTLY_PUTTING) == 0 || f->_IO_write_base == 0) { /* Allocate a buffer if needed. */ if (f->_IO_write_base == 0) { _IO_doallocbuf (f); <------------- here _IO_setg (f, f->_IO_buf_base, f->_IO_buf_base, f->_IO_buf_base); } Maybe add some debugging statements there? But printf is broken, so maybe use write(2, "foo\n", 4) and similar. (I'm not sure about just defining -D__ARM_EABI__=1 as you are doing--after all, it entails further stack alignment requirements. Maybe try +++ glibc-2.2.5/sysdeps/unix/sysv/linux/arm/sysdep.h 2021-02-22 00:44:43.300906460 +0100 @@ -29,8 +29,8 @@ of the kernel. But these symbols do not follow the SYS_* syntax so we have to redefine the `SYS_ify' macro here. */ #undef SYS_ify -#define SWI_BASE (0x900000) -#define SYS_ify(syscall_name) (__NR_##syscall_name) +#define SWI_BASE (0x000000) +#define SYS_ify(syscall_name) (__NR_##syscall_name & 0x8fffff) as a more minimal patch? Not sure...)