Does the dbx debugger work?

[meissner at dg_rtp.UUCP]

In article <270 at sdics.ucsd.EDU> wallen at 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?