This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfc] xfailed tests in gdb.c++/classes.exp

I like to pull mail threads utterly off-topic whenever possible:

On Thursday, February 27, 2003, at 07:51 PM, Michael Elizabeth Chastain wrote:

If you look in gnats, you will see users complaining that they can't
print their string variables (because C++ strings are implemented with
layers of templates and derived classes).  They are complaining that
operator overloading doesn't work.  They are complaining that they have
a std::vector<Foo> and they can't even look inside the damn thing.

We have the same problem here at Apple, introspecting objects. As a convention, many of the standard Cocoa Objective C classes include a "NSPrintForDebugger" member function which can print the object in some way that is meaningful to the developer. We have a gdb command, "print-object" or "po" which does an inferior function call into this. In the GUI, we let users right-click on locals et al and do this command. It's not fancy/seamless/beautiful, but it is enough for users to do what they need. It does depend on support from the class libraries, obviously.

That's still not ideal - your Locals window still shows a bunch of variables with raw pointers instead of the strings they contain. Rab Hagy added a feature last summer to display these objects as strings when using the ProjectBuilder GUI. He added a solib that is loaded into the inferior to provide some object introspection functions in the inferior executable, and at a stop he determines if an object is an NSString class or inherited from that class, and then gets the formatted version of that text.

This approach is very expensive (making an inferior function call for each local object for each step) so we'll surely need to refine it in the future, but it's a step in the right direction.

Well, Rab could provide better details on what he did and where he sees this going (I was utterly uninvolved), but we're looking at these same problems here at Apple. We haven't cracked into the C++ library yet, but the problems are of a similar sort.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]