标签 Assembly 下的文章

也谈C语言的内联函数

有这样一段代码:

/* foo.c */
#include  "stdio.h"

inline void foo() {
    printf("inline foo in %s\n", __FILE__);
}

int main() {
    foo();
    return 0;
}

我采用C99标准,并在不加任何优化选项的情况下编译之:

$ gcc -std=c99 foo.c -o foo
foo.c: In function ‘foo’:
/tmp/ccLGkuIK.o: In function `main':
foo.c:(.text+0×7): undefined reference to `foo'
collect2: ld returned 1 exit status

这样的结果出乎我的意料。我原以为用inline修饰的函数定义,如上面的foo函数,在编译器未开启内联优化时依旧可以作为外部函数定义被编译器使用。但通过上面gcc输出的错误信息来看,inline函数的定义并没有被看待为外部函数定义,这样链接器才无法找到foo这个符号。C99标准新增的inline似乎与我对inline语义的理解有所不同。

C语言原本是不支持inline的,但C++中原生对inline的支持让很多C编译器也为C语言实现了一些支持inline语义的扩展。C99将inline正式放入到标准C语言中,并提供了inline关键字。和C++中的inline一样,C99的inline也是对编译器的一个提示,提示编译器尽量使用函数的内联定义,去除函数调用带来的开销。inline只有在开启编译器优化选项时才会生效。正如上面的例子,当我们打开优化选项并重新编译时,我们会看到:

$ gcc -std=c99 foo.c -O2 -o foo
$./foo
$ inline foo in foo.c

在-O2的优化选项下,编译器进行了内联优化,并采用了foo的inline定义。通过汇编代码我们也可以看出:foo.s中并没有显式地使用call进行函数调用,函数调用被优化掉了:

/* foo.s : gcc -std=c99 foo.c -O2 -S */
    .file   "foo.c"
    .section    .rodata.str1.1,"aMS",@progbits,1
.LC0:
    .string "foo.c"
.LC1:
    .string "inline foo in %s\n"
    .text
    .p2align 4,,15
.globl main
    .type   main, @function
main:
    pushl   %ebp
    movl    %esp, %ebp
    andl    $-16, %esp
    subl    $16, %esp
    movl    $.LC0, 8(%esp)
    movl    $.LC1, 4(%esp)
    movl    $1, (%esp)
    call    __printf_chk
    xorl    %eax, %eax
    leave
    ret
    .size   main, .-main
    .ident  "GCC: (Ubuntu 4.4.3-4ubuntu5) 4.4.3"
    .section    .note.GNU-stack,"",@progbits

我们在另外一个文件bar.c中提供一个foo的外部函数定义:

/* bar.c */
#include

void foo() {
    printf("global foo in %s\n", __FILE__);
}

我们将foo.c和bar.c放在一起编译(未开启优化选项):
$ gcc -std=c99 foo.c bar.c -o foo
$ ./foo
$ global foo in bar.c

链接器为foo.c中的符号foo选择了bar.c中的foo函数定义。这样看来我们甚至可以有两个同名(名字都是foo)的函数定义,只不过一个是inline定义,一个是外部定义,它们并不冲突。

再开启优化选项,我们得到:
$ gcc -std=c99 foo.c bar.c -o foo
$ ./foo
$ inline foo in foo.c

这一次编译器选择了foo的inline定义。

究其原因:foo.c和bar.c分处于两个不同的编译单元,在未开启内联优化的情况下,foo.c对应的目标文件foo.o中foo只是一个未定义的符号,而bar.o中的foo却是一个global符号,并对应一块独立的实现代码。链接器自然采用了bar.c中的foo函数定义。而在开启了内联优化的情况下,编译器在进行foo.o这个编译单元的编译期间就直接对foo进行了优化,并采用了foo的inline定义,直接放到了main函数的汇编代码中,没有显式地call foo,并且foo.o中并未为foo单独生成Global函数代码,这样在最后的链接阶段,bar.o就变成"打酱油"的了^_^。

以上只是为了说明C99内inline语义而做的试验。在现实开发中,我们绝不应该这么去做。我们要确保函数的inline定义和非inline定义的语义一致性。那能否做到让一份函数定义既可以作为inline定义,也可以作为外部函数定义呢?这意味着我们在开启内联优化时,既要在inline函数定义的编译单元里执行内联优化,也要为inline函数生成一份独立的global的函数定义(汇编码)。

我们增加一个头文件foo.h:
/* foo.h */
extern void foo();

/* foo.c */
#include
#include "foo.h"

