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

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

[nidhi mittal hada]

---------- Forwarded message ----------
From: nidhi mittal hada <nidhimittal19@gmail.com>
Date: Tue, Aug 6, 2013 at 2:16 PM
Subject: Understanding disassembly x86 + understanding function call +
parameter pass and stack frame
To: Kernelnewbies <kernelnewbies@nl.linux.org>
Cc: Mulyadi Santosa <mulyadi.santosa@gmail.com>


Hi All,

I am using crash tool to analyze core dump obtained from red hat linux on
x86_64 platform.

And crash tool gives a stack trace of panic.
But its does not show function parameters which were passed in this stack
trace.

So i have to disassemble and understand the value of parameters passed to
these functions, while it panicked.
Which i am not able to understand much.

I would request help in knowing, how to understand disassembled function
call , on x86_64 arch.

Putting some of the doubts..

a)like which sequence the parameters, return address, etc are pushed on
stack?
b)Which registers are used, if some registers play some spl. role ?
c)lets say for a program a.c i use gcc -S a.c ...do we have some other
command to generate
somewhat more clear assembly code, may be with some comments in english

Any kind of help in understanding this will be appreciated ..

Thanks
Nidhi





-- 
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/20130806/ce61b82a/attachment.html 

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

[Saket Sinha]

Actually I need to ask you something rather than offering a solution.
Actually I have a similar sort of situation so I think I would ask here.

The issue I am facing is that I have been developing a filesystem
driver(over x86) which has become  "unstable"  by which I mean ,  at
compile time it is building but during runtime it fails when I call the
corresponding APIs from the user-space.

In order to find out exactly where it is failing, I need to debug the
driver.
I am very new to kernel development. I have heard about KGDB and KDB but it
takes quite a lot to get them working so waht are the other tools available?

Regards,
Saket Sinha




On Tue, Aug 6, 2013 at 2:36 PM, nidhi mittal hada
<nidhimittal19@gmail.com>wrote:

>
>
> ---------- Forwarded message ----------
> From: nidhi mittal hada <nidhimittal19@gmail.com>
> Date: Tue, Aug 6, 2013 at 2:16 PM
> Subject: Understanding disassembly x86 + understanding function call +
> parameter pass and stack frame
> To: Kernelnewbies <kernelnewbies@nl.linux.org>
> Cc: Mulyadi Santosa <mulyadi.santosa@gmail.com>
>
>
> Hi All,
>
> I am using crash tool to analyze core dump obtained from red hat linux on
> x86_64 platform.
>
> And crash tool gives a stack trace of panic.
> But its does not show function parameters which were passed in this stack
> trace.
>
> So i have to disassemble and understand the value of parameters passed to
> these functions, while it panicked.
> Which i am not able to understand much.
>
> I would request help in knowing, how to understand disassembled function
> call , on x86_64 arch.
>
> Putting some of the doubts..
>
> a)like which sequence the parameters, return address, etc are pushed on
> stack?
> b)Which registers are used, if some registers play some spl. role ?
> c)lets say for a program a.c i use gcc -S a.c ...do we have some other
> command to generate
> somewhat more clear assembly code, may be with some comments in english
>
> Any kind of help in understanding this will be appreciated ..
>
> Thanks
> Nidhi
>
>
>
>
>
> --
> Thanks & Regards
> Nidhi Mittal Hada
>
> http://nidhi-searchingmyself.blogspot.com/
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130806/431038cd/attachment-0001.html 

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

[Anuz Pratap Singh Tomar]

On Tue, Aug 6, 2013 at 10:43 AM, Saket Sinha <saket.sinha89@gmail.com>wrote:

> Actually I need to ask you something rather than offering a solution.
> Actually I have a similar sort of situation so I think I would ask here.
>
>
Please don't do this. Ask the question separately. There are better chances
of getting answer from looking at the topic of mail then piggybacking at
some else's mail. Not to mention it is just bad mailing list netiquettes.
Secondly do not top post. I don't understand why is so hard to follow a
simple rule which is pretty much a norm on all open source mailing list.
May be this will help
http://kernelnewbies.org/mailinglistguidelines

> The issue I am facing is that I have been developing a filesystem
> driver(over x86) which has become  "unstable"  by which I mean ,  at
> compile time it is building but during runtime it fails when I call the
> corresponding APIs from the user-space.
>
> In order to find out exactly where it is failing, I need to debug the
> driver.
> I am very new to kernel development. I have heard about KGDB and KDB but
> it takes quite a lot to get them working so waht are the other tools
> available?
>
> Well if you are debugging a kernel driver at filesystem level it will take
time, there are really no shortcuts and kgdb might be your best bet.
You can have a look at debugfs which might be useful
http://www.linuxforu.com/2010/10/debugging-linux-kernel-with-debugfs/
Another link I found by simple search
http://confluence.jetbrains.com/display/~roman.shevchenko/Debugging+native+file+system+watcher+for+Linux

Lastly there was some discussion on Filesystem debugging on *this* very
mailing list, so I would suggest you search in archives.


 Regards,
> Saket Sinha
>
>
>
>
> On Tue, Aug 6, 2013 at 2:36 PM, nidhi mittal hada <nidhimittal19@gmail.com
> > wrote:
>
>>
>>
>> ---------- Forwarded message ----------
>> From: nidhi mittal hada <nidhimittal19@gmail.com>
>> Date: Tue, Aug 6, 2013 at 2:16 PM
>> Subject: Understanding disassembly x86 + understanding function call +
>> parameter pass and stack frame
>> To: Kernelnewbies <kernelnewbies@nl.linux.org>
>> Cc: Mulyadi Santosa <mulyadi.santosa@gmail.com>
>>
>>
>> Hi All,
>>
>> I am using crash tool to analyze core dump obtained from red hat linux on
>> x86_64 platform.
>>
>> And crash tool gives a stack trace of panic.
>> But its does not show function parameters which were passed in this stack
>> trace.
>>
>> So i have to disassemble and understand the value of parameters passed to
>> these functions, while it panicked.
>> Which i am not able to understand much.
>>
>> I would request help in knowing, how to understand disassembled function
>> call , on x86_64 arch.
>>
>> Putting some of the doubts..
>>
>> a)like which sequence the parameters, return address, etc are pushed on
>> stack?
>> b)Which registers are used, if some registers play some spl. role ?
>> c)lets say for a program a.c i use gcc -S a.c ...do we have some other
>> command to generate
>> somewhat more clear assembly code, may be with some comments in english
>>
>> Any kind of help in understanding this will be appreciated ..
>>
>> Thanks
>> Nidhi
>>
>>
>>
>>
>>
>> --
>> Thanks & Regards
>> Nidhi Mittal Hada
>>
>> http://nidhi-searchingmyself.blogspot.com/
>>
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>


-- 
Thank you
Warm Regards
Anuz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130806/3f3728b6/attachment.html 

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

[Tobias Boege]

