• 18740阅读
  • 3回复

C/C++ 编译器和调试器以及静态库、动态库使用汇总(续/gcc部分) [复制链接]

上一主题 下一主题
离线ppking
 

只看楼主 倒序阅读 楼主  发表于: 2005-08-24
********gcc常用的编译选项对代码的影响 ********


★ 前言

本文讨论gcc的一些常用编译选项对代码的影响。当然代码变了,
它的内存布局也就会变了,随之exploit也就要做相应的变动。
gcc的编译选项实在太多,本文检了几个最常用的选项。


★ 演示程序

[alert7@redhat62 alert7]$ cat > test.c
#include
void hi(void)
{
printf("hi");
}

int main(int argc, char *argv[])
{
hi();
return 0;
}


★ 一般情况

[alert7@redhat62 alert7]$ gcc -o test test.c
[alert7@redhat62 alert7]$ wc -c test
11773 test
[alert7@redhat62 alert7]$ gdb -q test
(gdb) disass main
Dump of assembler code for function main:
0x80483e4 : push %ebp
0x80483e5 : mov %esp,%ebp
0x80483e7 : call 0x80483d0
0x80483ec : xor %eax,%eax
0x80483ee : jmp 0x80483f0
0x80483f0 : leave
0x80483f1 : ret
....
End of assembler dump.
(gdb) disass hi
Dump of assembler code for function hi:
0x80483d0 : push %ebp
0x80483d1 : mov %esp,%ebp
0x80483d3 : push $0x8048450
0x80483d8 : call 0x8048308
0x80483dd : add $0x4,%esp
0x80483e0 : leave
0x80483e1 : ret
0x80483e2 : mov %esi,%esi
End of assembler dump.

来看看部分的内存映象
(内存高址)
+--------+
|bffffbc4| argv的地址(即argv[0]的地址)
0xbffffb84 +--------+
|00000001| argc的值
0xbffffb80 +--------+
|400309cb|main的返回地址
0xbffffb7c +--------+ <-- 调用main函数前的esp
|bffffb98| 调用main函数前的ebp
0xbffffb78 +--------+ <-- main函数的ebp
|080483ec| hi()的返回地址
0xbffffb74 +--------+
|bffffb78| 调用hi()前的esp
0xbffffb70 +--------+
|08048450| "hi"的地址
0xbffffb6c +--------+
| ...... |
(内存低址)

leave 指令所做的操作相当于MOV ESP,EBP 然后 POP EBP
ret 指令所做的操作相当于POP EIP


★ -O 编译选项

With `-O', the compiler tries to reduce code size and execution time.
When you specify `-O', the two options `-fthread-jumps' and
`-fdefer-pop' are turned on
优化,减少代码大小和执行的时间

[alert7@redhat62 alert7]$ gcc -O -o test test.c
[alert7@redhat62 alert7]$ wc -c test
11757 test
[alert7@redhat62 alert7]$ gdb -q test
(gdb) disass main
Dump of assembler code for function main:
0x80483d8 : push %ebp
0x80483d9 : mov %esp,%ebp
0x80483db : call 0x80483c8
0x80483e0 : xor %eax,%eax
0x80483e2 : leave
0x80483e3 : ret
0x80483e4 : nop
...
End of assembler dump.
(gdb) disass hi
Dump of assembler code for function hi:
0x80483c8 : push %ebp
0x80483c9 : mov %esp,%ebp
0x80483cb : push $0x8048440
0x80483d0 : call 0x8048308
0x80483d5 : leave
0x80483d6 : ret
0x80483d7 : nop
End of assembler dump.

在main()中,把一条jmp指令优化掉了,很显然,这条指令是可以不需要的。
在hi()中,把add $0x4,%esp优化掉了,这会不会使stack不平衡呢?
来看看部分的内存映象
(内存高址)
+--------+
|bffffbc4| argv的地址(即argv[0]的地址)
0xbffffb84 +--------+
|00000001| argc的值
0xbffffb80 +--------+
|400309cb|main的返回地址
0xbffffb7c +--------+ <-- 调用main函数前的esp
|bffffb98| 调用main函数前的ebp
0xbffffb78 +--------+ <-- main函数的ebp
|080483e0| hi()的返回地址
0xbffffb74 +--------+
|bffffb78| 调用hi()前的esp
0xbffffb70 +--------+
|08048440| "hi"的地址
0xbffffb6c +--------+
| ...... |
(内存低址)

leave 指令所做的操作相当于把MOV ESP,EBP 然后 POP EBP
看到leave指令操作了没有,先把ebp-->esp,再pop ebp,这样即使
在过程内堆栈的esp,ebp是不平衡的,但只要返回时候碰到leave指令
就会平衡了,所以把add $0x4,%esp优化掉也是没有问题的。


★ -O2 编译选项

-O2 Optimize even more. Nearly all supported optimizations that do
not involve a space-speed tradeoff are performed. Loop unrolling
and function inlining are not done, for example. As compared to -O,
this option increases both compilation time and the performance of
the generated code.

[alert7@redhat62 alert7]$ gcc -O2 -o test test.c
[alert7@redhat62 alert7]$ wc -c test
11757 test
[alert7@redhat62 alert7]$ gdb -q test
(gdb) disass main
Dump of assembler code for function main:
0x80483d8 : push %ebp
0x80483d9 : mov %esp,%ebp
0x80483db : call 0x80483c8
0x80483e0 : xor %eax,%eax
0x80483e2 : leave
0x80483e3 : ret
...
0x80483ef : nop
End of assembler dump.
(gdb) disass hi
Dump of assembler code for function hi:
0x80483c8 : push %ebp
0x80483c9 : mov %esp,%ebp
0x80483cb : push $0x8048440
0x80483d0 : call 0x8048308
0x80483d5 : leave
0x80483d6 : ret
0x80483d7 : nop
End of assembler dump.

由于程序比较简单,再优化也没有好优化的了,所以跟-O出来的一样。


★ -fomit-frame-pointer 编译选项

-fomit-frame-pointer
Don't keep the frame pointer in a register for functions
that don't need one. This avoids the instructions to save,
set up and restore frame pointers; it also makes an extra
register available in many functions. It also makes
debugging impossible on most machines.

忽略帧指针。这样在程序就不需要保存,安装,和恢复ebp了。这样ebp也就是一个
free的register了,在函数中就可以随便使用了。

[alert7@redhat62 alert7]$ gcc -fomit-frame-pointer -o test test.c
[alert7@redhat62 alert7]$ wc -c test
11773 test
[alert7@redhat62 alert7]$ gdb -q test
(gdb) disass main
Dump of assembler code for function main:
0x80483e0 : call 0x80483d0
0x80483e5 : xor %eax,%eax
0x80483e7 : jmp 0x80483f0
0x80483e9 : lea 0x0(%esi,1),%esi
0x80483f0 : ret
....
End of assembler dump.
(gdb) disass hi
Dump of assembler code for function hi:
0x80483d0 : push $0x8048450
0x80483d5 : call 0x8048308
0x80483da : add $0x4,%esp
0x80483dd : ret
0x80483de : mov %esi,%esi
End of assembler dump.

在main()和hi()中都去掉了以下指令
push %ebp
mov %esp,%ebp//这两条指令安装
leave//这条指令恢复
来看看部分的内存映象
(内存高址)
+--------+
|bffffbc4| argv的地址(即argv[0]的地址)
0xbffffb84 +--------+
|00000001| argc的值
0xbffffb80 +--------+
|400309cb|main的返回地址
0xbffffb7c +--------+
|080483e5| hi()的返回地址
0xbffffb78 +--------+
|08048450| "hi"字符串的地址
0xbffffb74 +--------+
| ...... |
(内存低址)
没有保存上层执行环境的ebp.


★ -fomit-frame-pointer && -O2

-fomit-frame-pointer编译选项去掉了
push %ebp
mov %esp,%ebp//这两条指令安装
leave//这条指令恢复
-O2编译选项去掉了
add $0x4,%esp

两个加起来会不会这四条指令一起去掉,从而使stack不平衡呢?

[alert7@redhat62 alert7]$ gcc -fomit-frame-pointer -O2 -o test test.c
[alert7@redhat62 alert7]$ wc -c test
11741 test
[alert7@redhat62 alert7]$ gdb -q test
(gdb) disass main
Dump of assembler code for function main:
0x80483d8 : call 0x80483c8
0x80483dd : xor %eax,%eax
0x80483df : ret
End of assembler dump.
(gdb) disass hi
Dump of assembler code for function hi:
0x80483c8 : push $0x8048430
0x80483cd : call 0x8048308
0x80483d2 : add $0x4,%esp
0x80483d5 : ret
0x80483d6 : mov %esi,%esi
End of assembler dump.
来看看部分的内存映象
(内存高址)
+--------+
|bffffbc4| argv的地址(即argv[0]的地址)
0xbffffb84 +--------+
|00000001| argc的值
0xbffffb80 +--------+
|400309cb|main的返回地址
0xbffffb7c +--------+
|080483dd| hi()的返回地址
0xbffffb78 +--------+
|08048430| "hi"字符串的地址
0xbffffb74 +--------+
| ...... |
(内存低址)

此时就没有把add $0x4,%esp优化掉,如果优化掉的话,整个stack就
会变的不平衡,从而会导致程序出错。


★ -fPIC 编译选项

-fPIC If supported for the target machine, emit position-independent
code, suitable for dynamic linking,even if branches need large
displacements.
产生位置无关代码(PIC),一般创建共享库时用到。
在x86上,PIC的代码的符号引用都是通过ebx进行操作的。

[alert7@redhat62 alert7]$ gcc -fPIC -o test test.c
[alert7@redhat62 alert7]$ wc -c test
11805 test
[alert7@redhat62 alert7]$ gdb -q test
(gdb) disass main
Dump of assembler code for function main:
0x80483f8 : push %ebp
0x80483f9 : mov %esp,%ebp
0x80483fb : push %ebx
0x80483fc : call 0x8048401
0x8048401 : pop %ebx//取得该指令的地址
0x8048402 : add $0x1093,%ebx//此时ebx里面存放着是GOT表的地址
0x8048408 : call 0x80483d0
0x804840d : xor %eax,%eax
0x804840f : jmp 0x8048411
0x8048411 : mov 0xfffffffc(%ebp),%ebx
0x8048414 : leave
0x8048415 : ret
...
End of assembler dump.
(gdb) disass hi
Dump of assembler code for function hi:
0x80483d0 : push %ebp
0x80483d1 : mov %esp,%ebp
0x80483d3 : push %ebx
0x80483d4 : call 0x80483d9
0x80483d9 : pop %ebx
0x80483da : add $0x10bb,%ebx
0x80483e0 : lea 0xffffefdc(%ebx),%edx
0x80483e6 : mov %edx,%eax
0x80483e8 : push %eax
0x80483e9 : call 0x8048308
0x80483ee : add $0x4,%esp
0x80483f1 : mov 0xfffffffc(%ebp),%ebx
0x80483f4 : leave
0x80483f5 : ret
0x80483f6 : mov %esi,%esi
End of assembler dump.
来看看部分的内存映象

(内存高址)
+--------+
|bffffbc4| argv的地址(即argv[0]的地址)
0xbffffb84 +--------+
|00000001| argc的值
0xbffffb80 +--------+
|400309cb|main的返回地址
0xbffffb7c +--------+ <-- 调用main函数前的esp
|bffffb98| 调用main函数前的ebp
0xbffffb78 +--------+ <-- main函数的ebp
|401081ec| 保存的ebx
0xbffffb74 +--------+
|0804840d| (存放过call 0x8048401的下一条指令地址)
0xbffffb70 +--------+
|bffffb78| 调用hi()前的esp
0xbffffb6c +--------+
|08049494| GOT表地址
0xbffffb68 +--------+
|08048470|(存放过call 0x80483d9的下一条指令地址)
0xbffffb64 +--------+
| ...... |
(内存低址)


★ -static 编译选项

-static
On systems that support dynamic linking, this prevents
linking with the shared libraries. On other systems,
this option has no effect.
把一些函数都静态的编译到程序中,而无需动态链接了。

[alert7@redhat62 alert7]$ gcc -o test -static test.c
[alert7@redhat62 alert7]$ wc -c test
962808 test
[alert7@redhat62 alert7]$ gdb -q test
(gdb) disass main
Dump of assembler code for function main:
0x80481b4 : push %ebp
0x80481b5 : mov %esp,%ebp
0x80481b7 : call 0x80481a0
0x80481bc : xor %eax,%eax
0x80481be : jmp 0x80481c0
0x80481c0 : leave
0x80481c1 : ret
...
End of assembler dump.
(gdb) disass hi
Dump of assembler code for function hi:
0x80481a0 : push %ebp
0x80481a1 : mov %esp,%ebp
0x80481a3 : push $0x8071528
0x80481a8 : call 0x804865c
0x80481ad : add $0x4,%esp
0x80481b0 : leave
0x80481b1 : ret
0x80481b2 : mov %esi,%esi
End of assembler dump.
[alert7@redhat62 alert7]$ ldd test
not a dynamic executable
-static出来的代码已经没有PLT了,GOT虽然有,已经全部为0了。
离线ppking

只看该作者 1楼 发表于: 2005-08-24
****不同的硬件环境下给GCC指定哪些参数才可以得到最佳的性能****
[code:1:42d9ccecec]
一、1.2版(gcc 2.9.x版)

i386 (Intel), do you really want to install gentoo on that?
CHOST="i386-pc-linux-gnu"
CFLAGS="-march=i386 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=i386 -O3 -pipe -fomit-frame-pointer"

i486 (Intel), do you really want to install gentoo on that?
CHOST="i486-pc-linux-gnu"
CFLAGS="-march=i486 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=i486 -O3 -pipe -fomit-frame-pointer"

Pentium, Pentium MMX+, Celeron (Mendocino) (Intel)
CHOST="i586-pc-linux-gnu"
CFLAGS="-march=pentium -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium -O3 -pipe -fomit-frame-pointer"

Pentium Pro/II/III/4, Celeron (Coppermine), Celeron (Willamette?) (Intel)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=i686 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=i686 -O3 -pipe -fomit-frame-pointer"

Eden C3/Ezra (Via)
CHOST="i586-pc-linux-gnu"
CFLAGS="-march=i586 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=i586 -O3 -pipe -fomit-frame-pointer"

Quote : I did the original gentoo install using 1.2, with gcc 2.95 using -march=i586. i686 won't work.

K6 or beyond (AMD)
CHOST="i586-pc-linux-gnu"
CFLAGS="-march=k6 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=k6 -O3 -pipe -fomit-frame-pointer"

(A Duron will report "Athlon" in its /proc/cpuinfo)

Athlon (AMD)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=k6 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=k6 -O3 -pipe -fomit-frame-pointer"

For the following, i don't know of any flag that enhance performances..., do you ?

PowerPC
CHOST="powerpc-unknown-linux-gnu"
CFLAGS="-O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-O3 -pipe -fomit-frame-pointer"

Sparc
CHOST="sparc-unknown-linux-gnu"
CFLAGS="-O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-O3 -pipe -fomit-frame-pointer"

Sparc 64
CHOST="sparc64-unknown-linux-gnu"
CFLAGS="-O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-O3 -pipe -fomit-frame-pointer"



二、1.4版(gcc 3.x版):


i386 (Intel), do you really want to install gentoo on that ?
CHOST="i386-pc-linux-gnu"
CFLAGS="-march=i386 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=i386 -O3 -pipe -fomit-frame-pointer"

i486 (Intel), do you really want to install gentoo on that ?
CHOST="i486-pc-linux-gnu"
CFLAGS="-march=i486 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=i486 -O3 -pipe -fomit-frame-pointer"

Pentium 1 (Intel)
CHOST="i586-pc-linux-gnu"
CFLAGS="-march=pentium -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium -O3 -pipe -fomit-frame-pointer"

Pentium MMX (Intel)
CHOST="i586-pc-linux-gnu"
CFLAGS="-march=pentium-mmx -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium-mmx -O3 -pipe -fomit-frame-pointer"

Pentium PRO (Intel)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentiumpro -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentiumpro -O3 -pipe -fomit-frame-pointer"

Pentium II (Intel)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentium2 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium2 -O3 -pipe -fomit-frame-pointer"

Celeron (Mendocino), aka Celeron1 (Intel)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentium2 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium2 -O3 -pipe -fomit-frame-pointer"

Pentium III (Intel)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentium3 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium3 -O3 -pipe -fomit-frame-pointer"

Celeron (Coppermine) aka Celeron2 (Intel)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentium3 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium3 -O3 -pipe -fomit-frame-pointer"

Celeron (Willamette?) (Intel)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer"

Pentium 4 (Intel)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer"

Eden C3/Ezra (Via)
CHOST="i586-pc-linux-gnu"
CFLAGS="-march=i586 -m3dnow -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=i586 -m3dnow -O3 -pipe -fomit-frame-pointer"

quote : the ezra doesn't have any special instructions that you could optimize for, just consider is a K6-3...basically
a p2 with 3dnow

K6 (AMD)
CHOST="i586-pc-linux-gnu"
CFLAGS="-march=k6 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=k6 -O3 -pipe -fomit-frame-pointer"

K6-2 (AMD)
CHOST="i586-pc-linux-gnu"
CFLAGS="-march=k6-2 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=k6-2 -O3 -pipe -fomit-frame-pointer"

K6-3 (AMD)
CHOST="i586-pc-linux-gnu"
CFLAGS="-march=k6-3 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=k6-3 -O3 -pipe -fomit-frame-pointer"

Athlon (AMD)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=athlon -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=athlon -O3 -pipe -fomit-frame-pointer"

Athlon-tbird, aka K7 (AMD)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=athlon-tbird -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=athlon-tbird -O3 -pipe -fomit-frame-pointer"

Athlon-tbird XP (AMD)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer"

Athlon 4(AMD)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=athlon-4 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=athlon-4 -O3 -pipe -fomit-frame-pointer"

Athlon XP (AMD)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer"

Athlon MP (AMD)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=athlon-mp -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=athlon-mp -O3 -pipe -fomit-frame-pointer"

603 (PowerPC)
CHOST="powerpc-unknown-linux-gnu"
CFLAGS="-O3 -pipe -fomit-frame-pointer -fsigned-char"
CXXFLAGS="-O3 -pipe -fomit-frame-pointer -fsigned-char"

603e (PowerPC)
CHOST="powerpc-unknown-linux-gnu"
CFLAGS="-O3 -pipe -fomit-frame-pointer -fsigned-char"
CXXFLAGS="-O3 -pipe -fomit-frame-pointer -fsigned-char"

604 (PowerPC)
CHOST="powerpc-unknown-linux-gnu"
CFLAGS="-O3 -pipe -fomit-frame-pointer -fsigned-char"
CXXFLAGS="-O3 -pipe -fomit-frame-pointer -fsigned-char"

604e (PowerPC)
CHOST="powerpc-unknown-linux-gnu"
CFLAGS="-O3 -pipe -fomit-frame-pointer -fsigned-char"
CXXFLAGS="-O3 -pipe -fomit-frame-pointer -fsigned-char"

750 aka as G3 (PowerPC)
CHOST="powerpc-unknown-linux-gnu"
CFLAGS="-mcpu=750 -O3 -pipe -fomit-frame-pointer
-fsigned-char"
CXXFLAGS="-mcpu=750 -O3 -pipe -fomit-frame-pointer
-fsigned-char"

Note: do not use -march=

7400, aka G4 (PowerPC)
CHOST="powerpc-unknown-linux-gnu"
CFLAGS="-mcpu=7400 -O3 -pipe -fomit-frame-pointer
-fsigned-char -maltivec"
CXXFLAGS="-mcpu=7400 -O3 -pipe -fomit-frame-pointer
-fsigned-char -maltivec"

Note: do not use -march=

7450, aka G4 second generation (PowerPC)
CHOST="powerpc-unknown-linux-gnu"
CFLAGS="-mcpu=7450 -O3 -pipe -fomit-frame-pointer
-fsigned-char -maltivec"
CXXFLAGS="-mcpu=7450 -O3 -pipe -fomit-frame-pointer
-fsigned-char -maltivec"

Note: do not use -march=

PowerPC (If you don't know which one)
CHOST="powerpc-unknown-linux-gnu"
CFLAGS="-O3 -pipe -fomit-frame-pointer -fsigned-char"
CXXFLAGS="-O3 -pipe -fomit-frame-pointer -fsigned-char"

Sparc
CHOST="sparc-unknown-linux-gnu"
CFLAGS="-O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-O3 -pipe -fomit-frame-pointer"

Sparc 64
CHOST="sparc64-unknown-linux-gnu"
CFLAGS="-O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-O3 -pipe -fomit-frame-pointer"
[/code:1:42d9ccecec]
离线ppking

只看该作者 2楼 发表于: 2005-08-24
****************gcc使用手册*****************
使用语法:

  gcc [ option | filename ]...
  g++ [ option | filename ]...

  其中 option 为 gcc 使用时的选项(后面会再详述),
  而 filename 为欲以 gcc 处理的文件

说明:

  这 C 与 C++ 的 compiler 已将产生新程序的相关程序整合起来。产
生一个新的程序需要经过四个阶段:预处理、编译、汇编、连结,而这两
个编译器都能将输入的文件做不同阶段的处理。虽然原始程序的扩展名可
用来分辨编写原始程序码所用的语言,但不同的compiler,其预设的处理
程序却各不相同:

  gcc  预设经由预处理过(扩展名为.i)的文件为 C 语言,并於程式
      连结阶段以 C 的连结方式处理。

  g++  预设经由预处理过(扩展名为.i)的文件为 C++ 语言,并於程
序连结阶段以 C++ 的连结方式处理。

  原始程序码的扩展名指出所用编写程序所用的语言,以及相对应的处
理方法:

  .c  C 原始程序         ; 预处理、编译、汇编
  .C  C++ 原始程序        ; 预处理、编译、汇编
  .cc C++ 原始程序        ; 预处理、编译、汇编
  .cxx C++ 原始程序        ; 预处理、编译、汇编
  .m  Objective-C 原始程序    ; 预处理、编译、汇编
  .i  已经过预处理之 C 原始程序  ; 编译、汇编
  .ii 已经过预处理之 C++ 原始程序 ; 编译、汇编
  .s  组合语言原始程序      ; 汇编
  .S  组合语言原始程序      ; 预处理、汇编
  .h  预处理文件(标头文件)    ; (不常出现在指令行)

  其他扩展名的文件是由连结程序来处理,通常有:

  .o  Object file
  .a  Archive file

  除非编译过程出现错误,否则 "连结" 一定是产生一个新程序的最
  後阶段。然而你也可以以 -c、-s 或 -E 等选项,将整个过程自四
  个阶段中的其中一个停止。在连结阶段,所有与原始码相对应的
  .o 文件、程序库、和其他无法自文件名辨明属性的文件(包括不以 .o
  为扩展名的 object file 以及扩展名为 .a 的 archive file)都会
  交由连结程序来处理(在指令行将那些文件当作连结程序的参数传给
  连结程序)。

选项:

  不同的选项必须分开来下:例如 `-dr' 这个选项就与 `-d -r' 大
  不相同。

  绝大部份的 `-f' 及 `-W' 选项都有正反两种形式:-fname 及
  -fno-name (或 -Wname 及 -Wno-name)。以下只列出非预设的那个
  形式。

  以下是所有选项的摘要。以形式来分类。选项的意义将另辟小节说
  明。

  一般性(概略、常用的)选项
       -c -S -E -o file -pipe -v -x language

  程序语言选项
       -ansi -fall-virtual -fcond-mismatch
       -fdollars-in-identifiers -fenum-int-equiv
       -fexternal-templates -fno-asm -fno-builtin
       -fno-strict-prototype -fsigned-bitfields
       -fsigned-char -fthis-is-variable
       -funsigned-bitfields -funsigned-char
       -fwritable-strings -traditional -traditional-cpp
       -trigraphs

  编译时的警告选项
       -fsyntax-only -pedantic -pedantic-errors -w -W
       -Wall -Waggregate-return -Wcast-align -Wcast-qual
       -Wchar-subscript -Wcomment -Wconversion
       -Wenum-clash -Werror -Wformat -Wid-clash-len
       -Wimplicit -Winline -Wmissing-prototypes
       -Wmissing-declarations -Wnested-externs -Wno-import
       -Wparentheses -Wpointer-arith -Wredundant-decls
       -Wreturn-type -Wshadow -Wstrict-prototypes -Wswitch
       -Wtemplate-debugging -Wtraditional -Wtrigraphs
       -Wuninitialized -Wunused -Wwrite-strings

  除错选项
       -a -dletters -fpretend-float -g -glevel -gcoff
       -gxcoff -gxcoff+ -gdwarf -gdwarf+ -gstabs -gstabs+
       -ggdb -p -pg -save-temps -print-file-name=library
       -print-libgcc-file-name -print-prog-name=program

  最佳化选项
       -fcaller-saves -fcse-follow-jumps -fcse-skip-blocks
       -fdelayed-branch -felide-constructors
       -fexpensive-optimizations -ffast-math -ffloat-store
       -fforce-addr -fforce-mem -finline-functions
       -fkeep-inline-functions -fmemoize-lookups
       -fno-default-inline -fno-defer-pop
       -fno-function-cse -fno-inline -fno-peephole
       -fomit-frame-pointer -frerun-cse-after-loop
       -fschedule-insns -fschedule-insns2
       -fstrength-reduce -fthread-jumps -funroll-all-loops
       -funroll-loops -O -O2

  预处理选项
       -Aassertion -C -dD -dM -dN -Dmacro[=defn] -E -H
       -idirafter dir -include file -imacros file -iprefix
       file -iwithprefix dir -M -MD -MM -MMD -nostdinc -P
       -Umacro -undef

  汇编程序选项
       -Wa,option

  连结程序选项
       -llibrary -nostartfiles -nostdlib -static -shared
       -symbolic -Xlinker option -Wl,option -u symbol

  目录选项
       -Bprefix -Idir -I- -Ldir

  Target Options
       -b machine -V version

  与机器(平台)相关的选项
       M680x0 Options
       -m68000 -m68020 -m68020-40 -m68030 -m68040 -m68881
       -mbitfield -mc68000 -mc68020 -mfpa -mnobitfield
       -mrtd -mshort -msoft-float

       VAX Options
       -mg -mgnu -munix

       SPARC Options
       -mepilogue -mfpu -mhard-float -mno-fpu
       -mno-epilogue -msoft-float -msparclite -mv8
       -msupersparc -mcypress

       Convex Options
       -margcount -mc1 -mc2 -mnoargcount

       AMD29K Options
       -m29000 -m29050 -mbw -mdw -mkernel-registers
       -mlarge -mnbw -mnodw -msmall -mstack-check
       -muser-registers

       M88K Options
       -m88000 -m88100 -m88110 -mbig-pic
       -mcheck-zero-division -mhandle-large-shift
       -midentify-revision -mno-check-zero-division
       -mno-ocs-debug-info -mno-ocs-frame-position
       -mno-optimize-arg-area -mno-serialize-volatile
       -mno-underscores -mocs-debug-info
       -mocs-frame-position -moptimize-arg-area
       -mserialize-volatile -mshort-data-num -msvr3 -msvr4
       -mtrap-large-shift -muse-div-instruction
       -mversion-03.00 -mwarn-passed-structs

       RS6000 Options
       -mfp-in-toc -mno-fop-in-toc

       RT Options
       -mcall-lib-mul -mfp-arg-in-fpregs -mfp-arg-in-gregs
       -mfull-fp-blocks -mhc-struct-return -min-line-mul
       -mminimum-fp-blocks -mnohc-struct-return

       MIPS Options
       -mcpu=cpu type -mips2 -mips3 -mint64 -mlong64
       -mlonglong128 -mmips-as -mgas -mrnames -mno-rnames
       -mgpopt -mno-gpopt -mstats -mno-stats -mmemcpy
       -mno-memcpy -mno-mips-tfile -mmips-tfile
       -msoft-float -mhard-float -mabicalls -mno-abicalls
       -mhalf-pic -mno-half-pic -G num -nocpp

       i386 Options
       -m486 -mno-486 -msoft-float -mno-fp-ret-in-387

       HPPA Options
       -mpa-risc-1-0 -mpa-risc-1-1 -mkernel -mshared-libs
       -mno-shared-libs -mlong-calls -mdisable-fpregs
       -mdisable-indexing -mtrailing-colon

       i960 Options
       -mcpu-type -mnumerics -msoft-float
       -mleaf-procedures -mno-leaf-procedures -mtail-call
       -mno-tail-call -mcomplex-addr -mno-complex-addr
       -mcode-align -mno-code-align -mic-compat
       -mic2.0-compat -mic3.0-compat -masm-compat
       -mintel-asm -mstrict-align -mno-strict-align
       -mold-align -mno-old-align

       DEC Alpha Options
       -mfp-regs -mno-fp-regs -mno-soft-float -msoft-float

       System V Options
       -G -Qy -Qn -YP,paths -Ym,dir

  Code Generation Options
       -fcall-saved-reg -fcall-used-reg -ffixed-reg
       -finhibit-size-directive -fnonnull-objects
       -fno-common -fno-ident -fno-gnu-linker
       -fpcc-struct-return -fpic -fPIC
       -freg-struct-returno -fshared-data -fshort-enums
       -fshort-double -fvolatile -fvolatile-global
       -fverbose-asm

