From: Bob Carragher (dancebob_at_mindspring.com)
Date: Fri Aug 31 2001 - 08:34:20 BST
Hi guys,
I know I recently threw out a problem, but this one is bugging
me about as much. It seems that if one defines a breakpoint in
a function that is overloaded, then quits ups (implicitly saving
that session's breakpoint), then that breakpoint may not appear
in the correct location (or at all) when the breakpoint is read
in on a subsequent ups invocation. I have not verified whether
this occurs simply with overloaded global functions. It does
occur with overloaded member functions of classes.
Say you have a class, fooClass, with two definitions of an
overloaded function, fooOverload. The class definition is in
foo.h, and its implementation is in foo.cpp. Say foo.cpp contains
void fooClass::fooOverload(const int intParam) const {
int x = intParam * 5;
cout << "Hello world " << x << endl;
return;
}
void fooClass::fooOverload(const double doubleParam) const {
double f = doubleParam * 5;
cout << "Hello world " << f << endl;
return;
}
If you set a breakpoint in the second fooOverload() member
function, then quit ups normally, then restart ups and try to
reload the (saved) breakpoints, ups will complain about "out
of range offset"s or "no executable code" at that point. Or,
perhaps, it will silently insert a breakpoint in the wrong
location in the FIRST fooOverload() member function (sometimes
AFTER the "return" statement)!
Looking at the ups state file, I can see that the breakpoint
location is given by 4 reference points: the function name,
the file name, the file line number (from the top of the file),
and the line offset from the beginning of the function. I
presume ups uses some algorithm to approximately locate the
breakpoint in the given file using the other 3 reference points.
But, since only the function's name was given, how can ups be
sure that a line number or line offset that seems not to make
sense to it isn't the result of the source file being modified?
It seems to me that if more information about the function were
saved, then this placement algorithm could be improved.
Would it be difficult to also save, in addition to the function
name, its return type and parameter list (or, at least enough
information to differentiate between overloaded functions)?
As a stopgap solution for users, you can just reorder the
function definitions in the source file so that the one you
want to break in appears first, although that doesn't quite
work out if you need to break in the second one as well ....
Thanks!
Bob Carragher
This archive was generated by hypermail 2.1.4 : Wed Feb 13 2002 - 21:51:34 GMT