Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!seismo!mcnc!rti-sel!dg_rtp!meissner
From: meissner@dg_rtp.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Does the dbx debugger work?
Message-ID: <1206@dg_rtp.UUCP>
Date: Wed, 25-Feb-87 16:51:35 EST
Article-I.D.: dg_rtp.1206
Posted: Wed Feb 25 16:51:35 1987
Date-Received: Sat, 28-Feb-87 00:25:19 EST
References: <3647@brl-adm.ARPA> <270@sdics.ucsd.EDU>
Reply-To: meissner@dg_rtp.UUCP (Michael Meissner)
Organization: Data General (Languages @ Research Triangle Park, NC.)
Lines: 26

In article <270@sdics.ucsd.EDU> wallen@sdics.ucsd.EDU (Mark Wallen) writes:
> 
> 
> Couldn't one assist dbx with some ioctl()s to turn of write access
> (or read access) to certain pages that contained the variables you
> wanted to trace?  When the program tried to access that page, it
> would stop with a fault.  Then dbx would decide if the faulting address
> was one of interest or not.  If so, halt and interact with the
> user, otherwise (or after a continue) turn write (or read) access
> for the page back on, single step the faulting instruction,
> turn the access back off and then run.  Then the program should
> run at full steam except where it pinged on pages with traced
> variables.

Nice idea, but the problem with this is that various machines will not
give you enough state to identify the faulting instruction.  Some will
just give you a microcode context block and the page that needs to be
faulted in.  Variables also tend to come in clumps (like all auto's in a
stack frame, and tracing one forces access to any of them to slow down). 
Also to be really useful, you ideally would want to turn off access to
individual bits. 

-- 
	Michael Meissner, Data General	Uucp: ...mcnc!rti-sel!dg_rtp!meissner

It is 11pm, do you know what your sendmail and uucico are doing?