On Tue, 06 Aug 2013, nidhi mittal hada wrote:
> ---------- Forwarded message ----------
> From: nidhi mittal hada <nidhimittal19@gmail.com>
> Date: Tue, Aug 6, 2013 at 2:16 PM
> Subject: Understanding disassembly x86 + understanding function call +
> parameter pass and stack frame
> To: Kernelnewbies <kernelnewbies@nl.linux.org>
> Cc: Mulyadi Santosa <mulyadi.santosa@gmail.com>
> 
> 
> Hi All,
> 
> I am using crash tool to analyze core dump obtained from red hat linux on
> x86_64 platform.
> 
> And crash tool gives a stack trace of panic.
> But its does not show function parameters which were passed in this stack
> trace.
> 
> So i have to disassemble and understand the value of parameters passed to
> these functions, while it panicked.
> Which i am not able to understand much.
> 
> I would request help in knowing, how to understand disassembled function
> call , on x86_64 arch.
> 
> Putting some of the doubts..
> 
> a)like which sequence the parameters, return address, etc are pushed on
> stack?

Not necessarily on the stack. The AMD64 ABI [0] should help you here.
However, without knowledge of assembly I doubt you can achieve very much.

> b)Which registers are used, if some registers play some spl. role ?

You'll see in [0].

> c)lets say for a program a.c i use gcc -S a.c ...do we have some other
> command to generate
> somewhat more clear assembly code, may be with some comments in english
> 

Never heard of such a thing. Actually without optimisation, the generated
assembly code from gcc (from all I have seen and remember) is very clear -
sometimes a little bit clumsy, but clear. You should in fact practice with
something like -O2 if you are about to disassemble kernel functions...

> Any kind of help in understanding this will be appreciated ..

Regards,
Tobi

[0] http://www.uclibc.org/docs/psABI-x86_64.pdf

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

[Matthias Brugger]

2013/8/6 nidhi mittal hada <nidhimittal19@gmail.com>:
>
>
> ---------- Forwarded message ----------
> From: nidhi mittal hada <nidhimittal19@gmail.com>
> Date: Tue, Aug 6, 2013 at 2:16 PM
> Subject: Understanding disassembly x86 + understanding function call +
> parameter pass and stack frame
> To: Kernelnewbies <kernelnewbies@nl.linux.org>
> Cc: Mulyadi Santosa <mulyadi.santosa@gmail.com>
>
>
> Hi All,
>
> I am using crash tool to analyze core dump obtained from red hat linux on
> x86_64 platform.
>
> And crash tool gives a stack trace of panic.
> But its does not show function parameters which were passed in this stack
> trace.
>
> So i have to disassemble and understand the value of parameters passed to
> these functions, while it panicked.
> Which i am not able to understand much.
>
> I would request help in knowing, how to understand disassembled function
> call , on x86_64 arch.
>
> Putting some of the doubts..
>
> a)like which sequence the parameters, return address, etc are pushed on
> stack?
> b)Which registers are used, if some registers play some spl. role ?
> c)lets say for a program a.c i use gcc -S a.c ...do we have some other
> command to generate
> somewhat more clear assembly code, may be with some comments in english

I'm not a revers engineering pro, but maybe "ida pro" might help you.
It shows you which code block is called by which jump etc.
The downside it's not open source and it's not freeware (there exists
a limited version, which you can give a try).
There exist other free available revers engineering tools too. If I
can remember the name, I'll post it here.

Good luck!
Matthias

>
> Any kind of help in understanding this will be appreciated ..
>
> Thanks
> Nidhi
>
>
>
>
>
> --
> Thanks & Regards
> Nidhi Mittal Hada
>
> http://nidhi-searchingmyself.blogspot.com/
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>



-- 
motzblog.wordpress.com

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

[Tayade, Nilesh]

> -----Original Message-----
> From: kernelnewbies-bounces at kernelnewbies.org [mailto:kernelnewbies-
> bounces at kernelnewbies.org] On Behalf Of Matthias Brugger
> Sent: Tuesday, August 06, 2013 7:14 PM
> To: nidhi mittal hada
> Cc: kernelnewbies at kernelnewbies.org
> Subject: Re: Understanding disassembly x86 + understanding function call +
> parameter pass and stack frame
> 
> 2013/8/6 nidhi mittal hada <nidhimittal19@gmail.com>:
[...]
> > Hi All,
> >
> > I am using crash tool to analyze core dump obtained from red hat linux
> > on
> > x86_64 platform.
[...]
> >
> > Putting some of the doubts..
> >
> > a)like which sequence the parameters, return address, etc are pushed
> > on stack?
May be you would like to take a look at below link:
http://www.cs.virginia.edu/~evans/cs216/guides/x86.html [Section: Calling Convention] has the exact answer to your question.

> > b)Which registers are used, if some registers play some spl. role ?
You also might want to read the tutorials:
http://cocoafactory.com/blog/2012/11/23/x86-64-assembly-language-tutorial-part-1
This tutorial is in four parts. Part-2 has information on all the registers and their roles.
 
> > c)lets say for a program a.c i use gcc -S a.c ...do we have some other
> > command to generate somewhat more clear assembly code, may be with
> > some comments in English
Take a look at information on objdump command. You can compile the debug binary of the code and use objdump with certain options on that binary- this will dump the assembly code along with inline C code.

[...]
> 
> >
> > Any kind of help in understanding this will be appreciated ..
> >
> > Thanks
> > Nidhi

Hope it helps.

--
Thanks,
Nilesh  

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

[neha naik]

Hi,
  Pick up a global variable eg : In case of filesystem stack the vfs
structure available through built in gdb command or in case of
 device driver the gendisk structure.
  Then try to find this in the stack. When you get it,  look at the
register where it was showed and try to follow this with assembly code and
the
  source code.
  If you do this exercise you will start understanding assembly code better.
  Sometimes the global variable itself can point you to other structures
which you can find in your stack. And from that you can get a better
  idea about what is happening.

  I personally feel analysing dumps is more about practice.
Regards,
Neha

On Fri, Aug 9, 2013 at 1:19 PM, Tayade, Nilesh
<Nilesh.Tayade@netscout.com>wrote:

> > -----Original Message-----
> > From: kernelnewbies-bounces at kernelnewbies.org [mailto:kernelnewbies-
> > bounces at kernelnewbies.org] On Behalf Of Matthias Brugger
> > Sent: Tuesday, August 06, 2013 7:14 PM
> > To: nidhi mittal hada
> > Cc: kernelnewbies at kernelnewbies.org
> > Subject: Re: Understanding disassembly x86 + understanding function call
> +
> > parameter pass and stack frame
> >
> > 2013/8/6 nidhi mittal hada <nidhimittal19@gmail.com>:
> [...]
> > > Hi All,
> > >
> > > I am using crash tool to analyze core dump obtained from red hat linux
> > > on
> > > x86_64 platform.
> [...]
> > >
> > > Putting some of the doubts..
> > >
> > > a)like which sequence the parameters, return address, etc are pushed
> > > on stack?
> May be you would like to take a look at below link:
> http://www.cs.virginia.edu/~evans/cs216/guides/x86.html [Section: Calling
> Convention] has the exact answer to your question.
>
> > > b)Which registers are used, if some registers play some spl. role ?
> You also might want to read the tutorials:
>
> http://cocoafactory.com/blog/2012/11/23/x86-64-assembly-language-tutorial-part-1
> This tutorial is in four parts. Part-2 has information on all the
> registers and their roles.
>
> > > c)lets say for a program a.c i use gcc -S a.c ...do we have some other
> > > command to generate somewhat more clear assembly code, may be with
> > > some comments in English
> Take a look at information on objdump command. You can compile the debug
> binary of the code and use objdump with certain options on that binary-
> this will dump the assembly code along with inline C code.
>
> [...]
> >
> > >
> > > Any kind of help in understanding this will be appreciated ..
> > >
> > > Thanks
> > > Nidhi
>
> Hope it helps.
>
> --
> Thanks,
> Nilesh
>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130809/2170028e/attachment.html 

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

[nidhi mittal hada]

Thanks to all for replying with helpful links.
read a few of them ...

.. in order to apply that to practical use.. asking a ques ..please see

*Thats output of bt -f for a process *

deactivate_super is where i am concentrating for example/discussion sake

#11 [ffff88062b7bbe90] deactivate_super at ffffffff811798a0
    ffff88062b7bbe98: 0000000000000000 ffff8817de24e480
    ffff88062b7bbea8: ffff88062b7bbed8 ffffffff8119581f
#12 [ffff88062b7bbeb0] mntput_no_expire at ffffffff8119581f
    ffff88062b7bbeb8: 0000000000000000 0000000000000000
    ffff88062b7bbec8: ffff8817de24e480 0000000000000000
    ffff88062b7bbed8: ffff88062b7bbf78 ffffffff811962bb
#13 [ffff88062b7bbee0] sys_umount at ffffffff811962bb
    ffff88062b7bbee8: ffff88062b7bbf78 ffff88062b7bbf18
    ffff88062b7bbef8: ffff88062b7bbf78 ffffffff810d46e2
    ffff88062b7bbf08: ffff8817de24e4b0 000000001b9f3800
    ffff88062b7bbf18: ffff88062b7bbf18 ffff88062b7bbf18
    ffff88062b7bbf28: ffff88062b7bbf28 ffff88062b7bbf28
    ffff88062b7bbf38: ffff8817de24e480 ffff88012c523200
    ffff88062b7bbf48: 00007ffff7b6be60 00007ff689b9dab0
    ffff88062b7bbf58: 00007ff689b9db10 0000000000000000
    ffff88062b7bbf68: 0000000000000000 0000000000000000
    ffff88062b7bbf78: 00007ff689b9da90 ffffffff8100b0f2
#14 [ffff88062b7bbf80] system_call_fastpath at ffffffff8100b0f2
    RIP: 00007ff687cd9987  RSP: 00007ffff7b6b7b0  RFLAGS: 00010293
    RAX: 00000000000000a6  RBX: ffffffff8100b0f2  RCX: 0000000000000005
    RDX: 0000000000000000  RSI: 0000000000000000  RDI: 00007ff689b9dab0
    RBP: 00007ff689b9da90   R8: 00007ff689b9dad0   R9: 0000000000000000
    R10: 00007ffff7b6bfb0  R11: 0000000000000246  R12: 0000000000000000
    R13: 0000000000000000  R14: 0000000000000000  R15: 00007ff689b9db10
    ORIG_RAX: 00000000000000a6  CS: 0033  SS: 002b

*this is disassembly of that function*

crash> dis ffffffff811798a0
0xffffffff811798a0 <deactivate_super+112>:      mov    %r12,%rdi
crash> dis deactivate_super
0xffffffff81179830 <deactivate_super>:  push   %rbp
0xffffffff81179831 <deactivate_super+1>:        mov    %rsp,%rbp
0xffffffff81179834 <deactivate_super+4>:        push   %r12
0xffffffff81179836 <deactivate_super+6>:        push   %rbx
0xffffffff81179837 <deactivate_super+7>:        nopl   0x0(%rax,%rax,1)
0xffffffff8117983c <deactivate_super+12>:       mov    0x30(%rdi),%r12
0xffffffff81179840 <deactivate_super+16>:       mov
$0xffffffff81fc0a00,%rsi
0xffffffff81179847 <deactivate_super+23>:       mov    %rdi,%rbx
0xffffffff8117984a <deactivate_super+26>:       lea    0xb8(%rdi),%rdi
0xffffffff81179851 <deactivate_super+33>:       callq  0xffffffff8126a820
<_atomic_dec_and_lock>
0xffffffff81179856 <deactivate_super+38>:       test   %eax,%eax
0xffffffff81179858 <deactivate_super+40>:       je     0xffffffff811798b0
<deactivate_super+128>
0xffffffff8117985a <deactivate_super+42>:       subl
$0x3fffffff,0xb0(%rbx)
0xffffffff81179864 <deactivate_super+52>:       mov
$0xffffffff81fc0a00,%rax
0xffffffff8117986b <deactivate_super+59>:       incw   (%rax)
0xffffffff8117986e <deactivate_super+62>:       data32 xchg %ax,%ax
0xffffffff81179871 <deactivate_super+65>:       mov    0x48(%rbx),%rax
0xffffffff81179875 <deactivate_super+69>:       test   %rax,%rax
0xffffffff81179878 <deactivate_super+72>:       je     0xffffffff8117988f
<deactivate_super+95>
0xffffffff8117987a <deactivate_super+74>:       mov    0x8(%rax),%rax
0xffffffff8117987e <deactivate_super+78>:       test   %rax,%rax
0xffffffff81179881 <deactivate_super+81>:       je     0xffffffff8117988f
<deactivate_super+95>
0xffffffff81179883 <deactivate_super+83>:       xor    %edx,%edx
0xffffffff81179885 <deactivate_super+85>:       mov    $0xffffffff,%esi
0xffffffff8117988a <deactivate_super+90>:       mov    %rbx,%rdi
0xffffffff8117988d <deactivate_super+93>:       callq  *%rax
0xffffffff8117988f <deactivate_super+95>:       lea    0x70(%rbx),%rdi
0xffffffff81179893 <deactivate_super+99>:       callq  0xffffffff814ee5c0
<down_write>
0xffffffff81179898 <deactivate_super+104>:      mov    %rbx,%rdi
0xffffffff8117989b <deactivate_super+107>:      callq  *0x18(%r12)
0xffffffff811798a0 <deactivate_super+112>:      mov    %r12,%rdi
0xffffffff811798a3 <deactivate_super+115>:      callq  0xffffffff81193c20
<put_filesystem>


*This is code for this function*

/**
 *      deactivate_super        -       drop an active reference to
superblock
 *      @s: superblock to deactivate
 *
 *      Drops an active reference to superblock, acquiring a temprory one if
 *      there is no active references left.  In that case we lock
superblock,
 *      tell fs driver to shut it down and drop the temporary reference we
 *      had just acquired.
 */
void deactivate_super(struct super_block *s)
{
        struct file_system_type *fs = s->s_type;
        if (atomic_dec_and_test(&s->s_active)) {
                vfs_dq_off(s, 0);
                down_write(&s->s_umount);
                fs->kill_sb(s);
                put_filesystem(fs);
                put_super(s);
        }
}

EXPORT_SYMBOL(deactivate_super);

*now i want to get superblock dump from the stack frame of deactivate_super
obtained from bt -f.*


How do i proceed...

*Questions:-*
1)Which memory address in stack contains struct super_block *s
2)how does disassembly helps in knowing which register contain the struct
super_block *s
3)bt -f gives highlighted above, register dump at the end, does that help
in finding this information ???

If any other command can help in knowing thsi from crash dump ,,please let
me know

Thanks a lot for the helpful links given in replies ...


Thanks
Nidhi





On Sat, Aug 10, 2013 at 3:10 AM, neha naik <nehanaik27@gmail.com> wrote:

> Hi,
>   Pick up a global variable eg : In case of filesystem stack the vfs
> structure available through built in gdb command or in case of
>  device driver the gendisk structure.
>   Then try to find this in the stack. When you get it,  look at the
> register where it was showed and try to follow this with assembly code and
> the
>   source code.
>   If you do this exercise you will start understanding assembly code
> better.
>   Sometimes the global variable itself can point you to other structures
> which you can find in your stack. And from that you can get a better
>   idea about what is happening.
>
>   I personally feel analysing dumps is more about practice.
> Regards,
> Neha
>
> On Fri, Aug 9, 2013 at 1:19 PM, Tayade, Nilesh <Nilesh.Tayade@netscout.com
> > wrote:
>
>> > -----Original Message-----
>> > From: kernelnewbies-bounces at kernelnewbies.org [mailto:kernelnewbies-
>> > bounces at kernelnewbies.org] On Behalf Of Matthias Brugger
>> > Sent: Tuesday, August 06, 2013 7:14 PM
>> > To: nidhi mittal hada
>> > Cc: kernelnewbies at kernelnewbies.org
>> > Subject: Re: Understanding disassembly x86 + understanding function
>> call +
>> > parameter pass and stack frame
>> >
>> > 2013/8/6 nidhi mittal hada <nidhimittal19@gmail.com>:
>> [...]
>> > > Hi All,
>> > >
>> > > I am using crash tool to analyze core dump obtained from red hat linux
>> > > on
>> > > x86_64 platform.
>> [...]
>> > >
>> > > Putting some of the doubts..
>> > >
>> > > a)like which sequence the parameters, return address, etc are pushed
>> > > on stack?
>> May be you would like to take a look at below link:
>> http://www.cs.virginia.edu/~evans/cs216/guides/x86.html [Section:
>> Calling Convention] has the exact answer to your question.
>>
>> > > b)Which registers are used, if some registers play some spl. role ?
>> You also might want to read the tutorials:
>>
>> http://cocoafactory.com/blog/2012/11/23/x86-64-assembly-language-tutorial-part-1
>> This tutorial is in four parts. Part-2 has information on all the
>> registers and their roles.
>>
>> > > c)lets say for a program a.c i use gcc -S a.c ...do we have some other
>> > > command to generate somewhat more clear assembly code, may be with
>> > > some comments in English
>> Take a look at information on objdump command. You can compile the debug
>> binary of the code and use objdump with certain options on that binary-
>> this will dump the assembly code along with inline C code.
>>
>> [...]
>> >
>> > >
>> > > Any kind of help in understanding this will be appreciated ..
>> > >
>> > > Thanks
>> > > Nidhi
>>
>> Hope it helps.
>>
>> --
>> Thanks,
>> Nilesh
>>
>>
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>
>


-- 
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/20130812/34811210/attachment.html 

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

[Tobias Boege]

On Mon, 12 Aug 2013, nidhi mittal hada wrote:
> *this is disassembly of that function*
> 
> crash> dis ffffffff811798a0
> 0xffffffff811798a0 <deactivate_super+112>:      mov    %r12,%rdi
> crash> dis deactivate_super
> 0xffffffff81179830 <deactivate_super>:  push   %rbp
> 0xffffffff81179831 <deactivate_super+1>:        mov    %rsp,%rbp
> 0xffffffff81179834 <deactivate_super+4>:        push   %r12
> 0xffffffff81179836 <deactivate_super+6>:        push   %rbx
> 0xffffffff81179837 <deactivate_super+7>:        nopl   0x0(%rax,%rax,1)
> 0xffffffff8117983c <deactivate_super+12>:       mov    0x30(%rdi),%r12
> 0xffffffff81179840 <deactivate_super+16>:       mov
> $0xffffffff81fc0a00,%rsi
> 0xffffffff81179847 <deactivate_super+23>:       mov    %rdi,%rbx
> 0xffffffff8117984a <deactivate_super+26>:       lea    0xb8(%rdi),%rdi
> 0xffffffff81179851 <deactivate_super+33>:       callq  0xffffffff8126a820
> <_atomic_dec_and_lock>
> 0xffffffff81179856 <deactivate_super+38>:       test   %eax,%eax
> 0xffffffff81179858 <deactivate_super+40>:       je     0xffffffff811798b0
> <deactivate_super+128>
> 0xffffffff8117985a <deactivate_super+42>:       subl
> $0x3fffffff,0xb0(%rbx)
> 0xffffffff81179864 <deactivate_super+52>:       mov
> $0xffffffff81fc0a00,%rax
> 0xffffffff8117986b <deactivate_super+59>:       incw   (%rax)
> 0xffffffff8117986e <deactivate_super+62>:       data32 xchg %ax,%ax
> 0xffffffff81179871 <deactivate_super+65>:       mov    0x48(%rbx),%rax
> 0xffffffff81179875 <deactivate_super+69>:       test   %rax,%rax
> 0xffffffff81179878 <deactivate_super+72>:       je     0xffffffff8117988f
> <deactivate_super+95>
> 0xffffffff8117987a <deactivate_super+74>:       mov    0x8(%rax),%rax
> 0xffffffff8117987e <deactivate_super+78>:       test   %rax,%rax
> 0xffffffff81179881 <deactivate_super+81>:       je     0xffffffff8117988f
> <deactivate_super+95>
> 0xffffffff81179883 <deactivate_super+83>:       xor    %edx,%edx
> 0xffffffff81179885 <deactivate_super+85>:       mov    $0xffffffff,%esi
> 0xffffffff8117988a <deactivate_super+90>:       mov    %rbx,%rdi
> 0xffffffff8117988d <deactivate_super+93>:       callq  *%rax
> 0xffffffff8117988f <deactivate_super+95>:       lea    0x70(%rbx),%rdi
> 0xffffffff81179893 <deactivate_super+99>:       callq  0xffffffff814ee5c0
> <down_write>
> 0xffffffff81179898 <deactivate_super+104>:      mov    %rbx,%rdi
> 0xffffffff8117989b <deactivate_super+107>:      callq  *0x18(%r12)
> 0xffffffff811798a0 <deactivate_super+112>:      mov    %r12,%rdi
> 0xffffffff811798a3 <deactivate_super+115>:      callq  0xffffffff81193c20
> <put_filesystem>
> 
> 
> *This is code for this function*
> 
> /**
>  *      deactivate_super        -       drop an active reference to
> superblock
>  *      @s: superblock to deactivate
>  *
>  *      Drops an active reference to superblock, acquiring a temprory one if
>  *      there is no active references left.  In that case we lock
> superblock,
>  *      tell fs driver to shut it down and drop the temporary reference we
>  *      had just acquired.
>  */
> void deactivate_super(struct super_block *s)
> {
>         struct file_system_type *fs = s->s_type;
>         if (atomic_dec_and_test(&s->s_active)) {
>                 vfs_dq_off(s, 0);
>                 down_write(&s->s_umount);
>                 fs->kill_sb(s);
>                 put_filesystem(fs);
>                 put_super(s);
>         }
> }
> 
> EXPORT_SYMBOL(deactivate_super);
> 
> *now i want to get superblock dump from the stack frame of deactivate_super
> obtained from bt -f.*
> 
> 
> How do i proceed...
> 
> *Questions:-*
> 1)Which memory address in stack contains struct super_block *s

It's not on the stack in this case.

> 2)how does disassembly helps in knowing which register contain the struct
> super_block *s

The disassembly doesn't help you in this particular case. Well, it does but
it is way easier to think as follows:

The super_block pointer is the first argument to this function. We know from
the AMD 64 ABI that the first argument, if it fits, is to be delivered in
the %rdi register. Since 's' is a pointer, it fits, so you'll find the value
in the %rdi register.

Maybe it's a good idea to examine a little bit of the disassembly for your
understanding:

At the beginning of the disassembly, you see instructions

[1] 0xffffffff81179830 <deactivate_super>:          push   %rbp
[1] 0xffffffff81179831 <deactivate_super+1>:        mov    %rsp,%rbp
[2] 0xffffffff81179834 <deactivate_super+4>:        push   %r12
[2] 0xffffffff81179836 <deactivate_super+6>:        push   %rbx
[3] 0xffffffff81179837 <deactivate_super+7>:        nopl   0x0(%rax,%rax,1)
[4] 0xffffffff8117983c <deactivate_super+12>:       mov    0x30(%rdi),%r12

which sets up the stack frame ([1]), saves callee-saved registers as per the
ABI ([2]), does nothing ([3]) and then loads some data relative to %rdi into
%r12 ([4]). We already know that %rdi is 's' from the C code. So we could
guess that the above disassembly is performing

struct file_system_type *fs = s->s_type;

from the beginning of the C code. There is also proof for this assumption
later in the disassembly. The %r12 is used near the end of the disassembly
again:

[1] 0xffffffff81179898 <deactivate_super+104>:      mov    %rbx,%rdi
[2] 0xffffffff8117989b <deactivate_super+107>:      callq  *0x18(%r12)
[3] 0xffffffff811798a0 <deactivate_super+112>:      mov    %r12,%rdi
[4] 0xffffffff811798a3 <deactivate_super+115>:      callq  0xffffffff81193c20 <put_filesystem>

First something (we haven't tracked) is moved into %rdi ([1]), followed by a
call of a function from inside %r12 ([2]). This supposedly is a function
pointer in 'fs'. If we look at the C code, this is likely to be:

fs->kill_sb(s);

So %rbx must be a saved 's' (and it is: look at <deactive_super+23>).
Anyways, what follows is that %r12 is moved to %rdi ([3]) and another call
is made (which means that %r12 is to be the first parameter to this
function). put_filesystem() is called, so this must be the C code:

put_super(s);

And this makes sense, since we know %r12 is a copy of 's'.

I hope this shows that analysing (such small) functions is actually quite
easy. What you need, however, is the ABI in your head.

> 3)bt -f gives highlighted above, register dump at the end, does that help
> in finding this information ???

Yes. You'll find the address in 's' in the %rdi register.

Regards,
Tobi

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

[Tobias Boege]

On Mon, 12 Aug 2013, Tobias Boege wrote:
> On Mon, 12 Aug 2013, nidhi mittal hada wrote:
> > *this is disassembly of that function*
> > 
> > crash> dis ffffffff811798a0
> > 0xffffffff811798a0 <deactivate_super+112>:      mov    %r12,%rdi
> > crash> dis deactivate_super
> > 0xffffffff81179830 <deactivate_super>:  push   %rbp
> > 0xffffffff81179831 <deactivate_super+1>:        mov    %rsp,%rbp
> > 0xffffffff81179834 <deactivate_super+4>:        push   %r12
> > 0xffffffff81179836 <deactivate_super+6>:        push   %rbx
> > 0xffffffff81179837 <deactivate_super+7>:        nopl   0x0(%rax,%rax,1)
> > 0xffffffff8117983c <deactivate_super+12>:       mov    0x30(%rdi),%r12
> > 0xffffffff81179840 <deactivate_super+16>:       mov
> > $0xffffffff81fc0a00,%rsi
> > 0xffffffff81179847 <deactivate_super+23>:       mov    %rdi,%rbx
> > 0xffffffff8117984a <deactivate_super+26>:       lea    0xb8(%rdi),%rdi
> > 0xffffffff81179851 <deactivate_super+33>:       callq  0xffffffff8126a820
> > <_atomic_dec_and_lock>
> > 0xffffffff81179856 <deactivate_super+38>:       test   %eax,%eax
> > 0xffffffff81179858 <deactivate_super+40>:       je     0xffffffff811798b0
> > <deactivate_super+128>
> > 0xffffffff8117985a <deactivate_super+42>:       subl
> > $0x3fffffff,0xb0(%rbx)
> > 0xffffffff81179864 <deactivate_super+52>:       mov
> > $0xffffffff81fc0a00,%rax
> > 0xffffffff8117986b <deactivate_super+59>:       incw   (%rax)
> > 0xffffffff8117986e <deactivate_super+62>:       data32 xchg %ax,%ax
> > 0xffffffff81179871 <deactivate_super+65>:       mov    0x48(%rbx),%rax
> > 0xffffffff81179875 <deactivate_super+69>:       test   %rax,%rax
> > 0xffffffff81179878 <deactivate_super+72>:       je     0xffffffff8117988f
> > <deactivate_super+95>
> > 0xffffffff8117987a <deactivate_super+74>:       mov    0x8(%rax),%rax
> > 0xffffffff8117987e <deactivate_super+78>:       test   %rax,%rax
> > 0xffffffff81179881 <deactivate_super+81>:       je     0xffffffff8117988f
> > <deactivate_super+95>
> > 0xffffffff81179883 <deactivate_super+83>:       xor    %edx,%edx
> > 0xffffffff81179885 <deactivate_super+85>:       mov    $0xffffffff,%esi
> > 0xffffffff8117988a <deactivate_super+90>:       mov    %rbx,%rdi
> > 0xffffffff8117988d <deactivate_super+93>:       callq  *%rax
> > 0xffffffff8117988f <deactivate_super+95>:       lea    0x70(%rbx),%rdi
> > 0xffffffff81179893 <deactivate_super+99>:       callq  0xffffffff814ee5c0
> > <down_write>
> > 0xffffffff81179898 <deactivate_super+104>:      mov    %rbx,%rdi
> > 0xffffffff8117989b <deactivate_super+107>:      callq  *0x18(%r12)
> > 0xffffffff811798a0 <deactivate_super+112>:      mov    %r12,%rdi
> > 0xffffffff811798a3 <deactivate_super+115>:      callq  0xffffffff81193c20
> > <put_filesystem>
> > 
> > 
> > *This is code for this function*
> > 
> > /**
> >  *      deactivate_super        -       drop an active reference to
> > superblock
> >  *      @s: superblock to deactivate
> >  *
> >  *      Drops an active reference to superblock, acquiring a temprory one if
> >  *      there is no active references left.  In that case we lock
> > superblock,
> >  *      tell fs driver to shut it down and drop the temporary reference we
> >  *      had just acquired.
> >  */
> > void deactivate_super(struct super_block *s)
> > {
> >         struct file_system_type *fs = s->s_type;
> >         if (atomic_dec_and_test(&s->s_active)) {
> >                 vfs_dq_off(s, 0);
> >                 down_write(&s->s_umount);
> >                 fs->kill_sb(s);
> >                 put_filesystem(fs);
> >                 put_super(s);
> >         }
> > }
> > 
> > EXPORT_SYMBOL(deactivate_super);
> > 
> > *now i want to get superblock dump from the stack frame of deactivate_super
> > obtained from bt -f.*
> > 
> > 
> > How do i proceed...
> > 
> > *Questions:-*
> > 1)Which memory address in stack contains struct super_block *s
> 
> It's not on the stack in this case.
> 
> > 2)how does disassembly helps in knowing which register contain the struct
> > super_block *s
> 
> The disassembly doesn't help you in this particular case. Well, it does but
> it is way easier to think as follows:
> 
> The super_block pointer is the first argument to this function. We know from
> the AMD 64 ABI that the first argument, if it fits, is to be delivered in
> the %rdi register. Since 's' is a pointer, it fits, so you'll find the value
> in the %rdi register.
> 
> Maybe it's a good idea to examine a little bit of the disassembly for your
> understanding:
> 
> At the beginning of the disassembly, you see instructions
> 
> [1] 0xffffffff81179830 <deactivate_super>:          push   %rbp
> [1] 0xffffffff81179831 <deactivate_super+1>:        mov    %rsp,%rbp
> [2] 0xffffffff81179834 <deactivate_super+4>:        push   %r12
> [2] 0xffffffff81179836 <deactivate_super+6>:        push   %rbx
> [3] 0xffffffff81179837 <deactivate_super+7>:        nopl   0x0(%rax,%rax,1)
> [4] 0xffffffff8117983c <deactivate_super+12>:       mov    0x30(%rdi),%r12
> 
> which sets up the stack frame ([1]), saves callee-saved registers as per the
> ABI ([2]), does nothing ([3]) and then loads some data relative to %rdi into
> %r12 ([4]). We already know that %rdi is 's' from the C code. So we could
> guess that the above disassembly is performing
> 
> struct file_system_type *fs = s->s_type;
> 
> from the beginning of the C code. There is also proof for this assumption
> later in the disassembly. The %r12 is used near the end of the disassembly
> again:
> 
> [1] 0xffffffff81179898 <deactivate_super+104>:      mov    %rbx,%rdi
> [2] 0xffffffff8117989b <deactivate_super+107>:      callq  *0x18(%r12)
> [3] 0xffffffff811798a0 <deactivate_super+112>:      mov    %r12,%rdi
> [4] 0xffffffff811798a3 <deactivate_super+115>:      callq  0xffffffff81193c20 <put_filesystem>
> 
> First something (we haven't tracked) is moved into %rdi ([1]), followed by a
> call of a function from inside %r12 ([2]). This supposedly is a function
> pointer in 'fs'. If we look at the C code, this is likely to be:
> 
> fs->kill_sb(s);
> 
> So %rbx must be a saved 's' (and it is: look at <deactive_super+23>).
> Anyways, what follows is that %r12 is moved to %rdi ([3]) and another call
> is made (which means that %r12 is to be the first parameter to this
> function). put_filesystem() is called, so this must be the C code:
> 

Sorry, the following is wrong:

> put_super(s);
> 
> And this makes sense, since we know %r12 is a copy of 's'.
> 

It was meant to read:

put_filesystem(fs);

And this makes sense, since we know %r12 is 'fs'.

Regards,
Tobi

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

[amit mehta]

On Mon, Aug 12, 2013 at 5:28 PM, nidhi mittal hada
<nidhimittal19@gmail.com> wrote:
> Questions:-
> 1)Which memory address in stack contains struct super_block *s
> 2)how does disassembly helps in knowing which register contain the struct
> super_block *s
> 3)bt -f gives highlighted above, register dump at the end, does that help in
> finding this information ???

Have you *actually* spent your time on reading the AMD 64ABI [1] ?
Also there is a very nice and concise document available on x86_64
assembly [2]. While trying to analyse kernel crash dump using 'crash',
utility you might want to refer this page [1] and this blog [4] as well.

[1] http://www.uclibc.org/docs/psABI-x86_64.pdf
[2] www.cs.cmu.edu/~fp/courses/15213-s07/misc/asm64-handout.pdf
[3] http://people.redhat.com/~anderson/
[4] http://www.sungju.org/?p=1166

!!amit

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

[nidhi mittal hada]

On Mon, Aug 12, 2013 at 8:37 PM, amit mehta <gmate.amit@gmail.com> wrote:

> On Mon, Aug 12, 2013 at 5:28 PM, nidhi mittal hada
> <nidhimittal19@gmail.com> wrote:
> > Questions:-
> > 1)Which memory address in stack contains struct super_block *s
> > 2)how does disassembly helps in knowing which register contain the struct
> > super_block *s
> > 3)bt -f gives highlighted above, register dump at the end, does that
> help in
> > finding this information ???
>
> Have you *actually* spent your time on reading the AMD 64ABI [1] ?
> Also there is a very nice and concise document available on x86_64
> assembly [2]. While trying to analyse kernel crash dump using 'crash',
> utility you might want to refer this page [1] and this blog [4] as well.
>
> [1] http://www.uclibc.org/docs/psABI-x86_64.pdf
> [2] www.cs.cmu.edu/~fp/courses/15213-s07/misc/asm64-handout.pdf
> [3] http://people.redhat.com/~anderson/
> [4] http://www.sungju.org/?p=1166
>
> !!amit
>

*Thats my system on which  ran crash tool*
[nidhi at raw ~]$ uname -a
Linux raw.ind.hp.com 2.6.32-220.el6.hpsp16k1.x86_64 #1 SMP Mon Nov 19
17:07:07 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

*thats the information of coredump file:-*
      KERNEL: vmlinux
    DUMPFILE: vmcore.1  [PARTIAL DUMP]
        CPUS: 8
        DATE: Mon Jun 11 09:10:59 2012
      UPTIME: 13 days, 22:39:30
LOAD AVERAGE: 83.88, 62.23, 30.30
       TASKS: 393
    NODENAME: million.ind.hp.com
     RELEASE: 2.6.32-220.el6.hpsp16k1.x86_64
     VERSION: #1 SMP Mon Nov 19 17:07:07 UTC 2012
     MACHINE: x86_64  (2132 Mhz)
      MEMORY: 96 GB
       PANIC: "Kernel panic - not syncing: Watchdog detected hard LOCKUP on
cpu 4"
         PID: 26715
     COMMAND: "mount.*******"
        TASK: ffff8817dd4de0c0  [THREAD_INFO: ffff8802c3f80000]
         CPU: 4
       STATE: TASK_UNINTERRUPTIBLE (PANIC)


Thank you very very much .. *It was so helpful what Tobias and amit
explained.*

I actually skipped AMD64 ABI considering its for AMD architecture and mine
was
x86_64 .. my mistake !!

i read from wikipedia x86 calling convention link.
What i read was that all function arguments should be on stack .. thats
where i was wrong....!!!
I read that on x86_64 arg are pushed from right to left ..which also seems
wrong now..

Now i m finding AMD 64ABI is the thing to be read for understanding this
crash output.

Thanks a lottt

Nidhi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130813/a27674f6/attachment.html 

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

[amit mehta]

On Tue, Aug 13, 2013 at 5:47 PM, nidhi mittal hada
<nidhimittal19@gmail.com> wrote:
> thats the information of coredump file:-
>       KERNEL: vmlinux
>     DUMPFILE: vmcore.1  [PARTIAL DUMP]
>         CPUS: 8
>         DATE: Mon Jun 11 09:10:59 2012
>       UPTIME: 13 days, 22:39:30
> LOAD AVERAGE: 83.88, 62.23, 30.30
>        TASKS: 393
>     NODENAME: million.ind.hp.com
>      RELEASE: 2.6.32-220.el6.hpsp16k1.x86_64
>      VERSION: #1 SMP Mon Nov 19 17:07:07 UTC 2012
>      MACHINE: x86_64  (2132 Mhz)
>       MEMORY: 96 GB
>        PANIC: "Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 4"
>          PID: 26715
>      COMMAND: "mount.*******"
>         TASK: ffff8817dd4de0c0  [THREAD_INFO: ffff8802c3f80000]
>          CPU: 4
>        STATE: TASK_UNINTERRUPTIBLE (PANIC)
>

Seems, interrupts are not being re-enabled after a considerable amount of time.
BTW, I'd suggest you to refrain from posting internal organizational
details such
as the NODENAME above, in the public mailing lists.

!!amit

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

[nidhi mittal hada]

On Tue, Aug 13, 2013 at 6:02 PM, amit mehta <gmate.amit@gmail.com> wrote:

> On Tue, Aug 13, 2013 at 5:47 PM, nidhi mittal hada
> <nidhimittal19@gmail.com> wrote:
> > thats the information of coredump file:-
> >       KERNEL: vmlinux
> >     DUMPFILE: vmcore.1  [PARTIAL DUMP]
> >         CPUS: 8
> >         DATE: Mon Jun 11 09:10:59 2012
> >       UPTIME: 13 days, 22:39:30
> > LOAD AVERAGE: 83.88, 62.23, 30.30
> >        TASKS: 393
> >     NODENAME: million.ind.hp.com
> >      RELEASE: 2.6.32-220.el6.hpsp16k1.x86_64
> >      VERSION: #1 SMP Mon Nov 19 17:07:07 UTC 2012
> >      MACHINE: x86_64  (2132 Mhz)
> >       MEMORY: 96 GB
> >        PANIC: "Kernel panic - not syncing: Watchdog detected hard LOCKUP
> on cpu 4"
> >          PID: 26715
> >      COMMAND: "mount.*******"
> >         TASK: ffff8817dd4de0c0  [THREAD_INFO: ffff8802c3f80000]
> >          CPU: 4
> >        STATE: TASK_UNINTERRUPTIBLE (PANIC)
> >
>
> Seems, interrupts are not being re-enabled after a considerable amount of
> time.
> BTW, I'd suggest you to refrain from posting internal organizational
> details such
> as the NODENAME above, in the public mailing lists.
>
> !!amit
>


Hi Amit/Tobias,

I have understood that

*for x86_64 architecture and linux as operating system , GCC as compiler ,
the calling convention to be followed is AMD64 ABI.*
right?

*My doubt is :-*
1) Is the above statement true only for stack frames function call etc ?
OR
Is the above statement true for other things related to architecture,
like for knowing data type sizes, endianness, alignment ..

as http://www.uclibc.org/docs/psABI-x86_64.pdf, mentions , data type size
alignment etc everything ...
are these things same for AMD and x86 architecture both ???

2)Depending on data type, this above doc defines classes in which a
specific data type lie ..
classes like INTEGER, MEMORY , SSE, SSEUP etc ..
are same things applicable in my infrastructure too
OR
they are specific to AMD architecture... if so then whats followed on
x86_64 ..

3) is everything in this doc applicable to x86_64 or just a portion of it
can be followed
for x86_64 ?



Thanks
Nidhi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130814/5a050a3b/attachment.html 

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

[nidhi mittal hada]

On Wed, Aug 14, 2013 at 3:51 PM, nidhi mittal hada
<nidhimittal19@gmail.com>wrote:

