home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / dos / extra / docs / maillist / text / archive.95 / text7457.txt < prev    next >
Encoding:
Internet Message Format  |  1996-03-31  |  4.2 KB
  1. Received: from ftp.ardi.com (ftp.ardi.com [204.134.8.1]) by nacm.com (8.6.10/8.6.9) with SMTP id MAA25156 for <executor@nacm.com>; Sun, 3 Dec 1995 12:40:59 -0800
  2. Received: from ardi.com by ftp.ardi.com
  3.     (Smail3.1.29.1 #3) id m0tMLDQ-0007q6n; Sun, 3 Dec 95 13:40 MST
  4. Path: sloth.swcp.com!usenet
  5. From: "Clifford T. Matthews" <ctm@ardi.com>
  6. Newsgroups: comp.os.ms-windows.advocacy,comp.sys.mac.advocacy,comp.emulators.mac.executor
  7. Subject: debugging Mac programs (was Re: The Macintosh: A Toy?)
  8. Date: 28 Nov 1995 07:56:09 -0700
  9. Organization: ARDI
  10. Lines: 61
  11. Message-ID: <ufn39geqk7.fsf@ftp.ardi.com>
  12. References: <42kp5u$ep9@steel.interlog.com> <46uhre$nco@shellx.best.com>
  13.     <47ja1v$k3@crash.microserve.net> <489o5k$s40@news.aros.net>
  14.     <petrichDI2zLC.CtK@netcom.com> <48rl6o$bcb@news.aros.net>
  15.     <jragosta-2111951650550001@ppp-1002.dca.net>
  16.     <bootstrp-2611951124090001@bootstrap.vnet.net>
  17.     <steffenDIp4DF.Lzu@netcom.com>
  18. NNTP-Posting-Host: ftp.ardi.com
  19. In-reply-to: steffen@netcom.com's message of Mon, 27 Nov 1995 09:41:54 GMT
  20. X-Newsreader: Gnus v5.0
  21. Xref: sloth.swcp.com comp.os.ms-windows.advocacy:93003 comp.sys.mac.advocacy:74802 comp.emulators.mac.executor:1
  22. To: executor@nacm.com
  23. X-MailNews-Gateway: From newsgroup comp.emulators.mac.executor
  24. Sender: owner-paper@nacm.com
  25. Precedence: bulk
  26.  
  27.  
  28. I changed the subject, dropped a few newgroups and added c.e.m.e., and
  29. because the gateway between the Executor mailing list and
  30. c.e.m.e. isn't up yet, I'm manually cc'ing this to the Executor
  31. mailing list.
  32.  
  33. >>>>> "David" == David Steffen <steffen@netcom.com> writes:
  34.  
  35.     David> bootstrp@vnet.net (Nathan Tennies) wrote: *snip*
  36.  
  37.     >> Yeah, Joe, I asked this goof the same question about a week
  38.     >> ago.  No response.  Not only have these guys apparently not
  39.     >> heard of ResEdit, they certainly haven't heard of MacsBug.
  40.     >> Every Mac in the world has the hardware support to break into
  41.     >> the middle of any running task, look at the code it is running,
  42.     >> check the state of its heap, and even watch which calls it is
  43.     >> making to the MacOS.  It's a hacker's dream tool, and I'd love
  44.     >> to have this capability on my Windows computer.  No luck.
  45.  
  46.     David> Maybe you will have better luck with SoftIce.  Try checking
  47.     David> out http://www.numega.com
  48.  
  49.     David> In short, real hardware breakpoints like an ICE unit
  50.     David> because it uses hardware breakpoint registers to do its
  51.     David> job.
  52.  
  53.     [snip]
  54.  
  55. I like Macs and I'm not a big fan of the x86 architecture in general,
  56. but David is right -- the x86 has the ability to set *hardware*
  57. breakpoints that tell you when a memory location has changed value.
  58. This feature can be used from gdb under Linux on a PC which, added to
  59. real per-process memory protection, makes for a pretty nice debugging
  60. environment.
  61.  
  62. At ARDI we've written a Macintosh emulator (http://www.ardi.com/ or
  63. comp.emulators.mac.executor for more information) and have it running
  64. on both 68040 based NeXTs and PCs running DOS, Linux, Windows,
  65. NEXTSTEP, and OS/2 and, in general, we do our debugging on a PC
  66. running Linux because of the hardware breakpoint issue and the fact
  67. that we've tricked out gdb so that we can switch back and forth
  68. between disassembly in 68k mode and x86 mode.
  69.  
  70. So in addition to the tools that normal users of UNIX (and Linux) have
  71. on PCs, we also have special purpose tools for debugging Mac programs
  72. that let us see all the calls the Mac program is making, dump all the
  73. calls a program has made and do all sorts of low-level integrity
  74. checks on system data structures.  We can even compile our emulator
  75. with a special tool that wraps *every* memory reference instruction
  76. and then lets us know if any uninitialized memory is ever read.
  77.  
  78. Granted, most of our special purpose tools could be used on non-x86
  79. architectures, but I greatly value memory protection and the hardware
  80. watchpoints that we get when we use gdb on an x86.  In addition, since
  81. we have the source to gdb, we were able to add a very important
  82. feature (the ability to disassemble 68k code on an x86) trivially.  As
  83. a hacker, *my* dream tool would not lack memory protection, hardware
  84. watchpoints and complete source.
  85.  
  86. --Cliff
  87. ctm@ardi.com
  88.  
  89.