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]

Huge Apple gdb code dropping^H^H^H^H


Hi gdb'ers,

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
for submission.

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
that.

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:

ftp://sources.redhat.com/pub/gdb/contrib/apple-puma-branch-vs-fsf-2000-11-13.diffs.bz2

And here is the tarball:

ftp://sources.redhat.com/pub/gdb/contrib/apple-puma-branch.tar.bz2


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.

Jason
Free the Software!


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