From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20768 invoked by alias); 9 Nov 2002 09:49:32 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 20751 invoked from network); 9 Nov 2002 09:49:27 -0000 Received: from unknown (HELO molenda.com) (192.220.74.81) by sources.redhat.com with SMTP; 9 Nov 2002 09:49:27 -0000 Received: (qmail 28014 invoked by uid 19025); 9 Nov 2002 09:49:27 -0000 Date: Sat, 09 Nov 2002 01:49:00 -0000 From: Jason Molenda To: gdb@sources.redhat.com Subject: A few things we've been up to at Apple lately Message-ID: <20021109014927.A23527@molenda.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-SW-Source: 2002-11/txt/msg00094.txt.bz2 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