Discussion :

[acx01b]

J'ai enfin trouvé où était caché ce satané FieldOffset dans l'objet RtFieldInfo.
Pour ce faire j'ai mis un data break point sur l'adresse d'un champ, puis j'ai appelé Field.SetValue, ça m'a amené au code assembleur de clr.dll et au champ non typé RuntimeFieldHandle.m_ptr
(clr.dll c'est du code non managé mais heureusement ils ont laissé dans le .pdb les noms des fonctions)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
 
// RuntimeFieldHandle.cpp : main project file.
 
#include "stdafx.h"
 
using namespace System;
using namespace System::Reflection;
 
// Je définis un type .NET avec plein de champs, 
// et je retrouve bien l'offset 28 (en 32bit) pour le champ String ^s
 
ref struct A {
	Object ^h;
	Int32 ^k,^l,^m,pp;
	UInt32 a,b,c,d,e;
	Object ^h2;
private :
	Type ^t;
	Boolean p;
	UInt32 a2,b2,c2,d2,e2;
public:
	String ^s;
};
 
generic <typename T> value struct FieldReference {
	UInt32 offset;
	Object ^obj;
 
	value struct RuntimeFieldHandle_m_ptr {
		UInt32 a,b,offset; // attention UInt32 est peut-être uniquement valable en 32bit
	};
 
	static UInt32 GetFieldOffset(FieldInfo ^f) {
		RuntimeFieldHandle h = f->FieldHandle;
		IntPtr value = h.Value;
		RuntimeFieldHandle_m_ptr * m_ptr = (RuntimeFieldHandle_m_ptr *)(void*)value; // le type de value n'est pas communiqué par .NET : il faut le trouver soi-même
		UInt32 res = m_ptr->offset;
                // le premier bit est probablement un flag ?
		res &= 0x7FFFFFF; // attention 0x7FFFFFF est peut-être uniquement valable en 32bit
 
		return res +  sizeof(void*); // ajout de la VMT
	}
 
 
	FieldReference(Object ^obj, UInt32 offset) : obj(obj), offset(offset) {}
 
	FieldReference(Object ^obj, FieldInfo^ fi) : obj(obj) {
		offset = GetFieldOffset(fi);
	}
 
	FieldReference(Object ^obj, String ^fieldName) : obj(obj) {
		Type ^t = obj->GetType();
		FieldInfo ^fi = t->GetField(fieldName);
		offset = GetFieldOffset(fi);
	}
 
	property T Value {
 
		T get() {
			pin_ptr<Object^> tmp = &this->obj;
			void *ptr = (void*)tmp;
			char *objadr = *(char**)ptr;
			void *fieldadr = objadr + this->offset;
 
			return (T)*(Object^*)fieldadr;
		}
		void set(T t) {
			pin_ptr<Object^> tmp = &this->obj;
			void *ptr = (void*)tmp;
			char *objadr = *(char**)ptr;
			void *fieldadr = objadr + this->offset;
 
			*(Object^*)fieldadr = t;
		}
	};
};
 
int main(array<System::String ^> ^args)
{
	A ^a = gcnew A();
	a->s = "avant";
 
	FieldReference<String^> a_s(a,"s");
	a_s.Value = "apres";
	Console::WriteLine(a->s);
    return 0;
}

Je n'ai pas testé en 64 bit : la constante 0x7FFFFFF et les UInt32 de RuntimeFieldHandle_m_ptr deviennent peut-être des UInt64.

[Médinoc]

Ça, c'est du bas niveau comme je l'aime!
Bravo pour ton investigation.

[acx01b]

Je ne sais pas si tu savais mais je viens de regarder : les pin_ptr ont un coût nul ou presque. C'est juste une variable locale et une instruction lea (ldarga ou ldloca en MSIL), je suppose donc que c'est uniquement quand le garbage collector passe qu'il répertorie les pin_ptr et marque les objets correspondant comme "ne devant pas bouger (et donc restant dans la même génération ?)".

C'est cool mais ça n'est pas très consistant avec GCHandle par exemple (gcroot) qui fait je ne sais combien d'opérations (dans la propriété Target) pour récupérer l'objet, alors qu'en théorie il suffit d'une indirection de pointeur. D'ailleurs j'ai peur qu'au milieu du code de GCHandle.Target.get il n'y ait pas un truc du genre : "si le garbage collector est en train de passer, alors aller chercher le Object^ à un autre endroit" (comme je l'ai déjà dit, en temps normal le GCHandle est simplement un Object^* [ dans le cas du gcroot donc du GCHandle(.., GCHandleType::Normal) je n'ai pas trop regardé les autres] ).

Une autre misère de .NET est qu'on ne peut pas pinner dynamiquement un array<Object^> (si on fait un GCHandle(.., GCHandleType:: Pinned) sur un array, .NET il dit à l'exécution que ce n'est pas blittable...), résultat on est obligé d'utiliser les gcroot vu qu'on ne peut pas coder soi-même son propre mécanisme d'allocation dynamique d'Object^.

(C'est cool de trouver quelqu'un qui aime bien le "hardcore .NET". A mon taf je suis le seul que ça fasse rigoler, et j'avoue que j'ai l'impression de monologuer tout seul quand je raconte que Java ferait bien de faire comme .NET et de générer des exceptions compatibles avec les exceptions SEH et d'inclure des instructions de manipulation pointeur dans leur bytecode.)

[Médinoc]

Je ne sais pas comment ça marche à bas niveau, mais dans le CIL le pin est juste un mot-clé pinned sur une déclaration de variable locale.

Dans la Emit, ça se spécifie dans ILGenerator.DeclareLocal().