1

I have Raspbian Jessie installed on my Raspberry PI, and I have a virtual box with a fresh install of Debian Jessie for amd64 with the armhf architecture enabled, and with the ARM cross toolchain from Emdebian installed. This is gcc 4.9 on both systems, and libc6 2.19-17 on both systems.

However, when I cross-compile a simple hello world on amd64:

root@vbox:~/# arm-linux-gnueabihf-gcc-4.9 -g hello.c -o "hello.arm"

and try to run it on the ARM device, I get a segfault:

pi@raspberrypi ~/host/raspi $ gdb hello.arm
GNU gdb (Raspbian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from hello.arm...done.
(gdb) run
Starting program: /home/pi/host/raspi/hello.arm

Program received signal SIGSEGV, Segmentation fault.
0x0005f4be in ?? ()
(gdb)

Any thoughts as to what's wrong here?

naasking
  • 191
  • 1
  • 2
  • 5
  • What does file report for the executable on the Pi? – joan Apr 21 '15 at 12:34
  • hello.arm: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=469ec785414ff74b4b146daf7eb461097842f50b, not stripped – naasking Apr 21 '15 at 13:03
  • Unfortunately that looks okay to me. For a random binary I get /bin/mknod: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=577c091e4bffa2fffefa928740a9ca0f7c918e89, stripped which doesn't seem to have any significant difference. – joan Apr 21 '15 at 13:06
  • hello.arm segfaults even when built statically. However, at least here I get more meaningful output from gdb: Program received signal SIGSEGV, Segmentation fault. 0x00010ec0 in _dl_tls_setup () – naasking Apr 21 '15 at 13:11

2 Answers2

3

There's a gotcha here created by the lack of specificity with ARM cross-compilers. ARM actually refers to a family or series of instruction sets which are not necessarily compatible with one another.

Currently, by far the most common ARM architecture is ARMv7. This is widely used in mobile devices such as smartphones (including Apple's) and low-power embedded devices, which are often linux based. Hence, most linux distributions now come with x86 based cross-compilers which target ARMv7.

The Pi 2's quad core processor is ARMv7, but the previous A/B/+ models are not. They're the somewhat more obscure ARMv6; more precisely, to cross-compile for the pi (except the 2) you need something that targets armv6j.

This lack of specificity extends to other tools. Here's what file has to say about a stock executable from pidora, compiled for armv6j:

ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV) ...

And here's what it has to say about a stock executable from Fedora 21 ARM, compiled for armv7:

ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV) ...

Exactly the same thing. ARMv7 is backward compatible with ARMv6, meaning it includes all the commands from the latter, so if you try and run an ARMv6 binary on an ARMv7 system it will work. This is why the same Raspbian works on the pi 2. But ARMv6 is not forward compatible, because ARMv7 includes instructions it does not understand. If you try and run an ARMv7 binary on an ARMv6 system, you'll probably get:

'foobar' terminated by signal SIGILL (Illegal instruction)

Of course that's not the error you are getting. But if you are using a stock distro ARM cross-compiler, it's an ARMv7 compiler and the executables will only work on the Pi 2, not an A/B/+ model.

Community
  • 1
goldilocks
  • 56,430
  • 17
  • 109
  • 217
  • I suspected it might be something like this. And I take there is no standard repository for Raspberry PI cross tools, I'd instead have to either manually compile gcc and figure out the target invocations required, or I'd have to manually install binaries like this: https://github.com/raspberrypi/tools – naasking Apr 21 '15 at 13:26
  • Yeah, various people have put one out there for the pi. [Here's what worked for me](http://raspberrypi.stackexchange.com/a/14588/5538). – goldilocks Apr 21 '15 at 13:29
  • Looks like it could work, but it keeps failing saying it can't find libtool >= 1.5.26. I have libtool 2.4 installed. – naasking Apr 21 '15 at 14:13
  • Hmmph. Part of the reason I wrote all that down is because it was a real PITA. Possibly it means it wants a v. 1.x...although the one I have here where that was built is 2.4.2. – goldilocks Apr 21 '15 at 14:18
0

I also tried to cross compile an hello world on ubuntu x86 for a Raspberry PI2. I used to transfer the executable to PI2 with filezilla ftp client. After hours of investigation I checked the md5 on ubuntu and PI2 and they were different. I discovered filezilla was choosing ASCII as transfer mode...

a.dibacco
  • 101