Why are NOT the function parametters in the stack. They are in the register!

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Why are NOT the function parametters in the stack. They are in the register!

MCG LU Fengcheng
Hello all

      In my program, I have a confused problem. Any helps are welcome!

     I have the following function with variable parameters
     void PrintTrace(char* fileName, int lineNo, char* traceType, char* fmt,...)
     {
          va_list args;
          char buf[MX_SIZE];

          ...........................................................
          va_start(args,fmt);
          vsnprintf(buf,MX_SIZE,fmt,args);
          va_end(args);
          ..............................................................
     }

    Sometimes, program crash when PrintTrace is called. I use the gdb to analyze the problem.

    root@aaa-n3s30#gdb a.out core.1462
    GNU gdb 6.1.1
    .......................................
    Core was generated by `/home/lfc/a.out'.
    Program terminated with signal 11, Segmentation fault.
    .....................................................
    #0  0x4013641b in vfprintf () from /lib/libc.so.6  

    Then I run the bt, get the output:
  (gdb) bt
    #0  0x4013641b in vfprintf () from /lib/libc.so.6
    #1  0x40154b7c in vsnprintf () from /lib/libc.so.6
    #2  0x40079316 in PrintTrace (fileName=0x400a07a0 "/home/lfc/test.c", lineNo=340, traceType=0x0, fmt=0x0) at test.c:248
    #3  0x400934d2 in CmwInit (vceId=1003) at /home/lfc/test.c:340
    #4  0x08049281 in main (argc=1, argv=0xbffff954) at test.c:463  

    In the PrintTrace, traceType and fmt are both NULL. It's impossible. I always give the valid pointer for the traceType and fmt.

    I run f 2 and try to print the traceType and fmt address.
    (gdb) f 2
    #2  0x40079316 in PrintTrace (fileName=0x400a07a0 "/home/lfc/test.c", lineNo=340, traceType=0x0, fmt=0x0) at test.c:248
    (gdb) p &traceType
    Address requested for identifier "traceType" which is in register $eax
    (gdb) p &fmt
    Address requested for identifier "fmt" which is in register $eax  

     gdb complains fmt and traceType are in the register eax. Why not in the stack. In fact, lineNo and filename are in the stack. Gdb can print their address out.

     I check the eax value. It is zero. I also check the stack. I found the fmt and traceType address were in the stack.

     It's the gdb issue? I can't understand it.

      Help me!!!!!!!!!!!!!!!!!!

B.R.
Lu
Reply | Threaded
Open this post in threaded view
|

Re: Why are NOT the function parametters in the stack. They are in the register!

Daniel Jacobowitz-2
On Wed, Nov 02, 2005 at 02:07:26PM +0800, MCG LU Fengcheng wrote:

>     (gdb) p &traceType
>     Address requested for identifier "traceType" which is in register $eax
>     (gdb) p &fmt
>     Address requested for identifier "fmt" which is in register $eax  
>
>      gdb complains fmt and traceType are in the register eax. Why not in the stack. In fact, lineNo and filename are in the stack. Gdb can print their address out.
>
>      I check the eax value. It is zero. I also check the stack. I found the fmt and traceType address were in the stack.
>
>      It's the gdb issue? I can't understand it.

Usually this means they are no longer "available", but debug
information has failed to represent that fact.  They were loaded
from the stack, used, and then not used after the current call returns.

Don't worry about it.

--
Daniel Jacobowitz
CodeSourcery, LLC
Reply | Threaded
Open this post in threaded view
|

Re: Why are NOT the function parametters in the stack. They are in the register!

JimB-3
In reply to this post by MCG LU Fengcheng

"MCG LU Fengcheng" <[hidden email]> writes:
> Hello all
>     In the PrintTrace, traceType and fmt are both NULL. It's impossible. I always give the valid pointer for the traceType and fmt.

Did you compile your code with optimization?  Try compiling without
optimization and see if things behave more reasonably.

When the optimizer changes the program's code, it doesn't always
accurately describe to GDB what it has done.  When this happens, GDB
can run into troubles finding variables' values (among other things).