I compiled the code with -O0 optimization level
Ours is a customized processor which I am not supposed to reveal its
name/ arch
The scenario is exactly like this concerned to c code mentioned below
int main()
{
int a, b , c;
a =10;
b =20;
c = add(a,b);
return 0;
}
int add(int x, int y)
{
return x+y;
}
FRAME POINTER ------->>>>>
0x0006deb0
0x0006deac (variable c), valid location
0x0006dea8 (variable b), valid location
0x0006dea4 (variable a), valid location
0x0006dea0 (argument y) , valid location
STACK POINTER------>>
0x0006de9c (argument x) , valid location
0x0006de98 empty
0x0006de94 empty
0x0006de90 (variable a), as per debugger (invalid)
0x0006de8c (variable b), as per debugger(invalid)
0x0006de88 (variable c), as per debugger(invalid)
Though I am relatively new to gcc , as per my knowledge , local
variables and arguments should be filled between frame pointer and stack
pointer.
My STACK GROWS DOWNWARD and FRAME GROWS DOWNWARD. (both macros set to 1).
Thanks,
Sumanth G
Ian Lance Taylor wrote:
sumanth <sumanth.gundapneni@xxxxxxxxxxxxxxxxxx> writes:
I have an issue related to debugging information generated by compiler.
DEBUGGING TYPE is DWARF2.
COMPILER : gcc 4.3.3
Address of local variables is not generated aptly .
Lets take a sample code Example :
int main ()
{
int a , b, c;
a=10;
b=20;
c =a+b;
return 0;
}
when I debug it with gdb , address of variables a, b, c are not as
intended .
All the local variables should be filled in between frame pointer and
stack pointer ( stack is a top down stack).
Rather the local variables address are located 8 locations below stack
pointer.
Can anyone point me to the apt solution for this problem. What macros
should I refer to for correct debugging information generated by
compiler.
Are you sure there is a problem? The compiler is free to place local
variables where it chooses, within certain constraints. The debugging
information must reflect the actual location of the variables. It is
permitted for variables to be below the stack pointer on a processor
which uses a red zone, such as the x86_64.
Ian
