  device driver system crashes? 
 The Question is:
 
I'm developing the driver.
When I compile the driver, should I use "/NOOPT" option not to optimize the
code?
 
I compiled the driver with DECC V5.7-006 on AlphaServer2100,copied the
driver
object file to the target system (Personal Workstation 433au),linked,and
installed.
When the driver start,I met the system crash for access violation at address
 
of PC (Program Counter). When I compiled with no-optimize, the driver works
fine.
 
Thank you very much in advance.
 
 
 The Answer is:
 
  There are many opportunities for code to fail when compiled with one set
  of compiler options, but not with other options.
 
  With device drivers, use the SDA program (ANALYZE/CRASH) to determine the
  exact cause of the failure.  This will typically mean analyzing exact data
  contents of various registers and memory cells from the viewpoint of the
  device driver and the Alpha instruction set.  Information on the steps
  necessary to debug a device driver is included in the Digital Press book
  _Writing OpenVMS Alpha Device Drivers in C_, by Sherlock and Szubowicz.
 
  Examples of common problems include register corruptions, stack stompers,
  and asynchronous code resynchronization flaws -- code optimizers and code
  schedulers are notorious for changing the behaviour of latent source code
  errors, and latent errors can be either masked or unmasked by these tools.
 
  Although it is theoretically possible for a compiler bug to cause this
  sort of problem, it is most often caused by a coding error in the driver.
 
  Speculating about the cause does not help, since in either case the proper
  course of action is to analyze the machine code for the crash and determine
  exactly what went wrong.  If you should find a case where the compiler
  seems to generate faulty code then a _specific_ trouble report through
  official support channels is in order, indicating exactly which machine
  instructions generated by the compiler are considered faulty and which
  C construct(s) and associated C code caused the compiler to generate the
  problematic executable code.
 
 
