Thank you for your reply, we'll stick to win32 for now, and investigate FreeBSD possibilities later on.
Now we are facing another kind of the problem. We are trying to patch the sscoree.dll and mscorejt.dll to adopt the CLI to our backstepping debugger needs. The problem is that we don't want all the managed libraries to be bootstrapped against our version of the dlls. How could we alter the build process to perform two separate builds in clr/src but to use the result of only one of them later in fx/ ? Thank you in advance. ----- Original Message ----- From: "Jan Kotas" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, October 02, 2002 9:50 PM Subject: Re: [DOTNET-ROTOR] exception dispatching The Rotor exception handling should have this behavior on win32. On Windows, the Rotor portable exception handling is wrapper around the native win32 exception handling. Rotor exceptions are always raised as win32 exceptions - the win32 debugger will get first crack on these as usual. This is win32 specific, you won't get this behavior on FreeBSD. All Rotor exceptions go through the emulation layer in the PAL, so the other option to get first crack on exceptions is to hook into PAL_ExceptionFilter in pal\unix\exception\exception.c. This is the way to go if you want your stuff to work on FreeBSD. You should be able to do the same hook for FreeBSD in SEHRaiseException in pal/unix/exception/exception.c. If you are interested only in managed exceptions, you may also check the managed debugging interfaces (clr\src\inc\cordebug.idl). A documentation for managed debugging interfaces can be found in .NET Framework SDK (FrameworkSDK\Tool Developers Guide\docs\DebugRef.doc). .NET Framework SDK is part of the Visual Studio .NET install, or it can be downloaded from msdn.microsoft.com. -Jan This posting is provided "AS IS" with no warranties, and confers no rights.