PRAGMAS
  Two `#pragma' directives are supported for GNU C++, to
  permit using the same header file for two purposes: as a
  definition of interfaces to a given object class, and as
  the full definition of the contents of that object class.

  #pragma interface
       (C++ only.) Use this directive in header files
       that define object classes, to save space in most
       of the object files that use those classes. Nor-
       mally, local copies of certain information (backup
       copies of inline member functions, debugging infor-
       mation, and the internal tables that implement vir-
       tual functions) must be kept in each object file
       that includes class definitions. You can use this
       pragma to avoid such duplication. When a header
       file containing `#pragma interface' is included in
       a compilation, this auxiliary information will not
       be generated (unless the main input source file it-
       self uses `#pragma implementation'). Instead, the
       object files will contain references to be resolved
       at link time.

  #pragma implementation

  #pragma implementation "objects.h"
       (C++ only.) Use this pragma in a main input file,
       when you want full output from included header
       files to be generated (and made globally visible).
       The included header file, in turn, should use
       `#pragma interface'. Backup copies of inline mem-
       ber functions, debugging information, and the in-
       ternal tables used to implement virtual functions
       are all generated in implementation files.

       If you use `#pragma implementation' with no argu-
       ment, it applies to an include file with the same
       basename as your source file; for example, in
       `allclass.cc', `#pragma implementation' by itself
       is equivalent  to  `#pragma  implementation
       "allclass.h"'. Use the string argument if you want
       a single implementation file to include code from
       multiple header files.

       There is no way to split up the contents of a sin-
       gle header file into multiple implementation files.

文件说明
  file.c       C source file
  file.h       C header (preprocessor) file
  file.i       经预处理过的 C source file
  file.C       C++ source file
  file.cc      C++ source file
  file.cxx    C++ source file
  file.m       Objective-C source file
  file.s       assembly language file
  file.o       object file
  a.out       link edited output
  TMPDIR/cc*     temporary files
  LIBDIR/cpp     preprocessor
  LIBDIR/cc1     compiler for C
  LIBDIR/cc1plus   compiler for C++
  LIBDIR/collect   linker front end needed on some machines
  LIBDIR/libgcc.a  GCC subroutine library
  /lib/crt[01n].o  start-up routine
  LIBDIR/ccrt0  additional start-up routine for C++
  /lib/libc.a    standard C library, 参阅 man page intro(3)
  /usr/include  standard directory for #include files
  LIBDIR/include   standard gcc directory for #include files
  LIBDIR/g++-include additional g++ directory for #include

  LIBDIR is usually /usr/local/lib/machine/version.
  TMPDIR comes from the environment variable TMPDIR (default
  /usr/tmp if available, else /tmp).
离线ppking

只看该作者 3楼 发表于: 2005-08-24
**********静态、共享和动态库***********

C语言中有一些函数不需要进行编译,有一些函数也可以在多个文凭中使用。一般来说,这些函数都会执行一些标准任务,如数据库输入/输出操作或屏幕控制等。可以事先对这些函数进行编译,然后将它们放置在一些特殊的目标代码文件中,这些目标代码文件就称为库。库文件中的函数可以通过连接程序与应用程序进行连接。这样就不必在每次开发程序时都对这些通用的函数进行编译了。

不同类型的应用程序将会使用不同的函数库。例如:libdbm库中组包含了对数据库文件进行访问的dbm函数,需要对数据库进行操作的程序就会与该库进行连接。数学应用程序将使用数学库libm,X-Windows应用程序将使用Xlib库,libX11。另外,所有的程序都将使用标准的C函数库。libc,该库中包含了诸好内存管理或输入输出操作的基本函数,这些库都存放在/usr/lib这些系统公用的目录中,系统中的任何用户都可以利用这些库。当然用户也可以建立自己专用的库函数,供自己或其它指定的人员使用。

库可以有三种使用的形式:静态、共享和动态。静态库的代码在编译时就已连接到开发人员开发的应用程序中,而共享库只是在程序开始运行时才载入,在编译时,只是简单地指定需要使用的库函数。动态库则是共享库的另一种变化形式。动态库也是在程序运行时载入,但与共享库不同的是,使用的库函数不是在程序运行开始,而是在程序中的语句需要使用该函数时才载入。动态库可以在程序运行期间释放动态库所占用的内存,腾出空间供其它程序使用。由于共享库和动态库并没有在程序中包括库函数的内容,只是包含了对库函数的引用,因此代码的规模比较小。

已经开发的大多数库都采取共享库的方式。ELF格式的可执行文件使得共享库能够比较容易地实现,当然使用旧的a.out模式也可以实现库的共享。Linux系统中目前可执行文件的标准格式为ELF格式。

GNU库的使用必须遵守Library GNU Public License(LGPL许可协议)。该协议与GNU许可协议略有不同,开发人员可以免费使用GNU库进行软件开发,但必须保证向用户提供所用的库函数的源代码。

系统中可用的库都存放在/usr/lib和/lib目录中。库文件名由前缀lib和库名以及后缀组成。根据库的类型不同,后缀名也不一样。共享库的后缀名由.so和版本号组成,静态库的后缀名为.a。采用旧的a.out格式的共享库的后缀名为.sa。
libname.so.major.minor
libname.a

这里的name可以是任何字符串,用来唯一标识某个库。该字符串可以是一个单字、几个字符、甚至一个字母。数学共享库的库名为libm.so.5,这里的标识字符为m,版本号为5。libm.a则是静态数学库。X-Windows库名为libX11.so.6,这里使用X11作为库的标识,版本号为6。

使用gcc编译器就可以将库与自己开发的程序连接起来,例如:libc.so.5中包含了标准的输入输出函数,当连接程序进行目标代码连接时会自动搜索该程序并将其连接到生成的可执行文件中。标准的输入输出库中包含了许多基本的输入输出函数,如printf函数等。也可以连接其它的一些系统函数库,如数学库等,但与libc.so.5不同,大部分其它的系统库需要在命令行中显式指定所用的库名。

在/usr/lib和/lib目录中可以找到绝大多数的共享库。连接时将首先搜索这两个目录。有一些库也可能存放在特定的目录中,在/etc/ld.conf配置文件中给出了这些目录的列表。连接程序也会对列出的这些目录进行搜索。在默认情况下,Linux将首先搜索指定库的共享版本,如果找不到,才会去搜索静态版本。在对共享库进行更新或安装新库后,必须运行ldconfig命令更新/etc/ld.conf文件中相应的项(如果使用RPM进行安装,一般会自动进行更新,不过也不能保证这一点)。

在gcc编译器中引用可搜索到的目录中的库文件时,需要使用-l选项和库名。在gcc命令行上输入-lm可以在程序中连接标准算术库,-l将首先使用libname.so进行搜索,这里是libm.so。下面的例子将使用算术库创建bookrecs程序,请注意这里的-lm选项。
$ gcc main.c io.c -o bookrecs -lm

系统中还有一些其它可用的库,常用的是libncurses.a库,包含了一些简单的鼠标移动例程。在命令行中使用-lncurses选项引用libncurses.so库。下面的例子同时调用了数学和光标库。
$ gcc mian.c io.c -o bookrecs -lm -lncurses

在引用其它目录中的库时,需要使用-ldir选项指定该目录。该选项指定了搜索库函数时其它路径。在下面的例子中,用户在连接时使用了mydir目录中的myio.so库文件。
$ gcc main.c -o bookrecs -lmydir -lmyio
[ 此贴被ppking在2005-08-24 18:18重新编辑 ]
快速回复
限100 字节
 
上一个 下一个