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

[Ajay Garg]

Actually just realised that qemu does support integratorcp as one of
the supported-boards.

Unfortunately, when I use
          qemu-system-arm -machine integratorcp -nographic -kernel helloer.bin
the shell just hangs :(


Following are the details when run through gdb :

##########################################################################
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 integratorcp
-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 596)]

Program received signal SIGUSR1, User defined signal 1.
[Switching to Thread 0xb388f290 (LWP 596)]
memset () at ../ports/sysdeps/arm/memset.S:50
50    ../ports/sysdeps/arm/memset.S: No such file or directory.
(gdb) bt
#0  memset () at ../ports/sysdeps/arm/memset.S:50
#1  0xb65e1c6c in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
##########################################################################

On Wed, Apr 11, 2018 at 12:49 PM, Ajay Garg <address@hidden> wrote:
> Hi All.
>
> Just wondering if there is something specific that needs to changed at
> https://github.com/rumpkernel/rumprun/tree/master/platform/hw/arch/arm/integrator
> in order to get a hello-world app run on "virt" machine?
>
> If so, I would request the rumprun-guys to kindly throw in some light,
> on what needs to be done in order to have something run on a "virt"
> machine in qemu-context.
>
>
> Thanks and Regards,
> Ajay
>
> On Tue, Apr 10, 2018 at 3:49 PM, Ajay Garg <address@hidden> wrote:
>> Thanks Peter .. my sincere gratitude.
>> You pin-pointed the real issue ..
>>
>>
>>
>> On Tue, Apr 10, 2018 at 2:50 PM, Peter Maydell <address@hidden> wrote:
>>> On 10 April 2018 at 09:16, Ajay Garg <address@hidden> wrote:
>>>> On Tue, Apr 10, 2018 at 1:08 PM, Peter Maydell <address@hidden> wrote:
>>>>> What hardware (what CPU, board, etc) is this "rumprun" software
>>>>> expecting to run on?
>>>>
>>>> Yep, just to ensure that there are no cross-compiling issues, I am
>>>> building rumprun on the pseudo-real hardware itself.
>>>> In our case, the pseudo-real hardware are :
>>>>
>>>> a)
>>>> An ARM32 "virt" hardware/machine in a qemu environment
>>>> (https://translatedcode.wordpress.com/2016/11/03/installing-debian-on-qemus-32-bit-arm-virt-board/)
>>>>
>>>> Once I start  this machine, all environment is arm32, and I compile
>>>> rumprun within this environemnt without any cross-compiling.
>>>>
>>>> b)
>>>> A beaglebone-green-wireless.
>>>> This is a arm32 machine bottoms-up, so no question of cross-compiling
>>>> whatsoever here :)
>>>>
>>>> In both cases, I then use qemu-system-arm (on the "virt" machine, and
>>>> beaglebone-green-wireless itself).
>>>
>>> That's telling me what setups you're trying to compile in,
>>> which doesn't correspond necessarily to what the guest
>>> OS is built to run on.
>>>
>>>> One query : It is apparent that there is nested qemu-virtualization in
>>>> step a), could that be an issue?
>>>
>>> Why are you running this in a nested setup? I don't understand
>>> the purpose of doing that. It would be simpler and faster to
>>> just run the guest on a QEMU running in your native host system.
>>>
>>> Assuming this is the source for the guest you're trying to run:
>>>
>>> https://github.com/rumpkernel/rumprun/tree/master/platform/hw/arch
>>>
>>> that suggests that the only Arm board it supports is "integrator"
>>> (which is an absolutely ancient devboard with very little memory,
>>> no PCI and no virtio support). You need to confirm what Arm hardware
>>> this 'rumpkernel' is actually intended to run on, and then give QEMU
>>> the right command line arguments to emulate that hardware. I can't
>>> really help any further, I'm afraid -- you need somebody who knows
>>> about this guest OS.
>>>
>>> thanks
>>> -- PMM
>>
>>
>>
>> --
>> Regards,
>> Ajay
>
>
>
> --
> Regards,
> Ajay



-- 
Regards,
Ajay