printf和memcpy链接到标准C库

Question

It is my understanding that if I call printf in a program, by default (if the program isn't statically compiled) it makes a call to printf in the standard C library. However, if I were to call say memcpy , I'd hope the code would be inlined, as a function call is very expensive if memcpy is only copying a few bytes. If you're inlining sometimes and calling out others, the behaviour of your program after a libc upgrade is implementation dependent.

What actually occurs in both of these cases and generally?

Answer 1

An implementation is allowed by the C standard to behave "as if" the actual standard library function were called. This is indeed a common optimization: small memcpy calls can be unrolled/inlined, and much more.

You're right that in some cases you could upgrade your libc and not see any change in function calls which were optimized out.

Answer 2

You can always attempt to drive the compiler behavior. For instance, with gcc :

gcc -fno-inline -fno-builtin-inline -fno-inline-functions -fno-builtin...

You should check the different results with nm or directly the interrupt calls in the assembly source code.

Answer 3

First of all the function is never truly "inlined" - that applies to functions that you've written that are visible in the same compilation unit.

If you're inlining sometimes and calling out others, the behaviour of your program after a libc upgrade is implementation dependent.

This is not the case. The memcpy might be "inlined" at compile time . Once compiled, your libc version makes no difference.

In GCC, memcpy is recognized as a builtin . That means if GCC decides it, the call to memcpy will be replaced with a suitable implementation. On x86, this will usually be a rep movsb or similar instruction - depending on the size of the copy, and if it is of a constant size or not.

Answer 4

It's going to depend on a lot of things, here's how you can find out. GNU Binutils comes with a utility objdump that gives all sorts of details on what's in a binary.

On my system (an ARM Chromebook), compiling test.c:

#include <stdio.h>

int main(void) {
  printf("Hello, world!\n");
}

with gcc test.c -o test and then running objdump -R test gives

test:     file format elf32-littlearm

DYNAMIC RELOCATION RECORDS
OFFSET   TYPE              VALUE 
000105e4 R_ARM_GLOB_DAT    __gmon_start__
000105d4 R_ARM_JUMP_SLOT   puts
000105d8 R_ARM_JUMP_SLOT   __libc_start_main
000105dc R_ARM_JUMP_SLOT   __gmon_start__
000105e0 R_ARM_JUMP_SLOT   abort

These are the dynamic relocation entries that are in the file, all the stuff that will be linked in from libraries external to the binary. Here it seems that the printf has been entirely optimized out, since it is only giving a constant string, and thus puts is sufficient. If we modify this to

printf("Hello world #%d\n", 1);

then we get the expected

000105e0 R_ARM_JUMP_SLOT   printf

To get memcpy to be explicitly linked to, we have to prevent gcc from using its own builtin version with -fno-buildin-memcpy .