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+f...

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

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:

...

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.

...

-----Original Message----- From: kernelnewbies-bounces@kernelnewbies.org [mailto:kernelnewbies- bounces@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

...

...

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-pa... 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

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

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

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

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

...

...

...

...

...

...

...

...

...

security_sb_copy_data

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

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