bzs@BU-CS.BU.EDU (01/26/87)
>Basically, dbx needs better control over processes than is provided >by present kernels. >-- >In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Or hardware support. It might be useful for new hardware designers to glance at the IBM370's PER (Program Event Recording) facilities. It supports traps on events like stores, fetches (in address ranges), register changes and branches via loading of control registers. Such facilities should be more far-reaching than just dbx and kernel support should be fairly straightforward (control register state loaded from the proc struct at context switch time etc.) -Barry Shein, Boston University
wallen@sdics.UUCP (01/27/87)
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. Mark R Wallen Institute for Cognitive Science UC San Diego wallen@ucsd.edu
meissner@dg_rtp.UUCP (02/26/87)
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?