Today again see Cs630[1] Chapter 15, found inside a routine manydots.s unable to compile properly.
$ 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, first, according to the hint found that _start has multiple
Definition, so according to their own experience, the inside of the _start symbol to replace the main. Because the default program entry when compiling with GCC is main, not
_start. Information [2] tells us that _start is a real program entry, but this real entry is the default link of GCC to our executable file, assuming we set up a
_start symbol, that's multiple.
Definition (you can compile a C language program with the-s option of GCC to generate assembly code, see the program entry for assembly code, just the main, about who is the real program into
You can look at the information [2]).
That changed the _start for main, can be compiled normally, but why also appear segmentation fault it? The reason is that source code MANGDOTS.S is written for the platform 32, and I use the processor is 64-bit, and installed 64-bit ubuntu/linux.
[color= "Black"]$ Cat/proc/cpuinfo | grep "model name"
Model NAME:AMD Athlon (tm) X2 Dual Core Processor 4200+
Model NAME:AMD Athlon (tm) X2 Dual Core Processor 4200+
$ uname-a
Linux Falcon 2.6.26-1-amd64 #1 SMP Thu 11:13:42 UTC x86_64 gnu/linux
According to the data [3,4,5], we found that the 64-bit platform and 32-bit platform is very different, including the number of transfer methods, instruction set has a very large change, how can it be normal execution? Use
GCC's-m32 parameter compilation produces 32-bit target code instead of 64-bit target code, since 32-bit target code can be executed on a 64-bit host.
$ gcc-m32 Manydots.s-o manydots
$./manydots
How many dots does 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
Can see, this is okay.
In fact, we are able to do it in steps: Assemble first, then link. This will reduce the size of the target code, first look at the original size.
[color= "Black"]$ wc-c manydots
6495 Manydots
We assemble and link in steps:
[color= "Black"]//this time is required a default _start entrance, assuming not specified, will default to set a program entry address, because this time no one to set us a real entrance _start.
$ 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 does you want to see? 10
..........
It can be found that it works, but the target is reduced by 5,469 bytes. Why does it have this effect? The information [2] gives a specific explanation, which is interesting to consider.
By the way, "as--32 manydots.s-o MANYDOTS.O" can be directly used "$ gcc-m32-c manydots.s-o manydots.o" To do, they two actually do the same thing, You can view it through GCC's--verbose:
$ 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=c,c++,fortran,objc,obj-c++--PREFIX=/USR
--enable-shared--with-system-zlib--libexecdir=/usr/lib
--without-included-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 Assembler 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, the method of compiling 32-bit target code on a 64-bit host is summarized:
One, method one: Directly through the GCC assembly, link
1, ensure that there is no repeated _start entrance, replace the _start into main
2. Assemble and link with GCC plus-m32
Second, method Two: Step into the assembly, link
1, when the assembly, with the GCC plus-m32 or as plus--32 parameters.
2, in the link, with LD Plus-M elf_i386 the number of references.
[1] CS630 on Ubuntu with QEMU
Http://oss.lzu.edu.cn/blog/blog.php?/do_showone/tid_1808.html
[2] for your executable file "weight loss"
Http://oss.lzu.edu.cn/blog/blog.php?do_showone/tid_1547.html
[3] gcc in the AMD64 platform for the transfer of the parameters
Http://hi.baidu.com/bluebanboom/blog/item/381959af65ff36fbfaed5068.html
[4] Intel's 64-bit extension Technology Brief introduction
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 comes from Chinaunix blog, suppose to view the original text please point: http://blog.chinaunix.net/u2/76848/showart_1403907.html
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
compilation error "Undefined reference to"
Finally in the GCC began to compile, hoho~ make a bit, just happy for a while, and error depressed ~:
KLIB.C: (. text+0xda): Undefined reference to ' __stack_chk_fail '
Seems to say _stack_chk_fail we have a function reference that is not defined? But we're not practical. Wrestling, it doesn't seem to be the problem with our program. Take a look at what the internet says:
The GCC compilation of some version numbers often appears undefined reference to ' __stack_chk_fail ' error, allowing Cflags to be added to makefile-fno-stack-protector.
Well, let's add a cflags in our config file makefile.
CFLAGS =-I./include/-c-fno-stack-protector
Here I put a mistake on the back. Errors such as the following:
Undefined reference to ' memset '
This adds a parameter to the CFLAGS CFLAGS =-I/include/-c-fno-stack-protector-minline-all-stringops
So the compilation is passed. Most of these problems occur because the individual version number of GCC is set by default, for example, the GCC 4.13+ubuntu 7.10 I use may have this problem.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
compiler kernel error __stack_chk_fail on Ubuntu linux
Find Cflags in the makefile on the top floor and add the-fno-stack-protector logo!!!
Compiling a 32-bit target code on a 64-bit host
