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
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 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
http://nidhi-searchingmyself.blogspot.com/
-------------- 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