home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / linux / extra / docs / maillist / text / archive.95 / text2466.txt < prev    next >
Encoding:
Text File  |  1996-04-02  |  2.9 KB  |  66 lines
  1. The following message is a courtesy copy of an article
  2. that has been posted as well.
  3.  
  4.  
  5. I changed the subject, dropped a few newgroups and added c.e.m.e., and
  6. because the gateway between the Executor mailing list and
  7. c.e.m.e. isn't up yet, I'm manually cc'ing this to the Executor
  8. mailing list.
  9.  
  10. >>>>> "David" == David Steffen <steffen@netcom.com> writes:
  11.  
  12.     David> bootstrp@vnet.net (Nathan Tennies) wrote: *snip*
  13.  
  14.     >> Yeah, Joe, I asked this goof the same question about a week
  15.     >> ago.  No response.  Not only have these guys apparently not
  16.     >> heard of ResEdit, they certainly haven't heard of MacsBug.
  17.     >> Every Mac in the world has the hardware support to break into
  18.     >> the middle of any running task, look at the code it is running,
  19.     >> check the state of its heap, and even watch which calls it is
  20.     >> making to the MacOS.  It's a hacker's dream tool, and I'd love
  21.     >> to have this capability on my Windows computer.  No luck.
  22.  
  23.     David> Maybe you will have better luck with SoftIce.  Try checking
  24.     David> out http://www.numega.com
  25.  
  26.     David> In short, real hardware breakpoints like an ICE unit
  27.     David> because it uses hardware breakpoint registers to do its
  28.     David> job.
  29.  
  30.     [snip]
  31.  
  32. I like Macs and I'm not a big fan of the x86 architecture in general,
  33. but David is right -- the x86 has the ability to set *hardware*
  34. breakpoints that tell you when a memory location has changed value.
  35. This feature can be used from gdb under Linux on a PC which, added to
  36. real per-process memory protection, makes for a pretty nice debugging
  37. environment.
  38.  
  39. At ARDI we've written a Macintosh emulator (http://www.ardi.com/ or
  40. comp.emulators.mac.executor for more information) and have it running
  41. on both 68040 based NeXTs and PCs running DOS, Linux, Windows,
  42. NEXTSTEP, and OS/2 and, in general, we do our debugging on a PC
  43. running Linux because of the hardware breakpoint issue and the fact
  44. that we've tricked out gdb so that we can switch back and forth
  45. between disassembly in 68k mode and x86 mode.
  46.  
  47. So in addition to the tools that normal users of UNIX (and Linux) have
  48. on PCs, we also have special purpose tools for debugging Mac programs
  49. that let us see all the calls the Mac program is making, dump all the
  50. calls a program has made and do all sorts of low-level integrity
  51. checks on system data structures.  We can even compile our emulator
  52. with a special tool that wraps *every* memory reference instruction
  53. and then lets us know if any uninitialized memory is ever read.
  54.  
  55. Granted, most of our special purpose tools could be used on non-x86
  56. architectures, but I greatly value memory protection and the hardware
  57. watchpoints that we get when we use gdb on an x86.  In addition, since
  58. we have the source to gdb, we were able to add a very important
  59. feature (the ability to disassemble 68k code on an x86) trivially.  As
  60. a hacker, *my* dream tool would not lack memory protection, hardware
  61. watchpoints and complete source.
  62.  
  63. --Cliff
  64. ctm@ardi.com
  65.  
  66.