qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Crash when running hello-world unikernel for ARM


From: Ajay Garg
Subject: Re: [Qemu-devel] Crash when running hello-world unikernel for ARM
Date: Tue, 10 Apr 2018 09:51:31 +0530

Following is the gdb details :

##########################################################################################
address@hidden:~/rumprun-arm32$ gdb --args qemu-system-arm -machine virt
-nographic -kernel helloer.bin
GNU gdb (Debian 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 qemu-system-arm...(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/bin/qemu-system-arm -machine virt -nographic
-kernel helloer.bin
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0xb388f290 (LWP 3140)]
qemu: fatal: Trying to execute code outside RAM or ROM at 0x00100000

R00=00000000 R01=00000000 R02=00000000 R03=00000000
R04=00000000
Program received signal SIGUSR1, User defined signal 1.
[Switching to Thread 0xb388f290 (LWP 3140)]
0xb5e80f42 in write () at ../sysdeps/unix/syscall-template.S:81
81    ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0  0xb5e80f42 in write () at ../sysdeps/unix/syscall-template.S:81
#1  0xb5e45c84 in _IO_new_file_write (f=0xb5ee29f0 <_IO_2_1_stderr_>,
    data=0xb388c5a0, n=12) at fileops.c:1253
#2  0xb5e454b2 in new_do_write (address@hidden <_IO_2_1_stderr_>,
    address@hidden "R04=00000000", address@hidden)
    at fileops.c:530
#3  0xb5e460d0 in _IO_new_file_xsputn (f=0xb5ee29f0 <_IO_2_1_stderr_>,
    data=<optimized out>, n=12) at fileops.c:1335
#4  0xb5e2bc8e in buffered_vfprintf (address@hidden <_IO_2_1_stderr_>,
    address@hidden "R%02d=%08x", args=...) at vfprintf.c:2369
#5  0xb5e28418 in _IO_vfprintf_internal (s=0xb5ee29f0 <_IO_2_1_stderr_>,
    format=0x263e68 "R%02d=%08x", address@hidden "pg\201", ap=...,
    address@hidden) at vfprintf.c:1296
#6  0xb5e2ee00 in __fprintf (stream=<optimized out>,
    format=0x263e68 "R%02d=%08x") at fprintf.c:32
#7  0x000dc352 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
#0  0xb5e80f42 in write () at ../sysdeps/unix/syscall-template.S:81
#1  0xb5e45c84 in _IO_new_file_write (f=0xb5ee29f0 <_IO_2_1_stderr_>,
    data=0xb388c5a0, n=12) at fileops.c:1253
#2  0xb5e454b2 in new_do_write (address@hidden <_IO_2_1_stderr_>,
    address@hidden "R04=00000000", address@hidden)
    at fileops.c:530
#3  0xb5e460d0 in _IO_new_file_xsputn (f=0xb5ee29f0 <_IO_2_1_stderr_>,
    data=<optimized out>, n=12) at fileops.c:1335
#4  0xb5e2bc8e in buffered_vfprintf (address@hidden <_IO_2_1_stderr_>,
    address@hidden "R%02d=%08x", args=...) at vfprintf.c:2369
#5  0xb5e28418 in _IO_vfprintf_internal (s=0xb5ee29f0 <_IO_2_1_stderr_>,
    format=0x263e68 "R%02d=%08x", address@hidden "pg\201", ap=...,
    address@hidden) at vfprintf.c:1296
#6  0xb5e2ee00 in __fprintf (stream=<optimized out>,
    format=0x263e68 "R%02d=%08x") at fprintf.c:32
#7  0x000dc352 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
##########################################################################################

On Tue, Apr 10, 2018 at 9:44 AM, Ajay Garg <address@hidden> wrote:
> Thanks Alex for the reply ..
>
>>
>> Can you run under -s -S and gdb step the *guest* and see where it ends
>> up. The above error is usually indicative of the guest going off into
>> the weeds somewhere because the hardware isn't what it expects.
>>
>
> So, after your reply that it might be because of the
> hardware-mismatch, I kinda took a detour, and installed a arm32 "virt"
> machine on qemu on a x86_64 host, as per the steps at
> https://translatedcode.wordpress.com/2016/11/03/installing-debian-on-qemus-32-bit-arm-virt-board/
>
> All went fine, and then I compiled rumprun on this "virt" guest.
> Finally, upon running, I now get this :
>
> ##########################################################################################
> address@hidden:~/rumprun-arm32$ qemu-system-arm -machine virt -nographic
> -kernel helloer.bin
> qemu: fatal: Trying to execute code outside RAM or ROM at 0x00100000
>
> R00=00000000 R01=00000000 R02=00000000 R03=00000000
> R04=00000000 R05=00000000 R06=00000000 R07=00000000
> R08=00000000 R09=00000000 R10=00000000 R11=00000000
> R12=00000000 R13=00000000 R14=00000000 R15=00100000
> PSR=400001d3 -Z-- A svc32
> s00=00000000 s01=00000000 d00=0000000000000000
> s02=00000000 s03=00000000 d01=0000000000000000
> s04=00000000 s05=00000000 d02=0000000000000000
> s06=00000000 s07=00000000 d03=0000000000000000
> s08=00000000 s09=00000000 d04=0000000000000000
> s10=00000000 s11=00000000 d05=0000000000000000
> s12=00000000 s13=00000000 d06=0000000000000000
> s14=00000000 s15=00000000 d07=0000000000000000
> s16=00000000 s17=00000000 d08=0000000000000000
> s18=00000000 s19=00000000 d09=0000000000000000
> s20=00000000 s21=00000000 d10=0000000000000000
> s22=00000000 s23=00000000 d11=0000000000000000
> s24=00000000 s25=00000000 d12=0000000000000000
> s26=00000000 s27=00000000 d13=0000000000000000
> s28=00000000 s29=00000000 d14=0000000000000000
> s30=00000000 s31=00000000 d15=0000000000000000
> s32=00000000 s33=00000000 d16=0000000000000000
> s34=00000000 s35=00000000 d17=0000000000000000
> s36=00000000 s37=00000000 d18=0000000000000000
> s38=00000000 s39=00000000 d19=0000000000000000
> s40=00000000 s41=00000000 d20=0000000000000000
> s42=00000000 s43=00000000 d21=0000000000000000
> s44=00000000 s45=00000000 d22=0000000000000000
> s46=00000000 s47=00000000 d23=0000000000000000
> s48=00000000 s49=00000000 d24=0000000000000000
> s50=00000000 s51=00000000 d25=0000000000000000
> s52=00000000 s53=00000000 d26=0000000000000000
> s54=00000000 s55=00000000 d27=0000000000000000
> s56=00000000 s57=00000000 d28=0000000000000000
> s58=00000000 s59=00000000 d29=0000000000000000
> s60=00000000 s61=00000000 d30=0000000000000000
> s62=00000000 s63=00000000 d31=0000000000000000
> FPSCR: 00000000
> Aborted
> ##########################################################################################
>
>
> Additionally, I compiled rumprun on a beaglebone-green-wireless (arm32
> machine), and did the same test.
> (Fortunately), I got the exact same stacktrace as above, so I guess
> it's no more  an issue with hardware-mismatch now ..
>
> Not sure if this is an issue with qemu now, or rumprun ...
>
>
> Thanks and Regards,
> Ajay



-- 
Regards,
Ajay



reply via email to

[Prev in Thread] Current Thread [Next in Thread]