This is the mail archive of the
mailing list for the GDB project.
Huge Apple gdb code dropping^H^H^H^H
- From: Jason Molenda <jason-swarelist at molenda dot com>
- To: gdb at sources dot redhat dot com
- Date: Thu, 29 Nov 2001 00:59:01 -0800
- Subject: Huge Apple gdb code dropping^H^H^H^H
Apple maintains a modified version of gdb for their Mach/BSD based OS,
MacOS X. As I understand it, this gdb was inherited from a port done
and maintained at NeXT many moons ago (shout out to Michael), so it's
got a lot of history. We have an assignment to the FSF all signed these
days, but we haven't had time to get the patches into an appropriate form
Andrew wants to get these patches exposed to the light of day, and
even though we're plugging away at getting some clean submissions
put together, he wants the whole enchilada out there. I'm always
happy to oblige Andrew, so I've done this.
I want to note that I am creating this patch under duress. :-) I
think this patch is wholly useless and the only thing accomplished by
assembling it is to keep me from watching TV for an evening. A
useful result, I'll admit, but I think that's all we'll see. Here are
some of the reasons I believe this patch is useless:
The gdb sources have been in cvs for less than two years -
before that I've heard files were touched by hand. There is
a lot of cruft in here; there are pointless changes, changes
that are wrong, changes that seem to have been made by aliens
from another planet, changes that will serve as humor if you're
in the right mood. There are changes for things I've never
heard of - what's a Motorola 98k series processor, anyway? Why
in the world was bfd/cpu-i960.c changed in our sources? These
and many other mysteries await the adventurous diff reader.
The most recent FSF -> Apple merge that had taken place with
these sources was November 2000. We did our first import of
year 2001 just last month. Our trunk is not stable after this
mondo merge, so I wanted to send these patches which are to
the older, working version of gdb.
Applying this is not easy. The gdb repository on sourceware
was originally imports from the Cygnus repository, which Stan
and I would do periodically. For files that didn't have a real
checkin after these imports were ended, doing a "cvs co -D
2000-11-13" will give you the 1.1 version, not the correct
import version. When doing my initial sanity checks, I had to
run some scripts over my checkout of the FSF sources to get a
real vision of what the gdb sources looked like on 2000-11-13.
The testsuite has been utterly ignored. It's a mess, you'll
get 400-800 test failures if you can get it to work at all.
I gather tcl+expect+dejagnu could crash the early versions of
MacOS X, so not a lot of time has been spent on the testsuite
yet. (they no longer crash the OS, BTW)
Last I checked, our sources won't even build on non-MacOS X hosts.
You'll need to create a gdb-next and gdb-next/display-support
directories (gdb-next is a sibling of gdb/) before applying the
patch. This is where all the host support exists.
Very very very few ChangeLog entries, and the vast majority of
the cvs commit messages are empty as well.
This is almost certainly a one-time snapshot. If people really
want to see what's up with the Apple sources on a continuing
basis, the work is all happening on publically visible cvs
servers. We require developers to get a login through a
registration form, but that's a one-time annoyance which people
can suffer through.
I may put together a similar diff of our current trunk sources
(which are being regularly merged with current FSF sources) after
they've become a bit more stable.
To make everyone's lives easier, I'm also providing a copy of the
stable Apple gdb sources in a plain tar file. You may prefer the
diffs for browsing, but you'll prefer the plain tar file if you're
thinking of building this.
With all that said, why would you want this? Well, one thing is
that we're getting this all officially on the record as existing.
Apple has talked about submitting things for ages, and I think we
really are close to starting, but it doesn't hurt to throw this
out there. All of the Objective C gdb support should be in this
file, in one way or another, and I know folks are interested in
You should be able to build the tar file easily on a MacOS X 10.1
system. You'll need to configure with --enable-gdbmi, but that's
the only oddity that comes to mind right away (some UI_OUT code
isn't guarded with ifdefs).
For people not familiar, basic background: Mach is the kernel,
BSD sits on top of that, the two combined seem to be called "Darwin".
Our gdb has to handle both Mach signals and POSIX signals, and that
adds a lot of complication. Apple has an integrated development
environment with a GUI debugger interface, which talks to gdb via MI.
A fair amount of work has gone into tweaking MI, and none of it has
gone into matching changes to the testsuite - cf earlier statement
about 400-800 failures.
Darwin runs mostly on PPC and x86, although I gather it can be made
to work on other processors with enough patience. Most of our work
at Apple is on the PPC side of things.
Objective C is a version of C with classes from NeXT. It uses
brackets a lot, and its programmers think it's a great language. :-)
Most importantly to gdb, ObjC names have no mangled form and have
lots of spaces in them - you'll see symbol names like "-[NSExcpetion
raise]" and that's how it looks at all stages of compilation/reading.
The object file format is called MachO. I don't know much about it,
it appears pretty divergent from everything else I've seen. Apple has
its own linker and assembler (based on old circa 1.35 gas gld) with
little resemblance to their modern counterparts. There are some bfd
changes to handle MachO object file reading, and they work well enough
for gdb, but binutils itself is dodgy at best on Darwin.
Shared libraries are called "dylibs", and MacOS has some system of
libraries called "frameworks". I don't really understand what
Frameworks are all about - some kind of conglomeration of libraries
and includes for a particular facility. I think X windows would
be a Framework, for instance.
You'll notice that our gdb depends on electric-fence, a GPL memory
guard program included in the sources, but there's no real dependency;
no one has gotten around to taking out the dependency and removing
the directory from our gdb module.
Ah, as an aside, I created this patch with the "-w" flag to diff
to suppress whitespace diffs. You'd be surprised how many unnecessary
whitespace diffs were in the sources.
Here is the patch:
And here is the tarball:
Apple has an anoncvs server where you can get all of this for yourself,
look at http://www.opensource.apple.com/. You have to register to get
access to the anoncvs server (don't blame me, I agree that it's weak),
but I've heard it's a trivial little web form where you provide a name and
other information of optional veracity, and it gives you access to the
sources. BTW I've heard our cvs server is offline currently due to some
problems or something, so don't run right out and be surprised when there
is a problem. I'd assume it'll be back within the next week, but I know
nothing about what's up.
Feel free to ask questions, but questions that begin with "What the
hell is <crap crap crap> doing in file <shouldn't-be-touching-this>.c"
will not rate very high on my daily TODO list to reply to.
With luck, we'll have some real patch submissions in the near future
and this patch can fade into our distant memories.
Free the Software!