no
rights.
-Original Message-
From: Archana Ravindar [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 18, 2002 10:13 PM
To: [EMAIL PROTECTED]
Subject: Re: [DOTNET-ROTOR] gc heap structure for rotor
Barry Bond wrote:
For example, take a look at GCHeap::IsHeapPointer() in
sscli/src
Pinned objects fall into two categories. First, all arguments passed
via P/Invoke (also called NDirect) are implicitly pinned. Second,
objects can be explicitly allocated as pinned via the managed
System.Runtime.InteropServices.GCHandle.Alloc(Object, GCHandleType)
method, which adds entries to
The cgcDesc and gcdDescSeries classes are wrappers laid on top of an
object's MethodTable to simplify access. The MethodTable is laid out in
class.cpp's EEClass::BuildMethodTable(). For most objects,
EEClass::PlaceInstanceFields() lays out the object's fields, and is
responsible for creating the
The fjit directory builds mscorejt.dll, while clr\src\vm builds
cee_wks.lib, which is consumed by clr\src\dlls\mscoree to build
sscoree.dll. On Windows, each DLL has its own private namespace for
types and functions, with .def files controlling what names are made
available to other DLLs.
In
Take a look at sscli/docs/techinfo/logging.html - if you set
COMPLUS_LogToDebugger=1 in your environment, the Execution Engine will
route its debug messages to OutputDebugString. The PALs use a different
logging mechanism, but the Win32 PAL can also log via OutputDebugString.
Barry
This posting
Can you check two things?
1) Check that your new machine has a working Perl installation: the
SSCLI build process depends on it.
2) Open c:\users\yuan\proj\rotor\sscli\clr\builddf.log and search for
assemblyattributes.cspp. Hopefully, there will be an error message
nearby that will help
: Discussion of the Rotor Shared Source CLI implementation
[mailto:[EMAIL PROTECTED] On Behalf Of Barry Bond
Sent: Wednesday, August 20, 2003 2:19 PM
To: [EMAIL PROTECTED]
Subject: Re: [DOTNET-ROTOR] Build problem (again)
Can you check two things?
1) Check that your new machine has a working Perl
Files under clr\src shouldn't be including the Visual Studio version of
stdlib.h: the SSCLI tree provides its own version, in palrt\inc. Can
you confirm that E:\taanders\ROTORP\palrt\inc\stdlib.h exists and is 696
bytes long?
Also, please check that you don't have an INCLUDE environment
Have you confirmed that the server_addr you created looks correct under
the debugger? The typecast *(struct in_addr*)hp-h_addr looks
suspicous to me.
If you look at other callers of connect() in the SSCLI, you'll see code
like this:
/* prepare the sockaddr_in structure */
Take a look at the profiler, in sscli\samples\utilities\dnproprofiler.
There is a dnprofiler.html that describes a bit about the profiler
interface. You should be able to use the JITCOmpilationStarted()
callback to instrument each method's IL as it is jitted.
Barry
This posting is provided AS IS
You could host Rotor in-process inside a native app using the same
mechanism that clix.exe uses: call Win32 LoadLibrary() on mscoree.dll,
then GetProcAddress for _CorExeMain2 and call it. You *might* need to
first call LoadLibrary() on rotor_pal.dll and call its PAL_Initialize()
before loading
Have you looked at System.Diagnostics.StackFrame? Sources are in
clr\src\bcl\system\diagnostics\stacktrace.cs. This code uses an ECALL
in stackframe.cs to call native
DebugStackTrace::GetStackFramesInternal(), implemented in
clr\src\vm\debugdebugger.cpp. It in turn calls StackWalkFrames().
The current garbage collector frequently accesses the MethodTables of
all object in the heap. Can you re-use some of that code? ie.
clr/src/vm/gcsmp.cpp's Object::GetMethodTable() returns a MethodTable*
from an object.
Alternatively, you could store newly-allocated MethodTable objects in a
GcScanRoots and GcScanHandles don't push object pointers onto the mark
stack: they directly mark the objects as live, and for each live
object, push pointers to objects referenced from that first level onto
the mark stack. See GCHeap::Promote() for details: it is called from
clr/src/vm/appdomain.cpp pre-allocates some exceptions in
SystemDomain::CreatePreallocatedExceptions() by calling CreateHandle()
then StoreObjectInHandle(). They boil down into calls to
clr/src/vm/objecthandle.cpp. The GC calls objecthandle.cpp's
Ref_TraceNormalRoots() from within
'2' is File not found error.
Try this:
cd sscli/clr/src/ilasm
build
This should print a useful error message. If it doesn't, open
builddf.log in the current directory: it contains the output from all
of the tools used during the build.
From the list of things that failed, my
Jan 2004, Barry Bond wrote:
'2' is File not found error.
Try this:
cd sscli/clr/src/ilasm
build
This should print a useful error message. If it doesn't, open
builddf.log in the current directory: it contains the output from all
of the tools used during the build.
From
It's just a native-code app, so it can be debugged with Visual Studio
without needing to do any work ahead of time.
From inside your Rotor build window, run devenv.exe /debugexe
%TARGETCOMPLUS%\csc.exe foo.cs . That will launch Visual Studio and
tell it to debug the C# compiler as it compiles
You can use VS.NET's IDE to debug the native code parts of the SSCLI.
The document
file://c:/sscli/docs/debugging/debugging_overview.html#DebuggingUnmanage
dSSCLICodeonWindows explains how to do it.
It isn't practical to build the SSCLI from within VS.NET: the SSCLI
build process is very complex
] Accessing the class in different
source folder
Date: Sun, 6 Jul 2003 09:50:55 -0700
From: Barry Bond [EMAIL PROTECTED]
Reply-To: Discussion of the Rotor Shared Source CLI implementation
===
This list is hosted by DevelopMentor(r) http://www.develop.com
ASP.NET
,
On Mon, 21 Jun 2004, Barry Bond wrote:
A good example to follow is ildbsymbols.dll, in
clr\src\tools\ildbsymbols.
1. ildbsymbols has an ildbsymbols.def file that was manually authored
and is included in the tarball. The sources file in
clr\src\tools\ildbsymbols references it via DLLDEF
What platform are you running on? FreeBSD?
Barry
-Original Message-
From: Discussion of the Rotor Shared Source CLI implementation
[mailto:[EMAIL PROTECTED] On Behalf Of Archana
Sent: Tuesday, June 22, 2004 7:58 AM
To: [EMAIL PROTECTED]
Subject: [DOTNET-ROTOR] GetThread() function
Hi,
Things are working fine for you... the messages from the debugger just
aren't clear.
ERROR: Symbol file could not be found. Defaulted to export symbols for
ntdll.dll tells you that the debugger cannot find symbols for
ntdll.dll. That's OK... they're not needed to debug Rotor.
*** WARNING:
The PAL builds with /W3 /WX but you're seeing a level 4 warning, which
is interesting.
From your Rotor build window, can you run cl with no arguments and
send back the version number from its banner? Mine reports 13.10.3077.
Could you also send along sscli\pal\win32\build*.log? There might be
(ref:help needed wrt debugging, Jul24,2003,
that Barry Bond helped me with). i tried the method that was
suggested. but i am not able to locate the prolog here. and i dont know if
i can use SOS in the Free BSD platform?
i am running the application through gdb (Free BSD) and
doing a backtrace
MAXALLOC is defined only in debug builds (checked and fastchecked), not
in retail (free). The comment in utilcode.h is relevant:
00222 #ifdef MAXALLOC
00223 // these defs allow testers to specify max number of requests for
an allocation before
00224 // returning outofmemory
00225 void *
A DomainLocalBlock is a collection of per-appdomain data -
Assembly::Init() in clr\src\vm\assembly.cpp refers to it as DLS -
Domain Local Storage. Kind of like Windows Thread Local Storage (TLS),
but per-appdomain. All of its methods deal with module names and
indices into a per-appdomain list
Does your logging code also hook tailcalls? Search
clr\src\fjit\fjit.cpp for CORINFO_HELP_PROF_FCN_TAILCALL
I'm not sure if there are any tailcalls in a simple helloworld.
Barry
-Original Message-
From: Discussion of the Rotor Shared Source CLI implementation
[mailto:[EMAIL PROTECTED]
1. Here are steps for rebuilding after making a change to clr\src\vm...
cd \sscli\clr\src\vm
build -z- rebuilds the VM directory
without computing dependency information
cd ..\dlls\mscoree
build -z- rebuilds
The code that displays the text is in
fx\src\net\system\net\_connection.cs - search for Dump(). It looks
like it might be called as part the GlobalLog.DebugAddRequest call in
_connection.cs's SubmitRequest method.
All of the code is tagged with
[System.Diagnostics.Conditional(DEBUG)], so it is
Just launch env.bat with no arguments, and it will create a checked
build window, which defines _DEBUG and several other macros. env.bat
free creates a build window with debugging macros off.
Barry
-Original Message-
From: Discussion of the Rotor Shared Source CLI implementation
31 matches
Mail list logo
