A few things we've been up to at Apple lately

[Jason Molenda <jason-swarelist at molenda dot com>]

Hey all, I figured I'd send a note to say what's up as long as I'm
sending in a patch.

Klee and I have been going over the testsuite on our platform for
the past couple months.  Over time, our gdb had diverged from the
FSF gdb to the point where we had ~800 failures and a couple hundred
unresolved test cases -- the testsuite was useless for us.  We've
been fixing testcases to match our output where we've purposely
diverged from the FSF style; fixing our code to behave correctly;
and filing Apple internal bug reports for all the known failures.
We're down to 15-20 unfiled fails now, and many of those are known
failures in the generic code.

My time allocated for fixing test cases has expired, but as my last
little bit of work I created a testsuite/gdb.apple directory and
put in some really horribly written test cases :-) for several of
our platform-specific features or general features that haven't
been pushed back to the FSF.   (the latest version of all of this
is not yet on the mainline - the supercow-branch is where all the
action is at the moment)


Not to steal his thunder, but Jim Ingham has recently been adding
dynamic type information to varobj's for our long-suffering C++
users' benefit.  When a varobj represents a pointer to an object,
and the inferior changes the pointer to a different class (in the
same inheritance tree, I gather), var-update will record that
difference and know that any children of that varobj are now dead.
He does all of this with the rtti_type information.  I'm pretty
C++-stupid; Jim could explain why this is such a spiffy good thing
better than me.


Although not strictly new, Rab Hagy recently added a clever feature
to the Project Builder debugger UI for some common ObjectiveC
objects, e.g. NSString (akin to C++'s String).  When PB is displaying
an NSString object (or an object that inherits from NSString) in
its Locals window, it makes an inferior function call to render it
to a C string, which it displays.  People who program in language
like ObjC use the native String classes to store these sorts of
things, and a GUI that only displays a pointer to the object in its
Locals window is remarkably frustrating.  The cost of making these
inferior function calls is hard to swallow, but we've found it
makes the tool vastly more usable for end users.

Klee's recent changes have been almost entirely concerned with
boring old MacOS X shared library/executable file handling :-)
to get some naghty little edge cases tweaked up.  He's also been
merging over from the FSF quite frequently and trying to spank
out unnecessary divergence between the Apple and FSF gdb sources.

Well anyway, I happened have this all on the tip of my tongue so
I thought I'd dash off a note.  Having just cleaned up all the
gdb.mi test cases, I'm also happy to talk about all the things
we've changed in MI while making it work for Project Builder over
the past few years.  

Wait, here's one good one - would you believe our varobj's can
track when they've gone out of scope?  Man it's cool!  If you're
at a function like this:

void foo (void) {
  int a;
  char b;
  {
     int d;
     float f;
  }
}

When you stop at the top of foo and create objects for all the
locals, gdb will return 4 varobj's, with the last two ("d" and "f")
marked as in_scope="false".  The UI can then display all the
variables for the function and mark those not yet visible as "out
of scope" or greyed out.  When you step into the inner block, those
variables are updated to in_scope="true" and we can display their
values.


You can see all this and more -- much more! -- via our public anoncvs
server:
	http://developer.apple.com/darwin/tools/cvs/
(free reg required, blah blah, yes we know, Apple is evil, etc etc)

J