Still problems with gdb and nested functions.

Still problems with gdb and nested functions.

[tj]

I posted before about gdb not printing local variables when within 
nested functions and I thought the problem had been solved when it was 
mentioned my demo worked when using gdb 6.1, which I upgraded to.
BUt, now I have discovered even it has a problem.
Sample file:
#include <stdio.h>

int main(int argc, char *argv[]){

  int i,j;

  int inside(void){
    int k,l;

    k = 1;
    l = k;
    printf("inside, k = %d, l = %d\n", k,l);
    return 0;

  }

  inside();
  i = 0;
  j = 1;
}

Now, run gdb and do the following:
(gdb) b test.c:12
Breakpoint 1 at 0x8048352: file test.c, line 12.
(gdb) b test.c:19
Breakpoint 2 at 0x804838d: file test.c, line 19.
(gdb) run
Starting program: /home/wd4nmq/src/test/test/a.out

Breakpoint 1, inside.0 () at test.c:12
12          printf("inside, k = %d, l = %d\n", k,l);
(gdb) p k
No symbol "k" in current context.
(gdb) continue
Continuing.
inside, k = 1, l = 1

Breakpoint 2, main (argc=1, argv=0xbffff964) at test.c:19
19        j = 1;
(gdb) p i
$1 = 0
(gdb)

While it now prints the value of i, which it wasn't pre v6.1, but it 
still doesn't print the k value when stopped within the inside() 
function, where it is in scope.
Oh well, at least is some progress :-).

gcc 3.23
gdb 6.1

tj

Re: Still problems with gdb and nested functions.

[Paul Hilfinger]

> #include <stdio.h>
> 
> int main(int argc, char *argv[]){
> 
>   int i,j;
> 
>   int inside(void){
>     int k,l;
> 
>     k = 1;
>     l = k;
>     printf("inside, k = %d, l = %d\n", k,l);
>     return 0;
> 
>   }
> 
>   inside();
>   i = 0;
>   j = 1;
> }
> 
....
> Breakpoint 1, inside.0 () at test.c:12
> 12          printf("inside, k = %d, l = %d\n", k,l);
> (gdb) p k
> No symbol "k" in current context.

I presume you have confirmed that k is actually there (since it is set
only from a constant, it could be folded away even without fancy
optimization).

Paul Hilfinger

Re: Still problems with gdb and nested functions.

[Cal Erickson]

You might try updating your GCC release. We found the same problem and
it was fixed by upgrading GCC.

Cal Erickson

Paul Hilfinger wrote:
>>#include <stdio.h>
>>
>>int main(int argc, char *argv[]){
>>
>>  int i,j;
>>
>>  int inside(void){
>>    int k,l;
>>
>>    k = 1;
>>    l = k;
>>    printf("inside, k = %d, l = %d\n", k,l);
>>    return 0;
>>
>>  }
>>
>>  inside();
>>  i = 0;
>>  j = 1;
>>}
>>
> 
> ....
> 
>>Breakpoint 1, inside.0 () at test.c:12
>>12          printf("inside, k = %d, l = %d\n", k,l);
>>(gdb) p k
>>No symbol "k" in current context.
> 
> 
> I presume you have confirmed that k is actually there (since it is set
> only from a constant, it could be folded away even without fancy
> optimization).
> 
> Paul Hilfinger

-- 
===========================================================================
Cal Erickson                 MontaVista Software Inc.
Linux Consultant             1237 E. Arques Ave.
Phone (408) 328-0304         Sunnyvale CA 94085
Fax   (408) 328-9204         web http://www.mvista.com
===========================================================================

Re: Still problems with gdb and nested functions.

[Eli Zaretskii]

> Date: Tue, 22 Feb 2005 12:24:29 -0800
> From: Cal Erickson <cerickson@mvista.com>
> CC: tj <999alfred@comcast.net>, gdb@sources.redhat.com
> 
> You might try updating your GCC release. We found the same problem and
> it was fixed by upgrading GCC.

To what version of GCC?  I see this problem with GCC 3.4.3, which is
(AFAIK) the latest released version.

Re: Still problems with gdb and nested functions.

[Cal Erickson]

I believe, that Daniel J. back-ported it for us under contract from one
of the 3.4 GCC releases. I hope he is reading this. He can shed more
light on the area.

Cal

Eli Zaretskii wrote:
>>Date: Tue, 22 Feb 2005 12:24:29 -0800
>>From: Cal Erickson <cerickson@mvista.com>
>>CC: tj <999alfred@comcast.net>, gdb@sources.redhat.com
>>
>>You might try updating your GCC release. We found the same problem and
>>it was fixed by upgrading GCC.
> 
> 
> To what version of GCC?  I see this problem with GCC 3.4.3, which is
> (AFAIK) the latest released version.
> 

