g++ 3.2.1 not generating proper debugging information

g++ 3.2.1 not generating proper debugging information

[S B]

Hello all,

I have a small program for which g++ 3.2.1 doesn't seem to generate the
right debugging information. Although this problem was seen in a vendor
supplied cross compiler, I confirmed that it exists in 3.x.y native
compilers on RedHat and Solaris, so this mailing list seemed the most
obvious place to report it.

The magic combination to trigger this problems seems to be a string/int
pair straddling a while/switch code block:

#include <string>
#include <stdio.h>
int main(int argc, char *argv[]) {
    std::string a = "foo";
    int c = 0;
    while (c != -1) {
	switch (c = getchar()) {
	    default:
		printf ("read %d, %s\n", c, a.c_str());
		c = -1; // break the loop
		break;
	}
    }
    std::string b = "bar";
    int k = 10;
    printf("%s %s %d\n", a.c_str(), b.c_str(), k);
}

When I compile this with -g and default optimization and load it in
gdb, I can't see all the local variables via 'info locals'.

Here are my observations about the program:
- This is the exact combination that causes the problem; if I delete
one of the string variables, switch the order of variable definitions,
or delete the while/switch blocks, the problem goes away.
- To begin with, only the variable 'k' is visible. Even inside the
while loop, I can't see 'c' or 'a'.
- All variables become visible once I exit the while loop.
- It doesn't matter if I actually use the variables or not - they are
invisible until I exit the while loop.
- If I switch to g++ 2.95.3, all is well. Problem begins with g++
3.2.1.

(Cross) Compiler is:

/opt/hardhat3.0/hardhat/devkit/x86/586/bin/586-g++ -v
Reading specs from
/opt/hardhat3.0/hardhat/devkit/x86/586/bin/../lib/gcc-lib/i586-hardhat-linux/3.2.1/specs
Configured with: ../configure --host=i686-pc-linux-gnu
--target=i586-hardhat-linux --prefix=/opt/hardhat/devkit/x86/586
--exec-prefix=/opt/hardhat/devkit/x86/586
--bindir=/opt/hardhat/devkit/x86/586/bin
--sbindir=/opt/hardhat/devkit/x86/586/sbin
--sysconfdir=/opt/hardhat/devkit/x86/586/etc
--datadir=/opt/hardhat/devkit/x86/586/share
--includedir=/opt/hardhat/devkit/x86/586/include
--libdir=/opt/hardhat/devkit/x86/586/lib
--libexecdir=/opt/hardhat/devkit/x86/586/libexec
--localstatedir=/opt/hardhat/devkit/x86/586/var
--sharedstatedir=/opt/hardhat/devkit/x86/586/share
--mandir=/opt/hardhat/devkit/x86/586/man
--infodir=/opt/hardhat/devkit/x86/586/info
--program-transform-name=s,^,586-, --enable-cross
--with-gxx-include-dir=${prefix}/i586-hardhat-linux/include/g++-v3
--enable-shared --enable-languages=c,c++ --enable-threads=posix
--enable-__cxa_atexit --disable-multilib --with-cpu=i586
Thread model: posix
gcc version 3.2.1 20020930 (MontaVista)

Debugger is:
swtest38:~-15> gdb --version
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i586-hardhat-linux".

Target system is:
swtest38:~-18> uname -a
Linux swtest38 2.4.18 #1 Wed Feb 11 00:31:23 CST 2004 i586 unknown

Thanks for your time and help. If you need additional information,
please email me.

Sriram

PS: Sorry for not including the preprocessed output; I thought that
since string and stdio.h are standard header files, a source file is
sufficient.

Re: g++ 3.2.1 not generating proper debugging information

[Jim Wilson]

S B wrote:
> When I compile this with -g and default optimization and load it in
> gdb, I can't see all the local variables via 'info locals'.

The locals are there, but they have been put into a lexical block, which 
is not correct.  The current development sources seem to handle this 
correctly.  a, b, and c are visible in the entire function except the 
prologue/epilogue, and k is visible only after the loop.

info locals still didn't work for me though.  It fails to print the 
value of a, and then bails out.

This is for an x86-linux target that uses dwarf2 debug info.  I didn't 
check a stabs target like solaris.

By the way, we do not track bug reports sent to the mailing lists.  We 
only track bug reports filed into our bugzilla database.  If you want 
action taken on a bug report, it is better to put it in buzilla than to 
mail it to gcc-bugs.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com