Question

如果我在strlen.c中有以下内容：

int call_strlen(char *s) {
  return __builtin_strlen(s);
}

然后像这样用gcc和clang编译它：

gcc -c -o strlen-gcc.o strlen.c

clang -c -o strlen-clang.o strlen.c

我很惊讶地看到strlen-clang.o包含对＆＃34; strlen＆＃34;的引用，而gcc预计会内联函数并且没有这样的引用。（见下面的objdumps）。这是clang中的错误吗？我已在几个版本的clang编译器中测试过它，包括3.8。

编辑：这对我来说很重要的原因是我与-nostdlib链接，并且clang编译的版本给我一个链接错误，找不到strlen。

锵

@> objdump -d strlen-clang.o 

strlen-clang.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <call_strlen>:
   0: 55                    push   %rbp
   1: 48 89 e5              mov    %rsp,%rbp
   4: 48 83 ec 10           sub    $0x10,%rsp
   8: 48 89 7d f8           mov    %rdi,-0x8(%rbp)
   c: 48 8b 7d f8           mov    -0x8(%rbp),%rdi
  10: e8 00 00 00 00        callq  15 <call_strlen+0x15>
  15: 89 c1                 mov    %eax,%ecx
  17: 89 c8                 mov    %ecx,%eax
  19: 48 83 c4 10           add    $0x10,%rsp
  1d: 5d                    pop    %rbp
  1e: c3                    retq   


@> objdump -t strlen-clang.o 

strlen-clang.o:     file format elf64-x86-64

SYMBOL TABLE:
0000000000000000 l    df *ABS*  0000000000000000 strlen.c
0000000000000000 l    d  .text  0000000000000000 .text
0000000000000000 l    d  .data  0000000000000000 .data
0000000000000000 l    d  .bss 0000000000000000 .bss
0000000000000000 l    d  .comment 0000000000000000 .comment
0000000000000000 l    d  .note.GNU-stack  0000000000000000 .note.GNU-stack
0000000000000000 l    d  .eh_frame  0000000000000000 .eh_frame
0000000000000000 g     F .text  000000000000001f call_strlen
0000000000000000         *UND*  0000000000000000 strlen

GCC

@> objdump -d strlen-gcc.o 

strlen-gcc.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <call_strlen>:
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
   4:   48 89 7d f8             mov    %rdi,-0x8(%rbp)
   8:   48 8b 45 f8             mov    -0x8(%rbp),%rax
   c:   48 c7 c1 ff ff ff ff    mov    $0xffffffffffffffff,%rcx
  13:   48 89 c2                mov    %rax,%rdx
  16:   b8 00 00 00 00          mov    $0x0,%eax
  1b:   48 89 d7                mov    %rdx,%rdi
  1e:   f2 ae                   repnz scas %es:(%rdi),%al
  20:   48 89 c8                mov    %rcx,%rax
  23:   48 f7 d0                not    %rax
  26:   48 83 e8 01             sub    $0x1,%rax
  2a:   5d                      pop    %rbp
  2b:   c3                      retq   

@> objdump -t strlen-gcc.o 

strlen-gcc.o:     file format elf64-x86-64

SYMBOL TABLE:
0000000000000000 l    df *ABS*  0000000000000000 strlen.c
0000000000000000 l    d  .text  0000000000000000 .text
0000000000000000 l    d  .data  0000000000000000 .data
0000000000000000 l    d  .bss 0000000000000000 .bss
0000000000000000 l    d  .note.GNU-stack  0000000000000000 .note.GNU-stack
0000000000000000 l    d  .eh_frame  0000000000000000 .eh_frame
0000000000000000 l    d  .comment 0000000000000000 .comment
0000000000000000 g     F .text  000000000000002c call_strlen

Answer 1

只是为了获得优化：

使用clang -O0：

t.o:
(__TEXT,__text) section
_call_strlen:
0000000000000000    pushq   %rbp
0000000000000001    movq    %rsp, %rbp
0000000000000004    subq    $0x10, %rsp
0000000000000008    movq    %rdi, -0x8(%rbp)
000000000000000c    movq    -0x8(%rbp), %rdi
0000000000000010    callq   _strlen
0000000000000015    movl    %eax, %ecx
0000000000000017    movl    %ecx, %eax
0000000000000019    addq    $0x10, %rsp
000000000000001d    popq    %rbp
000000000000001e    retq

使用clang -O3

t.o:
(__TEXT,__text) section
_call_strlen:
0000000000000000    pushq   %rbp
0000000000000001    movq    %rsp, %rbp
0000000000000004    popq    %rbp
0000000000000005    jmp _strlen

现在，解决问题：

clang文件声称clang支持所有GCC支持的内置。
但是，GCC documentation似乎将内置函数及其库等价物的名称视为同义词：

两种形式都有相同的类型（包括原型），相同的地址（当它们的地址被采用时），以及与C库函数[...]相同的含义。

此外，它不保证内置函数与库等效（如strlen的情况）确实得到优化：

其中许多功能仅在某些情况下得到优化;如果它们在特定情况下未被优化，则会发出对库函数的调用。

此外，clang internals manual仅提及__builtin_strlen一次：

__builtin_strlen和strlen：如果参数是字符串文字，则这些常量折叠为整数常量表达式。

除此之外，他们似乎没有做出任何承诺。

因为在你的情况下，__builtin_strlen的参数不是字符串文字，并且因为GCC文档允许将内置函数的调用转换为库函数调用，所以clang的行为似乎完全有效。

"patch for review" on the clang developers mailing list也说：

[...]它仍然会回退到运行时使用库strlen，如果编译时评估不可能/不需要[...]。

那是在2012年，但文本表明至少在那时，只支持编译时评估。

现在，我看到两个选项：

如果您只需要自己编译程序然后使用和/或分发它，我建议您只使用gcc。
如果你需要其他人能够在gcc和clang下编译代码，我建议添加一个C库作为静态链接的依赖。

我强烈建议反对滚动您自己的标准库函数实现，即使对于看似简单的情况（如果您不同意，请尝试编写自己的strlen实现，然后将其与{ {3}}）。

Answer 2

GCC和Clang都没有承诺内联这个内置。 You quoted一些GCC文档似乎做出了这样的承诺：

... GCC内置函数总是内联扩展...

但这是一个脱离背景的句子片段。 The complete sentence是

除了具有库等价物的内置函数之外，例如下面讨论的标准C库函数，或者扩展到库调用 GCC内置函数总是内联扩展，因此没有相应的入口点，并且无法获得它们的地址。

__builtin_strlen具有等效的strlen库，所以这句话没有对它是否被内联做出承诺。

在Clang建造的不是那么内置？

2 个答案: