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@xxxxxxxxx> 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,
NehaOn Fri, Aug 9, 2013 at 1:19 PM, Tayade, Nilesh <Nilesh.Tayade@xxxxxxxxxxxx> wrote:
> -----Original Message-----
> From: kernelnewbies-bounces@xxxxxxxxxxxxxxxxx [mailto:kernelnewbies-
> bounces@xxxxxxxxxxxxxxxxx] On Behalf Of Matthias Brugger
> Sent: Tuesday, August 06, 2013 7:14 PM
> To: nidhi mittal hada
> Cc: kernelnewbies@xxxxxxxxxxxxxxxxx
> Subject: Re: Understanding disassembly x86 + understanding function call +
> parameter pass and stack frame
>
> 2013/8/6 nidhi mittal hada <nidhimittal19@xxxxxxxxx>:[...]
> > Hi All,[...]
> >
> > I am using crash tool to analyze core dump obtained from red hat linux
> > on
> > x86_64 platform.
> >May be you would like to take a look at below link:
> > Putting some of the doubts..
> >
> > a)like which sequence the parameters, return address, etc are pushed
> > on stack?
http://www.cs.virginia.edu/~evans/cs216/guides/x86.html [Section: Calling Convention] has the exact answer to your question.
You also might want to read the tutorials:
> > b)Which registers are used, if some registers play some spl. role ?
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.
> > some comments in English
> > 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
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.
[...]
>Hope it helps.
> >
> > Any kind of help in understanding this will be appreciated ..
> >
> > Thanks
> > Nidhi
--
Thanks,
Nilesh
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
--
Thanks & Regards
Nidhi Mittal Hada
http://nidhi-searchingmyself.blogspot.com/
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
