This is the mail archive of the
cygwin@sourceware.cygnus.com
mailing list for the Cygwin project.
Re: kernel mode debugging
- To: bianchi@www.arte.unipi.it, ealiberti@hotmail.com
- Subject: Re: kernel mode debugging
- From: "Emanuele Aliberti" <ealiberti@hotmail.com>
- Date: Tue, 31 Aug 1999 08:45:08 CEST
- Cc: cygwin@sourceware.cygnus.com
[native applications with gcc/win32]
>Don't think so. At least not in the beta 20.1 I have. And the CRC used is
>theoretically proprietary (though I have seen at least a - virus? - guy
>presenting code to implement it).
Can you send me a reference to get that pseudo-CRC code?
[kernel debugging]
>While in kernel mode, you must also consider that there are even drivers
>who "know" they can safely use some registers and memory locations (i.e.,
>they neither save nor restore them) because of their class mode
>counterparts being written with MS C/C++. This is mostly what I was
>thinking about when mentioning hidden assumptions.
That seems a bit risky, even for MS. I know the executive exports many data
symbols, but I always assumed they are read-only for thirdy party modules.
About register, perhaps you saw a __fastcall in the debugger, and that seems
exactly a piece of code that does NOT save/restore registers (at least that
was my feeling the first time I met it). I don't belive your assertion be
true: how could the SMP kernel cope with the expected intricacies such a
piece of code has when dealing with synchronization, if it could only place
its trust in the VC++ compiler, which has a static view of the system?
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com