ftp.nice.ch/pub/next/developer/objc/mach/dis.README

This is the README for dis.N.bs.tar.gz [Download] [Browse] [Up]

This is a version of Bill Spitzak's Mach-O object file format
680x0 disassembler.  It was originally distributed along with
"Hack Kit 2" just as NeXTStep 2.0 was released.

I needed a disassembler and I found the source code this is based
on.  It didn't compile at all under NeXTstep 3.0.  So, I hacked on
it a little bit.  Now it compiles fairly cleanly under NeXTStep 3.2,
and it still does the same disassembly as it used to.

Bruce Ediger
bediger@teal.csn.org
ediger@metamatic.denver.co.us


Main changes:

1. Total reformatting of source code.  The original style was a little
   eccentric, seemingly chosen to minimize source code line count at
   the expense of clarity.

2. Removed most of the Magic Numbers used in the code, replaced them
   with symbolic constants from system .h files.  There's still a
   few Magic Number Constants in the actual disassembly, but they
   don't have a header file replacement.  The original code seemed
   to have an allergy to symbolic constants.

3. Made the Mach-O file support work with the official system header
   files.  Spitzak had concocted some custom thing that subsumed most
   of mach-o/loader.h, mach-o/nlist.h, mach-o/ldsyms.h and a few others.
   Needless to say, this concoction didn't track official NeXT include
   file updates.  This change necessitated changing arguments to a lot
   of the functions that dealt with Mach-O files, or the original author's
   conception of them.

4. Removed a few inexplicable things like using lseek() to find a file's
   size.

5. Used a simple memory-mapped file object to replace the scattered
   uses of map_fd().  This neccessitated making the main() routine be
   Objective-C source.



What I couldn't do, but wanted to do:

1. Make the symbol table use comprehensible.  I still don't really
   understand what's going on.  It seems to me that the
   code does things the hard way.  A hashtable or something might
   be faster and more understandable, but I was afraid to replace
   the code already existant because it seems to work.

2. Make it use the symbol table and/or LINKEDIT info from shared
   libraries to identify calls into the shared libraries.  This
   stems from the odd symbol table stuff.  Unfortunately, a dissassembly
   of a stripped object file won't be as informative as it could.

3. Make it completely ANSI C.  There appears to be some hoseup in
   sys/types.h vs bsd/libc.h in the NeXTStep 3.2 include files.
   Or kill me.

These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.