Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>,
	<http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Date: Fri, 27 Aug 1999 10:27:30 +0200 (CEST)
From: Federico Bianchi <bianchi AT pc-arte2 DOT arte DOT unipi DOT it>
To: Emanuele Aliberti <ealiberti AT hotmail DOT com>
cc: cygwin AT sourceware DOT cygnus DOT com
Subject: kernel mode debugging
In-Reply-To: <19990827074216.24316.qmail@hotmail.com>
Message-ID: <Pine.LNX.4.10.9908270954280.2256-100000@www.arte.unipi.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 27 Aug 1999, Emanuele Aliberti wrote:

> >Well, apart from the __fastcall convention, and SEH, you should at least
> >update the linker to handle the NATIVE subsystem and all the other driver
> >things (the MS CRC comes to mind).
> 
> The native subsystem is already supported ("--subsystem native" at least for 
> applications; I am not sure if ld honours the "--entry DriverEntry" when 
> native is the target)

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).

> >Symbols must be in *KD / WinDBG format
> >(at least until Micro$oft doesn't document fully how the remote kernel
> >debugging facility work) unless you are going to happily trace into pure
> >machine code.
> 
> Doesn't exist a kernel version of the gdb?

No.  Moreover, there are a lot of internal fields only available if you
link to the *KDext* DLLs, so you must support them (in one way or another)
- and note they change at any new every service pack or release, so
reimplementing them is simply out of question.

> >Both the DDK and the system itself make a lot of (sometimes hidden)
> >assumptions about how the compiler works, and this is going to worsen due
> >to the use of floating point / MMX-whatever and C++ code in kernel mode -
> >just think of how the name mangling operates on gcc and MSVC and you'll
> >why I think a Cygwin DDK is probably too ambitious a goal at this stage
> >(NASM or - ykes! - GAS/GASP might find their role much earlier, though -
> >but this is a different option).
> 
> Am I wrong, or isn't FP explicitly forbidden in WNT4 kernel modules? There 
> are two system calls to save/restore the coprocessor's state but nothing 
> more (KeRestoreFloatingPointState, KeSaveFloatingPointState).

You are absolutely right. But this is no more the case on NT5 (Win2k) due 
to multimedia and its kernel mode requirements. As of the C++ virtual
function members, they are used to some extent in the Win2k FS modules, or
so Micro$oft and OSR folks say (I didn't bother verifying myself).

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.

Side note: as I told Chris, making gcc a reliable DDK platform involves
making it extremely close to MS C when it comes to its generated
code - and it would probably be no more gcc, but, maybe, a gcc/egcs
back-end for an MS C++ clone, with all its implications. There is a very
sensible reason, after all, if companies like Borland/Imprise, Watcom,
Metaware or Metroworks didn't even try to give direct NT DDK bindings to
their compilers and limited themselves to Win32 apps (I say "direct"
because you can still use in most cases things like, say, Numega Driver
Studio, but that's another story). CE might be different, but I wouldn't
bet on that.

More in general, supporting proprietary (and not fully documented) systems
like NT often tends to be a nightmare, especially with the continuous
upgrade policy Microsoft folks do - if you look, say, at the Platform SDKs
in the latest two years you will see there are _lots_ of differences, and
keeping in touch often means not being able to target old platforms (Sun
folks learned the lesson and succeeded in making it even worse with their
Java DK, but that's another story).

Best regards to you all

	 		Federico Bianchi
			Dipartimento di Storia delle Arti
			Universita` degli Studi di Pisa
			p.zza S.Matteo in Soarta, 2 - 56127 Pisa (Italy)
			tel. +39-050-587111 (cent.), +39-050-587224 (uff.)
			fax. +39-050-580128; e-mail: <f DOT bianchi AT arte DOT unipi DOT it>
			===================================================
			!DISCLAIMER!: my e-mail reflects _my_own_ opinions!
			===================================================


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com