>
>
> On Tue, Aug 13, 2013 at 6:02 PM, amit mehta <gmate.amit@gmail.com> wrote:
>
>> On Tue, Aug 13, 2013 at 5:47 PM, nidhi mittal hada
>> <nidhimittal19@gmail.com> wrote:
>> > thats the information of coredump file:-
>> >       KERNEL: vmlinux
>> >     DUMPFILE: vmcore.1  [PARTIAL DUMP]
>> >         CPUS: 8
>> >         DATE: Mon Jun 11 09:10:59 2012
>> >       UPTIME: 13 days, 22:39:30
>> > LOAD AVERAGE: 83.88, 62.23, 30.30
>> >        TASKS: 393
>> >     NODENAME: million.ind.hp.com
>> >      RELEASE: 2.6.32-220.el6.hpsp16k1.x86_64
>> >      VERSION: #1 SMP Mon Nov 19 17:07:07 UTC 2012
>> >      MACHINE: x86_64  (2132 Mhz)
>> >       MEMORY: 96 GB
>> >        PANIC: "Kernel panic - not syncing: Watchdog detected hard
>> LOCKUP on cpu 4"
>> >          PID: 26715
>> >      COMMAND: "mount.*******"
>> >         TASK: ffff8817dd4de0c0  [THREAD_INFO: ffff8802c3f80000]
>> >          CPU: 4
>> >        STATE: TASK_UNINTERRUPTIBLE (PANIC)
>> >
>>
>> Seems, interrupts are not being re-enabled after a considerable amount of
>> time.
>> BTW, I'd suggest you to refrain from posting internal organizational
>> details such
>> as the NODENAME above, in the public mailing lists.
>>
>> !!amit
>>
>
>
> Hi Amit/Tobias,
>
> I have understood that
>
> *for x86_64 architecture and linux as operating system , GCC as compiler
> , the calling convention to be followed is AMD64 ABI.*
> right?
>
> *My doubt is :-*
> 1) Is the above statement true only for stack frames function call etc ?
> OR
> Is the above statement true for other things related to architecture,
> like for knowing data type sizes, endianness, alignment ..
>
> as http://www.uclibc.org/docs/psABI-x86_64.pdf, mentions , data type size
> alignment etc everything ...
> are these things same for AMD and x86 architecture both ???
>
> 2)Depending on data type, this above doc defines classes in which a
> specific data type lie ..
> classes like INTEGER, MEMORY , SSE, SSEUP etc ..
> are same things applicable in my infrastructure too
> OR
> they are specific to AMD architecture... if so then whats followed on
> x86_64 ..
>
> 3) is everything in this doc applicable to x86_64 or just a portion of it
> can be followed
> for x86_64 ?
>
>
>
> Thanks
> Nidhi
>
>
>
>
>
>
>
>
>
>
> And next question is ..

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 ?

Thanks
Nidhi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130814/c0991f39/attachment.html 

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

[Valdis.Kletnieks at vt.edu]

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());'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130814/6c358146/attachment.bin 

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

[nidhi mittal hada]

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@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 

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

[Tobias Boege]

On Tue, 03 Sep 2013, nidhi mittal hada wrote:
> 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.
>
> [...]
> 
> *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);
> }

You won't find a "direct *call* instruction, with function name, written in
english" because 'get_sb' is not a function[*] but a function pointer. And
moreover it is a member of a structure.

You will have to find out where a pointer to this structure is stored and
where a member relative to this structure it is referenced in a call
instruction. (Hint: It is the only function pointer inside 'type' which is
used in this function. Moreover, it is the only function pointer used in
this function at all.)

Regards,
Tobi

[*] To my shame, I have no clue about the subtleties of definitions of
    entities in the C language. Please forgive me if my words don't accord
    with these definitions.

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

[Valdis.Kletnieks at vt.edu]

On Wed, 14 Aug 2013 15:51:20 +0530, nidhi mittal hada said:

> *for x86_64 architecture and linux as operating system , GCC as compiler ,
> the calling convention to be followed is AMD64 ABI.*
> right?
>
> *My doubt is :-*
> 1) Is the above statement true only for stack frames function call etc ?
> OR
> Is the above statement true for other things related to architecture,
> like for knowing data type sizes, endianness, alignment ..
>
> as http://www.uclibc.org/docs/psABI-x86_64.pdf, mentions , data type size
> alignment etc everything ...
> are these things same for AMD and x86 architecture both ???

AMD developed the 64-bit extensions, Intel adopted them as well. The two
architectures are identical for alignment, word sizes, opcodes, and all that
stuff, until you get to truly processor-dependent things like whether it has
SSE3, SSE4, SSE42 extension opcodes, specific MSRs that are only available on
certain family/model/stepping, and so on.  So unless you're looking at *very
specific* things like "Does this particular Intel i5 chipset have the VT-D
extension?" or "how does this CPU handle on the fly firmware updates?" you can
treat the AMD and Intel 64-bit architectures the same.  By the time you're
looking at *that* level of detail, there's more difference between an Intel
Atom N4xx and an Intel Sandy Bridge-based Xeon than there is between Intel and
AMD, even though they're all able to run x86_64.

And if you're doing *that* sort of coding, you want to go look at how
the code that handles the /proc/cpuinfo pseudo-file handles the the
'flags' line, and how code uses the bits presented there, and how the
kernel determines which cpufreq driver to use, and so on...


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130814/87245ed6/attachment.bin 

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

[Andreas Platschek]

> c)lets say for a program a.c i use gcc -S a.c ...do we have some other 
> command to generate
> somewhat more clear assembly code, may be with some comments in english
>
Not sure if this is of any help, but the kernel build system (no idea 
how to do this for user space programs) offers to generate a listing 
that interleaves the c code into assembly making it better readable. So 
if your function is e.g. in kernel/rtmutex.c you could do the following:

andi at PC63:~/working_git/linux-next$ make kernel/rtmutex.lst
   SYSHDR arch/x86/syscalls/../include/generated/uapi/asm/unistd_32.h
   SYSHDR arch/x86/syscalls/../include/generated/uapi/asm/unistd_64.h
<SNIP>
   HOSTCC  scripts/asn1_compiler
   MKLST   kernel/rtmutex.lst
No System.map
andi at PC63:~/working_git/linux-next$

here is one function from the resulting rtmutex.lst file:

static void fixup_rt_mutex_waiters(struct rt_mutex *lock)
{
   70:    e8 00 00 00 00           callq  75 <fixup_rt_mutex_waiters+0x5>
                                      71: R_X86_64_PC32 
__fentry__+0xfffffffffffffffc
   75:    55                       push   %rbp
   76:    48 ff 05 00 00 00 00     incq   0x0(%rip)        # 7d 
<fixup_rt_mutex_waiters+0xd>
                                       79: R_X86_64_PC32 .bss+0x6fc
   7d:    48 89 e5                 mov    %rsp,%rbp
   80:    53                       push   %rbx
   81:    48 89 fb                 mov    %rdi,%rbx
                                            if (!rt_mutex_has_waiters(lock))
   84:    e8 8e ff ff ff           callq  17 <rt_mutex_has_waiters>
   89:    48 ff 05 00 00 00 00     incq   0x0(%rip)        # 90 
<fixup_rt_mutex_waiters+0x20>
             8c: R_X86_64_PC32    .bss+0x704
   90:    85 c0                    test   %eax,%eax
   92:    75 0c                    jne    a0 <fixup_rt_mutex_waiters+0x30>
}

btw. you can for example generate the pre-processed code in the same way:

andi at PC63:~/working_git/linux-next$ make kernel/rtmutex.i

or the assembly code:

andi at PC63:~/working_git/linux-next$ make kernel/rtmutex.s

this is especially helpful, as it also contains a list of all the flags 
used for compiling.

regards,
andi


> Any kind of help in understanding this will be appreciated ..
>
> Thanks
> Nidhi
>
>
>
>
>
> -- 
> Thanks & Regards
> Nidhi Mittal Hada
>
> http://nidhi-searchingmyself.blogspot.com/
>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130806/25fc4a97/attachment-0001.html