Hello,
I hope that I am wrong about this following statement and supporting
text; gdb cannot properly deal with the concept of namespaces in the c++
language.
First I'll mention the machine details:
- The first machine I tried this on
- UltraSparc-10 running Solaris 2.5
- gdb 4.16
- g++ not sure
- The second machine I tried this on
- Pentium 133 running Mandrake Linux 7.0 with kernal version 2.2.1
- gdb 4.18
- g++ 2.95.2
Both machines exhibited identical behaviour (well, the pentium did it
slowly :) ).
-----TEST1-----
The debugger can cope with this straight forward use of namespaces:
namespace A {
class Object {...};
}
namespace B {
class Object {...};
}
int main(void) {
A::Object a;
B::Object b;
//use a and b and you can pick them out with the debugger just fine...
}
Attached to this post you will find a file called test1.script.txt with
a capture of the
gdb session showing it doing what it is supposed to do (on Linux only)
-----TEST2-----
The debugger choked on this next kind of "trickery" which can be found
on pg.847 of the Stroustrup book (Third Edition) with some modifications
to initial values for easy indentification in the debugger:
namespace X {
int i=10,j=10,k=10;
}
int k=0;
int main(void)
{
int i = 0;
using namespace X;
i++; // compiler uses local, so does debugger
// the compiler uses X::j here however the debugger has
// no concept of either X::j or ::j and claims that j is an undefined
symbol.
j++;
// the compiler uses the global k
// the debugger will properly display the global k, however I think
that this
// was not deliberate behavior... see next comment
::k++;
// the compiler uses X::k
// the debugger has no concept of X::k and chooses to display the
// global k.
X::k++;
}
The debugger could not handle X::j and would complain that it could not
resolve X. It would always display the global (if it could find one)
and never
find the X:: namescoped variable when it should have.
Doing the tab-symbol complete would show X::j but still complain about
the
undefined symbol X.
The compiler behaved as it should in all cases (I did added some
printf's and
whatnot). A file has been attached to this email titled
test2.script.txt which
shows the debug session with gdb (on linux only).
I tried a few tricks like compiling with -gstabs or -gstabs+ to get
*extra* debug symbol information in the target with no improvement.
If it is true that gdb cannot currently handle this, is it going to in
the future? It is
conceivable that many large projects/applications would use namespace's
to better
organize code and would also require this support when attempting to
debug them.
One such project is the one I am involved in at work!!!
Thanks in advance for any insight/advice or hints regarding this issue.
Tim
[twhite@cr486275-a namespace_test]$ gdb test1
GNU gdb 19991116
Copyright 1998 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-mandrake-linux"...
(gdb) show demangle-style
The current C++ demangling style is "auto".
(gdb) show language
The current source language is "auto; currently c++".
(gdb) show overload-resolution
Overload resolution in evaluating C++ functions is on.
(gdb) b main
Breakpoint 1 at 0x8048656: file test1.cc, line 20.
(gdb) l
11 namespace B {
12 class Object {
13 public:
14 int i;
15 Object() { i=20; };
16 };
17 }
18
19 int main(void) {
20 A::Object a;
(gdb) l
21 B::Object b;
22
23 cout << "hi" << endl;
24 }
(gdb) r
Starting program: /home/twhite/src/namespace_test/test1
Breakpoint 1, main () at test1.cc:20
20 A::Object a;
(gdb) n
21 B::Object b;
(gdb) n
23 cout << "hi" << endl;
(gdb) print a
$1 = {i = 10}
(gdb) print b
$2 = {i = 20}
(gdb) c
Continuing.
hi
Program exited normally.
(gdb) quit
[twhite@cr486275-a namespace_test]$
[
[twhite@cr486275-a namespace_test]$ gdb test2
GNU gdb 19991116
Copyright 1998 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-mandrake-linux"...
(gdb)
(gdb) show demangle-style
The current C++ demangling style is "auto".
(gdb) show language
The current source language is "auto; currently c++".
(gdb) show overload-resolution
Overload resolution in evaluating C++ functions is on.
(gdb) l
3 namespace X {
4 int i=10,j=10,k=10;
5 }
6
7 int k=0;
8
9 int main(void)
10 {
11
12 int i = 0;
(gdb) l
13
14 using namespace X;
15 i++; // compiler uses local, so does debugger
16
17 // the compiler uses X::j here however the debugger has
18 // no concept of either X::j or ::j and claims that j is an undefined
symbol.
19 j++;
20
21 // the compiler uses the global k
22 // the debugger will properly display the global k, however I think
that this
(gdb) l
23 // was not deliberate behavior... see next comment
24 ::k++;
25
26 // the compiler uses X::k
27 // the debugger has no concept of X::k and chooses to display the
global k.
28 X::k++;
29 }
(gdb) b main
Breakpoint 1 at 0x8048536: file test2.cc, line 12.
(gdb) r
Starting program: /home/twhite/src/namespace_test/test2
Breakpoint 1, main () at test2.cc:12
12 int i = 0;
(gdb) n
15 i++; // compiler uses local, so does debugger
(gdb) print i
$1 = 0
(gdb) print X::i
No symbol "X" in current context.
(gdb) n
19 j++;
(gdb) n
24 ::k++;
(gdb) print j
No symbol "j" in current context.
(gdb) print k
$2 = 0
(gdb) print ::k
$3 = 0
(gdb) print X::k
No symbol "X" in current context.
(gdb) n
28 X::k++;
(gdb) n
29 }
(gdb) c
Continuing.
Program exited normally.
(gdb) quit
[twhite@cr486275-a namespace_test]$
