Re: Template Problems
Re: Template Problems
- Subject: Re: Template Problems
- From: Andreas Grosam <email@hidden>
- Date: Fri, 12 Aug 2005 16:04:14 +0200
On 11.08.2005, at 20:29, Jim Ingham wrote:
On Aug 11, 2005, at 10:43 AM, Mike Jackson wrote:
So when will we actually get a version of GDB from _this_ year?
Running gdb -version yields the following:
GNU gdb 6.1-20040303 (Apple version gdb-413) (Wed May 18 10:17:02 GMT
2005)
Copyright 2004 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 "powerpc-apple-darwin".
GDB 6.3 was released earlier this year, is there any idea when we can
expect this to be incorporated into Xcode? Can I safely compile GDB
on OS X and use this newer compiled version? What would the pitfalls
of this approach be?
Note that just because the last merge date is last year doesn't mean
we haven't been working on gdb in the meantime. Are there any crucial
bug fixes in the FSF gdb between 6.1 and 6.3 that you need? Note
template handling is not one of these, that works the same in the FSF
gdb 6.3 and our gdb.
The FSF gdb doesn't have the support for Mac OS X. So the pitfall of
that approach would be it wouldn't work at all :-(
I had reasonable impressed my VC++ using coworkers with Shark and
OpenGL Profiler. Both were instrumental in profiling our cross
platform C++ code. Almost had them talked into purchasing a few
powerbooks. BUT then I tried to debug some C++ template code and
Xcode fell flat on its face. We ended up doing what the others below
did, we move back over to the PC and VC++. Now they are asking _me_
if _I_ want a PC with VC++? !@#$*(#?@#(#@&!??!@!
Yes, this is a big problem with gdb for our C++ users. Unfortunately
it is harder to fix than it should be because the "one breakpoint to
one address" assumption is larded all over in gdb...
So, where is the problem?
Does apple-gcc not emitting the correct debugging symbols?
Is gdb not capable to handle the debugging symbols?
Is the debugging format STABS insufficient to be precise?
Or even more worse, is STABS not capable to handle this?
Or is just XCode not able to determine several code adresses for the
same source line, when setting a break point. (not a question, we know
XCode can't do this, yet).
IMHO, this lack of feature can be solved.
You can work around it by breaking on template functions by name or by
using the "rbreak" command in the console.
Yes and No.
Yes, because you probably break at the correct code line, but NO
because XCode is not always capable to sync with the source. Means, gdb
does not always determine the correct soure line for a certain address.
So, you often just get random source lines when you break or step thru
(for instance, in comments).
Andreas
Jim
Mike Jackson
On Aug 5, 2005, at 11:53 AM, Andreas Grosam wrote:
On 05.08.2005, at 14:55, Steve Baxter wrote:
Personally I've almost given up using debuggers on the Mac:
I have to second this.
I use Unit tests to ensure code is correct - on a more low level.
Unit testing is really great - once you got familiar with it.
For more complex problems, though - you need a debugger. So, i can't
omit it - but the current version is also that buggy, that is is
almost unusable.
Dear Apple engineers, you don't need a bug report, just click 5
times. For instance, the debugger is almost always unable to return
from a function and get back to the caller.
Andreas
- Applications take too long to start. Our apps can take 1 minute+
to start under CW or XCode. The app takes about 10 seconds to
start from the Finder. It takes about 10 seconds to start under
the debugger on the PC. Slow starting murders your productivity as
a developer.
- Breakpoints so often just do not work, particularly in
applications with multiple plugins. I don't trust the debugger -
did my code not get called for some reason or did it just not stop?
I can never be sure. We use templates *heavily* (they are great
for image processing applications).
- The debugger is mind-numbingly slow when stepping through code.
- Under CW the debugger would frequently hang when trying to step
across a framework boundary
When I want to debug a cross-platform class I now end up using my
PC, much as I hate the UI of VC++. When I have to debug on the Mac
I mostly use trace() statements to log to the console.
To make the Mac a viable development platform, Apple really have to
get to grips with the speed and reliability of GCC, GDB and XCode
editing. Debugging was actually much better with CFM apps on Mac
OS 9. Mach-O and GDB on X seem to be a bit of a step backwards!
Cheers,
Steve.
On 5 Aug 2005, at 02:55, Mike Jackson wrote:
So if GDB is so messed up with Templates, how does anyone actually
debug a template class? Sorry for the naive question, but I am new
to this whole mess.
Mike
On Aug 4, 2005, at 7:57 PM, Andreas Grosam wrote:
On 04.08.2005, at 23:12, Jim Ingham wrote:
The problem here is that the gdb's "break" command assumes that
there is a 1-1 correspondence between the break expression and
the code address implementing it. This is obviously not true
for templates. It's on our list of things to fix, but we
haven't fixed it yet.
This not only seems the only problem.
For instance, if you have a class template and a certain
instantiation of a member function, say
int Foo<int>::foo()
then, in gdb the command
(gdb) list Foo<int>::foo()
might return a total wrong location in the source files where the
function should start ( begin of function body).
where determining the address of the member function via
(gdb) info line Foo<int>::foo()
returns:
Line xxx of "path/to/source/where/it/has/been/instantiated.cp/"
starts at address 0x1234 and ends at 0x2345
Firstly, "Line xxx" points apparently to the correct line number
in the source file where the function is defined as a template,
and more precisely, at the line for the first statement - which
is the initialization of the first argument with default values
- as opposed to the begin of the function body.
The path, on the other hand, seams to be the source file where
the template has been instantiated. That is, line number and path
are pretty unrelated!!
Secondly, the addresses seem to be correct.
When searching the source lines for a specific address:
(gdb) list *0x1234
it returns
0x1234 is in Foo<int>::foo()
(path/to/source/where/it/has/been/instantiated.cp: xxx)
which is equally wrong - the line number and the file does not
match.
Only if we have "luck", the compiler correctly matches the line
of the defintion of the template and the path to the file where
the template is defined. Only then, gdb is also able to print
correctly the source when using command:
(gdb) list Foo<int>::foo()
or
(gdb) list *0x1234
Well, the problem is, there is a bug elsewhere when the compiler
generates debug infos for templates.
Not surprisingly, that XCode hardly can manage such corrupt debug
informations.
Andreas
You can work around it for breaking on functions in the gdb
command-line by using the "rbreak" command:
(gdb) rbreak Printer.*print
That will break on all the versions of the print method of the
Printer template class.
You can also do set breakpoints on the individual
instantiations, for instance:
(gdb) break Printer<int>::print
will only break on the int version... You can do this second
bit by adding "Symbolic Breakpoints" in the Xcode Breakpoint
window. The one trick I noticed is that if you use ZeroLink, we
bail out too early and don't set the breakpoint... So you need
to turn off ZeroLink to get this to work.
Jim
On Aug 4, 2005, at 12:20 PM, Mike Jackson wrote:
OK,
I can reproduce the problem very simply. Create a new C++
Tool project. Add a new file called FindLoops.h
Put the following in the file.
#include <iostream>
template <class T> class Printer {
public:
static void print(const T&t) {
std::cout << t << std::endl;
}
};
In main.cpp put the following:
#include <iostream>
#include "FindLoops.h"
int main (int argc, char * const argv[]) {
std::cout << "Hello, World!\n";
Printer<int>::print(10);
Printer<double>::print(10.5);
std::cout << "DONE" << std::endl;
return 0;
}
Check the compile settings to have FULL debug symbols. Set a
breakpoint in the "FindLoops.h" file at the line that does the
cout. Run the debugger. Xcode flys right past the break point.
Now, if I put the template in the main.cpp file, then the
debugger will hit the breakpoint.
I am new to C++ and all this, so can some one explain what
might be happening (**cough _apple_ cough **) ;-)
Mike Jackson
On Aug 4, 2005, at 2:25 PM, Mike Jackson wrote:
I went back through all my projects and set the debug symbols
to "ALL". Still no luck stopping at a breakpoint.
Mike
On Aug 4, 2005, at 1:54 PM, Mike Jackson wrote:
I tried the following in a "test" project: In main.cpp
#include <iostream>
template <class T> class Printer {
public:
static void print(const T&t) {
std::cout << t << std::endl;
}
};
int main (int argc, char * const argv[]) {
// insert code here...
std::cout << "Hello, World!\n";
Printer<int>::print(10);
Printer<double>::print(10.5);
return 0;
}
The debugger will stop in the template just fine. In my case,
the template code is in _another_ project that is referenced
by the current project, and the template code is in a .h
file. Don't know if this makes a difference or not. I am
still too new to C++/Xcode to know. I did double check that
Optimization is OFF in all the projects, although I will
double check that.
Mike Jackson
On Aug 4, 2005, at 10:28 AM, Andreas Grosam wrote:
On 04.08.2005, at 15:38, Wade Girard wrote:
First this to do is to verify that you are generating debug
symbols, the second is to verify that optimizing is OFF.
Note that setting it to none -o0 is not off.
according the doc, -O0 optimization is indeed off and is the
default. But -O isn't off, did you mean this?
My experience is, that there are (still) a lot of troubles
with the debugger especially with templates - not only
regarding synchronizing with the source.
What may confuse source synchronizing (even with -O0):
Long comments at arbitrary positions in the file
Macros, multi line
templates
static inline functions
breakpoints in member initializer lists
Although it is better than it was in XCode 1.5, this *may*
happen frquently - not always and it is not always
reproducible. I have no workaround for this problem.
If it happens, i try several other things to solve my
original problem - typically loosing a lot of time and
getting disappointed and annoyed.
When having templates, I also recommend to close the
assembly window, since there might occure more troubles: if
this happens, the debugger just refuses to work at all.
Furthermore, it is a bit faster, so one step only takes 2
seconds instead of 3.
Andreas
The only way that I know of to do this is to use a xcconfig
file and have/add the following two lines
GCC_DEBUGGING_SYMBOLS = full
GCC_OPTIMIZATION_LEVEL =
On Aug 4, 2005, at 7:47 AM, Mike Jackson wrote:
I'll try again.
The debugger is ignoring breakpoints set inside a
template
function. How do I get the debugger to actually stop at
those
breakpoints?
Stats: Xcode 2.1. OS X 10.4.2. PB 1.67/1.5GB RAM
Thanks for any Help
---
Mike Jackson
mike _at_ bluequartz dot net
This email sent to email@hidden
This email sent to email@hidden
---
Mike Jackson
mike _at_ bluequartz dot net
_______________________________________________
---
Mike Jackson
mike _at_ bluequartz dot net
---
Mike Jackson
mike _at_ bluequartz dot net
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
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:
email@hidden
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:
email@hidden
This email sent to email@hidden
---
Mike Jackson
mike _at_ bluequartz dot net
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
Stephen Baxter
Software Development Manager
Improvision
email@hidden
+44-2476-692229
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
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:
email@hidden
This email sent to email@hidden
---
Mike Jackson
mike _at_ bluequartz dot net
_______________________________________________
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:
email@hidden
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