2013-01-07 24 views
5

W ciągu ostatnich kilku tygodni bawiłem się przy użyciu the unmanaged .NET debugging API.Odczytywanie pól instancji podczas debugowania zestawów JIT

Podczas MSDN dokumentuje sama interfejsy, aby dowiedzieć się, jak właściwie korzystać z nich w żaden znaczący sposób, że uciekają się do różnych blogów (głównie Mike Stall's) oraz zarządzanych owijarki w the CLR Managed Debugger samples i ILSpy sources. W końcu udało mi się dołączyć mój program testowy do działającego procesu, ustawić punkty przerwania i uderzyć je.

To, co chciałbym zrobić, to uderzyć w taki punkt przerwania, odczytać pole odnośnej instancji obiektu. Działa to dobrze, gdy metoda docelowa debugowania nie jest NGEN lub JIT, przez disabling loading NGEN'ed assemblies (ustawienie środowiska "COMPLUS_ZAPDISABLE = 1") i disabling JIT optimizations (inaczej "sztuczka pliku .ini").

Jednak gdy próbuję zrobić to samo z moim idealnym celem - kod zoptymalizowany pod kątem handlu detalicznego (NGEN/JIT) - nie działa. Na przykład: Mogę na trafienie punktu przerwania wejściowego nadal pobrać liczbę argumentów metody, ale nie mogę uzyskać pierwszego argumentu sam (debugowanie API zgłasza wyjątek).

Teraz wyobrażam sobie, że powodem tego jest to, że interfejsy API do debugowania mają być niezależne od platformy, w tym przypadku zespoły już nie są. Ale co jeśli zaakceptuję tę zależność od platformy na Intel: o ile mi wiadomo, CLR używa fastcall calling convention, gdzie w tym przypadku rejestr ECX zawiera pierwszy argument metody (niejawne "to" odniesienie dla funkcji składowych).

Przetestowałem to, i rzeczywiście po trafieniu punktu przerwania, ECX zawiera OBJECTREF (adres instancji obiektu), w NGEN'ed zespoły.

Teraz ostatnim krokiem w odczytaniu pola instancji jest pobranie przesunięcia pola względem tego wskaźnika, i tutaj utknąłem, ponieważ wydaje mi się, że nie mogę się dowiedzieć, jak CLR wykonuje the packing of the instance fields during native code generation.

Rozumiem, że może to być wersja/implementacja CLR zależna, ale najwyraźniej są sposoby, ponieważ WinDbg z rozszerzeniem SOS jest w stanie znaleźć ten układ. Jeśli nie za pośrednictwem interfejsów API debugowania, czy mogę w jakiś sposób wykorzystać SOS.dll?

Odpowiedz

0

Na pierwsze pytanie, powodem, dla którego nie można znaleźć argumentów/lokalnych, jest debugowanie zoptymalizowanego kodu. Zoptymalizowany kod nie pozwala na śledzenie argumentów/locals.

Co do drugiego pytania, należy użyć SOS.dll SOSEX.dll lub PSSCOR2/4.dll w WinDbg lub SOS/PSSCOR w Visual Studio, aby odczytać pola obiektu.

EDYCJA: Teraz widzę, że chcesz to zrobić z kodu. Wymaga to, niestety, użycia API Data Access (DAC), który jest nieudokumentowany.

Powiązane problemy