I'm going through a course on gdb. In the later lessons the course covers debugging on ARM architecture, so I'm presented a setup that allows me to emulate such situation.
My current setup comprises:
Windows 10: physical host
Ubuntu 12.04.5 LTS: guest os via Oracle Virtual Box on Windows 10
Linux debian-armel 2.6.32-5-versatile: guest os via qemu 2.8.0 on Ubuntu
The ARM Debian image comes from https://people.debian.org/~aurel32/qemu/armel/
The image is launched with
qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.32-5-versatile -initrd initrd.img-2.6.32-5-versatile -hda debian_squeeze_armel_standard.qcow2 -append "root=/dev/sda1" -m 256 -redir tcp:2222::22
I modified the sources.list and apt.conf to allow apt to work, since the distro is quite outdated. I updated and upgraded and installed gcc and gdb.
The problem arises when trying to debug; I can load executables in gdb:
root#debian-armel:~/video-11/video-11# file ./main
./main: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
but when I try to run it inside gdb, I receive this message and the execution hangs, until I'm able to kill the gdb process from another console:
------------[ cut here ]------------
WARNING: at /build/linux-2.6-fIxTVd/linux-2.6-2.6.32/debian/build/source_armel_none/kernel/sched.c:2628 wake_up_process+0x2c/0x48()
Modules linked in: loop sg smc91x sr_mod mii cdrom psmouse evdev ext3 jbd mbcache sd_mod crc_t10dif sym53c8xx scsi_transport_spi scsi_mod
[<c002b068>] (unwind_backtrace+0x0/0xdc) from [<c0046f88>] (warn_slowpath_common+0x4c/0x80)
[<c0046f88>] (warn_slowpath_common+0x4c/0x80) from [<c00446f0>] (wake_up_process+0x2c/0x48)
[<c00446f0>] (wake_up_process+0x2c/0x48) from [<c0026930>] (arch_ptrace+0x214/0x4bc)
[<c0026930>] (arch_ptrace+0x214/0x4bc) from [<c00508d8>] (sys_ptrace+0x9c/0x164)
[<c00508d8>] (sys_ptrace+0x9c/0x164) from [<c0024ec0>] (ret_fast_syscall+0x0/0x28)
---[ end trace 98ab50bc781b314f ]---
How can I resolve this issue?
Not my answer, but to enable the question to be marked as closed:
This is likely a bug in the guest kernel (though not certainly so), so
I would start by trying with a more recent kernel than 2.6.32, which
is now nearly 8 years old. – Peter Maydell Mar 3 '17 at 13:14
Related
Goal:: "Is to emulate imx6 Quad G4 device with QEMU or any other emulation software. I have got u-boot-mx6q-4g.bin and mon_imx_minikernel.bin files from the actual working device"
I m novice to emulation world. Honestly don't know where to start.
I believe QEMU supports "imx6 Quad 4G ram devices" with sabrelite board but qemu version installed on host machine Ubuntu 16.04 is missing sabrelite board, did try to install qemu-user-static but still no luck.
qemu-system-arm -M help
Supported machines list is missing sabrelite in my installation.
qemu-system-arm -version
QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.32), Copyright (c) 2003-2008 Fabrice Bellard
Currently my host machine is Ubuntu 16.04
$uname -a
Linux mike 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Any guidance is very much appreciated
apt upgrade qemu* has not upgraded the OS.
However Sabrelite and more machine options showed up after upgrading host OS to 18.04.
In process of upgrade it upgraded the QEMU also.
I have installed Debian on qemu 64-bit ARM (followed this tutorial)
uname -a
Linux test 4.9.0-7-arm64 #1 SMP Debian 4.9.110-1 (2018-07-05) aarch64 GNU/Linux
and I am trying to run 32 bit elf files on it, but some work some don't:
bash: ./file_2: cannot execute binary file: Exec format error
running file command on the file that runs, I get:
file_1: ELF 32-bit LSB executable, ARM, EABI4 version 1 (SYSV), statically linked, not stripped
and the one that does not run:
file_2: ELF 32-bit LSB executable, ARM, version 1 (ARM), statically
linked, stripped
and both work on 32bit system(armv7l)
the only difference is that SYSV/ARM version.
is there any work around without recompiling the kernel?(read this post)
As the linked post suggests, this requires CONFIG_COMPAT to be enabled in the kernel. On the other hand I would be surprised if your kernel didn't have it -- the Debian 4.9.0-4 kernel I have from doing that tutorial does set CONFIG_COMPAT. You can check whether your kernel has it enabled by looking at the config file for it which will be in /boot/ in the guest. If it's missing then you need a new kernel, and nothing else will help.
However in your case you do have CONFIG_COMPAT, and some executables work. The difference between the ones that work and the ones that don't is that the working ones are EABI, and the non-working ones are OABI. OABI is an old and obsolete ABI for 32-bit Arm Linux binaries (the "O" stands for "old", and it's been a bad choice for a decade or so...) and it is not supported by the 64-bit kernel's CONFIG_COMPAT. You'll need to rebuild those binaries from source as EABI binaries if you want to run them under a 64-bit kernel.
I install qemu-system-arm in Ubuntu 16.04 to run firmware of dlink DIR868L. But when I use the command chroot ./squashfs-root/ /bin/sh, it just shows Illegal instruction. I get squashfs-root/from DIR868LB1_FW203b01.bin by binwalk and I am sure that /bin/sh exists in squashfs-root/.
I start qemu by sudo qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.32-5-versatile -initrd initrd.img-2.6.32-5-versatile -hda debian_squeeze_armel_standard.qcow2 -append "root=/dev/sda1" -net nic -net tap and use scp to cpoy squashfs-root/ into virtual mechine. And I met the same problem when using debian_wheezy_armel_standard.qcow2
What should I do ? It has bothered me for the whole afternoon.
Or can anyone give me an example to run the arm firmware in qemu ? I only find lots of examples using firmware based on mips.
Thanks a lot !
The problem is almost certainly because whatever CPU is in the DIR868lL is newer than the ARM926 CPU that the "versatilepb" board has. If the binaries from that firmware are built to use newer instructions, then running them in an emulation of an older CPU will result in an 'illegal instruction' signal, just as if you'd run them on real older ARM hardware.
This is similar to taking binaries that were built for a Core2 Duo and trying to run them on your old Pentium system: it won't work.
I am trying to run a cross compiled file with qemu, but get "Permission denied" / "Operation not permitted" erros (even when running with sudo).
I am running Debian 8.7 i386 in a VirtualBox 5.0.22, cross compiling to ARM. The cross-compile setup is described in more detail here http://exploringbeaglebone.com/chapter7.
The cross-compiled file runs fine when copied over to a native ARM device.
#include <stdio.h>
int main()
{
printf("Hello ARM\n";
return 0
}
Build it:
# arm-linux-gnueabihf-gcc testARM.c -o testARM -Wall
# file testARM
# testARM: ELF 32-bit LSB executable, ARM, EABI5 version1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=...., not stripped
Trying to run directly gives
# ./testARM
# bash: ./testARM: Permission denied
Trying to run via qemu
# qemu-arm ./testARM
# ./testARM: Operation not permitted
Same with sudo
# sudo qemu-arm ./testARM
# ./testARM: Operation not permitted
Running it native on the platform it was cross-compiled for works
beaglebone:~$ ./testARM
Hello ARM
Of course, I also checked the file permissions ( rwxr-xr-x )
Googling showed me someone else with the same issue, but no solution.
My best guess is that running qemu from within VirtualBox is causing the issue, but there are multiple reports that it just works. Host CPU is an Intel Core i7.
What could be the issue? I would like to run automated tests as part of the build process, thats why a working setup with qemu would be nice.
As #TobySpeight supposed, this was just a filesystem mount flag issue. It is described on stackexchange here.
Using the exec flag for mounting resolved the issue: mount -o remount,exec filesystem
I'm trying to build a simple kernel module and run it on the Raspberry Pi. I have downloaded kernel sources from official raspberry site, but they have slightly different kernel version then my raspbian on board.
Is it necessary to have fully identical version of kernel on source and target machine to run kernel module? I have this on my Raspberry Pi
$ uname -a
Linux raspberrypi 4.4.11+ #888 Mon May 23 20:02:58 BST 2016 armv6l GNU/Linux
And this about my module
$ modinfo ./threads.ko
filename: /lib/modules/4.4.11+/kernel/mymodules/./threads.ko
version: 0.0.1
description: Kernel threads example
author: xxxxxx
license: GPL
srcversion: C906582EC824D2D8DA76BFB
depends:
vermagic: 4.4.13+ mod_unload modversions ARMv6
As you see: "4.4.11+" vs "4.4.13+"...
Why am I asking? I have a error when insert module:
$ sudo insmod ./threads.ko
insmod: ERROR: could not insert module ./threads.ko: Invalid module format
And do not understand, it is valuable difference in last number of version of the kernel or there is another problem.
Is it necessary to have fully identical version of kernel on source and target machine to run kernel module?
Yes.