Re: Understanding disassembly x86 + understanding function call + parameter pass and stack frame

[nidhi mittal hada <nidhimittal19@xxxxxxxxx>]

Hi,

while in the pursuit of learning to understand assembly ..

This is my doubt ..Please help to understand

I want to catch where in this disassembly call is made to get_sb function.

Somehow in this disassembly, i m not finding, a direct call instruction, with function name, written in english.

Hence, i m trying to interpret assembly and correlate with source code in C line by line.

I have written my understanding in comments herewith assembly ..Kindly help to correct

--------------------------------------------------------------------------------------------------------------------------------------------------
crash> dis vfs_kern_mount
0xffffffff81183880 <vfs_kern_mount>:    push   %rbp
0xffffffff81183881 <vfs_kern_mount+1>:  mov    %rsp,%rbp
0xffffffff81183884 <vfs_kern_mount+4>:  sub    $0x40,%rsp
0xffffffff81183888 <vfs_kern_mount+8>:  mov    %rbx,-0x28(%rbp)
0xffffffff8118388c <vfs_kern_mount+12>: mov    %r12,-0x20(%rbp)
0xffffffff81183890 <vfs_kern_mount+16>: mov    %r13,-0x18(%rbp)
0xffffffff81183894 <vfs_kern_mount+20>: mov    %r14,-0x10(%rbp)
0xffffffff81183898 <vfs_kern_mount+24>: mov    %r15,-0x8(%rbp)
0xffffffff8118389c <vfs_kern_mount+28>: nopl   0x0(%rax,%rax,1)
0xffffffff811838a1 <vfs_kern_mount+33>: mov    $0xffffffffffffffed,%rbx
0xffffffff811838a8 <vfs_kern_mount+40>: test   %rdi,%rdi
0xffffffff811838ab <vfs_kern_mount+43>: mov    %rdi,%r12
0xffffffff811838ae <vfs_kern_mount+46>: mov    %esi,%r13d
0xffffffff811838b1 <vfs_kern_mount+49>: mov    %rdx,%r14
0xffffffff811838b4 <vfs_kern_mount+52>: je     0xffffffff8118395b <vfs_kern_mount+219>
0xffffffff811838ba <vfs_kern_mount+58>: mov    %rdx,%rdi
0xffffffff811838bd <vfs_kern_mount+61>: mov    %rcx,-0x38(%rbp)

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<IGNORING THE ABOVE TEXT FOR NOW>>>>>>>>>>>>>>>>>>>>>>>>

0xffffffff811838c1 <vfs_kern_mount+65>: callq  0xffffffff811a1f60 <alloc_vfsmnt>>>>>>>>>>>>>>>>>>>>>>>>>>>>

0xffffffff811838c6 <vfs_kern_mount+70>: test   %rax,%rax>>>should contain mnt
0xffffffff811838c9 <vfs_kern_mount+73>: mov    %rax,%rbx
0xffffffff811838cc <vfs_kern_mount+76>: mov    -0x38(%rbp),%rcx
0xffffffff811838d0 <vfs_kern_mount+80>: je     0xffffffff811839f0 <vfs_kern_mount+368>>>>>>goto out, if rax is 0

0xffffffff811838d6 <vfs_kern_mount+86>: test   %rcx,%rcx>>>>if data is false = 0
0xffffffff811838d9 <vfs_kern_mount+89>: je     0xffffffff811838e7 <vfs_kern_mount+103>>>>>>type->get_sb()

0xffffffff811838db <vfs_kern_mount+91>: testb  $0x2,0x8(%r12)>>>r12 contains type
0xffffffff811838e1 <vfs_kern_mount+97>: je     0xffffffff811839b8 <vfs_kern_mount+312>>>>>>>>alloc_secdata

0xffffffff811838e7 <vfs_kern_mount+103>:        xor    %r15d,%r15d
0xffffffff811838ea <vfs_kern_mount+106>:        mov    %rbx,%r8
0xffffffff811838ed <vfs_kern_mount+109>:        mov    %r14,%rdx
0xffffffff811838f0 <vfs_kern_mount+112>:        mov    %r13d,%esi
0xffffffff811838f3 <vfs_kern_mount+115>:        mov    %r12,%rdi
0xffffffff811838f6 <vfs_kern_mount+118>:        callq  *0x10(%r12)>>>>>>>>>>security_sb_copy_data

0xffffffff811838fb <vfs_kern_mount+123>:        test   %eax,%eax
0xffffffff811838fd <vfs_kern_mount+125>:        js     0xffffffff81183990 <vfs_kern_mount+272>>>>>>>goto out_free_secdata
0xffffffff81183903 <vfs_kern_mount+131>:        mov    0x28(%rbx),%rax
0xffffffff81183907 <vfs_kern_mount+135>:        test   %rax,%rax
0xffffffff8118390a <vfs_kern_mount+138>:        je     0xffffffff811839fc <vfs_kern_mount+380>>>>>>>>>> get_sb
0xffffffff81183910 <vfs_kern_mount+144>:        orq    $0x20000000,0x58(%rax)
0xffffffff81183918 <vfs_kern_mount+152>:        mov    %r15,%rdx
0xffffffff8118391b <vfs_kern_mount+155>:        mov    %r13d,%esi
0xffffffff8118391e <vfs_kern_mount+158>:        mov    0x28(%rbx),%rdi
0xffffffff81183922 <vfs_kern_mount+162>:        callq  0xffffffff8121b9b0 <security_sb_kern_mount>>>>>>>>>>>>>>>>>>>>>>>>>

