From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Molenda To: gdb@sources.redhat.com Subject: Huge Apple gdb code dropping^H^H^H^H Date: Thu, 29 Nov 2001 00:59:00 -0000 Message-id: <20011129005901.A60085@molenda.com> X-SW-Source: 2001-11/msg00334.html 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 doing in file .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! From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7940 invoked by alias); 29 Nov 2001 08:59:07 -0000 Mailing-List: contact gdb-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 7846 invoked from network); 29 Nov 2001 08:59:02 -0000 Received: from unknown (HELO sj1-3-4-16.iserver.com) (192.220.127.209) by hostedprojects.ges.redhat.com with SMTP; 29 Nov 2001 08:59:02 -0000 Received: (qmail 63922 invoked by uid 19025); 29 Nov 2001 08:59:01 -0000 Date: Sat, 24 Nov 2001 06:24:00 -0000 From: Jason Molenda To: gdb@sources.redhat.com Subject: Huge Apple gdb code dropping^H^H^H^H Message-ID: <20011129005901.A60085@molenda.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i X-SW-Source: 2001-11/txt/msg00227.txt.bz2 Message-ID: <20011124062400.fpOfwKMd2lqBT8HhjRiV9UGMMQlVzcxNMAw7uyskWck@z> 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 doing in file .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!