[Pnet-developers] [bug #4535] mscorlib value types being marked as regular classes

[nobody]

=================== BUG #4535: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=4535&group_id=353

Changes by: Rhys Weatherley <address@hidden>
Date: Mon 08/04/2003 at 06:50 (GMT)

            What     | Removed                   | Added
---------------------------------------------------------------------------
          Resolution | None                      | Fixed
              Status | Open                      | Closed


------------------ Additional Follow-up Comments ----------------------------
Fix commited by Gopal - 1 Aug 2003



=================== BUG #4535: FULL BUG SNAPSHOT ===================


Submitted by: Rich333                 Project: DotGNU Portable.NET          
Submitted on: Wed 07/30/2003 at 18:17
Category:  None                       Severity:  5 - Major                  
Bug Group:  None                      Resolution:  Fixed                    
Assigned to:  None                    Status:  Closed                       

Summary:  mscorlib value types being marked as regular classes

Original Submission:  The basic mscorlib value types (e.g. Int32, Char) are 
being marked as regular classes when referenced from other assemblies. This is 
causing things like initobj on these types to fail verification. Within 
mscorlib they seem to be treated properly. You can see things like "box        
class [mscorlib]System.Char" by "ildasm pnetlib/System/System.dll | grep 
System.Char". The problem appears to be in the ILClass attributes for these 
types. I printf'd the attribs for System.Char (at least, that's what the 
classInfo's ILClassName said it was) in the INITOBJ case in verify_obj.c and it 
came out as 0x2109. I'm not sure if the missing IL_META_TYPEDEF_SYSTEM_MASK 
bits are a part of the problem, but I know the missing 
IL_META_TYPEDEF_CLASS_SEMANTICS_MASK bits are.


Rich

Follow-up Comments
*******************

-------------------------------------------------------
Date: Mon 08/04/2003 at 06:50       By: rweather
Fix commited by Gopal - 1 Aug 2003

-------------------------------------------------------
Date: Thu 07/31/2003 at 15:40       By: Rich333
I found this bug because mcs.exe is failing to verify, because of an initobj on 
System.Char. The IsCPPointer check in the INITOBJ case in verify_obj.c is 
failing because the ILType_FromValueType on classInfo is returning what appears 
to be garbage. The ILTypeIdentical fails as a result, and a verification 
exception is thrown. The attached file generates a dynamic assembly which, when 
run, gives the same verification exception, for the same reason.

-------------------------------------------------------
Date: Thu 07/31/2003 at 00:49       By: rweather
The information that indicates that a type is a value type
is stored in the library assembly, not in the referencing
assembly.  There is no way in metadata to record this
in the reference.

The ildasm program only dumps a single assembly at a
time, without loading the dependencies.  And so sometimes
it needs to guess as to what the foreign type is.  This can
cause it to show "class" when you might expect "valuetype",
especially for "box" and "initobj" instructions.

Besides, the IL_META_TYPEDEF_VALUE_TYPE flag
is *not* used to mark value types.  A value type is anything
that inherits from "System.ValueType".  That flag is obsolete
and is not used any more by the ECMA specifications.

The runtime engine, which does load the dependencies,
will resolve the type, discover that it inherits from the
System.ValueType class, and then "know" that it is a
value type.

Do you have a test case that demonstrates a problem at
runtime, or was it just something you noticed in ildasm?


CC list is empty


File Attachments
****************

-------------------------------------------------------
Date: Thu 07/31/2003 at 15:40  Name: xyz.cs  Size: 1KB   By: Rich333
Generates a dynamic assembly which, when run, shows the problem.
http://savannah.gnu.org/bugs/download.php?group_id=353&amp;bug_id=4535&amp;bug_file_id=567


For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=4535&group_id=353

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/