> -----Original Message----- > From: John de la Garza [mailto:john@xxxxxxxxx] > 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@xxxxxxxxxxxxxxxxxxxxxxxxxxxx) (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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
