1. Yes, it is for arg iterator to work. This code could use some
cleanup.
2. This code is building the layout of the FramedMethodFrame C++ class
on the stack one word at a time. The Frame vtable is used to call
virtual methods, e.g. Frame::GcScanRoots.
3. m_Next is uninitialized space at this
Check out:
http://research.microsoft.com/collaboration/university/europe/Events/dot
netcc/Version2/Extending_the_SSCLI.ppt
-Jan
-Original Message-
From: Discussion of the Rotor Shared Source CLI implementation
[mailto:[EMAIL PROTECTED] On Behalf Of Paween .Me
Sent: Saturday, August 13,
Unfortunately, sscli.net was shutdown. To patch for Windows XP is pretty
small. Just add the following 3 lines to
sscli/rotorenv/bin/makefile.def:
# Set linker options
#
+ !if $(VS71COMNTOOLS) !=
+ LINKER_FLAGS = $(LINKER_FLAGS) /SAFESEH:NO
+ !endif
+
# Merge .rtc section with .text.
All stores of object references into GC heap have to go via write
barrier so that GC is notified about them.
newObject-param1 = param1;
newObject-param2 = param2;
should be something like:
SetObjectReference(newObject-param1, param1);
SetObjectReference(newObject-param2, param2);
Also,
Here is the picture:
Object: MethodTable:
+++ +
| MethodTable* | --- | DWORD m_wFlags | |
| DWORD m_BaseSize| |
+ ... | | EEClass* m_pEEClass | |
+
There is a per-thread exception state stored in m_handlerInfo member of
current Thread. The object being thrown is in
m_handlerInfo.m_pThrowable.
Passing HRESULT in ExceptionInformation is just a local exception
handling contract in a few parts of the CLR codebase. It is not the
usual way things
You may need change in rotorenv/bin/makefile.def mentioned in
http://mailserver.di.unipi.it/pipermail/dotnet-sscli/msg00244.html.
Add the following 3 lines right before # Merge .rtc section with... in
rotorenv/bin/makefile.def:
!if $(VS71COMNTOOLS) !=
LINKER_FLAGS = $(LINKER_FLAGS) /SAFESEH:NO
We are aware of issues with running Rotor on non-English locales.
Unfortunately, we did not have bandwidth to find and fix all of them. It
is mentioned in readfirst.html:
Please note that the Rotor distribution was only tested on operating
systems using English locales. There are known problems
This is due to version incompatibility.
servicing.sscli.net project contained fixes to make Rotor work well on
FreeBSD 5.2. Unfortunately, sscli.net was shut down. I have not found a
new home for the Rotorv1 servicing project yet. I will send you the
patch to try it out - the mailing list does
You can use makefile project to debug the Rotor C# compiler:
- New / Project / Visual C++ Projects / General / makefile project
- Type the full path to csc.exe you want to debug in Application
settings.
- Add the .cpp to the project so that VS can find them. (Alternatively,
you can set source
1. The C# structs go through that codepath. If you set breakpoint there
for clix hello.exe, it will be hit many times.
(System.SwitchStructure[mscorlib.dll] is the first class it is hit for.)
2. emit_grow is the macro that fjit uses to allocate space for structs.
-Jan
-Original Message-
This is support for arrays of constant size. This feature was not fully
implemented and it is disabled. You can assume that isValueArray always
returns false.
-Jan
-Original Message-
From: Discussion of the Rotor Shared Source CLI implementation
[mailto:[EMAIL PROTECTED] On Behalf Of
JIT_WriteBarrier and JIT_StructWriteBarrier are there for other
(optimizing) JITs. Rotor's FJIT never emits code that calls these
functions.
ErectWriteBarrier is the function that performs the write barrier
update. It is called from a couple of more places in addition the
JIT_*WriteBarrier
FJIT is non-optimizing regardless of the build flavor. It will never
emit calls to JIT_WriteBarrier and JIT_StructWriteBarrier.
-Jan
-Original Message-
From: Discussion of the Rotor Shared Source CLI implementation
[mailto:[EMAIL PROTECTED] On Behalf Of Gajah Mada
Sent: Tuesday, November
Consider following program:
static Object x;
static Object y;
static void Main() {
x = null;
x = null;
x = null;
x = null;
y = new Object();
y = y;
y = y;
y = y;
}
Without optimizations, you will get the behavior you are seeing. An
optimizing compiler or JIT can
It is not entirely clear what does your write barrier: overwrites
00B7F964 with 00B7F964 log entry means. I assume that you have
printf(write barrier: overwrites %08x with %08x\n, dst, ref); to the
JIT_CheckedWriteBarrier function.
#1: Overwriting the start of the object with its address would be
1. Why is the number bumped up by 2 every time someone waits on the
lock?
This field is a combination of a bit flag and counter. The bit flag is
the lowest bit, the counter is the rest.
2. What is the meaning of doing (state - 2) | 1) - and why?
This decrements the counter and sets the flag.
of the Rotor Shared Source CLI
implementation [mailto:[EMAIL PROTECTED] On
Behalf Of Jan Kotas
Sent: 17 October 2004 12:06
To: [EMAIL PROTECTED]
Subject: Re: [DOTNET-ROTOR] Explanation of AwareLock's m_MonitorHeld
1. Why is the number bumped up by 2 every time someone waits on the
lock
The implementation of stack walk is in clr\src\vm\stackwalk.cpp. Look
for Thread::StackWalkFrames and Thread::StackWalkFramesEx.
The stackwalk clr\src\VM\COMCodeAccessSecurityEngine.cpp
-Original Message-
From: Discussion of the Rotor Shared Source CLI implementation
[mailto:[EMAIL
(Hit send too soon...)
The implementation of stack walk is in clr\src\vm\stackwalk.cpp. Look
for Thread::StackWalkFrames and Thread::StackWalkFramesEx.
For an example of use of this function from security-system, look for
CodeAccessCheckStackWalkCB in
clr\src\vm\COMCodeAccessSecurityEngine.cpp.
Another possible explanation for what you are seeing could be that an exception is
thrown. You are not going to receive method exit callbacks for methods exited by
exception being thrown.
-Jan
Od: Discussion of the Rotor Shared Source CLI implementation za
You can trigger GC from VM code by calling g_pGCHeap-GarbageCollect(generation). Look
at GCInterface::CollectGeneration in vm\comutilnative.cpp for example
(http://dotnet.di.unipi.it/Content/sscli/docs/doxygen/clr/vm/comutilnative_8cpp-source.html).
You should be in cooperative GC mode to call
The fastest way is to run build in clr/src/vm and
clr/src/dlls/mscoree.
-Jan
-Original Message-
From: Discussion of the Rotor Shared Source CLI implementation
[mailto:[EMAIL PROTECTED] On Behalf Of Gajah Mada
Sent: Wednesday, September 08, 2004 9:44 AM
To: [EMAIL PROTECTED]
Subject:
I am not aware of any such limitation in the remoting layer. You are
likely running into limits of the underlying HTTP network stack.
Google for MaxConnectionsPerServer to find more info about how to
workaround it.
-Jan
-Original Message-
From: Discussion of the Rotor Shared Source CLI
If you want to expose this feature in C# and seemingly integrate into
IL, then it involves:
- Carefully design the whole thing: Do you really need a new
instruction? Won't be attribute or method enough? If it needs to be a
new instruction, should it be a standalone instruction or prefix? Etc.
-
as pointed
out by you in the first option- if i want to have a method instead of
another instruction, what would the changes involve. it might be a lot
simpler than this?
Regards
archana
On Mon, 23 Aug 2004, Jan Kotas wrote:
If you want to expose this feature in C# and seemingly integrate into
IL
a new alloc function
Hi,
i just realised that the choice of allocation is required at the
alloc-site level rather than at the class level
so the only option is the last one- wrapping the new operator?
could u please elaborate on that??
Thanks
archana
On Tue, 24 Aug 2004, Jan Kotas wrote:
New
The behavior you are seeing can be caused by your program being compiled
as Windows application that has no console - /target:winexe option for
C# compiler.
Make sure that you are compiling your application as console application
- /target:exe option for C# compiler.
-Jan
-Original
compileCEE_NEWOBJ is hit for both allocations points for me. Are you
setting your breakpoints before Main is jitted?
-Jan
-Original Message-
From: Discussion of the Rotor Shared Source CLI implementation
[mailto:[EMAIL PROTECTED] On Behalf Of Archana
Sent: Saturday, July 10, 2004 5:31 AM
The implementation for BeginInvoke and EndInvoke comes from
COMDelegate::GetInvokeMethodStub (clr\src\vm\prestub.cpp).
The actual code is emitted in CTPMethodTable::CreateDelegateStub
(clr\src\VM\i386\remotingx86.cpp).
-Jan
-Original Message-
From: Discussion of the Rotor Shared Source
Unfortunately, we did not have enough time to implement DumpStack on FreeBSD. The
workaround is to use a regular backtrace, and then use IP2MD SOS command to get the
names for managed methods.
Below is transcript of debugging session that demonstrates it.
-Jan
(gdb) break main
Breakpoint 1 at
This was a known problem with the non-final Rotor releases. Can you
check whether you have the final Rotor v1 sources? Go to
rotorenv\bin\version.h and look for #define rup 3. If you see anything
lower than 3 there, you do not have the final Rotor v1 sources. Download
them from
GetThread() returns non-NULL only if SetupThread() was called on the
thread. If you need GetThread() to return non-NULL, you need to call
SetupThread() at least once on the thread.
GetThread is not a function. It is a pointer to a function. It is
defined in threads.h / threads.cpp. It points to
I have started project at http://servicing.sscli.net to cumulate changes
for building Rotor on latest OS version. I have used Eric Albert's
Panther patch and Andrew Gray's FreeBSD 5.1 patch as starting points,
and added a bunch of new fixes. So far this project contains fixes to
make SSCLI 1.0
It could be bug in the implementation of RootReferences callback method.
Is there an easy way to setup a repro to observe this behavior?
-Jan
-Original Message-
From: Discussion of the Rotor Shared Source CLI implementation
[mailto:[EMAIL PROTECTED] On Behalf Of SUBSCRIBE
DOTNET-ROTOR
1. If you are talking about static Object foo = new Foo() in C#, Foo
is allocated in GC heap.
2. It depends on what you mean by VM internal objects. The managed VM
internal objects are allocated in GC heap, the unmanaged ones are not.
For example thread: There are two different objects
Searching for 'cmd' : return code '0xc005' in
C:\sscli\clr\src\builddf.log should give you a clue what went wrong.
-Jan
-Original Message-
From: Discussion of the Rotor Shared Source CLI implementation
[mailto:[EMAIL PROTECTED] On Behalf Of Sam Gentile
Sent: Sunday, March 14, 2004
[mailto:[EMAIL PROTECTED] On Behalf Of Archana
Sent: Thursday, February 05, 2004 6:36 AM
To: [EMAIL PROTECTED]
Subject: Re: [DOTNET-ROTOR] about Pinning objects
Hi,
On Thu, 5 Feb 2004, Jan Kotas wrote:
The only way to see in the current implementation whether the given
object is pinned
PROTECTED]
Subject: Re: [DOTNET-ROTOR] about Pinning objects
Hi,
On Thu, 5 Feb 2004, Jan Kotas wrote:
If both foo and bar are on the stack the callback will be called
multiple times for the string: for the argument of foo(), for the
argument of bar() and finally for the pinned variable in bar
The space in metadata string pool is not reused for System.String
literals. System.String objects are created on demand for strings
literals. These System.String objects have own copy of the data.
The metadata string pool is optimized for small size: UTF8 encoding (1
byte per character for ASCII
Your technique could fail this way if there is some complex code
following the call to FJit_pHlpMyTest in the helper. The helper frame
interpreter needs to interpret its way out into the jitted code. If you
want to know more details, read the How FCall works paragraph in
clr\src\vm\fcall.h.
I do
Ok, there are two ways how to get around this issue:
1. Change the return type of your method to be int, always return 0 from
the method (you will need to use HELPER_METHOD_FRAME_BEGIN_RET_0 instead
of HELPER_METHOD_FRAME_BEGIN_0 to make it compile), and call the method
using the following
The method tables for arrays are created by
ClassLoader::CreateArrayMethodTable in clr\src\vm\array.cpp.
Another special method table that you may run into is transparent proxy
method table. It is created by CTPMethodTable::CreateTPMethodTable in
clr\src\vm\remoting.cpp.
-Jan
This posting is
The following code will fill ARG_1 with the pointer to the MethodTable*
that's treated as class handle by many parts of the execution engine:
enregisterTOS;
mov_register_indirect_to(ARG_1,TOS_REG_1);
BTW: It is not possible to get the exact CORINFO_CLASS_HANDLE at JIT
time.
-Jan
This posting
GetClass()-GetDebugClassName() is a quick way to find the description
for the method table in debug build. Can reply back what this returns
for the special method tables that are troubling you?
-Jan
This posting is provided AS IS with no warranties, and confers no
rights.
-Original
The gen0 collection copies everything over, so there is no need to clear
the bits on the original objects.
The only exception is if there are pinned objects in the gen0. The bits
are cleared in gc_heap::scavenge_pinned_objects in this case - look for
clear_marked_pinned.
-Jan
This posting is
The problem you are seeing is caused by optimization settings. The
default Rotor build flavor is fastchecked: both optimizations and
debugging instrumentation are turned on.
Try using the checked build flavor of Rotor. Setup the environment by
running env.bat checked and then do buildall as
followed the guide to use Get/SetILFunctionBody posted a while
ago by
Jan Kotas. The code works fine in my Rotor build.
I would like to modify the code so that the Main method displays a
Please
Help message before returning. i.e. if the original Main method
displays
Hello World, then the new code
Add the following code fragment to gcscan.cpp:
StackWalkAction PrintCallerCallback(CrawlFrame* pCf, VOID* pData)
{
MethodDesc *pMD = pCf-GetFunction();
fprintf(stderr, Allocation from: %s\n, pMD-GetName());
return SWA_ABORT;
}
void PrintCaller()
{
StackWalkFunctions(GetThread(),
My answers are inline.
-Jan
This posting is provided AS IS with no warranties, and confers no
rights.
-Original Message-
From: Discussion of the Rotor Shared Source CLI implementation
[mailto:[EMAIL PROTECTED] On Behalf Of Albert Miranda
Sent: Monday, November 10, 2003 1:36 AM
To:
The information about the stack ranges is not available in Rotor. You
should be able to add it if you really need to. On Windows, you can get
this by information from NT_TIB structure or using VirtualQuery. NT_TIB
structure is a convenient way to get the committed stack - check this
article
JIT calls ICorMethodInfo::canTailCall to determine whether it is safe to
use tail call in the given situation.
The implementation of canTailCall is in clr\src\vm\jitinterface.cpp.
-Jan
This posting is provided AS IS with no warranties, and confers no
rights.
-Original Message-
From:
When I'm emitting my stub, do I have to call EmitMethodStubProlog
first so that it can pick up the return address correctly?
Using EmitMethodStubProlog is a convenient way how to do it.
how does the stub access parameters from the previous activation
record.
Using ArgIterator. See
Check GCHeap::FinalizerThreadCreate in clr\src\vm\gcee.cpp on how the GC
finalizer thread is created. The creation of your helper thread should
be similar. It can be something like:
MyThread = SetupUnstartedThread();
h = MyThread-CreateNewThread(4096, myThread, NULL, newThreadId);
if (!h) { ...
The regular HELPER_METHOD_FRAME_BEGIN/END assumes that it is right next
to the stack frame of jitted code.
stack frame of the method with HELPER_METHOD_FRAME
stack frame of jitted method
Your change probably made stack frames to look like this:
stack frame of the method with
m_pMethTab is null? I'm hitting that - it's apparently getting to my
assertion via EEClass::RunClassInit. Is the method table not yet set up
at
that point?
Thanks,
-Chris
-Original Message-
From: Discussion of the Rotor Shared Source CLI implementation
[mailto:[EMAIL PROTECTED] Behalf Of Jan
C4018:
'=' : signed/unsigned mismatch
and when i add /w to the compiler option it says overriding /w with
/w4
does 4 mean the warning level over here?
Thanks
archana
On Sat, 2 Aug 2003, Jan Kotas wrote:
Try removing -WX and -Wall from COMPILER_WARNINGS in
rotorenv\bin\sources.cor.
-Jan
The code for the NEWSFAST helper is dynamically generated in
jitinterfacex86.cpp:
hlpFuncTable[CORINFO_HELP_NEWSFAST].pfnHelper =
JIT_TrialAlloc::GenAllocSFast(flags);
-Jan
This posting is provided AS IS with no warranties, and confers no
rights.
-Original Message-
From: Discussion of
Set breakpoint at the EmitXXX function. Once the breakpoint is hit find
out where the code got placed in memory by looking at the return value
of the sl.Link()-GetEntryPoint(). you may need to step out a couple of
frames to get to this point. Set the breakpoint at the entrypoint of the
dynamically
Managed code is executed during the FX build. Thus FJIT has to be
functional in order to build the FX folder. Your changes most likely
broke FJIT.
You can check the fx\src\builddf.log for more detailed error
description. It may give you a hint on what got broken.
The FX build is not the easier
There is always enough space in gen1 to promote the whole gen0. It is
guaranteed by the code in gc_heap::allocate_semi_space:
//do we have enough room for the whole gen0 allocation
// plus the promoted gen 0 in the current segment.
-Jan
This posting is provided AS IS with no
sscli\docs\techinfo\pal_guide.html in your Rotor distribution has the
spec for the PAL architecture.
The Rotor book (http://www.oreilly.com/catalog/sscliess/) has chapter
on PAL with explanations of some implementation details.
-Jan
This posting is provided AS IS with no warranties, and
MethodDesc::Call is used in the EE itself to call the managed code. Here
is an example from comutilnative.cpp:
MethodDesc *pMD =
g_Mscorlib.GetMethod(METHOD__EXCEPTION__GET_MESSAGE);
ARG_SLOT GetMessageArgs[] = { ObjToArgSlot(objException) };
MessageString =
Yes, it is possible. The GC can not be blocked by any lock taken in
managed code.
-Jan
This posting is provided AS IS with no warranties, and confers no
rights.
-Original Message-
From: Discussion of the Rotor Shared Source CLI implementation
[mailto:[EMAIL PROTECTED] On Behalf Of
The image flags I meant were CorLoadOSMap, CorLoadOSImage, and
CorLoadDataMap (as opposed to CorLoadImageMap), which causes the bug
to
occur. Because only when a module has one of these flags, the
Cor_RtlImageRvaToOffset method is called. I was just interested in
what
these flags
0x80090003 is NTE_BAD_KEY. Is comes from CryptImportKey in
palrt\src\crypt.cpp. The problem is that the crypto key in your public
key is invalid.
ilasm from .NET Framework reports an error for me as well, except that
the error code is different (0x80131414).
-Jan
This posting is provided AS IS
int* is not tracked by the garbage collector thus it is not necessary to
use write barrier for it.
In a correct program, int* has to point into interior of *pinned* object
or other memory location that can't be moved by the garbage collector.
This fact has to be guaranteed by the user code.
Here is the relevant paragraph from the ECMA C# Language Specification
that you can download at http://msdn.microsoft.com/net/ecma/:
When a method declaration includes an extern modifier, the method is
said to be an external method. External methods are implemented
externally, typically using a
My wild guess would be that you are not erecting helper frame somewhere
(HELPER_METHOD_FRAME_BEGIN/ HELPER_METHOD_FRAME_END family of macros),
but it is hard to be sure without having more info.
If this hint does not help you, can you post the callstack of the
assert? There should be some
Since your JIT_Checkpoint is probably a helper call you should be using
HCIMPL0 macro to implement it.
There are a several differences between helper calls and fcalls:
- Fcalls are implemented using FCIMPLXXX/FCIMPLEND macros. They are
hooked through the tables in vm/ecall.cpp. They have a
The C# compiler have to emit security attributes to require permissions
to run unverifiable code when /unsafe is used. This is required by the
CLR security model. The serialization of the security attributes is
implemented in the managed code - that's why the runtime is being
initialized when
from the InvokeMethodByName call when the
return is a managed object type?
Ted Neward
{ .NET Java } Author, Instructor
http://www.javageeks.com
http://www.clrgeeks.com
- Original Message -
From: Jan Kotas [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, August 02, 2002 5:20 PM
Subject
There are many possible answers to this one. If I have to pick two,
they will be:
- We are focused on portability. The exceptions interop is not
portable in general, so it is not a priority for us.
- We have shipped the source code, anybody can implement it and share
the implementation with
73 matches
Mail list logo
