The 64-bit system cannot run the analysis process of the 32-bit program because it cannot find the 32-bit program loader.
In
http://wiki.ok-labs.com/Microkernel
Download
Arm-linux-gnueabi-4.2.4.tar.gz, sdk-xscale-3.0.tar.gz, Skyeye 1.2.1nand skyeye.conf, and operate according to tut-sdk-singlecell.pdf.
export PATH=$PATH:`pwd`/arm-unknown-linux-gnueabi/bin
Add it to the PATH environment variable.
Go to the singlecell directory and run the make command. The following error is returned:
Make-C hello KERNEL = micro BUILD = debugmake [1]: Enter the directory "/home/xuzhina/Downloads/singlecell/hello" cp hello. xml. in build. micro-debug/bin/hello. xmlmake [1]: arm-unknown-linux-gnueabi-gcc: The command does not find the arm-unknown-linux-gnueabi-ld-o build. micro-debug/bin/hello-Ttext = 0x80000000-L/home/xuzhina/Downloads/sdk/okl4/xscale/micro-debug/libs/home/xuzhina/Downloads/ sdk/okl4/xscale/micro-debug/libs/crt0.o build. micro-debug/src/hello. o -- start-group/home/xuzhina/Downloads/sdk/okl4/xscale/micro-debug/libs/libc. a/home/xuzhina/Downloads/sdk/okl4/xscale/micro-debug/libs/libokl4.a -- end-groupmake [1]: arm-unknown-linux-gnueabi-ld: command not found make [1]: *** [build. micro-debug/bin/hello] Error 127 make [1]: Leave the directory "/home/xuzhina/Downloads/singlecell/hello" make: *** [hello/build. micro-debug/bin/hello. xml] Error 2
It's strange. Why can't I find it? Run
arm-unknown-linux-gnueabi
Press the TAB key and the following result is displayed:
[xuzhina@localhost singlecell]$ arm-unknown-linux-gnueabi-arm-unknown-linux-gnueabi-addr2line arm-unknown-linux-gnueabi-gprofarm-unknown-linux-gnueabi-ar arm-unknown-linux-gnueabi-ldarm-unknown-linux-gnueabi-as arm-unknown-linux-gnueabi-nmarm-unknown-linux-gnueabi-c++ arm-unknown-linux-gnueabi-objcopyarm-unknown-linux-gnueabi-c++filt arm-unknown-linux-gnueabi-objdumparm-unknown-linux-gnueabi-cpp arm-unknown-linux-gnueabi-ranlibarm-unknown-linux-gnueabi-g++ arm-unknown-linux-gnueabi-readelfarm-unknown-linux-gnueabi-gcc arm-unknown-linux-gnueabi-sizearm-unknown-linux-gnueabi-gcc-4.2.4 arm-unknown-linux-gnueabi-stringsarm-unknown-linux-gnueabi-gccbug arm-unknown-linux-gnueabi-striparm-unknown-linux-gnueabi-gcov
That is to say, the command can be found. Why can't it be found?
Copy the command in the preceding error message and execute it,
arm-unknown-linux-gnueabi-ld -o build.micro-debug/bin/hello -Ttext=0x80000000 -L/home/xuzhina/Downloads/sdk/okl4/xscale/micro-debug/libs /home/xuzhina/Downloads/sdk/okl4/xscale/micro-debug/libs/crt0.o build.micro-debug/src/hello.o --start-group /home/xuzhina/Downloads/sdk/okl4/xscale/micro-debug/libs/libc.a /home/xuzhina/Downloads/sdk/okl4/xscale/micro-debug/libs/libokl4.a --end-group
The following error message is displayed:
Bash:/home/xuzhina/Downloads/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-ld:/lib/ld-linux.so.2: bad ELF interpreter: there is no file or directory
Generally, a program must first be loaded into the memory by the loader to create a process space for execution. From the error above, we can see that there is no loader, so this executable file cannot be parsed.
So why can other programs be executed, such as/bin/ls?
First, let's take a look at the arm-unknown-linux-gnueabi-ld and/bin/ls types:
[xuzhina@localhost singlecell]$ file /home/xuzhina/Downloads/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-ld/home/xuzhina/Downloads/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-ld: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped[xuzhina@localhost singlecell]$ file /bin/ls/bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0xec333a104e045327c5e3d0ca6dda16c610a210f3, stripped
We can see that arm-unknown-linux-gnueabi-ld is a 32-bit program, And/bin/ls is a 64-bit program.
But is the 64-bit system compatible with 32-bit programs? Do 64-bit programs have different loaders. Take a look at the ldd results of both.
[Xuzhina @ localhost singlecell] $ ldd/bin/lslinux-vdso.so.1 => (0x00007fffbf1fe000) libselinux. so.1 =>/lib64/libselinux. so.1 (0x00007fe71af3b000) libcap. so.2 =>/lib64/libcap. so.2 (0x00007fe71ad36000) libacl. so.1 =>/lib64/libacl. so.1 (0x00007fe71ab2c000) libc. so.6 =>/lib64/libc. so.6 (0x00007fe71a76b000) libpcre. so.1 =>/lib64/libpcre. so.1 (0x00007fe71a50a000) liblzma. so.5 =>/lib64/liblzma. so.5 (0x00007fe71a2e4000) libdl. so.2 =>/lib64/libdl. so.2 (0x00007fe71a0e0000)/lib64/ld-linux-x86-64.so.2 (0x00007fe71b178000) libattr. so.1 =>/lib64/libattr. so.1 (0x00007fe719edb000) libpthread. so.0 =>/lib64/libpthread. so.0 (0x00007fe719cbe000) [xuzhina @ localhost singlecell] $ ldd/home/xuzhina/Downloads/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-ld is not a dynamic executable file [xuzhina @ localhost singlecell] $ ls/lib/ld-linux.so.2ls: inaccessible/lib/ld-linux.so.2: No file or directory
That is to say, if a 64-bit system can run 32-bit programs, a 32-bit loader must be installed.
So, which package is the ld-linux.so.2? Since my system is centos 7, so I know from rpmfind.net that the ld-linux.so.2 belongs to glibc. i686.
After glibc. i686 is installed, re-make and get the following result:
[Xuzhina @ localhost singlecell] $ makemake-C hello KERNEL = micro BUILD = debugmake [1]: Enter the directory "/home/xuzhina/Downloads/singlecell/hello" cp hello. xml. in build. micro-debug/bin/hello. xmlarm-unknown-linux-gnueabi-ld-o build. micro-debug/bin/hello-Ttext = 0x80000000-L/home/xuzhina/Downloads/sdk/okl4/xscale/micro-debug/libs/home/xuzhina/Downloads/ sdk/okl4/xscale/micro-debug/libs/crt0.o build. micro-debug/src/hello. o -- start-group/home/xuzhina/Downloads/sdk/okl4/xscale/micro-debug/libs/libc. a/home/xuzhina/Downloads/sdk/okl4/xscale/micro-debug/libs/libokl4.a/home/xuzhina/Downloads/arm-unknown-linux-gnueabi/bin /.. /lib/gcc/arm-unknown-linux-gnueabi/4.2.4/libgcc. a -- end-groupmake [1]: Leave the directory "/home/xuzhina/Downloads/singlecell/hello"
Solve the problem.