From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17887 invoked by alias); 27 Jun 2003 07:40:05 -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 17880 invoked from network); 27 Jun 2003 07:40:04 -0000 Received: from unknown (HELO molenda.com) (192.220.74.81) by sources.redhat.com with SMTP; 27 Jun 2003 07:40:04 -0000 Received: (qmail 12306 invoked by uid 19025); 27 Jun 2003 07:40:04 -0000 Date: Fri, 27 Jun 2003 08:13:00 -0000 From: Jason Molenda To: gdb@sources.redhat.com Cc: klee@apple.com Subject: Howdy from Apple; Fix and Continue implemented Yet Again Message-ID: <20030627004003.A6119@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: 2003-06/txt/msg00501.txt.bz2 Hi all, Sorry for the total lack of communication from the Apple gdb group these past couple months. We were working at a full-on pace for the Apple World Wide Developer's Conference preview release and became even more lax in our net.community.communications than normal. The two biggest features we've added to gdb for this WWDC release are cached symfiles and fix and continue. Klee has been working on cached symfiles on-and-off for the last year (as those looking at our sources already know), and this is the release where we've enabled it by default for our users. Klee can speak far more intelligently on the topic than me, but briefly this is akin to a precompiled header file in gcc; gdb builds up an objfile structure for a shared library and then dumps that objfile structure to disk. When that shared library is loaded by an inferior process, gdb can map in the frozen objfile structure from disk instead of re-parsing/allocating all of the debug info from the shared library. Cached symfiles shows its greatest benefits when you've got a lot of shared libraries that don't change often. We are shipping the feature with a script that builds cached symfiles for all of the system shared libraries; it would be entirely possible to do the same for a user's project if the user had several shared libraries as a part of his project and they were most often unchanged. Fix and continue is a feature implemented by many other debuggers, which we added to our gdb for this release. Sun Workshop, SGI ProDev WorkShop, Microsoft's Visual Studio, HP's wdb, and Sun's Hotspot Java VM all provide this feature in one way or another. I based our implementation on the HP wdb Fix and Continue feature, which they added a few years back. Although my final implementation follows the general outlines of the approach they took, there is almost no shared code between them. Some of this is because of the architectual differences (both the processor and the ABI), but even more of it is due to implementation design differences. The wdb approach is to have the debugger as the center of the world; you edit your file from within wdb, wdb recompiles your files, and wdb applies the fix; when debugging ends, wdb removes your executable. Instead, I moved much of this up to our IDE, Xcode, and left gdb with the back-end work, with a single "fix in this file" command. Our IDE has a perfectly good editor and build system -- no reason to duplicate that in gdb. It was a good approach for us, but it's hard to say which is better if we were talking about a FSF sources implementation of the same. I'm happy to outline everything involved in implementing F&C in gdb if people are curious, but I don't expect the code to be especially contributable -- even if I moved all of the processor/ABI details into their appropriate arch/target vectors, there would still remain the fact that the separation of work I chose makes no sense without an IDE on top of gdb. (and IMHO the approach that HP chose doesn't fit well with the common behavior of gdb.) We've still got a lot of work to do for our next OS release, but I think we'll all be aspiring to be more involved with the net lists. (well, we'll all fall asleep for a week or so after WWDC finishes on Friday, but after THAT :-) Jason PS- Another interesting new feature added by the devtools group at Apple was "Zero Link", where the link phase of compilation is elided. Instead the app turns into dozens -- hundreds -- of little shared libraries that are pulled in as they're referenced by a stub program. Pretty cool stuff, but it's relevant to gdb because we've found gdb gets pretty pokey when a program consists of hundreds of shared libraries. I don't know when our focus will turn this way exactly, but I expect we're going to be turning our attention to optimizing symbol lookups in gdb. I know lots of other folks are working in this code, so we'll be extra mindful about talking about these things with the community. (I shouldn't speak for others -- *I'll* be extra mindful, and I'll encourage my cohorts to do the same :)