Segfault when using arm-linux-gnueabi-g++ -o, no problems without -o

2
votes

I am trying to cross-compile some code to run on an ARM Cortex A8 (the AR.Drone 2.0, if it makes a difference).

I installed Ubuntu 12.04 LTS 32-bit on my Virtualbox (with Windows 7 64-bit host), and my cross-compiled code works perfectly fine.

On another computer, I installed the same version of Ubuntu (without Virtualbox), but I'm encountering weird errors. The smallest code snippet I've gotten that demonstrates the problem is a "hello world" program (I can show the code here if necessary):

  • I've executed: sudo apt-get install g++ gcc-arm-linux-gnueabi g++-arm-linux-gnueabi
  • When I run arm-linux-gnueabi-g++ hello.cpp, the cross-compiled code (a.out) works fine on the ARM.
  • When I run arm-linux-gnueabi-g++ -o hello hello.cpp, I get a segfault when executing hello on the ARM.
  • I've compared the outputs of file hello and read-elf -A hello when compiled with Virtualbox and without, and they look identical.
  • I don't have gdb on the ARM, so I can't gdb it to find out where the segfault is coming from.

Any ideas/solutions would be greatly appreciated. I did not have to set up anything special on my Virtualbox, so I'm quite confused why the PC without Virtualbox cannot cross-compile correctly.

3
c++armcross-compiling
try to check dmesg (cat /proc/kmsg) or if you can use strace to see where it is failing. – auselen
For a simple "hello world", comparing the disassembly (arm-linux-gnueabi-objdump -d) is also a viable option. – Notlikethat

3 Answers

4
votes

If you are using Filezilla or the like make sure that you are not using "auto" as transfer mode. Choose "binary", I had the very same problem transferring a simple hello world program from my ubuntu to an arm target (Xilinx Zynq) and after hours spent investigating I checked the md5 of the executable both on ubuntu and the target discovering that they were different.

0
votes

have you tried debugging the seg fault using gdb or similar?

build your code in debug mode (output debug symbols), and follow the steps described here

the call stack is particularly useful.

The chances are that there is a run time dependency missing in your environment.

0
votes

I am facing the same issue, even on two machines (a VM and a direct install), and I was not able to solve it yet.

However, the following "workaround" worked for me (this essentially installs the ARM Toolchain by Mentor Graphics, formerly known as Code Sourcery, to cross-compile for the AR Drone 2):

  • Download "arm-2012.03-57-arm-none-linux-gnueabi.bin" from here

  • Install it by typing (needs sudo if you want to install to system dirs)

    $ chmod +x arm-2012.03-57-arm-none-linux-gnueabi.bin
$ ./arm-2012.03-57-arm-none-linux-gnueabi.bin

    and step through the (graphical) setup.

  • Finally, compile your sources with the binaries located in

    $INSTALL_PATH/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin/

    For example:

    ./arm-none-linux-gnueabi-gcc -march=armv7-a hello.c -o helloworld

    The resulting binary should be executable w/o any problems. ;-)

For the sake of completeness / all other readers: You can copy the binary to the Drone by using any FTP client (e. g., ftp, WinSCP, FileZilla, ...) connecting to 192.168.1.1 (assumes your host has connected to the WLAN created by the Drone). To execute it, set the executable bit by chmod +x helloworld and run it ./helloworld.

BTW: There isn't a "debugger" on the AR Drone 2 but you can use gdb remote debugging by starting gdbserver on the device (this tool is already on the device), see (e. g.) http://ftp.gnu.org/old-gnu/Manuals/gdb/html_node/gdb_130.html