On a remote machine, I have qemu-x86_64 installed. Upon trying to find the version of the same I'm presented with the following information.
$ qemu-x86_64 -version
qemu-x86_64 version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard
I'm trying to understand what qemu-kvm is. We will not discuss whole system emulation but only qemu user level emulation.
QEMU supports 2 kinds of emulation : system and user level. In System level emulation the whole system is emulated, and you see that an OS can be booted up using the same. In User level emulation, I'm able to run binaries compiled for an architecture on another architecture. eg: I end up being able to run Linux MIPS binaries on an x86-64 machine.
The version information for qemu-x86_64 on my machine is as follows.
qemu-x86_64 version 2.2.0 (Debian 1:2.2+dfsg-5expubuntu9.2), Copyright (c) 2003-2008 Fabrice Bellard
I'm trying to understand what kind of a qemu-x86_64 is running on the remote machine. Where does kvm fit in? The remote machine is also a 64-bit machine.
When I run a 64-bit binary on the remote machine using its qemu-x86_64, there is no binary translation going on, instead qemu is using KVM to execute the instructions on actual hardware. If so, what part does qemu play? Does it handle privileged instructions? I'm trying to understand where exactly kvm comes into the picture.
In essential binary-translation allows you to run instructions of another architecture (e.g., MIPS) on your physical machine. The target architecture is simulated. For example, the registers in the simulated MIPS machine are just some variables in the QEMU process.
It is true that QEMU can use binary-translation to simulate a x86_64 machine on your computer. However because it's simulating a same architecture, the instructions can actually be directly executed by the host machine without translation! QEMU employs some techniques which use the hardware supports from CPU and OS/software supports such as KVM/Xen. It's still simulation, or you can call it virtualization.
Related
My prof. has asked me to do assembly language programming in linux through NASM X86 64 bit.
Since,I have Mac with me the programs will need to be modified for the MacOS, may be due to the system calls and whatever other reasons.
How shall I replicate the same environment as asked by my prof.in my macos ?
Will it be good enough if I install linux in my Macbook ?
If yes, then what will be the difference between the "Linux in Windows PC" and "Linux in Mac" in terms of programs that I will write ?
If no, then how shall I deal with that ?
Will it be good enough if I install linux in my Macbook ?
Installing it in a VM might be more convenient (you don't need to reboot to go from MacOS to Linux), but installing it directly on your Macbook will also work.
If yes, then what will be the difference between the "Linux in Windows PC" and "Linux in Mac" in terms of programs that I will write ?
"Mac vs. PC" marketing terminology not withstanding, Macs run the same types of x64 CPUs as "regular PCs" and Linux doesn't care which other operating systems are also installed on your system. So if you write assembly on a Linux on an x64 Mac, you'll use the exact same x64 instructions and Linux syscalls as you would when running Linux on an x64 non-Mac.
I want to install Arch Linux on my old HP Pavilion zv5000 (which should have a Pentium 4 CPU).
I was not sure about which version was right for me, between x86-64 and i686, so I chose the archlinux-2017.03.01-dual.iso file on the download page of one of the Arch Linux mirror sites (for example, this mirror). I tried the "dual" version because I was not able to extract archlinux-bootstrap-2017.03.01-i686.tar.gz nor archlinux-bootstrap-2017.03.01-x86_64.tar.gz.
But now, after I burned the ISO image on a CD, booting from the live CD and trying to install Arch gives me:
This kernel requires an x86-64 CPU, but only detected an i686 CPU.
Unable to boot - please use a kernel appropriate for your CPU.
Why is it impossible to extract the .tar.gz files? I tried from two or three mirrors but trying to extract it with tar xzf gives me write permission errors.
Also, what is the "dual" ISO image really? Maybe my mistake was here.
[*] Yes, I am totally noob :)
I faced the same problem. Actually dual iso means you can choose either 64 or i86 when booting. And it was true until March 2017. Starting from March i686 version is not supported anymore.
When I downloaded iso of 2016 everything worked fine.
I presently run Linux 2.4.27 (Debian Sarge) on a PowerPC Mac G4 machine. I need to write software for Linux 2.4.18 running on a PowerPC 405 machine, and the binaries I am producing on my Mac G4 running 2.4.27 with both GCC 3.3.5 and GCC 2.95.3 (I have both installed) are having problems; I have built a static version of cURL with both compilers that segfaults when run on this 2.4.18 PowerPC 405 machine. I have noticed that binaries built on a 2.4.18 kernel with a cross compiler work (x86->PPC), however. Unfortunately, the machine that makes those binaries is unavailable to me, and I am really trying to get the Mac to be the "one stop shop" in this development effort (I want to be able to test and run on this machine).
I cannot find a 2.4.18 distribution of Linux for PowerPC anywhere. What can I do to build binaries that will work on a PowerPC 405 machine running Linux 2.4.18 given a PowerPC Mac G4 running a 2.4.27 kernel? Is building GLIBC for 2.2.5 and setting the compilers to use it the answer, or do I have to somehow build a whole kernel of 2.4.18 to support what I am trying to do?
Several weeks later, it appears that the solution suggested by user sessyargc.jp was indeed to use a cross compiler. I am accepting my answer only because I want to close this question out and I can find no way to give sessyargc.jp credit, since he/she only made a comment. Still, thank you sessyargc.jp for pointing the way!
I solved a similar problem in the past, I used the QEMU emulator on my x86 machine.
QEMU emulates the PowerPC-405 CPU too, here is the list of emulated PowerPC CPUs https://github.com/hackndev/qemu/blob/master/target-ppc/STATUS.
QEMU turns your PC in an hypervisor i.e. works like VirtualBox. But QEMU can also emulate CPUs that are different from the host PC one.
You can install and run a PowerPC Linux VM on a standard(cheap) x86 PC and compile your binaries directly in that VM. CPU emulation is a bit slow, but it works.
Regards
I have a ARM Coretex-A8 development board from Freescale (i.MX53) running Linux Ubuntu. It boots up just fine and I can access the system with mouse/keyboard/terminal.
To get started I would like to make an application running on the board inside the host OS, just as you do when you run application on your PC.
My problem is to compile my test program, using toolchains like YAGARTO which is based on gcc i end up in trouble with the linking bacause I have not defined any startup script.
I find lot of information on building "bare metal" configurations (inluding compiling the kernel and make load and link scripts), but not anything usefull for making a application running on a host OS.
My development environment is running on Windows 7. I also have the option to run on Linux X86, but i doubt this whould help me making ARM applications.
For ARM-Linux application development the preferable choice is a Linux Host(x86) machine with a ARM toolchain installed in it. In Ubuntu Desktop machine you can use the following command to install ARM toolchain:
apt-get install gcc-arm-linux-gnueabi
After toolchain installation you can use the following command for cross compilation:
gcc-arm-linux-gnueabi-gcc -o hello hello.c
Using this toolchain you can cross-compile your C program using Standard C library without the need of startup code. Applications can be cross-compiled at your Host Linux(x86) platform and run on Target Linux(ARM) platform.
Windows version of ARM-Linux Toolchain is also available. You can get it from here.
Linaro Developers Wiki - an open organization focused on improving Linux on ARM, will be a good reference for your work.
My .deb package, built on 32-bit Ubuntu and containing executables compiled with gcc, won't install on the 64-bit version of the OS (the error message says 'Wrong architecture i386'). This is confusing to me because I thought that in general 32-bit software worked on 64-bit hardware, but not vice-versa.
Will it be possible for me to produce a .deb file that I can install on a 64-bit OS, using my 32-bit machine? Is it just a matter of using the appropriate compiler flags to produce the executables (and if so what are they), or is the .deb file itself somehow specific to one processor architecture?
The deb installer is probably refusing to install your package because it was (correctly) labeled with a conflicting Architecture: field. i386 code can be executed on an amd64 machine, but it requires that all the appropriate dependencies (32-bit libraries, etc.) be present. It's better to build separate packages for each architecture.
Yes, you can build for 64-bit on your 32-bit machine. It's called cross-compiling, and it requires that you create a build environment for that purpose. To get started, you might want to look up the dpkg-cross and apt-cross tools.
Alternatively, you can just install a virtual machine running a 64-bit OS, and build for your secondary architecture there.
The architecture is just an option in the config file of debian package. By default it uses those from uname. You can override it but there is an easier way.
In general, most 32-bit programs will run fine on 64-bit. However, unless you have a very old PC, it is also very easy to install a mini 64-bit debian in a virtualbox virtual machine. You probably only need base + build essentials + dev libraries. This will not take a lot of diskspace. If you can spare 2G diskspace, just install a desktop debian.
There are more options to do crosscompilation, with various degrees of automation.
I use the virtualbox method regularly. It is easy and fast.
If you run 64-bit linux making a 32-bit environment is as easy as mkdebootstrap + linux32 + chroot.