inline void foo() {
    printf("foo in %s\n", __FILE__);
}

int main() {
    foo();
    return 0;
}

我们在开启优化和未开启优化两种情况下分别编译执行:
$ gcc -std=c99 foo.c -o foo
$ ./foo
$ foo in foo.c

$ gcc -std=c99 foo.c -o foo -O2
$ ./foo
$ foo in foo.c

我们看到:无论哪种情况,我们都可以顺利通过编译,并且得到正确的执行结果。我们来看看汇编码有何变化:

在未开启优化的情况下,我们得到如下汇编码:

.globl foo
    .type   foo, @function
foo:
    pushl   %ebp
    … …
    call    printf
    leave
    ret
    .size   foo, .-foo

    … …
main:
    pushl   %ebp
    movl    %esp, %ebp
    andl    $-16, %esp
    call    foo
    … …
    ret

内联优化并未生效,main代码中进行了foo的函数调用。但与本文开始时的那个例子不同的是,编译器为foo生成了一份独立的global的函数定义汇编码块,这块代码可以直接被外部引用,也就是说在未开启优化的情况下,foo定义被看成了外部函数定义。

但开启优化选项的情况下,我们得到如下汇编码:
.globl foo
    .type   foo, @function
foo:
    pushl   %ebp
    … …
    call    __printf_chk
    leave
    ret
    … …
main:
    pushl   %ebp
    movl    %esp, %ebp
    andl    $-16, %esp
    subl    $16, %esp
    movl    $.LC0, 8(%esp)
    movl    $.LC1, 4(%esp)
    movl    $1, (%esp)
    call    __printf_chk
    xorl    %eax, %eax
    leave
    ret

内联优化生效了,main代码中并未显式地进行foo的函数调用。并且编译器依旧为foo生成了一份独立的global的函数定义汇编码块,这块代码可以直接被外部引用,也就是说在开启优化的情况下,foo定义在本编译单元被看作内联定义,同时对其他编译单元而言,也是外部函数定义。

我们通过在头文件中增加一个外部函数声明实现了我们的目标!不过上面方法虽然实现了一份定义既可以当作inline定义,也可以作为外部定义,但inline定义仅局限于定义它的那个编译单元,其他编译单元即使在开启内联优化时,依旧无法实施内联优化。如果我们希望多个编译单元共享一份inline定义并且这份定义也可以同时作为外部函数定义,我们该如何做呢? – 那我们只能把inline定义放到头文件中了!见下面代码:

/* foo.h */
inline void foo() {
    printf ("foo in %s\n", __FILE__);
}

/* foo.c */
#include
#include "foo.h"

int main() {
    foo();
    return 0;
}

/* bar.c */
#include
#include "foo.h"

void bar() {
    foo();
}

$ gcc -std=c99 foo.c -S -O2
我们看看开启优化情况下的bar.c和foo.c对应的汇编代码,以foo.s为例:

/* foo.s */
… …
main:
    pushl   %ebp
    movl    %esp, %ebp
    andl    $-16, %esp
    subl    $16, %esp
    movl    $.LC0, 8(%esp)
    movl    $.LC1, 4(%esp)
    movl    $1, (%esp)
    call    __printf_chk
    xorl    %eax, %eax
    leave
    ret
… …

内联优化生效,bar.s也是一样,不过编译器没有为我们生成foo的独立外部定义代码,这样的foo定义只能作为inline定义,而不能被作为外部函数定义。如果此时不开启优化选项编译,我们还会得到如下错误:
/tmp/ccpp1E7i.o: In function `main':
foo.c:(.text+0×7): undefined reference to `foo'
/tmp/ccQk872R.o: In function `bar':
bar.c:(.text+0×7): undefined reference to `foo'
collect2: ld returned 1 exit status

我们稍作改动,在foo.c和bar.c的文件开始处,我们加上这样一行代码:"extern inline void foo();",加上后,我们重新编译,这回foo在被内联优化的同时,也被生成了一份独立的外部函数定义。我们的目标又达到了!

总之,C99中inline相对比较怪异,使用时务必小心慎重。

发现一隐藏多年的Bug

C语言程序员在平时工作中,到底如何获取成就感呢?我几乎可以肯定的是:找到一个隐藏已久,多年无人发现的大Bug肯定可以归属到C程序员成就感的范畴中。与操作系统斗、与编译器斗、与内存斗,其乐无穷吗^_^。

