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