Claudio Brotto

SOS ... che non e' una richiesta di aiuto ...

In questo caso SOS sta per Son Of Strike.

Alcuni debugger (tra gli altri CDB e WinDBG) espongono un meccanismo di "estensione" tramite il quale DLL di terze parti, purchè ovviamente scritte in maniera opportuna, possono aggiungere funzionalità a quelle native del debugger stesso. Una sorta di meccanismo a plug-in, insomma.

SOS è, infatti, una dll di estensione ai debugger sopra citati che viene distribuita con l'SDK del .NET Framework e che consente di visualizzare alcune strutture interne del Common Language Runtime: informazioni su tipi, GC, thread e via discorrendo.

Personalmente non sono un amante dei debugger a linea di comando (come CDB) e non mi trovo spesso ad utilizzare WinDBG (forse perchè mi è capitato raramente di dover fare debug su una macchina di produzione, dove VisualStudio non è quasi mai installato, nè tanto meno installabile).

In realtà SOS è utilizzabile in modo estremamente semplice anche da VS.NET.

E' sufficiente "attaccarsi" ad un processo col debugger in modalità nativa (almeno), sospendere l'esecuzione, aprire la finestra Immediate (Debug->Windows->Immediate) e passare (se già non è attiva) alla modalità immediata digitando immed al prompt.

Non resta che caricare la dll tramite:

.load sos.dll

(il path completo non dovrebbe essere necessario, poichè l'installazione di Visual Studio ha messo a posto le variabili di ambiente in modo opportuno).

SOS mette a disposizione una serie piuttosto ampia (e ampliata col procedere delle versioni del CLR, anche in modo notevole con la 2.0) di comandi.

Non ne riporto la lista poiché basta digitare !help per ottenere l'elenco completo. L'ultima release, che accompagna la beta 2, consente anche di ottenere alcune righe di informazione su ogni singolo comando, semplicemente digitando !help <nomecomando>.

L'utilità di questa "cosa" ?

Poca dal punto di vista meramente pratico (se dobbiamo sviluppare un sito in ASP.NET o un'applicazione Windows probabilmente riusciamo a farne a meno senza troppa difficoltà ...).

Molta dal punto di vista "accademico": perchè, appunto, permette di catturare informazioni sulle strutture interne al runtime e, quindi, sul reale funzionamento di alcune delle sue componenti.

Per rendere la cosa un po' meno astratta, riporto un esempio che mostra come sia possibile visualizzare il codice x86 emesso dal Jitter nella compilazione di un metodo.

Innanzitutto, scriviamoci un programma "scratch", anche banale, come questo:

using System;
using System.Runtime.CompilerServices;

namespace SOS {

  class Program {
        
    static void Main() {
      Console.Write("Aggiungo 10 a 5. Il risultato è: ");
      Console.WriteLine(Add(5, 10).ToString());
      Console.ReadLine();
    }

    [MethodImpl(MethodImplOptions.NoInlining)]
    static Int32 Add(Int32 first, Int32 second) { 
      return first + second; 
    }
  }
}

Il metodo Add, che è quello che andremo ad esaminare, è volutamente marcato come "non-inlinabile", in modo tale che il Jitter non ne inserisca il corpo sostituendolo alla chiamata in Main e, di fatto, evitandone la compilazione ... dedicata.

Compiliamo in Release ed eseguiamo. Attacchiamo il debugger al processo e sospendiamone l'esecuzione.Non resta che caricare SOS all'interno del processo ed iniziare ad utilizzarne le funzionalità (.load sos.dll).

Il percorso che dovremo seguire per scoprire il codice macchina generato dal Jitter per il metodo Add è un po' lungo, benchè piuttosto lineare:

1. si parte dalla struttura che rappresenta il tipo Program in memoria ...
2. dalla quale si ottiene l'elenco dei metodi definiti o ridefiniti ...
3. nel quale si cerca il metodo Add ...
4. che infine si decompila !

(1) Per visualizzare le informazioni su un tipo al runtime si può utilizzare il comando !DumpMT <indirizzo MethodTable> . L'indirizzo di memoria della MethodTable relativa al tipo Program non è ovviamente noto a priori: esistono diversi modi per ottenerlo, ma il più semplice consiste nel chiedere ad SOS di indicarcelo, a partire dal nome del tipo e del modulo che lo contiene, tramite il comando !Name2EE <nome modulo> <nome tipo>. Quindi:

(2) Poi ci facciamo elencare i metodi definiti da Sos.Program. Lo switch MD (MethodDesc) indica a SOS la richiesta di un elenco completo con le informazioni su ciascuna entry della tabella dei metodi:

(3) Le informazioni disponibili sono diverse: la locazione di memoria che contiene il codice del metodo (o il rimando al thunk di compilazione), l'indirizzo della relativa MethodDesc, il fatto che il metodo sia già stato compilato o meno dal Jitter (JIT/None), che sia un metodo statico o di istanza ([hasThis]). Si può ottenere un dettaglio ulteriore tramite:

(4) In fondo si nota l'indirizzo (Virtual Address) del codice del metodo in memoria. Non resta che decompilarlo:

Voila, gioco finito :-)

Se vi interessa, vi lascio un paio di link con qualche approfondimento e qualche ulteriore esempio d'uso.

http://blogs.msdn.com/yunjin/archive/2005/05/15/417569.aspx

http://blogs.msdn.com/mvstanton/archive/2004/04/05/108023.aspx