the cost of inlining?

[Jeff Haran]

> -----Original Message-----
> From: John de la Garza [mailto:john at 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 at 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 at 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 at 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