<<<<<<<<<<<<<<IGNORING THE BELOW TEXT TOO>>>>>>>>>>>>>>>>>>>>>>>>

0xffffffff81183927 <vfs_kern_mount+167>:        test   %eax,%eax
0xffffffff81183929 <vfs_kern_mount+169>:        jne    0xffffffff81183978 <vfs_kern_mount+248>
0xffffffff8118392b <vfs_kern_mount+171>:        mov    0x28(%rbx),%rdi
0xffffffff8118392f <vfs_kern_mount+175>:        mov    0x28(%rdi),%r8
0xffffffff81183933 <vfs_kern_mount+179>:        test   %r8,%r8
0xffffffff81183936 <vfs_kern_mount+182>:        js     0xffffffff81183a02 <vfs_kern_mount+386>
0xffffffff8118393c <vfs_kern_mount+188>:        mov    0x20(%rbx),%rax
0xffffffff81183940 <vfs_kern_mount+192>:        add    $0x70,%rdi
0xffffffff81183944 <vfs_kern_mount+196>:        mov    %rbx,0x10(%rbx)
0xffffffff81183948 <vfs_kern_mount+200>:        mov    %rax,0x18(%rbx)
0xffffffff8118394c <vfs_kern_mount+204>:        callq  0xffffffff8109c1a0 <up_write>
0xffffffff81183951 <vfs_kern_mount+209>:        xor    %esi,%esi
0xffffffff81183953 <vfs_kern_mount+211>:        mov    %r15,%rdi
0xffffffff81183956 <vfs_kern_mount+214>:        callq  0xffffffff8112c820 <free_pages>

Thats the definition of function

vfs_kern_mount(struct file_system_type *type, int flags, const char *name, void *data)
{
        struct vfsmount *mnt;
        char *secdata = NULL;
        int error;

        if (!type)
                return ERR_PTR(-ENODEV);

        error = -ENOMEM;

      mnt = alloc_vfsmnt(name);
        if (!mnt)
                goto out;

<<<<<<<<<<<<<<THIS PORTION, IS   NOT  VISIBLE  TO ME, IN  ASSEMBLY   >>>>>>>>>>>>>>>

        if (data && !(type->fs_flags & FS_BINARY_MOUNTDATA)) {
                secdata = alloc_secdata();
                if (!secdata)
                        goto out_mnt;

                error = security_sb_copy_data(data, secdata);
                if (error)
                        goto out_free_secdata;
        }
       
   error = type->get_sb(type, flags, name, data, mnt);>>>>>>>>>>>>>>>>thats the line i want to catch, in assembly above. Where is this call  made in assembly ???
        if (error < 0)
                goto out_free_secdata;
        BUG_ON(!mnt->mnt_sb);
        mnt->mnt_sb->s_flags |= MS_BORN;
       
        error = security_sb_kern_mount(mnt->mnt_sb, flags, secdata);
        if (error)
                goto out_sb;
.
.     
.
.
.
out_sb:
        dput(mnt->mnt_root);
        deactivate_locked_super(mnt->mnt_sb);
out_free_secdata:
        free_secdata(secdata);
out_mnt:
        free_vfsmnt(mnt);
out:   >>>368
        return ERR_PTR(error);
}


         

On Wed, Aug 14, 2013 at 5:05 PM, <Valdis.Kletnieks@xxxxxx> wrote:

On Wed, 14 Aug 2013 16:14:34 +0530, nidhi mittal hada said:

> 1)if i want to get value of a local variable, of a function,  from stack
> trace thats bt-f output, obtained using crash ..
> No where AMD64 ABI mentions how local variables are stored ..
> is it in some specific sequence of registers ? is it in stack ?

Yes, no, maybe, depends on how smart the compiler is.  Local variables
are local, and thus by definition not part of the ABI.  The compiler
may decide that a given 'int' can be kept in %r8 for most of the
time, but stored at 24 bytes into the stack across 1 function call,
and another variable is in %r9 most of the time, but in that same location
24 bytes into the stack across a different function call (and that's
OK, because it always knows which variable is using that location
24 bytes into the stack when).

In some cases, a variable may even be totally optimized out of existence.
For example, if you have

int foo ( int c ) {
int a, b;

   b = c * 5;
   a = b + getpid();
   return a;
}

the compiler can (and probably *will*) optimize both a and b
away and convert it to 'return (c*5 + getpid());'

--
Thanks & Regards
Nidhi Mittal Hada

http://nidhi-searchingmyself.blogspot.com/

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies