This is the mail archive of the gdb@sources.redhat.com 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]

Howdy from Apple; Fix and Continue implemented Yet Again


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 :)


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