Compile and generate 32-bit target code on a 64-bit host

Today, I read chapter 15 of cs630 [1] and found that the manydots. s routine in it could not be compiled normally.
$ GCC manydots. S-O manydots
/Tmp/ccivmrvt. O: In function '_ start ':
(. Text + 0x0): Multiple definition of '_ start'
/Usr/lib/GCC/x86_64-linux-gnu/4.3.1/.../../lib/crt1.o :(. Text + 0x0): first defined here
/Usr/lib/GCC/x86_64-linux-gnu/4.3.1/.../lib/crt1.o: In function '_ start ':
(. Text + 0x20): Undefined reference to 'main'
Collect2: LD returned 1 exit status
$ Sed-I-e "s/_ start/main/g" manydots. s
$ GCC manydots. S-O manydots
$./Manydots
Segmentation fault
$ File manydots
Manydots:
Elf 64-bit LSB executable, x86-64, Version 1 (sysv), dynamically linked
(Uses SHARED libs), for GNU/Linux 2.6.8, not stripped

Through the above experiment, we first find that _ start has multiple
Definition, so according to your own experience, replace the _ start symbol in with main. Because the default program entry during GCC compilation is main, rather
_ Start. Document [2] tells us that _ start is the real program entry, but this real entry is linked to our executable file by default by GCC. If we set another
The _ start symbol, that is, multiple.
Definition (you can use the-s option of GCC to compile a C language program to generate assembly code. Let's look at the assembly code program entry, which happens to be main.
For more information, see [2].
After _ start is changed to main, it can be compiled normally. Why does segmentation fault still appear? The reason is that the source code mangdots. S is written for the 32 platform, while the processor I use is 64-bit, And the 64-bit Ubuntu/Linux is installed.
[Color = "black"] $ CAT/proc/cpuinfo | grep "model name"
Model name: AMD athlon (TM) 64x2 dual core processor 4200 +
Model name: AMD athlon (TM) 64x2 dual core processor 4200 +
$ Uname-
Linux Falcon 2.6.26-1-amd64 #1 SMP Thu Aug 28 11:13:42 UTC 2008 x86_64 GNU/Linux


According to the data [3, 4, 5], we found that the 64-bit platform is very different from the 32-bit platform, including the parameter transmission mode and instruction set, how can we make it run normally? Exploitation
The GCC-M32 parameter compilation generates 32-bit target code, instead of 64-bit target code, because the 32-bit target code can run on a 64-bit host.
$ Gcc-M32 manydots. S-O manydots
$./Manydots
How many dots do you want to see? 10
..........
$ File manydots
Manydots:
Elf 32-bit LSB executable, Intel 80386, Version 1 (sysv), dynamically
Linked (uses SHARED libs), for GNU/Linux 2.6.8, not stripped
As you can see, this is okay.
In fact, we can also do it step by step: first assemble, then link. This can reduce the size of the target code. First, let's look at the original size.
[Color = "black"] $ WC-C manydots
6495 manydots


We will compile and link them step by step:
[Color = "black"] // a default _ Start entry is required at this time. If this parameter is not specified, a program entry address is set by default, at this time, no one has set a real portal _ start for us.
$ Sed-I-e "s/main/_ start/g" manydots. s
$ As -- 32 manydots. S-O manydots. o
$ LD-M elf_i386 manydots. O-o manydots
$ WC-C manydots
1026 manydots
$ Echo "6495-1026" | BC
5469
$./Manydots
How many dots do you want to see? 10
..........

It can be found that this can work normally, but the target is reduced by 5469 bytes. Why is this effect? The document [2] provides a detailed explanation. If you are interested, you can study it.
By the way, "As -- 32 manydots. s-O manydots. O "can be directly used" $ gcc-M32-C manydots. s-O manydots. O "to do it. The two of them actually do the same thing. You can check through -- verbose of GCC:
$ GCC -- verbose-M32-C manydots. S-O manydots. o
Using built-in specs.
Target: x86_64-linux-gnu
Configured
With: ../src/configure-V -- With-pkgversion = 'debian 4.3.1-9'
-- With-bugurl = file: // usr/share/doc/gcc-4.3/readme. Bugs
-- Enable-languages ages = C, C ++, Fortran, objc, obj-C ++ -- prefix =/usr
-- Enable-shared -- With-system-zlib -- libexecdir =/usr/lib
-- Without-receivded-gettext -- enable-threads = POSIX -- enable-NLS
-- With-gxx-include-Dir =/usr/include/C ++/4.3 -- Program-suffix =-4.3
-- Enable-clocale = GNU -- enable-libstdcxx-Debug -- enable-objc-GC
-- Enable-mpfr -- enable-ClD -- enable-checking = release
-- Build = x86_64-linux-gnu -- Host = x86_64-linux-gnu
-- Target = x86_64-linux-gnu
Thread model: POSIX
GCC version 4.3.1 (Debian 4.3.1-9)
Collect_gcc_options = '-v''-m32''-C'-O' manydots. o' '-mtune = generic'
As-v-QY -- 32-O manydots. O manydots. s
GNU extends er version 2.18.0 (x86_64-linux-gnu) using BFD version (GNU binutils for Debian) 2.18.0.20080103
Compiler_path =/usr/lib/GCC/x86_64-linux-gnu/4.3.1/:/usr/lib/GCC/x86_64-linux-gnu/4.3.1/:/usr/lib/GCC/x86_64-linux-gnu /: /usr/lib/GCC/x86_64-linux-gnu/4.3.1/:/usr/lib/GCC/x86_64-linux-gnu/:/usr/lib/GCC/x86_64-linux-gnu/4.3.1 /: /usr/lib/GCC/x86_64-linux-gnu/
LIBRARY_PATH =/usr/lib/GCC/x86_64-linux-gnu/4.3.1/32/:/usr/lib/GCC/x86_64-linux-gnu/4.3.1/32 /: /usr/lib/GCC/x86_64-linux-gnu/4.3.1 /.. /.. /.. /.. /lib32/:/lib /.. /lib32/:/usr/lib /.. /lib32/:/usr/lib/GCC/x86_64-linux-gnu/4.3.1/:/usr/lib/GCC/x86_64-linux-gnu/4.3.1 /: /usr/lib/GCC/x86_64-linux-gnu/4.3.1 /.. /.. /.. /:/lib/:/usr/lib/
Collect_gcc_options = '-v''-m32''-C'-O' manydots. o' '-mtune = generic'
Finally, we will summarize how to compile and generate the 32-bit target code on a 64-bit Host:
I. Method 1: directly assemble and link through gcc
1. Make sure that there are no repeated _ start entries. Replace _ start with main.
2. Use GCC with the-M32 parameter for assembly and link
Ii. Method 2: Step-by-step compilation and link
1. Add the-M32 parameter with GCC or the -- 32 parameter with the as parameter during assembly.
2. Add the-M elf_i386 parameter to the LD when linking.
[1] cs630 on Ubuntu with qemu
Http://oss.lzu.edu.cn/blog/blog.php? /Do_showone/tid_1808.html
[2] "lose weight" for your Executable File"
Http://oss.lzu.edu.cn/blog/blog.php? Do_showone/tid_1547.html
[3] parameter transfer of GCC on the amd64 Platform
Http://hi.baidu.com/bluebanboom/blog/item/381959af65ff36fbfaed5068.html
[4] Intel's 64-bit extension technology
Http://www.njyangqs.com/hardware/ia-32etech.htm
[5] amd64 architecture tech docs
Http://www.amd.com/us-en/Processors/DevelopWithAMD/0
,30_2252_739_7044,00.html




This article is from the chinaunix blog, If you view the original, click: http://blog.chinaunix.net/u2/76848/showart_1403907.html

++ ++

Compilation error "undefined reference"

Finally compiled in GCC, Hoho ~ Make, just a while ago, I was so happy, and I got an error again ~ :

Klib. c :(. Text + 0xda): Undefined reference to '_ stack_chk_fail'

It seems that _ stack_chk_fail has an undefined function reference? But we have never used this function? It seems that our program is not a problem. Let's take a look at what the Internet says:
In some versions of GCC, the undefined reference to '_ stack_chk_fail' error often occurs during compilation. You can add-fno-Stack-Protector in cflags of makefile.
Well, let's add a sentence in cflags In The makefile of our configuration file.
Cflags =-I./include/-C-fno-Stack-Protector
Here I also paste a later error. The error is as follows:
Undefined reference to 'memset'
Add the cflags parameter cflags =-I./include/-C-fno-Stack-protector-minline-all-stringops in cflags.
In this way, the compilation is successful. Most of these problems occur because of the default settings of some GCC versions. For example, this problem may occur when I use GCC 4.13 + Ubuntu 7.10.