I want to study RISC-V processor in gem5 with 32-bit architecture. I have made a C executable with cross compiler riscv32-unknown-elf-gcc and I tried to test in syscall emulation mode. I don’t have any errors but the output is wrong. Have you got any ideas about it?C program
gem5 results
gem5 supports 64-bit RISC-V ISA (RV64GC to be specific) and I think, that's why you might be seeing wrong output for 32 bit binaries. I will suggest compiling your code for riscv64.
-Ayaz
Related
I have PowerPC e5500 family based embedded board. I want to compile a linux kernel with Yocto. I want this kernel to be a little endian kernel. But when I try to enable little-endian option in kernel config (make menuconfig), there is only big endian option.
I made a little research. PowerPC arch mostly supporting big-endian. I want to ask this question, if is there any way to compile PPC kernel for little-endian, can anyone tell me ?
The Linux kernel only supports little-endian kernels on 64-bit Book3S processors (see CPU_LITTLE_ENDIAN in arch/powerpc/platforms/Kconfig.cputype), and it's only really supported for Power8 (ISA 2.07) onward. Embedded systems (Book3E-based, such as the e5500) are all big-endian only - at least as far as the kernel is concerned.
My question is quite specific. I have to write a simple program which works with files and should be run on arm 32bit (android). The crucial point is that it MUST use the _llseek syscall. This syscall exists in a 32bit linux kernel but is absent in a 64bit one.
Technically I can write and run this program on the arm device (phone in my case) but I do things on a 64bit box which I would normally use for tests and debugs. In this case my program fails to compile and run on my 64bit box due to the lack of this syscall.
What can be a workaround? I need some friendly test/debug environment. Is installing a 32bit virtual linux the only option?
Thanks in advance, Alex
The -m32 flag worked and indeed the 64bit kernel accepted the bytecode. Stupid enough that I did not come to this simple option myself, thanks.
Or put it differently. I did not notice that the 64bit kernel implements all 32bit calls in parallel, even those absent in the native 64bit code.
You can install an entire Linux 32 bits (x86/32 i.e. ia32) system in a partition -or simply a subdirectory- and run it under chroot in a 64 bits x86-64 Linux kernel (because 64 bits kernels for x86-64 are generally configured to be able to run 32 bits x86 code, that is to execve(2) a 32 bits x86 ELF executable binary) The debootstrap command (on Debian & related) is documenting such a use, see also schroot (you might not need to install every package in 32 bits chroot, only the relevant ones).
You can also use gcc -m32 to compile to a 32 bits x86 ELF binary on a 64 bits x86-64 machine. You may need additional packages (often with multilib or ia32 or x86 in their name).
Of course you need to recompile the application since ARM is not the same as x86/32 bits
However, you cannot run an ARM 32 bits application (only a x86 32 bits one) on a 64 bits x86-64 Linux. To run an ARM application on x86, you need an ARM emulator (e.g. qemu....)
So, debug first your thing on x86/32 bits using a 32 bits chroot-ed environment on your 64 bits x86-64 Linux system.
Going thru the ARMv8 manual, I have the following questions to help understand the big picture.
Can legacy 32 bit app. (ARMv7 or earlier) run as is on the ARMv8 OS?
If the legacy applications need to be rebuilt for ARMv8 and assuming that I rebuild the application as 32 bit (Aarch32), does this need 32 bit OS underlying support? (It is interesting to know how the addressing mechanism works here.)
Please provide references wherever possible.
PS: I am targeting Linux OS with Aarch64 support (3.7 and later)
Aarch64 platform may run 32bit ARM but this compatibility is optional.
To run AArch32 binaries you need all libraries application would use in 32bit versions. Same as with i686 binaries on x86-64 systems.
There is also a Linux arm64 CONFIG_COMPAT at: https://github.com/torvalds/linux/blob/v4.17/arch/arm64/Kconfig#L1274 which says:
This option enables support for a 32-bit EL0 running under a 64-bit
kernel at EL1. AArch32-specific components such as system calls,
the user helper functions, VFP support and the ptrace interface are
handled appropriately by the kernel.
which will likely be required, and an ARM employee mentioned on this thread: https://community.arm.com/processors/f/discussions/5535/running-armv7-binaries-on-armv8 that userland instructions are basically the same with some exceptions:
For something like a Linux application, then yes. ARMv8-A includes AArch32, which provides backwards compatibility with ARMv7-A. There are some limitations, such as the SWP instruction no longer being supported. But these are types of things that applications are unlikely to be using (and were deprecated in ARMv7).
For baremetal, you have all the usual problems of using a binary from one platform on another. So you are going to need to do some degree of porting in most cases.
I then tried it for myself with this QEMU full system setup but my attempt failed: I compiled a C hello world with the armv7 compiler as:
arm-linux-gcc -static hello_world.c
and put the built file into the aarch64 target, but when I tried to run it it failed with:
a.out: line 1: syntax error: unexpected word (expecting ")")
even though /proc/config.gz says that CONFIG_COMPAT is set.
It seems that the Linux kernel is not identifying it as an ELF file but rather falling back to /bin/sh, I get the same error if I do:
sh /mnt/9p/a.out
is trying to use the shell binfmt instead of ELF.
In particular, I know that the Linux kernel can choose between archs from the binfmt signature because qemu-user does so: https://unix.stackexchange.com/questions/41889/how-can-i-chroot-into-a-filesystem-with-a-different-architechture
I encountered this while trying to understand ELF (Executable and Linking Format).
Steps I followed
Wrote a simple application.
main.c containing
int main(int argc, char **argv){ return 0;}
Compiled in linux environment using gcc. (Done on intel laptop)
Simplest command possible
gcc main.c
Now when I run a.out, it runs without any issue. So build is fine.
I used readelf tool to retrieve the ELF information, where in machine field is put as Advanced Micro Devices X86-64.
This part puzzled me.
So I checked the file header of a.out, it was as per ELF-64 specification (Value 64 - EM_X86_64).
Would anyone care to explain, why does the executable, built in 64 bit mode on linux, show machine type as AMD x86 64?
The x86_64 platform was called the AMD64 platform back when AMD introduced it. Initially, it was far from clear that Intel would ever support it.
You notice how long after i386's ceases to exist, a lot of software had the architecture tag i386? It was because i386 CPUs introduced the instruction set that software uses. Similarly, AMD introduced the instruction set your program uses, so it has an architecture tag that reflects the first CPUs that supported its instruction set. (Modern 32-bit code is still often tagged i686 which refers to the Pentium Pro, circa 1995.)
For a while, the IA-64 (Intel Architecture 64-bit) or Itanium chips were Intel's 64-bit offering, and the Pentium-class chips were the IA-32 chips. The IA-64 chip instruction set was sufficiently different from the Pentium code set that people did not pick it up in large numbers. Meanwhile, AMD came out with a 64-bit extension to the Pentium code set - and that got a lot of support. After a while, Intel bowed to the inevitable and made its own chips that were compatible with the AMD x86/64 chips. But it was AMD that specified the architecture, so it gets the credit in the name.
why does the executable ... show machine type as AMD x86 64?
Because the ELF machine code, used by file, was registered by AMD. There is the official list of registered codes: http://www.sco.com/developers/gabi/latest/ch4.eheader.html (the table at second page):
e_machine
This member's value specifies the required architecture for an individual file.
Name Value Meaning
EM_NONE 0 No machine
...
EM_X86_64 62 AMD x86-64 architecture
I want to learn programming in assembler for PowerPC and ARM, but I'm unable to buy real hardware for this purpose. I'm thinking about using QEMU for that. However I'm not sure if it emulates both architectures enough well, that I'll compile and run my programs in native assembler on it?
QEMU works well for testing program correction (i.e. whether the code would properly run on an actual ARM or PowerPC) but it is not good for testing program efficiency: the emulation is not cycle accurate, and speed measured with QEMU cannot be reliably (or even unreliably) correlated with speed on true hardware.
Also, QEMU will not trap unaligned memory accesses, which is not a problem for PowerPC emulation (the PowerPC tolerates unaligned accesses) but may be for ARM (an unaligned access, e.g. reading a 32-bit word in RAM from an address which is not a multiple of 4, will work fine with QEMU but would trigger an exception on a true ARM processor).
Apart from these points, QEMU is fine for assembly development on ARM or MIPS (haven't tried PowerPC, because I found an old iBook on eBay for that; but I have done ARM and MIPS assembly with QEMU and then ran the resulting code on true hardware, and this worked). You can either emulate a whole system and run Debian in it (in which case the compiler, linker, text editor... will also run in emulation), or use the "user-mode emulation" where the ARM/MIPS executable is run directly, with a wrapper which converts system calls into those for the host PC (this assumes that the host is a PC running Linux). The latter is more convenient (you have access to your normal home directory, programming tools are native...) but requires installing cross-development tools. See buildroot for that (and link with -static, this will avoid many headaches).
Since I have found signs that Debian for PowerPC and for ARM can run on QEMU, I suppose this won't be a problem.