This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

varobj/2046: gdb fails to display SOME local symbols generated by different versions of g++


>Number:         2046
>Category:       varobj
>Synopsis:       gdb fails to display SOME local symbols generated by different versions of g++
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sun Dec 04 01:28:01 GMT 2005
>Closed-Date:
>Last-Modified:
>Originator:     S. Chaudhuri
>Release:        gdb 6.3, 6.4
>Organization:
>Environment:
SunOS 5.8 SunFire V210
>Description:
This bug originated on the GCC bug list as referenced by http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25234.

When trying to debug the following block of code, some of the function's local variables can not be displayed using display, print, or info scope [function].  Display and print will work after a certain point within the stack frame of the function foo(), but long after the variables are initialized.

Different results on all three versions of g++ [2.95.3, 3.3.3, 4.0.0].

Only 2.95.3 produces the desired output.

After investigating the gcc bug list, several potential duplicates have been dismissed as not being the same issue, as referenced below:

8542
10156
11098
24526

The issue was first noticed on a SunOS 5.8 SunFire V210 server when trying to upgrade from gcc 2.95.2 to gcc 3.3.3.  All of the following scenarios are reproducible using gdb 6.3 and 6.4.
>How-To-Repeat:
Please examine
the following source code and output.

#include <string>
using std::string;

#include <map>
using std::map;

class myElem
{
};

class myMap : public map<string, myElem>
{
};

class myClass
{
};

int
foo(myClass& asset)
{
    int          rcode(0);
    unsigned int n;

    n = 0;
    switch(n)
    {
        default:
            break;
    }

#ifndef GOODDBG
    map<string, myElem> nfacts;
#endif

    myElem mfacts;

    return rcode;
}

int
main(int argc, char *argv[])
{
    myClass c;
    foo( c );
    return 0;
}


-------------------------------

!!! MISSING THREE SYMBOLS !!!
> g++3.3.3 -Wno-deprecated -gstabs+ -o test test.C
> gdb test
GNU gdb 6.3
Copyright 200....
(gdb) info scope foo
Scope for foo:
Symbol asset is an argument at stack/frame offset 68, length 4.
Symbol mfacts is a local variable at frame offset -41, length 1.

!!! MISSING ONE SYMBOL !!!
> g++3.3.3 -Wno-deprecated -gstabs+ -DGOODDBG -o test test.C
> gdb test
GNU gdb 6.3
Copyright 200....
(gdb) info scope foo
Scope for foo:
Symbol asset is an argument at stack/frame offset 68, length 4.
Symbol rcode is a local variable at frame offset -20, length 4.
Symbol n is a local variable at frame offset -24, length 4.
Symbol mfacts is a local variable at frame offset -25, length 1.

!!! MISSING ONE SYMBOL !!!
> g++4.0.0 -Wno-deprecated -gstabs+ -o test test.C
> gdb test
GNU gdb 6.3
Copyright 200....
(gdb) info scope foo
Scope for foo:
Symbol asset is an argument at stack/frame offset 68, length 4.
Symbol rcode is a local variable at frame offset -24, length 4.
Symbol n is a local variable at frame offset -20, length 4.
Symbol nfacts is a local variable at frame offset -48, length 24.

!!! WORKS CORRECTLY !!!
> g++2.95.2 -Wno-deprecated -gstabs+ -o test test.C
> gdb test
GNU gdb 6.3
Copyright 200....
(gdb) info scope foo
Scope for foo:
Symbol asset is an argument at stack/frame offset 68, length 4.
Symbol rcode is a local variable at frame offset -20, length 4.
Symbol n is a local variable at frame offset -24, length 4.
Symbol nfacts is a local variable at frame offset -40, length 12.
Symbol mfacts is a local variable at frame offset -41, length 1.


Based on the fact that changing the GOODDBG flag alters the appearance of
unrelated symbols in the debugger, it seems like this is not the desired effect
due to optimization or for any other logical reason.

Additionally, gcc produces debugging info for each of the variables:
        .stabs  "mfacts:(1,1)",128,0,37,-41
        .stabn  192,0,0,.LBB2-.LFB994
        .stabs  "rcode:(0,1)",128,0,23,-12
        .stabs  "n:(0,4)",128,0,24,-16
        .stabs  "nfacts:(1,133)",128,0,34,-40
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]