Re: How bad is GDB and C++? (was: GDB and c++ template class)
Re: How bad is GDB and C++? (was: GDB and c++ template class)
- Subject: Re: How bad is GDB and C++? (was: GDB and c++ template class)
- From: Jim Ingham <email@hidden>
- Date: Fri, 5 Nov 2004 11:36:58 -0800
There are a set of known limitations in gdb's C++ support that it will
help you to know about as you go along.
1) gdb has this old-fashioned notion that the mapping of source-line ->
code address is 1-1. We are slowly working to change this, but it is
pretty deeply ingrained. That means that source-line based breakpoints
in templates will set in the first instance of the template, and not in
the others. So you have to break on the template method name rather
than the file:line.
This can also cause problems with inline functions, though if you
compile at -O0, gcc generally doesn't actually inline anything, but
uses the out of line copy instead. We can break on that just fine.
I don't have any current bugs about stepping into templated functions,
or printing arguments, etc, in them. If anybody sees problems with
this, and can file a bug with a code example, that would really help.
2) gdb's breakpoint parser is pretty general, and sometimes C++ names
confuse it. The solution to this is to single quote the C++ name:
break 'Foo::bar (int, int, double)'
Also if you are working from the command line, using Tab completion can
help you get it right.
3) gdb tries to guess the dynamic type of objects (if you are working
on the commandline, you can do:
(gdb) set print object on
to get it to do this.) This is in fact very useful. But it doesn't
currently get this right if you have virtual inheritance. It will then
just print the static type of the object.
4) The debugging format that we are using doesn't support C++
namespaces. I was hoping that we would be able to move over to the
newer form (Dwarf) for the next release, but that's not going to make
it. We will get there soon, however.
That accounts for some of the difference between the C++ experience on
Mac OS X, and Linux - where Dwarf is already the default debugging
format. So you will have problems if you have lots of namespaces, and
I can't really solve these in gdb till I have some information about
them from the compiler...
5) There are some bugs with calling overloaded functions: we don't
always pick the correct function. You can work around this by using
the mangled name of the function. nm will tell you the mangled names,
you can look in there for the ones with the correct class & method
names, then in gdb, you can use:
(gdb) maint demangle <MANGLED NAME>
to figure out which one you want.
Lots of folks at Apple use gdb, and I can generally make it through the
lunch line without getting beaten up, so it must not be all bad :-) We
don't use alot of heavily templated C++ code at Apple, however, so it
is quite likely there are bugs out there that I don't know about.
gdb actually works great for C applications, which is what I use it on
most of the time (gdb being written in C...) There were a few C++
related crashing bugs in gdb's Xcode support in 1.0 & fewer but still
some in 1.2. I don't know of any more in 1.5.
Looking through my bug list, however, I don't see much in this area
beyond what I have already mentioned. If you come across anything,
please file it. Try as I might, I find it very hard to fix "blows
chunks"...
Jim
On Nov 4, 2004, at 9:09 PM, Andy Wiese wrote:
Thanks everyone for your feedback! I hope some of you have found it at
least cathartic.
So what I actually surmised from all this is that yes, GDB does in
fact debug c++, just not nearly as well as some highly integrated
proprietary development tools, especially on certain closed
proprietary architectures. I'll veer away from an epistle on why I
will walk an extra mile to use cross-platform open source tools
whenever possible. However, in this case, I said was setting the bar
pretty low, and it seemed like GDB is serving the role for many
people, so I took the time today to move over my unit testing
framework, my unicode console, and its accompanying custom ostream and
streambuf. All are heavily templatized c++. I am debugging it all just
fine, including inspecting structs and variables.
gcc's strict c++ is giving me fits, but I'm sure that's good medicine
in the long run.
Its just a tiny beginning and I'm sure I'll have my gripes to add in
due time. But it looks like I'm in the game. You poor suckers, that
surely means I'll be pestering the list with my stupid questions for a
while to come.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden