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

nidhi mittal hada nidhimittal19 at gmail.com
Tue Sep 3 05:16:55 EDT 2013


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
0xffffffff811838ba <vfs_kern_mount+58>: mov    %rdx,%rdi
0xffffffff811838bd <vfs_kern_mount+61>: mov    %rcx,-0x38(%rbp)
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<IGNORING THE ABOVE TEXT FOR

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

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

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

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)*
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
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 <*

<<<<<<<<<<<<<<IGNORING THE BELOW TEXT TOO>>>>>>>>>>>>>>>>>>>>>>>>
0xffffffff81183927 <vfs_kern_mount+167>:        test   %eax,%eax
0xffffffff81183929 <vfs_kern_mount+169>:        jne    0xffffffff81183978
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
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
0xffffffff81183951 <vfs_kern_mount+209>:        xor    %esi,%esi
0xffffffff81183953 <vfs_kern_mount+211>:        mov    %r15,%rdi
0xffffffff81183956 <vfs_kern_mount+214>:        callq  0xffffffff8112c820

*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;

        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;
        mnt->mnt_sb->s_flags |= MS_BORN;

    *    error = security_sb_kern_mount(mnt->mnt_sb, flags, secdata);*
        if (error)
                goto out_sb;
*out:*   >>>368
        return ERR_PTR(error);

On Wed, Aug 14, 2013 at 5:05 PM, <Valdis.Kletnieks at vt.edu> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130903/0bf9f5c1/attachment-0001.html 

More information about the Kernelnewbies mailing list