0

I am rather new to C. I have a simple method copying memory from one location to another (similar to strdup() but for any type and without constraints of a terminating \0 character):

void *memdup(void* src, int length) {
    void *dst = malloc(length);
    memcpy(dst, src, length);
    return dst;
}

I am compiling it with GCC on mingw64 (the program will be cross platform):

$ gcc --version
gcc.exe (Rev3, Built by MSYS2 project) 10.1.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -c -Wall -g -I../include -D__USE_MINGW_ANSI_STDIO=1 util.c -o util.o

Can anybody explain to me why there are so many nops at the end of the method ?

0000000000404940 <memdup>:
  404940:       55                      push   %rbp
  404941:       48 89 e5                mov    %rsp,%rbp
  404944:       48 83 ec 30             sub    $0x30,%rsp
  404948:       48 89 4d 10             mov    %rcx,0x10(%rbp)
  40494c:       89 55 18                mov    %edx,0x18(%rbp)
  40494f:       8b 45 18                mov    0x18(%rbp),%eax
  404952:       48 98                   cltq
  404954:       48 89 c1                mov    %rax,%rcx
  404957:       e8 0c 60 00 00          callq  40a968 <malloc>
  40495c:       48 89 45 f8             mov    %rax,-0x8(%rbp)
  404960:       8b 45 18                mov    0x18(%rbp),%eax
  404963:       48 63 d0                movslq %eax,%rdx
  404966:       48 8b 45 f8             mov    -0x8(%rbp),%rax
  40496a:       49 89 d0                mov    %rdx,%r8
  40496d:       48 8b 55 10             mov    0x10(%rbp),%rdx
  404971:       48 89 c1                mov    %rax,%rcx
  404974:       e8 e7 5f 00 00          callq  40a960 <memcpy>
  404979:       48 8b 45 f8             mov    -0x8(%rbp),%rax
  40497d:       48 83 c4 30             add    $0x30,%rsp
  404981:       5d                      pop    %rbp
  404982:       c3                      retq
  404983:       90                      nop
  404984:       90                      nop
  404985:       90                      nop
  404986:       90                      nop
  404987:       90                      nop
  404988:       90                      nop
  404989:       90                      nop
  40498a:       90                      nop
  40498b:       90                      nop
  40498c:       90                      nop
  40498d:       90                      nop
  40498e:       90                      nop
  40498f:       90                      nop
Rob
  • 14,746
  • 28
  • 47
  • 65
Spliffster
  • 6,959
  • 2
  • 24
  • 19
  • Perhaps it is filled out to be a multiple of 16 bytes, with a consistent filler for tidiness. – Weather Vane Jul 28 '20 at 17:21
  • It's probably something related to memory allocation. It looks like they are trying to go up to a multiple of 16 bytes – JoelFan Jul 28 '20 at 17:21
  • I'm not 100% sure but `nop` instructions are very common in un-optimized compilations to make things easier for debugging. I was surprised to inspect most of the `nop`'s disappear when compiled with `-O2` or `-O3` option. – ssd Jul 28 '20 at 17:27

0 Answers0