vaughan@puma.cad.mcc.com (Paul Vaughan) (02/02/90)
We have been experiencing difficulty using gdb with large g++ programs. I'm hoping that some of you can share some insight into the operation and usage of gdb so that we can make better use of it. The biggest problem we're having now is extremely slow file loading when starting up and when setting breakpoints. When initiating gdb we wait about a minute under the message: Reading symbol data from /net/redcloud/d0/rpj/igmod36/SUN3/prism...done. Since our executable (produced with -g and unstripped) is over 12M, this doesn't seem too unreasonable, but what exactly is being done here, and what might make it go faster? (Other than a SparcStation!--we're stuck on Sun 3/60's.) If we try to set a break point, we inevitably get one or more messages like the following: Reading in symbols for Foo.cc...done. Reading in symbols for bar.cc...done. These can take minutes, apiece. It frequently mentions files that have very little to do with the location of the breakpoints. When we step, it also usually has to read in files, and again, it frequently reads in an unrelated file. What exactly is going on here? I don't understand why it has to read in symbols for individual source files, after it has already spent a minute reading in the symbols for the overall executable. Is it reading the .o files, the .cc files, or just more out of the executable file? I'm thinking about getting more memory, in the hopes that the root of our trouble is disk thrashing. Can anyone corroborate that theory? Now for some smaller problems, that we have learned to live with. I realize that some of these things are too much to expect of gdb--I'm just hoping someone can offer advice or new methodologies for using it. gdb does not properly display objects derived using multiple inheritance, or single inheritance and virtual base classes. We've learned to ignore all information printed about virtual base class slots, and also any information on any but the first branch in a multiply inherited object. When we want to see the slots in the virtual base class, we usually do a p *_vb$foo, where _vb$foo is the name of the (implicit) slot that points to the virtual base class object. Looking at the other sides of an object (the slots inherited from any but the first base class when using MI) is somewhat more difficult. gdb doesn't seem to call virtual functions correctly. About the only way I can be sure what function gets called when interactively calling functions is to determine the munged function name and to use that. This is somewhat difficult since the symbol name munging mechanism has changed--I can't just guess anymore. gdb does not perform the same translations when applying casts to pointers that the compiler would. That is, if you've got a Foo* and you cast it to be a Bar* in gdb, it uses the same pointer value regardless of the relationship between the classes Foo and Bar. Although gdb 1.34 does accept function names using c++ syntax (eg. Buffer::Init) for setting breakpoints and such, it won't print them out that way. I remember some discussion of hooking the name munger up to gdb. Does anyone have this sort of extension? I haven't even tried to specify an overloaded function to gdb, does anyone know if and how that works. Finally, does anyone have more success with some other debugger? gdb compatibility with g++ seems to be a fairly low priority item for those who maintain it. I know g++ itself has been keeping Tiemann busy for some time. Paul Vaughan, MCC CAD Program | ARPA: vaughan@mcc.com | Phone: [512] 338-3639 Box 200195, Austin, TX 78720 | UUCP: ...!cs.utexas.edu!milano!cadillac!vaughan