Re: Understanding disassembly x86 + understanding function call + parameter pass and stack frame
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.
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Understanding disassembly x86 + understanding function call + parameter pass and stack frame
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
0x81183880 vfs_kern_mount:push %rbp
0x81183881 vfs_kern_mount+1: mov%rsp,%rbp
0x81183884 vfs_kern_mount+4: sub$0x40,%rsp
0x81183888 vfs_kern_mount+8: mov%rbx,-0x28(%rbp)
0x8118388c vfs_kern_mount+12: mov%r12,-0x20(%rbp)
0x81183890 vfs_kern_mount+16: mov%r13,-0x18(%rbp)
0x81183894 vfs_kern_mount+20: mov%r14,-0x10(%rbp)
0x81183898 vfs_kern_mount+24: mov%r15,-0x8(%rbp)
0x8118389c vfs_kern_mount+28: nopl 0x0(%rax,%rax,1)
0x811838a1 vfs_kern_mount+33: mov$0xffed,%rbx
0x811838a8 vfs_kern_mount+40: test %rdi,%rdi
0x811838ab vfs_kern_mount+43: mov%rdi,%r12
0x811838ae vfs_kern_mount+46: mov%esi,%r13d
0x811838b1 vfs_kern_mount+49: mov%rdx,%r14
0x811838b4 vfs_kern_mount+52: je 0x8118395b
vfs_kern_mount+219
0x811838ba vfs_kern_mount+58: mov%rdx,%rdi
0x811838bd vfs_kern_mount+61: mov%rcx,-0x38(%rbp)
IGNORING THE ABOVE TEXT FOR
NOW
0x811838c1 vfs_kern_mount+65: callq 0x811a1f60 *
alloc_vfsmnt*
0x811838c6 vfs_kern_mount+70: test %rax,%rax*should contain
mnt *
0x811838c9 vfs_kern_mount+73: mov%rax,%rbx
0x811838cc vfs_kern_mount+76: mov-0x38(%rbp),%rcx
0x811838d0 vfs_kern_mount+80: je 0x811839f0
vfs_kern_mount+368*goto out, if rax is 0 *
0x811838d6 vfs_kern_mount+86: test %rcx,%rcxif data is
false = 0
0x811838d9 vfs_kern_mount+89: je 0x811838e7
vfs_kern_mount+103*type-get_sb()*
0x811838db vfs_kern_mount+91: testb $0x2,0x8(%r12)r12
contains type
0x811838e1 vfs_kern_mount+97: je 0x811839b8
vfs_kern_mount+312*alloc_secdata*
0x811838e7 vfs_kern_mount+103:xor%r15d,%r15d
0x811838ea vfs_kern_mount+106:mov%rbx,%r8
0x811838ed vfs_kern_mount+109:mov%r14,%rdx
0x811838f0 vfs_kern_mount+112:mov%r13d,%esi
0x811838f3 vfs_kern_mount+115:mov%r12,%rdi
0x811838f6 vfs_kern_mount+118:callq *0x10(%r12)*
security_sb_copy_data
*
0x811838fb vfs_kern_mount+123:test %eax,%eax
0x811838fd vfs_kern_mount+125:js 0x81183990
vfs_kern_mount+272*goto out_free_secdata *
0x81183903 vfs_kern_mount+131:mov0x28(%rbx),%rax
0x81183907 vfs_kern_mount+135:test %rax,%rax
0x8118390a vfs_kern_mount+138:je 0x811839fc
vfs_kern_mount+380* get_sb*
0x81183910 vfs_kern_mount+144:orq
$0x2000,0x58(%rax)
0x81183918 vfs_kern_mount+152:mov%r15,%rdx
0x8118391b vfs_kern_mount+155:mov%r13d,%esi
0x8118391e vfs_kern_mount+158:mov0x28(%rbx),%rdi
0x81183922 vfs_kern_mount+162:callq 0x8121b9b0 *
security_sb_kern_mount*
IGNORING THE BELOW TEXT TOO
0x81183927 vfs_kern_mount+167:test %eax,%eax
0x81183929 vfs_kern_mount+169:jne0x81183978
vfs_kern_mount+248
0x8118392b vfs_kern_mount+171:mov0x28(%rbx),%rdi
0x8118392f vfs_kern_mount+175:mov0x28(%rdi),%r8
0x81183933 vfs_kern_mount+179:test %r8,%r8
0x81183936 vfs_kern_mount+182:js 0x81183a02
vfs_kern_mount+386
0x8118393c vfs_kern_mount+188:mov0x20(%rbx),%rax
0x81183940 vfs_kern_mount+192:add$0x70,%rdi
0x81183944 vfs_kern_mount+196:mov%rbx,0x10(%rbx)
0x81183948 vfs_kern_mount+200:mov%rax,0x18(%rbx)
0x8118394c vfs_kern_mount+204:callq 0x8109c1a0
up_write
0x81183951 vfs_kern_mount+209:xor%esi,%esi
0x81183953 vfs_kern_mount+211:mov%r15,%rdi
0x81183956 vfs_kern_mount+214:callq 0x8112c820
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
Re: Understanding disassembly x86 + understanding function call + parameter pass and stack frame
On Tue, Aug 13, 2013 at 6:02 PM, amit mehta gmate.a...@gmail.com wrote: On Tue, Aug 13, 2013 at 5:47 PM, nidhi mittal hada nidhimitta...@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: 8817dd4de0c0 [THREAD_INFO: 8802c3f8] 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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Understanding disassembly x86 + understanding function call + parameter pass and stack frame
On Mon, Aug 12, 2013 at 8:37 PM, amit mehta gmate.a...@gmail.com wrote: On Mon, Aug 12, 2013 at 5:28 PM, nidhi mittal hada nidhimitta...@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@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: 8817dd4de0c0 [THREAD_INFO: 8802c3f8] 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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Understanding disassembly x86 + understanding function call + parameter pass and stack frame
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.tay...@netscout.comwrote: -Original Message- From: kernelnewbies-boun...@kernelnewbies.org [mailto:kernelnewbies- boun...@kernelnewbies.org] On Behalf Of Matthias Brugger Sent: Tuesday, August 06, 2013 7:14 PM To: nidhi mittal hada Cc: kernelnewbies@kernelnewbies.org Subject: Re: Understanding disassembly x86 + understanding function call + parameter pass and stack frame 2013/8/6 nidhi mittal hada nidhimitta...@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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Understanding disassembly x86 + understanding function call + parameter pass and stack frame
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 nidhimitta...@gmail.comwrote: -- Forwarded message -- From: nidhi mittal hada nidhimitta...@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 kernelnewb...@nl.linux.org Cc: Mulyadi Santosa mulyadi.sant...@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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Understanding disassembly x86 + understanding function call + parameter pass and stack frame
On Tue, Aug 6, 2013 at 10:43 AM, Saket Sinha saket.sinh...@gmail.comwrote: 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 nidhimitta...@gmail.com wrote: -- Forwarded message -- From: nidhi mittal hada nidhimitta...@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 kernelnewb...@nl.linux.org Cc: Mulyadi Santosa mulyadi.sant...@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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Thank you Warm Regards Anuz ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Fwd: Understanding disassembly x86 + understanding function call + parameter pass and stack frame
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@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@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__+0xfffc
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 c0test %eax,%eax
92:75 0cjnea0 fixup_rt_mutex_waiters+0x30
}
btw. you can for example generate the pre-processed code in the same way:
andi@PC63:~/working_git/linux-next$ make kernel/rtmutex.i
or the assembly code:
andi@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@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
