Is there is a way to know dynamically Linux architecture, whether it x86-64 or x86?
The Posix standard uname function (implemented in the uname(2) syscall) is dynamically giving you the information about the CPU. You probably want the machine field.
Caution about x86-64 kernels running a 32 bit program (e.g. a 32 bits Debian distribution chroot-ed in a 64 bits Debian, or perhaps a 32 bits ELF binary running on a 64 bits system); I have no idea what they give in that situation; I would imagine some x86_64 in that case, since the kernel does not really know about the binaries and libc of the system.
See also the Linux specific personality(2) syscall.
Google is your friend: http://sourceforge.net/p/predef/wiki/Architectures/
You want to test for the macros __amd64__ and __i386__. Ideally, you don't test the macros at all and write correct, portable code.
You can use lscpu command to list characteristics about CPU.
Related
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 have written a small 16-bit assembly program that writes some values in some memory locations.Is there a way I can test it in 32-bit protected mode on Linux?
qemu, dosbox, bochs
Yes, 16-bit code is supported in user processes in Linux. The system call to do it is called vm86() (there's a man page, but there's not much in it). It is, naturally, only works on x86 platforms (and 32-bit only).
If you want an example, the ELKS project has a complete tool for running ELKS 8086 binaries on Linux, which uses it:
https://github.com/lkundrak/dev86/tree/master/elksemu
Look for the run_elks() function. It's pretty straightforward.
I'm currently in the process of learning assembly language.
I'm using Gas on Linux Mint (32-bit). Using this book:
Programming from the Ground Up.
The machine I'm using has an AMD Turion 64 bit processor, but I'm limited to 2 GB of RAM.
I'm thinking of upgrading my Linux installation to the 64-bit version of Linux Mint, but I'm worried that because the book is targeted at 32-bit x86 architecture that the code examples won't work.
So two questions:
Is there likely to be any problems with the code samples?
Has anyone here noticed any benefits in general in using 64-bit Linux over 32-bit (I've seen some threads on Stack Overflow about this but they are mostly related to Windows Vista vs. Windows XP.)
Your code examples should all still work. 64-bit processors and operating systems can still run 32-bit code in a sort of "compatability mode". Your assembly examples are no different. You may have to provide an extra line of assembly or two (such as .BITS 32) but that's all.
In general, using a 64-bit OS will be faster than using a 32-bit OS. x86_64 has more registers than i386. Since you're working on assembly, you already know what registers are used for... Having more of them means less stuff has to be moved on and off the stack (and other temporary memory) thus your program spends less time managing data and more time working on that data.
Edit: To compile 32-bit code on 64-bit linux using gas, you just use the commandline argument "--32", as noted in the GAS manual
Even if you run Linux 64bit, it is possible to compile and run 32bit binaries on it. I don't know how good Mint's support for that is, I assume you should check.
64bit assembler however is not fully compatible to 32bit, for example you have different (more) registers. There are some specific instructions not available on either platform.
I would say the move to 64bit is not a big deal. You can still write 32bit assembly and then perhaps try to get it also running as 64bit (shouldn't be too hard), as a source of even more programming/learning fun.
Usually 32-bits is plenty so only use 64-bits or more if you really NEED IT.
Best to decide prior to programming if you want to do it as a 32-bit app or
a 64-bit app and then stick to it as mixed mode debugging ca get tricky fast.
I would like to discover the machine architecture type of a big number of machines. I have the hostname of each machine. The machines have Debian 4 linux, SunOS 9, SunOS 10 or Apple Darwin. All are unix-like, but with minor differences.
I would like to know:
- architecture (x86, x86_64, ia64, sparc, powerpc...)
- processor type (intel pentium, pentium pro, pentium II, sparc, powerpc, itanium, athlon, core 2 duo, cytrix, etc...)
- number of processors
Beware, I want the "type" of the machine. The stupid approach using 'uname' does not work on Sun and it also returns things like 'i686' when the machine is in fact 'x86_64' but the operating system is 32 bits. /proc/cpuinfo doesn't work neither, and things get even more complicated because some machines dont have a C compiler installed (I'm sure they all have sh, perhaps python or perl, dunno).
Thanks in advance!! :)
arch ; uname -a
arch is the standard way to get the name of the CPU instruction set. uname -a gets a bunch of stuff about the OS. uname withouth the a gets the OS name.
However programmatically speaking, the equivalent to arch is uname -m.
You can try the following Perl one-liner:
perl -MConfig -e 'print "$Config{myarchname}\n";'
I know on Mac OS X Leopard with Perl 5.10.0 it prints "i386-darwin". I don't know of a way in Perl to get the actual processor name - your best bet is probably C since it's a fairly limited set of possibilities. You can get at a C compiler's predefined macros from Perl:
perl -MConfig -e 'print join("\n", split(/ /, $Config{cppsymbols})), "\n";'
This will list C macros like __LITTLE_ENDIAN__ and __MACH__ for Mach-O format and __i386__ (on Leopard at least), as well as the useless ones like __GNUC__ and __STDC__. Of course, all of this help assumes you have Perl on all machines. If not, I'm sure other languages have similar facilities to help you.
I would suggest you look at the facter component of the Puppet system. From the URL http://reductivelabs.com/projects/facter/.
A cross-platform Ruby library for retrieving facts from operating systems. Supports multiple resolution mechanisms, any of which can be restricted to working only on certain operating systems or environments. Facter is especially useful for retrieving things like operating system names, IP addresses, MAC addresses, and SSH keys.
Why /proc/cpuinfo doesn't work?
I don't know all of the OSs you mentioned, but I think it give quite detailed information under Linux. At least, with the model of CPU, other informations can be looked up from a data table.
The software can only see what the OS let it to see, so if the OS doesn't provide informations like /proc/cpuinfo, then you'll have no way to know it.
reply to the comments:
I am not saying look for /proc/cpuinfo for all the OS. It's a two steps method: first you find out which OS it is using uname, then look for the OS specific position for the cpu info.
This is not a complete answer, but it may help you reach your goal.
arch does not work on HP-UX Itanium, and it does not have the /proc filesystem, as you mentioned.
This explains how to determine the endianness (byte order) the O/S is using simply with shell commands. It works on at least 4 major Unixes (Linux x86_64, Solaris Sparc, AIX/Power, HP-UX Itanium). If you know the byte ordering you can deduce a lot about which CPU you're dealing with, based on this source.
For instance, if Solaris won't tell you the correct architecture, but you see that it's big endian, you at least know you're not on x86_64, and probably Sparc.
Finally, for Sparc you can do this to determine whether the OS is running in 32 or 64 bit mode:
# isalist -v
sparcv9+vis2 sparcv9+vis sparcv9 sparcv8plus+vis2 sparcv8plus+vis sparcv8plus sparcv8 sparcv8-fsmuld sparcv7 sparc
If it says 'sparcv9' it's 64 bit, sparcv8 is 32
The use of uname -a will bring you to much information, so you have to search for the information you want to have.
Just use:
uname -i
for the hardware platform
or
uname -m
for the machine hardware name