Re: How long does it take to build a compiler?

maniattb@cs.rpi.edu (Bill Maniatty)
Wed, 10 Nov 1993 14:29:56 GMT

          From comp.compilers

Related articles
[3 earlier articles]
Re: How long does it take to build a compiler? ywlee@sparc0a.cs.uiuc.edu (Youngwhan Lee) (1993-11-01)
Re: How long does it take to build a compiler? ryer@dsd.camb.inmet.com (1993-11-01)
Re: How long does it take to build a compiler? neitzel@ips.cs.tu-bs.de (1993-11-04)
Re: How long does it take to build a compiler? graham@pact.srf.ac.uk (1993-11-05)
Re: How long does it take to build a compiler? xjam@ginkgo.CS.Berkeley.EDU (1993-11-09)
Re: How long does it take to build a compiler? pardo@cs.washington.edu (1993-11-09)
Re: How long does it take to build a compiler? maniattb@cs.rpi.edu (1993-11-10)
Debuggers with data breakpoints (WAS: How long does it take ...) pardo@cs.washington.edu (1993-11-11)
Re: debuggers zstern@adobe.com (1993-11-11)
Re: debuggers shyamal@seas.smu.edu (1993-11-11)
Re: debuggers wjw@eb.ele.tue.nl (1993-11-11)
debuggers ssimmons@convex.com (1993-11-11)
| List of all articles for this month |

Newsgroups: comp.compilers
From: maniattb@cs.rpi.edu (Bill Maniatty)
Keywords: debug, comment
Organization: Rensselaer Polytechnic Institute, Troy NY, USA
References: 93-10-124 93-11-059
Date: Wed, 10 Nov 1993 14:29:56 GMT

xjam@ginkgo.CS.Berkeley.EDU (Crossjammer) writes:
>[I suspect debugging virtual machine code is easier than debugging
> generated assembly.]


pardo@cs.washington.edu (David Keppel) writes:
|> Rarely, however, are there symbolic debuggers for the machine code of the
|> virtual machine; that makes it harder to debug the VM code. Also, note
|> that one *could* write a VM for real hardware and use that to debug ...
|>
|> I suspect that in general it is *harder* to debug using a VM ...


One beef that I have with most debuggers I use (gdb, sdb, dbx, ...) is
that on most workstations under unix, the debuggers do NOT use hardware
defined break points, so that I cannot set watch on a data location. I'm
not sure whether this is for portability reasons (seems like a poor excuse
to not support such a useful feature), or other reasons. In that sense
debugging on a VM is potentially easier, since if you have the source, you
can set break points on read or write of data locations.


What was interesting, was that if memory serves me right (it has been
about 5 years now) the VAX/VMS operating system did support setting watch
on memory locations. That proved to be a very useful feature.


Of course you could use an ICE (In Circuit Emulator) which is a hardware
VM, or a Logic Analyzer, but these tools are probably best for timing
bugs, and should not be necessary for machines with hardware breakpoint
support.


The main thing to note about debuggers implemented in software, is that
they perturb your run time environment, and can change symptoms. VM's
have the potential disadvantage of changing timing so that timing,
synchronization, and mutual exclusion problems might be difficult (or
worse impossible) to reproduce without running on the native hardware.


Bill
--
| maniattb@cs.rpi.edu - in real life Bill Maniatty
[I modified gdb 3.x a few years ago to add watchpoints, implemented using
the 386's hardware watchpoints. It worked reasonably well, but the gdb
maintainers declined to take my code back because they wanted something that
would work everywhere. I believe that they think that with some cooperation
from the paging system they can provide useful watchpoints via page
faults. -John]
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.