-- 
===========================================================================
Cal Erickson                 MontaVista Software Inc.
Linux Consultant             1237 E. Arques Ave.
Phone (408) 328-0304         Sunnyvale CA 94085
Fax   (408) 328-9204         web http://www.mvista.com
===========================================================================

Re: Still problems with gdb and nested functions.

[Cal Erickson]

Eli,
Here is the original gcc bug filed in bugz.
The fix came out of gcc 3.5 cvs.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14444
no proper debugging information for local variable

Cal


Eli Zaretskii wrote:
>>Date: Tue, 22 Feb 2005 12:24:29 -0800
>>From: Cal Erickson <cerickson@mvista.com>
>>CC: tj <999alfred@comcast.net>, gdb@sources.redhat.com
>>
>>You might try updating your GCC release. We found the same problem and
>>it was fixed by upgrading GCC.
> 
> 
> To what version of GCC?  I see this problem with GCC 3.4.3, which is
> (AFAIK) the latest released version.

-- 
===========================================================================
Cal Erickson                 MontaVista Software Inc.
Linux Consultant             1237 E. Arques Ave.
Phone (408) 328-0304         Sunnyvale CA 94085
Fax   (408) 328-9204         web http://www.mvista.com
===========================================================================

Re: Still problems with gdb and nested functions.

[Eli Zaretskii]

> cc: gdb@sources.redhat.com
> Date: Tue, 22 Feb 2005 12:15:11 -0800
> From: Paul Hilfinger <hilfingr@EECS.Berkeley.EDU>
> 
> > No symbol "k" in current context.
> 
> I presume you have confirmed that k is actually there (since it is set
> only from a constant, it could be folded away even without fancy
> optimization).

AFAIK, GCC never optimizes _anything_ under -O0, not even redundant
register reloads.

Anyway, the disassembly I posted shows that k does in fact exist and
is stored on the stack, as expected.

Re: Still problems with gdb and nested functions.

[Eli Zaretskii]

> Date: Tue, 22 Feb 2005 14:17:42 -0500
> From: tj <999alfred@comcast.net>
> 
> Breakpoint 1, inside.0 () at test.c:12
> 12          printf("inside, k = %d, l = %d\n", k,l);
> (gdb) p k
> No symbol "k" in current context.
> (gdb) continue
> Continuing.
> inside, k = 1, l = 1

I can confirm this, but it looks like this is either a GCC problem, or
perhaps GCC generates DWARF-2 debug info that confuses GDB.  Observe:

  $ gcc -O0 -ggdb3 -o test test.c
  $ gdb ./test
  ...
  (gdb) break 12
  Breakpoint 1 at 0x16de: file test.c, line 12.
  (gdb) info address k
  No symbol "k" in current context.
  (gdb) disassemble
  Dump of assembler code for function inside.0:
  0x000016c8 <inside.0+0>:        push   %ebp
  0x000016c9 <inside.0+1>:        mov    %esp,%ebp
  0x000016cb <inside.0+3>:        sub    $0x18,%esp
  0x000016ce <inside.0+6>:        mov    %ecx,0xfffffffc(%ebp)
  0x000016d1 <inside.0+9>:        movl   $0x1,0xfffffff8(%ebp)
  0x000016d8 <inside.0+16>:       mov    0xfffffff8(%ebp),%eax
  0x000016db <inside.0+19>:       mov    %eax,0xfffffff4(%ebp)
  0x000016de <inside.0+22>:       sub    $0x4,%esp
  0x000016e1 <inside.0+25>:       pushl  0xfffffff4(%ebp)
  0x000016e4 <inside.0+28>:       pushl  0xfffffff8(%ebp)
  0x000016e7 <inside.0+31>:       push   $0x16b0
  0x000016ec <inside.0+36>:       call   0x3360 <printf>
  0x000016f1 <inside.0+41>:       add    $0x10,%esp
  0x000016f4 <inside.0+44>:       mov    $0x0,%eax
  0x000016f9 <inside.0+49>:       leave
  0x000016fa <inside.0+50>:       ret
  End of assembler dump.
  (gdb) info locals
  No locals.

The disassembly clearly shows that GDB is wrong: the variable k is
stored at 0xfffffff8(%ebp).

Now watch what happens with stabs debug info:

  gcc -O0 -gstabs3 -o test test.c
  $ gdb ./test
  ...
  (gdb) break 12
  Breakpoint 1 at 0x160e: file test.c, line 12.
  (gdb) info address k
  Symbol "k" is a local variable at frame offset -8.
  (gdb) print k
  $1 = 1
  (gdb) info locals
  k = 1
  l = 1
  (gdb)

So with stabs debug info, GDB works correctly, but with the default
DWARF-2 debug info, it gets confused.

(Strangely, the code location corresponding to breakpoint at line 12
is also different in these two builds: 0x160e vs 0x16de.  Why would
debug info affect code locations? anyone?)