今天测试人员在进行平台迁移测试时发现一个致命的问题,导致系统不能正常工作。问题提到我这,为了不耽误测试进度,马上丢下手头的工作开始问题的查找,经过GDB多次跟踪调试,终于发现了一隐藏多年的问题,至于能否称为Bug呢,我还不敢确定,因为我尚不清楚当年的前辈们在书写这些代码时到底是如何考虑的。

前不久听说隐藏在FreeBSD系统中长达25年的一个Bug终于被Fixed了,当然今天我发现的这个问题肯定不及FreeBSD的这个Bug重要,但是对于我们的产品来说还是有很大意义的。

其实这个问题很简单,这里简单用一个例子来展示这个问题(稍后我还会用这个例子做进一步深入分析):
/* TestFoo.c 注意该文件并不一定在所有编译器下都能顺利编译通过,警告是不可避免的了 */

typedef struct Foo {
        int     a;
        int     b;
        int     c;
} Foo;

int main() {
        Foo f;
        f.a = 17;
        f.b = 23;
        f.c = 19;

        test_foo(f);
}

void test_foo(Foo *pfoo) {
        pfoo->c = 29;
}

明眼人一眼就能看得出来,test_foo调用时,没有按照test_foo的原型传入f的地址,而是将f以值得形式传给了test_foo这个函数。就是这样的一个很低级的问题。当然了如果一个系统只有几行代码的话,这个问题可能会马上暴露出来;但是在一个拥有几十万行代码且稳定运行了若干年的系统中,没人会注意这个问题。

有人马上会提出两个疑问:
1) 为什么编译器没能给出参数类型不匹配的警告?
2) 为什么系统能在这样明显的问题下稳定运行若干年而不出错呢?

首先回答第一个问题:之所以编译器没能给出警告是因为项目遗留代码不规范的缘故,在调用test_foo这个角色函数的C文件中并没有引用test_foo原型声明所在的头文件,更不专业的是:test_foo这个函数根本没有在任何头文件中给予原型声明;这样一来,编译器在编译阶段无从知道test_foo到底是个什么样子的函数,也就无法给出正确的调用检查了。而在链接阶段根本不对参数进行有效检查,导致漏洞得以延续。

第二个问题也是今天在发现这个问题后我最最疑惑的了。按理论上分析,如果按照上述例子中代码,f以值传递方式传入test_foo,test_foo会将f的头4个字节转换成一个Foo指针类型,这样在test_foo中引用pfoo时实际上访问的地址应该是0×11(17d),这个地址在应用程序进程地址空间属于系统地址空间,用户根本无法访问,一旦访问势必违法,如果在SUN SPARC平台上势必是要崩core的。但是实际情况是这样吗?我将上述程序放到SPARC Solaris9平台上用GCC 3.2版本编译器编译后,居然执行后一切OK。而这个源代码放到X86 Solaris 10上用GCC 3.4.6编译后(如果想编译成功,需要将test_foo的返回值改成int)运行就会出Core。初步得出结论:不同CPU体系对该种代码的处理有不同,需逐一分析。

先来看看SPARC Solaris9,用GDB跟踪程序:
Starting program: a.out

Breakpoint 1, test_foo (pfoo=0xffbff0c0) at TestFoo.c:20
20              pfoo->c = 29;
(gdb) up
#1  0x0001069c in main () at TestFoo.c:15
15              test_foo(f);
(gdb) p &f
$1 = (Foo *) 0xffbff0d0

可以看到在main中,f的地址是0xffbff0d0,而传入test_foo后,pfoo指向的地址居然是0xffbff0c0了。一个推翻前面推理的猜想:编译器在栈上复制了一份f,得到了f',并将f'的地址传给了test_foo。但是编译器为什么要这么做呢?似乎是当编译器发现传入函数的实际参数的值类型大于形式参数类型的时候,都要这么来做,这里我也没有什么特殊的根据,只是通过实验得出这个结论。比如:

/* testvaluepass.c */
typedef struct Foo {
        int     a;
        int     b;
        int     c;
} Foo;

int main() {
        Foo     f;
        f.a     = 17;
        func(f);
}

void func(int x) {
        x = 7;
}

/* testvaluepass.s , <=gcc -S testvaluepass.c*/
main:
        !#PROLOGUE# 0
        save    %sp, -144, %sp        // 寄存器窗口切换(似乎是SPARC独有的机制),fp<- old_sp, new_sp <- old_sp – 144
        !#PROLOGUE# 1
        mov     17, %o0
        st      %o0, [%fp-32]        //%fp-32 &f.a

        ldd     [%fp-32], %o0
        std     %o0, [%fp-48]        //从%fp-48开始,复制f得到f',先copy一个dword,再来一个word,一共12个字节
        ld      [%fp-24], %o0
        st      %o0, [%fp-40]

        add     %fp, -48, %o0        //将f'的地址存入%o0,在subroutine func中, %o0随着寄存器窗口的变动,新栈帧中%i0等于old栈帧中的%o0,也就是f'在栈上的首地址
        call    func, 0
         nop
        mov     %o0, %i0
        nop
        ret
        restore

