5

I am looking at this header file in linux kernel: https://elixir.bootlin.com/linux/v4.14/source/arch/x86/boot/string.h

#ifndef BOOT_STRING_H
#define BOOT_STRING_H

/* Undef any of these macros coming from string_32.h. */
#undef memcpy
#undef memset
#undef memcmp

void *memcpy(void *dst, const void *src, size_t len);
void *memset(void *dst, int c, size_t len);
int memcmp(const void *s1, const void *s2, size_t len);

#define memcpy(d,s,l) __builtin_memcpy(d,s,l)
#define memset(d,c,l) __builtin_memset(d,c,l)
#define memcmp  __builtin_memcmp

...

#endif /* BOOT_STRING_H */

I can't figure out what does the #undef + function declaration + macro define on memcpy, memset and memcmp do. For example, it first declares a function memcpy and then defines a macro memcpy after that. I am not sure what's the purpose of this. I find that this function is defined here: https://elixir.bootlin.com/linux/v4.14/source/arch/x86/boot/copy.S#L20. If somewhere in the code uses memcpy (for example here: https://elixir.bootlin.com/linux/v4.14/source/arch/x86/boot/main.c#L40) uses memcpy what does it use? The function defined in copy.S or the __builtin_memcpy?

darklord
  • 5,077
  • 12
  • 40
  • 65
  • Possibly the purpose of the declarations is so that it still works if people bypass the following macroes (e.g. undef them) – M.M Dec 16 '18 at 20:33

1 Answers1

0

The function declaration and macro are not conflicting. memcpy() has several definitions in the kernel, which is hinted at by the comment above the #undef blocks -- there is another memcpy() defined in string_32.h.

#undef memcpy is cancelling out the #define found in string_32.h so that it will not exist in any file that includes /boot/string.h. memcpy() is then declared, and a new macro is built for it.

The #define statement is creating a new macro for memcpy(), as the one from string_32.h no longer exists in this context. Kernel developers use macros for a variety of reasons; see answers in this thread for more.

/boot/copy.S is an assembly file. You can read a bit about its role here. The memcpy() being used in /boot/main.c is coming from /boot/string.h -- check the include statements.

buratino
  • 1,408
  • 2
  • 17
  • 40
  • when you say it is coming from /boot/string.h do you mean the __builtin_memcpy? My assumption is that it eventually use the one in copy.S otherwise why there is such a definition in the same module. – darklord Dec 17 '18 at 02:22
  • `__builtin_memcpy(d,s,l)` is a macro for `memcpy(d,s,l)`, meaning they evaluate to the same thing: the definition of `void *memcpy(void *dst, const void *src, size_t len);`. Since you don't actually see `__builtin_memcpy()` being called on the line in **/boot/main.c** that you linked to, you can safely assume that you're calling `memcpy()` directly. The version of `memcpy` in **copy.S** is being used by an assembler, not in **/boot/main.c**, which is discussed in one of the posts I linked to. – buratino Dec 17 '18 at 03:48