"(gdb) launches" crash when running executable files on qemu emulated weapon architecture "

This is my first message, I am writing to you, because this time I can’t really get away from this problem.

I am taking a course on gdb. In subsequent lessons, the course covers debugging the ARM architecture, so I’m presented with a setting that allows me to emulate this situation.

My current setup consists of:

  • Windows 10: physical host
    • Ubuntu 12.04.5 LTS: guest OS via Oracle Virtual Box in Windows 10
      • Linux debian-armel 2.6.32-5-universal: guest os via qemu 2.8.0 on Ubuntu

The ARM Debian image comes from https://people.debian.org/~aurel32/qemu/armel/

Image is launched using

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 changed sources.list and apt.conf so that apt works as the distribution is pretty outdated. I updated and updated and installed gcc and gdb.

The problem occurs 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 get this message and execution freezes until I can 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 ]--- 

Can someone point me in a direction to solve this problem?

Thanks in advance!

+6
source share
1 answer

Not my answer, but for the question to be marked as closed:

This is probably a mistake in the guest kernel (although it is not), so I would like to start with a later kernel than 2.6.32, which is now almost 8 years old. - Peter Maydell 3 March at 13:14

0
source

Source: https://habr.com/ru/post/1015434/


All Articles