RE: the cost of inlining?

Dec. 5, 2014

      ...
-----Original Message-----
From: John de la Garza [mailto:john@jjdev.com]
Sent: Thursday, December 04, 2014 7:14 PM
To: Jeff Haran
Cc: Kernel Newbies
Subject: Re: the cost of inlining?
On Fri, Dec 05, 2014 at 01:32:35AM +0000, Jeff Haran wrote:
...
$ cat atomic_read.c
#include <asm/atomic.h>
#include <asm/system.h>
int samp_atomic_read(atomic_t *v)
{
        int val;
val = atomic_read(v);
        return val;
}
I couldn't get it to build with the #inclue <asm/system.h>, but it built when I
removed it.
...
I dump the resultant .ko, I get this:
...
objdump -S -M intel atomic_read.ko
atomic_read.ko:     file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <samp_atomic_read>:
#include <asm/atomic.h>
#include <asm/system.h>
int samp_atomic_read(atomic_t *v)
{
   0:   55                      push   rbp
   1:   48 89 e5                mov    rbp,rsp
   4:   e8 00 00 00 00          call   9 <samp_atomic_read+0x9>
 *
 * Atomically reads the value of @v.
 */
static inline int atomic_read(const atomic_t *v) {
        return v->counter;
   9:   8b 07                   mov    eax,DWORD PTR [rdi]
    int val;
val = atomic_read(v);
        return val;
}
   b:   c9                      leave
   c:   c3                      ret
   d:   90                      nop
   e:   90                      nop
   f:   90                      nop
My ouput differs:
john@vega:~/foo$ objdump -S -M intel atomic_read.ko
atomic_read.ko:     file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <samp_atomic_read>:
   0: 55                    push   rbp
   1: 8b 07                 mov    eax,DWORD PTR [rdi]
   3: 48 89 e5              mov    rbp,rsp
   6: 5d                    pop    rbp
   7: c3                    ret
John,

Would you mind sharing what kernel version/distro you are using?

I'm using a somewhat dated Redhat version for this:

$ cat /proc/version
Linux version 2.6.32-71.15.1.el6.x86_64 (mockbuild@x86-009.build.bos.redhat.com) (gcc version 4.4.4 20100726 (Red Hat 4.4.4-13) (GCC) ) #1 SMP Sun Jan 23 10:39:44 EST 2011
[jharan@build-fusion-linux]~$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.0 (Santiago)
$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.0 (Santiago)
$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.4 20100726 (Red Hat 4.4.4-13) (GCC)

I wonder if my results are from one of Redhat's tweaks.

The only benefit I can think of from this extra call instruction is if v is a bad address and the dereference of v causes a trap, the stack trace will have that return address on it.

Thanks,

Jeff Haran