func:
        !#PROLOGUE# 0
        save    %sp, -112, %sp
        !#PROLOGUE# 1
        st      %i0, [%fp+68]        //将f'地址写入本地变量x中
        mov     7, %i0
        st      %i0, [%fp+68]        //将7赋值给x
        nop
        ret
        restore

有了这个例子之后,我们可以分析第一个例子了,同样也是在经过汇编之后:
main:
        !#PROLOGUE# 0
        save    %sp, -144, %sp
        !#PROLOGUE# 1
        mov     17, %o0
        st      %o0, [%fp-32]
        mov     23, %o0
        st      %o0, [%fp-28]
        mov     19, %o0
        st      %o0, [%fp-24]

        ldd     [%fp-32], %o0        //这四行语句在重新复制一个f
        std     %o0, [%fp-48]
        ld      [%fp-24], %o0
        st      %o0, [%fp-40]

        add     %fp, -48, %o0         //将新f'的地址放到%o0中,而不是将[%fp-48]存入%o0,关键啊!
        call    test_foo, 0
         nop
        mov     %o0, %i0
        nop
        ret
        restore

test_foo:
        !#PROLOGUE# 0
        save    %sp, -112,         // 寄存器窗口切换,fp<- old_sp, new_sp %i0
        !#PROLOGUE# 1
        st      %i0, [%fp+68]          //%i0存储的是f’的地址,是在save时由%o0得来的,存入[%fp+68],即形式参数变量在栈上的地址。而恰好的是这个参数还是一个Foo*类型,这也是在SPARC上没出错的原因了。
        ld      [%fp+68], %i1        //%i此时存储的是f'的地址, 这个就是gdb跟踪时的0xffbff0c0
        mov     29, %i0
        st      %i0, [%i1+8]        //将29存入f'.c里面去了
        nop
        ret
        restore

这样一来,没有出core的原因也就找到了,但是编译器为何如此做,还无法得出确切结论。

前面说过,在X86平台上,第一个例子程序是出core的,我们同样也来看看x86平台下的汇编码(与SPARC不同,esp一直在动):
.globl main
        .type   main, @function
main:
.LFB2:
.LM1:
        pushl   %ebp
.LCFI0:
        movl    %esp, %ebp        //ebp <- old sp
.LCFI1:
        subl    $24, %esp        
.LCFI2:
        andl    $-16, %esp        
        movl    $0, %eax
        addl    $15, %eax
        addl    $15, %eax
        shrl    $4, %eax
        sall    $4, %eax
        subl    %eax, %esp
.LM2:
        movl    $17, -24(%ebp)        //f.a  init %ebp-24
.LM3:
        movl    $23, -20(%ebp)        //f.b  init %ebp-20
.LM4:
        movl    $19, -16(%ebp)        //f.c  init %ebp-16
.LM5:
        subl    $4, %esp
        pushl   -16(%ebp)        //push onto stack, as first parameter
        pushl   -20(%ebp)
        pushl   -24(%ebp)       
.LCFI3:
        call    test_foo
        addl    $16, %esp
.LM6:
        leave
        ret
test_foo:
.LFB3:
.LM7:
        pushl   %ebp            //save old ebp
.LCFI4:
        movl    %esp, %ebp        //current ebp <- old esp
.LCFI5:
.LM8:
        movl    8(%ebp), %eax        //eax <- ebp + 8 ,将ebp+8那块内存的值放到%eax,而这个值恰好是0×11(17d)
        movl    $29, 8(%eax)        //访问0×11+8显然不合理,出core

看来,不同平台的编译器生成代码差异还是不小的,但是在系统里发现的这个问题到底是否定性为Bug呢?也许这样的一个问题在早期的实现者头脑里早已经是已知的了,他可能就是故意这么做的。如果真的是这样的话,那还真不能算作一个bug,而是我们水平太浅,没能意识到这点。但可以肯定的是是这样编写代码绝对是一个不好的代码风格和习惯。另外发现代码中除了这一处之外还有多处相类似的调用,多是将变量值直接付给一个地址参数了。

附:  SPARC汇编笔记

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats