Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Dieses Thema enthält eine Übersicht über die Verwendung von Debuggerdatenmodell-C++-Schnittstellen zum Erweitern und Anpassen der Funktionen des Debuggers.
Debuggerdatenmodell-C++-Hostschnittstellen
des Debuggerdatenmodellhosts
Das Debuggerdatenmodell ist so konzipiert, dass es sich um ein komponentenisiertes System handelt, das in verschiedenen Kontexten gehostet werden kann. Normalerweise wird das Datenmodell im Kontext einer Debuggeranwendung gehostet. Um ein Host des Datenmodells zu sein, müssen eine Reihe von Schnittstellen implementiert werden, um kernige Aspekte des Debuggers verfügbar zu machen: seine Zielbestimmung, ihre Speicherplätze, ihr Evaluator, ihr symbolisches und Typsystem usw. Während diese Schnittstellen von jeder Anwendung implementiert werden, die das Datenmodell hosten möchte, werden sie sowohl vom Kerndatenmodell als auch von jeder Erweiterung genutzt, die mit dem Datenmodell interagiert.
Die Gruppe der Kernschnittstellen ist:
| Schnittstellenname | BESCHREIBUNG |
|---|---|
| IDebugHost | Die Kernschnittstelle für den Debughost. |
| IDebugHostStatus | Eine Schnittstelle, über die ein Client den Status des Hosts abfragen kann. |
| IDebugHostContext | Eine Abstraktion eines Kontexts innerhalb des Hosts (z. B. ein bestimmtes Ziel, ein bestimmter Prozess, ein bestimmter Adressraum usw....) |
| IDebugHostErrorSink | Eine Schnittstelle, die von Aufrufern implementiert wird, um Fehler aus bestimmten Teilen des Host- und Datenmodells zu erhalten |
| IDebugHostEvaluator / IDebugHostEvaluator2 | Der Auswertungsauswert des Debughosts. |
| IDebugHostExtensibility | Eine Schnittstelle zum Erweitern der Funktionen des Hosts oder teile davon (z. B. der Ausdrucksauswertung). |
Das Typsystem und die symbolischen Schnittstellen sind:
| InterfaceName | BESCHREIBUNG |
|---|---|
| IDebugHostSymbols | Kernschnittstelle, die Zugriff auf und Auflösung von Symbolen bietet |
| IDebugHostSymbol / IDebugHostSymbol2 | Stellt ein einzelnes Symbol beliebiger Art dar. Das bestimmte Symbol ist eine Ableitung dieser Schnittstelle. |
| IDebugHostModule | Stellt ein modul dar, das in einem Prozess geladen wurde. Dies ist eine Art von Symbol. |
| IDebugHostType / IDebugHostType2 | Stellt einen systemeigenen/spracheigenen Typ dar. |
| IDebugHostConstant | Stellt eine Konstante innerhalb symbolischer Informationen dar (z. B. ein Argument ohne Typvorlage in C++) |
| IDebugHostField | Stellt ein Feld innerhalb einer Struktur oder Klasse dar. |
| IDebugHostData | Stellt Daten innerhalb eines Moduls dar (wäre dies innerhalb einer Struktur oder Klasse, wäre es ein IDebugHostField) |
| IDebugHostBaseClass | Stellt eine Basisklasse dar. |
| IDebugHostPublic | Stellt ein Symbol in der öffentlichen Tabelle eines PDB dar. Dies enthält keine Typinformationen, die ihr zugeordnet sind. Es handelt sich um einen Namen und eine Adresse. |
| IDebugHostModuleSignature | Stellt eine Modulsignatur dar – eine Definition, die mit einer Gruppe von Modulen nach Name und/oder Version übereinstimmt. |
| IDebugHostTypeSignature | Stellt eine Typsignatur dar – eine Definition, die einem Satz von Typen nach Modul und/oder Name entspricht. |
die Kernhostschnittstelle: IDebugHost
Die IDebugHost-Schnittstelle ist die Kernschnittstelle eines Datenmodellhosts. Sie wird wie folgt definiert:
DECLARE_INTERFACE_(IDebugHost, IUnknown)
{
STDMETHOD(GetHostDefinedInterface)(_COM_Outptr_ IUnknown** hostUnk) PURE;
STDMETHOD(GetCurrentContext)(_COM_Outptr_ IDebugHostContext** context) PURE;
STDMETHOD(GetDefaultMetadata)(_COM_Outptr_ IKeyStore** defaultMetadataStore) PURE;
}
Die GetHostDefinedInterface-Methode gibt die private Hauptschnittstelle des Hosts zurück, sofern dies für den angegebenen Host vorhanden ist. Für Debuggingtools für Windows ist die hier zurückgegebene Schnittstelle ein IDebugClient (cast to IUnknown).
Die GetCurrentContext-Methode gibt eine Schnittstelle zurück, die den aktuellen Zustand des Debuggerhosts darstellt. Die genaue Bedeutung dieses Vorgangs bleibt dem Host überlassen, enthält jedoch in der Regel Elemente wie Sitzung, Prozess und Adressraum, die auf der Benutzeroberfläche des Debughosts aktiv sind. Das zurückgegebene Kontextobjekt ist weitgehend undurchsichtig für den Aufrufer, aber es ist ein wichtiges Objekt, das zwischen Aufrufen an den Debughost übergeben werden soll. Wenn ein Aufrufer beispielsweise Speicher liest, ist es wichtig zu wissen, aus welchem Prozess und Adressraum der Speicher gelesen wird. Dieser Begriff wird im Begriff des Kontextobjekts gekapselt, das von dieser Methode zurückgegeben wird.
Die GetDefaultMetadata-Methode gibt einen Standardmetadatenspeicher zurück, der für bestimmte Vorgänge (z. B. Zeichenfolgenkonvertierung) verwendet werden kann, wenn keine expliziten Metadaten übergeben wurden. Auf diese Weise kann der Debughost einige Kontrolle über die Darstellung einiger Daten haben. Die Standardmetadaten können z. B. einen PreferredRadix-Schlüssel enthalten, sodass der Host angeben kann, ob Ordinale im Dezimal- oder Hexadezimalwert angezeigt werden sollen, falls nicht anders angegeben.
Beachten Sie, dass Eigenschaftswerte im Standardmetadatenspeicher manuell aufgelöst werden müssen und das Objekt übergeben müssen, für das die Standardmetadaten abgefragt werden. Die GetKey-Methode sollte anstelle von GetKeyValue verwendet werden.
Statusschnittstelle: IDebugHostStatus
Die IDebugHostStatus-Schnittstelle ermöglicht einem Client des Datenmodells oder des Debughosts, bestimmte Aspekte des Status des Debughosts zu ermitteln. Die Schnittstelle ist wie folgt definiert:
DECLARE_INTERFACE_(IDebugHostStatus, IUnknown)
{
STDMETHOD(PollUserInterrupt)(_Out_ bool* interruptRequested) PURE;
}
Die PollUserInterrupt-Methode wird verwendet, um zu fragen, ob der Benutzer des Debughosts eine Unterbrechung des aktuellen Vorgangs angefordert hat. Ein Eigenschaftsaccessor im Datenmodell kann z. B. beliebigen Code aufrufen (z. B. eine JavaScript-Methode). Dieser Code kann eine beliebige Zeit in Anspruch nehmen. Um den Debughost reaktionsfähig zu halten, sollte jeder solche Code, der eine beliebige Zeit in Anspruch nehmen kann, eine Unterbrechungsanforderung durch Aufrufen dieser Methode überprüfen. Wenn der wert "interruptRequested" als "true" zurückgegeben wird, sollte der Aufrufer sofort abgebrochen und ein Ergebnis von E_ABORT zurückgeben.
Kontextschnittstelle: IDebugHostContext
Kontext ist einer der wichtigsten Aspekte des Datenmodells und des zugrunde liegenden Debughosts. Wenn Sie ein Objekt halten, ist es wichtig zu wissen, woher ein Objekt stammt – welcher Prozess ist darin enthalten, welcher Adressraum es zugeordnet ist. Wenn Sie diese Informationen kennen, können Sie Dinge wie Zeigerwerte richtig interpretieren. Ein Objekt vom Typ "IDebugHostContext" muss an viele Methoden auf dem Debughost übergeben werden. Diese Schnittstelle kann auf verschiedene Arten erworben werden:
- Durch Abrufen des aktuellen Kontexts des Debuggers: Aufrufen der GetCurrentContext-Methode von IDebugHost
- Durch Abrufen des Kontexts eines Objekts: Aufrufen der GetContext-Methode von IModelObject
- Durch Abrufen des Kontexts eines Symbols: Aufrufen der GetContext-Methode von IDebugHostSymbol
Darüber hinaus gibt es zwei Werte, die im Kontext einer IDebugHostContext-Schnittstelle eine besondere Bedeutung haben, die entweder von einem Datenmodell oder einer Debughostmethode zurückgegeben oder übergeben wird:
nullptr: ein Hinweis darauf, dass kein Kontext vorhanden ist. Es ist perfekt gültig, damit einige Objekte keinen Kontext haben. Das Debugger-Objekt im Stammnamespace des Datenmodells verweist nicht auf etwas innerhalb eines bestimmten Prozess- oder Adressraums. Sie hat keinen Kontext.
USE_CURRENT_HOST_CONTEXT: Ein Sentinelwert, der angibt, dass der aktuelle Benutzeroberflächenkontext des Debughosts verwendet werden soll. Dieser Wert wird nie vom Debughost zurückgegeben. Es kann jedoch an jede Debughostmethode übergeben werden, die einen Eingabe-IDebugHostContext anstelle des expliziten Aufrufens der GetCurrentContext-Methode von IDebugHost verwendet. Beachten Sie, dass das explizite Übergeben von USE_CURRENT_HOST_CONTEXT häufig leistungsleistungsfähiger ist als das explizite Abrufen des aktuellen Kontexts.
Die Kontexte eines Hostkontexts sind weitgehend undurchsichtig für den Aufrufer. Der einzige Vorgang, den ein Aufrufer außerhalb des Kerndebughosts mit einem Hostkontext ausführen kann, besteht darin, ihn mit einem anderen Hostkontext zu vergleichen.
Die IDebugHostContext-Schnittstelle ist wie folgt definiert:
DECLARE_INTERFACE_(IDebugHostContext, IUnknown)
{
STDMETHOD(IsEqualTo)(_In_ IDebugHostContext *pContext, _Out_ bool *pIsEqual) PURE;
}
Die IsEqualTo-Methode vergleicht einen Hostkontext mit einem anderen Hostkontext. Wenn die beiden Kontexte gleichwertig sind, wird ein Hinweis darauf zurückgegeben. Beachten Sie, dass dieser Vergleich keine Äquivalenz der Schnittstelle ist. Dadurch wird der zugrunde liegende undurchsichtige Inhalt des Kontexts selbst verglichen.
Fehlersenke: IDebugHostErrorSink
IDebugHostErrorSink ist ein Mittel, mit dem ein Client Benachrichtigungen über Fehler erhalten kann, die während bestimmter Vorgänge auftreten und diese Fehler bei Bedarf weiterleiten können. Die Schnittstelle ist wie folgt definiert:
enum ErrorClass
{
ErrorClassWarning,
ErrorClassError
}
DECLARE_INTERFACE_(IDebugHostErrorSink, IUnknown)
{
STDMETHOD(ReportError)(_In_ ErrorClass errClass, _In_ HRESULT hrError, _In_ PCWSTR message) PURE;
}
Die ReportError-Methode ist ein Rückruf auf der Fehlersenke, um ihn darüber zu informieren, dass ein Fehler aufgetreten ist, und der Spüle erlauben, den Fehler an die gewünschte Benutzeroberfläche oder jeden Mechanismus weiterzuleiten.
Host-Evaluator: IDebugHostEvaluator / IDebugHostEvaluator2
Einer der wichtigsten Funktionen, die der Debughost für Clients bereitstellt, ist der Zugriff auf seine sprachbasierte Ausdrucksauswertung. Die IDebugHostEvaluator- und IDebugHostEvaluator2-Schnittstellen sind die Mittel für den Zugriff auf diese Funktionalität vom Debughost.
Die Schnittstellen sind wie folgt definiert:
DECLARE_INTERFACE_(IDebugHostEvaluator2, IDebugHostEvaluator)
{
//
// IDebugHostEvaluator:
//
STDMETHOD(EvaluateExpression)(_In_ IDebugHostContext* context, _In_ PCWSTR expression, _In_opt_ IModelObject* bindingContext, _COM_Errorptr_ IModelObject** result, _COM_Outptr_opt_result_maybenull_ IKeyStore** metadata) PURE;
STDMETHOD(EvaluateExtendedExpression)(_In_ IDebugHostContext* context, _In_ PCWSTR expression, _In_opt_ IModelObject* bindingContext, _COM_Errorptr_ IModelObject** result, _COM_Outptr_opt_result_maybenull_ IKeyStore** metadata) PURE;
//
// IDebugHostEvaluator2:
//
STDMETHOD(AssignTo)(_In_ IModelObject* assignmentReference, _In_ IModelObject* assignmentValue, _COM_Errorptr_ IModelObject** assignmentResult, _COM_Outptr_opt_result_maybenull_ IKeyStore** assignmentMetadata) PURE;
}
Mit der EvaluateExpression-Methode kann der Debughost einen Sprachausdruck (z. B. C++) auswerten und den resultierenden Wert dieses Ausdrucksauswertungsfelds als IModelObject zurückgeben. Diese spezielle Variante der Methode lässt nur Sprachkonstrukte zu. Alle zusätzlichen Funktionen, die innerhalb des Ausdrucksvaluators des Debughosts angezeigt werden, der in der Sprache nicht vorhanden ist (z. B. LINQ-Abfragemethoden), wird für die Auswertung deaktiviert.
Die EvaluateExtendedExpression-Methode ähnelt der EvaluateExpression-Methode, mit der Ausnahme, dass sie zusätzliche nichtsprachliche Funktionen aktiviert, die ein bestimmter Debughost dem Ausdrucksauswerter hinzufügen möchte. Für Debuggingtools für Windows ermöglicht dies beispielsweise anonyme Typen, LINQ-Abfragen, Modulqualifizierer, Formatbezeichner und andere Nicht-C/C++-Funktionen.For Debugging Tools for Windows, for example, this enables anonym types, LINQ queries, module qualifizierer, format specifiers, and other non-C/C++functionality.
IDebugHostEvaluator2
Die AssignTo-Methode führt Zuweisungen gemäß der Semantik der zu debuggenden Sprache aus.
Hosterweiterungsschnittstelle: IDebugHostExtensibility
Bestimmte Funktionen des Debughosts unterliegen optional der Erweiterbarkeit. Dies kann z. B. den Ausdrucksauswerter enthalten. Die IDebugHostExtensibility-Schnittstelle ist die Mittel, über die auf diese Erweiterbarkeitspunkte zugegriffen wird. Die Schnittstelle ist wie folgt definiert:
DECLARE_INTERFACE_(IDebugHostExtensibility, IUnknown)
{
STDMETHOD(CreateFunctionAlias)(_In_ PCWSTR aliasName, _In_ IModelObject *functionObject) PURE;
STDMETHOD(DestroyFunctionAlias)(_In_ PCWSTR aliasName) PURE;
}
Die CreateFunctionAlias-Methode erstellt einen "Funktionsalias", einen "Schnellalias" für eine in einer Erweiterung implementierte Methode. Die Bedeutung dieses Alias ist hostspezifisch. Er kann den Ausdrucksauswert des Hosts um die Funktion erweitern oder etwas ganz anderes tun.
Die DestroyFunctionAlias-Methode rückgängig machen einen vorherigen Aufruf der CreateFunctionAlias-Methode rückgängig. Die Funktion ist nicht mehr unter dem Namen des Schnellalias verfügbar.
Zugreifen auf das Datenmodell
In erster Linie sind die Datenmodellerweiterungs-APIs so konzipiert, dass sie für die Anwendung neutral sind (in der Regel ein Debugger), der als Host des Datenmodells fungiert. Theoretisch kann jede Anwendung das Datenmodell hosten, indem eine Reihe von Host-APIs bereitgestellt wird, die das Typsystem der Debugziele der Anwendung und eine Reihe von projizierten Objekten im Namespace des Datenmodells über die Ziele, Prozesse, Threads usw. verfügbar machen... befinden sich in diesen Debugzielen.
Während die Datenmodell-APIs - diejenigen, die IDataModel, IDebugHostund die Ausgänge von IModelObject - beginnen, sind so konzipiert, dass sie portierbar sind, definieren sie nicht, was eine "Debuggererweiterung" ist. Heute muss eine Komponente, die Debugtools für Windows und das bereitgestellte Modul erweitern möchte, eine Modulerweiterung schreiben, um Zugriff auf das Datenmodell zu erhalten. Diese Modulerweiterung muss nur eine Modulerweiterung in so viel sein, wie dies der Lade- und Bootstrapping-Mechanismus für die Erweiterung ist. Daher würde eine minimale Implementierung Folgendes bieten:
- DebugExtensionInitialize: Eine Methode, die einen erstellten IDebugClient verwendet, um Zugriff auf das Datenmodell zu erhalten und Objektmodellmanipulationen einzurichten.
- DebugExtensionUninitialize: Eine Methode, mit der die In DebugExtensionInitialize ausgeführten Objektmodellmanipulationen rückgängig machen.
- DebugExtensionCanUnload: Eine Methode, die angibt, ob die Erweiterung entladen werden kann. Wenn in der Erweiterung noch LIVE-COM-Objekte vorhanden sind, muss dies angegeben werden. Dies ist die Entsprechung des Debuggers der DLLCanUnloadNow von COM. Wenn dies den S_FALSE Hinweis auf die Unfähigkeit zum Entladen zurückgibt, kann der Debugger dies später abfragen, um festzustellen, ob ein Entladen sicher ist oder die Erweiterung erneut initialisiert wird, indem DebugExtensionInitialize erneut aufgerufen wird. Die Erweiterung muss darauf vorbereitet sein, beide Pfade zu verarbeiten.
- DebugExtensionUnload-: Eine Methode, die alle endgültigen Bereinigungen vor dem Entladen der DLL ausführt
Bridge Interface: IHostDataModelAccess
Wie bereits erwähnt, erstellt sie beim Aufruf von DebugExtensionInitialize einen Debugclient und erhält Zugriff auf das Datenmodell. Dieser Zugriff wird über eine Brückenschnittstelle zwischen den älteren IDebug*-Schnittstellen von Debugtools für Windows und dem Datenmodell bereitgestellt. Diese Brückenschnittstelle ist "IHostDataModelAccess" und wird wie folgt definiert:
DECLARE_INTERFACE_(IHostDataModelAccess, IUnknown)
{
STDMETHOD(GetDataModel)(_COM_Outptr_ IDataModelManager** manager, _COM_Outptr_ IDebugHost** host) PURE;
}
Die GetDataModel-Methode ist die Methode auf der Brücke-Schnittstelle, die Zugriff auf beide Seiten des Datenmodells bietet: Der Debughost (der untere Rand des Debuggers) wird durch die zurückgegebene IDebugHost-Schnittstelle Ausgedrückt die Hauptkomponente des Datenmodells – der Datenmodell-Manager wird von der zurückgegebenen IDataModelManager-Schnittstelle ausgedrückt.
Debugger-Datenmodell-Systemschnittstellen
des Datenmodellhosts
Das Debuggerdatenmodell ist so konzipiert, dass es sich um ein komponentenisiertes System handelt, das in verschiedenen Kontexten gehostet werden kann. Normalerweise wird das Datenmodell im Kontext einer Debuggeranwendung gehostet. Um ein Host des Datenmodells zu sein, müssen eine Reihe von Schnittstellen implementiert werden, um kernige Aspekte des Debuggers verfügbar zu machen: seine Zielbestimmung, ihre Speicherplätze, ihr Evaluator, ihr symbolisches und Typsystem usw. Während diese Schnittstellen von jeder Anwendung implementiert werden, die das Datenmodell hosten möchte, werden sie sowohl vom Kerndatenmodell als auch von jeder Erweiterung genutzt, die mit dem Datenmodell interagiert.
Das Typsystem und die symbolischen Schnittstellen sind:
| Schnittstellenname | BESCHREIBUNG |
|---|---|
| IDebugHostSymbols | Kernschnittstelle, die Zugriff auf und Auflösung von Symbolen bietet |
| IDebugHostSymbol / IDebugHostSymbol2 | Stellt ein einzelnes Symbol beliebiger Art dar. Das bestimmte Symbol ist eine Ableitung dieser Schnittstelle. |
| IDebugHostModule | Stellt ein modul dar, das in einem Prozess geladen wurde. Dies ist eine Art von Symbol. |
| IDebugHostType / IDebugHostType2 | Stellt einen systemeigenen/spracheigenen Typ dar. |
| IDebugHostConstant | Stellt eine Konstante innerhalb symbolischer Informationen dar (z. B. ein Argument ohne Typvorlage in C++) |
| IDebugHostField | Stellt ein Feld innerhalb einer Struktur oder Klasse dar. |
| IDebugHostData | Stellt Daten innerhalb eines Moduls dar (wäre dies innerhalb einer Struktur oder Klasse, wäre es ein IDebugHostField) |
| IDebugHostBaseClass | Stellt eine Basisklasse dar. |
| IDebugHostPublic | Stellt ein Symbol in der öffentlichen Tabelle eines PDB dar. Dies enthält keine Typinformationen, die ihr zugeordnet sind. Es handelt sich um einen Namen und eine Adresse. |
| IDebugHostModuleSignature | Stellt eine Modulsignatur dar – eine Definition, die mit einer Gruppe von Modulen nach Name und/oder Version übereinstimmt. |
| IDebugHostTypeSignature | Stellt eine Typsignatur dar – eine Definition, die einem Satz von Typen nach Modul und/oder Name entspricht. |
Die anderen Kernschnittstellen sind:
| Schnittstellenname | BESCHREIBUNG |
|---|---|
| IDebugHost | Die Kernschnittstelle für den Debughost. |
| IDebugHostStatus | Eine Schnittstelle, über die ein Client den Status des Hosts abfragen kann. |
| IDebugHostContext | Eine Abstraktion eines Kontexts innerhalb des Hosts (z. B. ein bestimmtes Ziel, ein bestimmter Prozess, ein bestimmter Adressraum usw....) |
| IDebugHostErrorSink | Eine Schnittstelle, die von Aufrufern implementiert wird, um Fehler aus bestimmten Teilen des Host- und Datenmodells zu erhalten |
| IDebugHostEvaluator / IDebugHostEvaluator2 | Der Auswertungsauswert des Debughosts. |
| IDebugHostExtensibility | Eine Schnittstelle zum Erweitern der Funktionen des Hosts oder teile davon (z. B. der Ausdrucksauswertung). |
Die symbolische Hauptschnittstelle: IDebugHostSymbols
Die IDebugHostSymbols-Schnittstelle ist der Hauptstartpunkt für den Zugriff auf Symbole im Debugziel. Diese Schnittstelle kann von einer Instanz von IDebugHost abgefragt werden und wird wie folgt definiert:
DECLARE_INTERFACE_(IDebugHostSymbols, IUnknown)
{
STDMETHOD(CreateModuleSignature)(_In_z_ PCWSTR pwszModuleName, _In_opt_z_ PCWSTR pwszMinVersion, _In_opt_z_ PCWSTR pwszMaxVersion, _Out_ IDebugHostModuleSignature** ppModuleSignature) PURE;
STDMETHOD(CreateTypeSignature)(_In_z_ PCWSTR signatureSpecification, _In_opt_ IDebugHostModule* module, _Out_ IDebugHostTypeSignature** typeSignature) PURE;
STDMETHOD(CreateTypeSignatureForModuleRange)(_In_z_ PCWSTR signatureSpecification, _In_z_ PCWSTR moduleName, _In_opt_z_ PCWSTR minVersion, _In_opt_z_ PCWSTR maxVersion, _Out_ IDebugHostTypeSignature** typeSignature) PURE;
STDMETHOD(EnumerateModules)(_In_ IDebugHostContext* context, _COM_Outptr_ IDebugHostSymbolEnumerator** moduleEnum) PURE;
STDMETHOD(FindModuleByName)(_In_ IDebugHostContext* context, _In_z_ PCWSTR moduleName, _COM_Outptr_ IDebugHostModule **module) PURE;
STDMETHOD(FindModuleByLocation)(_In_ IDebugHostContext* context, _In_ Location moduleLocation, _COM_Outptr_ IDebugHostModule **module) PURE;
STDMETHOD(GetMostDerivedObject)(_In_opt_ IDebugHostContext *pContext, _In_ Location location, _In_ IDebugHostType* objectType, _Out_ Location* derivedLocation, _Out_ IDebugHostType** derivedType) PURE;
}
Die CreateModuleSignature-Methode erstellt eine Signatur, die verwendet werden kann, um eine Gruppe bestimmter Module anhand des Namens und optional nach Version abzugleichen. Es gibt drei Komponenten für eine Modulsignatur:
- A name: a matching module must have a name which is an exact case insensitive match against the name in the signature
- Eine Mindestversion: Wenn angegeben, muss ein übereinstimmende Modul mindestens eine Mindestversion aufweisen, die mindestens so hoch ist wie diese Version. Versionen werden im Format "A.B.C.D" angegeben, wobei jeder nachfolgende Teil weniger wichtig als der vorherige Teil ist. Nur das erste Segment ist obligatorisch.
- Eine maximale Version: Wenn angegeben, muss ein übereinstimmende Modul eine maximale Version aufweisen, die nicht höher als diese Version ist. Versionen werden im Format "A.B.C.D" angegeben, wobei jeder nachfolgende Teil weniger wichtig als der vorherige Teil ist. Nur das erste Segment ist obligatorisch.
Die CreateTypeSignature-Methode erstellt eine Signatur, die verwendet werden kann, um einer Gruppe konkreter Typen zuzuordnen, indem sie Modul- und Typname enthält. Das Format der Typnamensignaturzeichenfolge ist spezifisch für die zu debuggende Sprache (und debughost). Bei C/C++ entspricht die Signaturzeichenfolge einer NatVis-Typspezifikation. Das heißt, die Signaturzeichenfolge ist ein Typname, bei dem Für Vorlagenargumente Wildcards (angegeben als *) zulässig sind.
CreateTypeSignatureForModuleRange-
Die CreateTypeSignatureForModuleRange-Methode erstellt eine Signatur, die verwendet werden kann, um einer Gruppe konkreter Typen nach Modulsignatur und Typnamen zuzuordnen. Dies ähnelt der CreateTypeSignature-Methode, mit der Ausnahme, dass der Aufrufer die argumente übergibt, die zum Erstellen einer Modulsignatur erforderlich sind (als ob die Modulsignatur mit der CreateModuleSignature-Methode erstellt wurde).
Die EnumerateModules-Methode erstellt einen Enumerator, der jedes Modul aufzählt, das in einem bestimmten Hostkontext verfügbar ist. Dieser Hostkontext kann einen Prozesskontext kapseln, oder er kapselt etwas wie den Windows-Kernel.
Die FindModuleByName-Methode durchsieht den angegebenen Hostkontext und sucht ein Modul mit dem angegebenen Namen und gibt eine Schnittstelle zurück. Es ist legal, nach dem Modul anhand des Namens mit oder ohne die Dateierweiterung zu suchen.
Die FindModuleByLocation-Methode durchsucht den angegebenen Hostkontext und bestimmt, welches Modul die Adresse des angegebenen Speicherorts enthält. Anschließend wird eine Schnittstelle zu diesem Modul zurückgegeben.
Das GetMostDerivedObject verwendet das Typsystem des Debuggers, um den Laufzeittyp eines Objekts vom statischen Typ zu bestimmen. Diese Methode verwendet nur symbolische Informationen und Heuristiken, die auf der Typsystemebene verfügbar sind, um diese Analyse durchzuführen. Solche Informationen können C++ RTTI (Laufzeittypinformationen) oder die Analyse der Form der virtuellen Funktionstabellen des Objekts enthalten. Es enthält keine Elemente wie das bevorzugte Laufzeittypkonzept für ein IModelObject. Wenn die Analyse keinen Laufzeittyp finden kann oder einen Laufzeittyp nicht finden kann, der vom statischen Typ unterscheidet, der an die Methode übergeben wird, wird möglicherweise der Eingabespeicherort und -typ übergeben. Die Methode schlägt aus diesen Gründen nicht fehl.
die Zentrale individuelle Symbolschnittstelle: IDebugHostSymbol
Jedes Symbol, das vom Datenmodellhost zurückgegeben werden kann, wird auf irgendeine Weise von IDebugHostSymbol abgeleitet. Dies ist die Kernschnittstelle, die jedes Symbol unabhängig von der Art des Symbols implementiert. Je nach Art des Symbols kann ein bestimmtes Symbol eine Reihe anderer Schnittstellen implementieren, die Attribute für die bestimmte Art von Symbol zurückgeben, die durch diese Schnittstelle dargestellt werden. Die IDebugHostSymbol2 /IDebugHostSymbol-Schnittstelle wird wie folgt definiert:
DECLARE_INTERFACE_(IDebugHostSymbol2, IDebugHostSymbol)
{
//
// IDebugHostSymbol:
//
STDMETHOD(GetContext)(_COM_Outptr_ IDebugHostContext** context) PURE;
STDMETHOD(EnumerateChildren)(_In_ SymbolKind kind, _In_opt_z_ PCWSTR name, _Out_ IDebugHostSymbolEnumerator **ppEnum) PURE;
STDMETHOD(GetSymbolKind)(_Out_ SymbolKind *kind) PURE;
STDMETHOD(GetName)(_Out_ BSTR* symbolName) PURE;
STDMETHOD(GetType)(_Out_ IDebugHostType** type) PURE;
STDMETHOD(GetContainingModule)(_Out_ IDebugHostModule **containingModule) PURE;
STDMETHOD(CompareAgainst)(_In_ IDebugHostSymbol *pComparisonSymbol, _In_ ULONG comparisonFlags, _Out_ bool *pMatches) PURE;
//
// IDebugHostSymbol2
//
STDMETHOD(EnumerateChildrenEx)(_In_ SymbolKind kind, _In_opt_z_ PCWSTR name, _In_opt_ SymbolSearchInfo* searchInfo, _Out_ IDebugHostSymbolEnumerator **ppEnum) PURE;
}
Es ist sehr wichtig zu beachten, dass diese Schnittstelle viele Arten von Symbolen darstellt - durch die SymbolKind-Aufzählung, die Werte wie folgt enthält:
| Enumarant | Bedeutung |
|---|---|
| Symbol | Nicht angegebener Symboltyp |
| SymbolModule | Das Symbol ist ein Modul und kann für IDebugHostModule abgefragt werden. |
| SymbolType | Das Symbol ist ein Typ und kann für IDebugHostType abgefragt werden. |
| SymbolField | Das Symbol ist ein Feld (ein Datenelement innerhalb einer Struktur oder Klasse) und kann nach IDebugHostField abgefragt werden. |
| SymbolConstant | Das Symbol ist ein konstanter Wert und kann für IDebugHostConstant abgefragt werden. |
| SymbolData | Das Symbol ist Daten, die kein Element einer Struktur oder Klasse sind und für IDebugHostData abfragbar sind. |
| SymbolBaseClass | Das Symbol ist eine Basisklasse und kann für IDebugHostBaseClass abfragt werden. |
| SymbolPublic | Das Symbol ist ein Eintrag in der öffentlichen Tabelle eines Moduls (ohne Typinformationen) und ist für IDebugHostPublic abfragbar. |
| SymbolFunction | Das Symbol ist eine Funktion und kann für IDebugHostData abfragt werden. |
Die GetContext-Methode gibt den Kontext zurück, in dem das Symbol gültig ist. Dies stellt zwar Elemente wie das Debugziel und den Prozess-/Adressraum dar, in dem das Symbol vorhanden ist, aber möglicherweise nicht so spezifisch wie ein Kontext, der aus anderen Mitteln abgerufen wird (z. B. aus einem IModelObject).
Die EnumerateChildren-Methode gibt einen Enumerator zurück, der alle untergeordneten Elemente eines bestimmten Symbols aufzählt. Bei einem C++-Typ werden z. B. die Basisklassen, Felder, Memberfunktionen und ähnliches als untergeordnete Elemente des Typsymbols betrachtet.
Modulschnittstelle: IDebugHostModule
Das Konzept eines Moduls, das innerhalb eines Adressraums geladen wird, wird im Datenmodell auf zwei verschiedene Arten dargestellt: Auf Der Systemebene des Typs über die IDebugHostModule-Schnittstelle. Hier ist ein Modul ein Symbol und kernattribute des Moduls sind Schnittstellenmethodenaufrufe, die über das Debugger.Models.Module-Datenmodell auf Datenmodellebene projiziert werden. Dies ist eine erweiterbare Kapselung der Typsystem-IDebugHostModule-Darstellung eines Moduls.
Die IDebugHostModule-Schnittstelle wird wie folgt definiert (methoden ignorieren, die generisch für IDebugHostSymbol sind):
DECLARE_INTERFACE_(IDebugHostModule, IDebugHostSymbol)
{
//
// IDebugHostModule:
//
STDMETHOD(GetImageName)(_In_ bool allowPath, _Out_ BSTR* imageName) PURE;
STDMETHOD(GetBaseLocation)(_Out_ Location* moduleBaseLocation) PURE;
STDMETHOD(GetVersion)(_Out_opt_ ULONG64* fileVersion, _Out_opt_ ULONG64* productVersion) PURE;
STDMETHOD(FindTypeByName)(_In_z_ PCWSTR typeName, _Out_ IDebugHostType** type) PURE;
STDMETHOD(FindSymbolByRVA)(_In_ ULONG64 rva, _Out_ IDebugHostSymbol** symbol) PURE;
STDMETHOD(FindSymbolByName)(_In_z_ PCWSTR symbolName, _Out_ IDebugHostSymbol** symbol) PURE;
}
Die GetImageName-Methode gibt den Bildnamen des Moduls zurück. Abhängig vom Wert des AllowPath-Arguments kann der zurückgegebene Bildname den vollständigen Pfad zum Bild enthalten.
Die GetBaseLocation-Methode gibt die Basisladeadresse des Moduls als Standortstruktur zurück. Die zurückgegebene Standortstruktur für ein Modul verweist in der Regel auf eine virtuelle Adresse.
Die GetVersion-Methode gibt Versionsinformationen zum Modul zurück (vorausgesetzt, dass solche Informationen erfolgreich aus den Headern gelesen werden können). Wenn eine bestimmte Version angefordert wird (über einen Nicht-Nullptr-Ausgabezeiger) und nicht gelesen werden kann, wird ein entsprechender Fehlercode vom Methodenaufruf zurückgegeben.
Die FindTypeByName-Methode findet einen Typ, der innerhalb des Moduls durch den Typnamen definiert ist, und gibt ein Typsymbol dafür zurück. Diese Methode kann einen gültigen IDebugHostType zurückgeben, der niemals über explizite Rekursion von untergeordneten Elementen des Moduls zurückgegeben wird. Der Debughost kann die Erstellung von abgeleiteten Typen ermöglichen – Typen, die nicht jemals innerhalb des Moduls selbst verwendet werden, sondern von Typen abgeleitet sind. Wenn die Struktur "MyStruct" beispielsweise in den Symbolen des Moduls definiert ist, der Typ "MyStruct **" jedoch nie verwendet wird, gibt die FindTypeByName-Methode möglicherweise legitimerweise ein Typsymbol für MyStruct ** zurück, obwohl dieser Typname nie explizit in den Symbolen für das Modul angezeigt wird.
Die FindSymbolByRVA-Methode findet ein einzelnes übereinstimmende Symbol an der angegebenen relativen virtuellen Adresse innerhalb des Moduls. Wenn an der angegebenen RVA kein einzelnes Symbol vorhanden ist (z. B. gibt es mehrere Übereinstimmungen), wird von dieser Methode ein Fehler zurückgegeben. Beachten Sie, dass diese Methode lieber ein privates Symbol über ein Symbol in der öffentlichen Tabelle zurückgibt.
Die FindSymbolByName-Methode findet ein einzelnes globales Symbol des angegebenen Namens innerhalb des Moduls. Wenn kein einzelnes Symbol vorhanden ist, das dem angegebenen Namen entspricht, wird von dieser Methode ein Fehler zurückgegeben. Beachten Sie, dass diese Methode lieber ein privates Symbol über ein Symbol in der öffentlichen Tabelle zurückgibt.
Zugriff auf das Typsystem: IDebugHostType2 / IDebugHostType
Eine bestimmte Sprache/systemeigener Typ wird durch die IDebugHostType2- oder IDebugHostType-Schnittstellen beschrieben. Beachten Sie, dass einige der Methoden für diese Schnittstellen nur für bestimmte Typen gelten. Ein bestimmtes Typsymbol kann auf einen der folgenden Typen verweisen, wie in der TypeKind-Aufzählung beschrieben:
| Typart | BESCHREIBUNG |
|---|---|
| TypeUDT | Ein benutzerdefinierter Typ (eine Struktur, Klasse, Vereinigung usw.). Ein Modellobjekt mit einem systemeigenen Typ, dessen Art TypeUDT ist, verfügt über eine kanonische Darstellung von ObjectTargetObject, in dem der Typ immer innerhalb des entsprechenden IModelObjects gespeichert wird. |
| TypePointer | Ein Zeiger. Ein Modellobjekt mit einem systemeigenen Typ, dessen Art TypePointer ist, weist eine kanonische Darstellung von ObjectIntrinsic auf, wobei der Wert des Zeigers auf VT_UI8 erweitert und als systeminterne Daten in diesem 64-Bit-Formular beibehalten wird. Jedes Typsymbol von TypePointer weist einen Basistyp (wie von der GetBaseType-Methode zurückgegeben) des Typs auf, auf den der Zeiger zeigt. |
| TypeMemberPointer | Ein Zeiger auf das Klassenelement. Ein Modellobjekt mit einem systemeigenen Typ, dessen Art TypeMemberPointer ist, hat eine kanonische Darstellung, die systemintern ist (der Wert, der dem Zeigerwert entspricht). Die genaue Bedeutung dieses Werts ist compiler-/debughostspezifisch. |
| TypeArray | Ein Array. Ein Modellobjekt mit einem systemeigenen Typ, dessen Art TypeArray ist, weist eine kanonische Darstellung von ObjectTargetObject auf. Die Basisadresse des Arrays ist die Position des Objekts (abgerufen über die GetLocation-Methode), und der Typ des Arrays wird immer beibehalten. Jedes Typsymbol von TypeArray weist einen Basistyp (wie von der GetBaseType-Methode zurückgegeben) des Typs auf, von dem das Array ein Array ist. |
| TypeFunction | Eine Funktion. |
| TypeTypedef | Ein Typedef. Ein Modellobjekt mit einem systemeigenen Typ, dessen Art andernfalls TypeTypedef sein würde, weist eine kanonische Darstellung auf, die mit der kanonischen Darstellung des letzten Typs identisch ist, der dem Typedef zugrunde liegt. Dies erscheint für den Endbenutzer des Objekts vollständig transparent und die Typinformationen, es sei denn, die expliziten Typedef-Methoden von IDebugHostType2 werden verwendet, um Typedef-Informationen abzufragen, oder es gibt ein explizites Datenmodell, das für den Typedef registriert ist. Beachten Sie, dass die GetTypeKind-Methode niemals TypeTypedef zurückgibt. Jede Methode gibt den endgültigen Typ zurück, der dem Typedef zugrunde liegt. Es gibt typedef spezifische Methoden für IDebugHostType2, mit denen die typedef-spezifischen Informationen abgerufen werden können. |
| TypeEnum | Eine Enumeration. Ein Modellobjekt mit einem systemeigenen Typ, dessen Art TypeEnum ist, weist eine kanonische Darstellung von ObjectIntrinsic auf, wobei der Wert und der Typ des systeminternen Werts mit dem Enumerationswert identisch sind. |
| TypeIntrinsic | Ein systeminterner (Basistyp). Ein Modellobjekt mit einem systemeigenen Typ, dessen Art TypeIntrinsic ist, weist eine kanonische Darstellung von ObjectIntrinsic auf. Die Typinformationen können beibehalten werden – insbesondere, wenn der zugrunde liegende Typ vollständig vom Variant-Datentyp (VT_*) der systeminternen Daten beschrieben wird, die im IModelObject gespeichert sind. |
Die allgemeine IDebugHostType2 /IDebugHostType-Schnittstelle wird wie folgt definiert (ausgenommen IDebugHostSymbol-Methoden):
DECLARE_INTERFACE_(IDebugHostType2, IDebugHostType)
{
//
// IDebugHostType:
//
STDMETHOD(GetTypeKind)(_Out_ TypeKind *kind) PURE;
STDMETHOD(GetSize)(_Out_ ULONG64* size) PURE;
STDMETHOD(GetBaseType)(_Out_ IDebugHostType** baseType) PURE;
STDMETHOD(GetHashCode)(_Out_ ULONG* hashCode) PURE;
STDMETHOD(GetIntrinsicType)(_Out_opt_ IntrinsicKind *intrinsicKind, _Out_opt_ VARTYPE *carrierType) PURE;
STDMETHOD(GetBitField)(_Out_ ULONG* lsbOfField, _Out_ ULONG* lengthOfField) PURE;
STDMETHOD(GetPointerKind)(_Out_ PointerKind* pointerKind) PURE;
STDMETHOD(GetMemberType)(_Out_ IDebugHostType** memberType) PURE;
STDMETHOD(CreatePointerTo)(_In_ PointerKind kind, _COM_Outptr_ IDebugHostType** newType) PURE;
STDMETHOD(GetArrayDimensionality)(_Out_ ULONG64* arrayDimensionality) PURE;
STDMETHOD(GetArrayDimensions)(_In_ ULONG64 dimensions, _Out_writes_(dimensions) ArrayDimension *pDimensions) PURE;
STDMETHOD(CreateArrayOf)(_In_ ULONG64 dimensions, _In_reads_(dimensions) ArrayDimension *pDimensions, _COM_Outptr_ IDebugHostType** newType) PURE;
STDMETHOD(GetFunctionCallingConvention)(_Out_ CallingConventionKind* conventionKind) PURE;
STDMETHOD(GetFunctionReturnType)(_COM_Outptr_ IDebugHostType** returnType) PURE;
STDMETHOD(GetFunctionParameterTypeCount)(_Out_ ULONG64* count) PURE;
STDMETHOD(GetFunctionParameterTypeAt)(_In_ ULONG64 i, _Out_ IDebugHostType** parameterType) PURE;
STDMETHOD(IsGeneric)(_Out_ bool* isGeneric) PURE;
STDMETHOD(GetGenericArgumentCount)(_Out_ ULONG64* argCount) PURE;
STDMETHOD(GetGenericArgumentAt)(_In_ ULONG64 i, _Out_ IDebugHostSymbol** argument) PURE;
//
// IDebugHostType2:
//
STDMETHOD(IsTypedef)(_Out_ bool* isTypedef) PURE;
STDMETHOD(GetTypedefBaseType)(_Out_ IDebugHostType2** baseType) PURE;
STDMETHOD(GetTypedefFinalBaseType)(_Out_ IDebugHostType2** finalBaseType) PURE;
STDMETHOD(GetFunctionVarArgsKind)(_Out_ VarArgsKind* varArgsKind) PURE;
}
IDebugHostType2/IDebugHostType General Methods
Die folgenden IDebugHostType-Methoden sind für jeden Typ allgemein, unabhängig davon, welche Art von der GetTypeKind-Methode zurückgegeben wird:
STDMETHOD(GetTypeKind)(_Out_ TypeKind *kind) PURE;
STDMETHOD(GetSize)(_Out_ ULONG64* size) PURE;
STDMETHOD(GetBaseType)(_Out_ IDebugHostType** baseType) PURE;
STDMETHOD(GetHashCode)(_Out_ ULONG* hashCode) PURE;
Die GetTypeKind-Methode gibt die Art des Typs (Zeiger, Array, systemintern usw.) zurück, auf die sich das Symbol bezieht.
Die GetSize-Methode gibt die Größe des Typs zurück (so, als ob eine größeof(type) in C++ durchgeführt wurde).
Wenn es sich bei dem Typ um eine Ableitung eines anderen einzelnen Typs handelt (z. B. als MyStruct * abgeleitet von MyStruct'), gibt die GetBaseType-Methode den Basistyp der Ableitung zurück. Bei Zeigern gibt dies den Typ zurück, auf den verwiesen wird. Bei Arrays gibt dies zurück, was das Array ein Array ist. Wenn der Typ kein solcher abgeleiteter Typ ist, wird ein Fehler zurückgegeben.
Die GetHashCode-Methode gibt einen 32-Bit-Hashcode für den Typ zurück. Mit Ausnahme einer globalen Übereinstimmung (z. B. eine Typsignatur, die * entspricht, die mit allen Elementen übereinstimmt, die vom Host zulässig sind), muss jede Typinstanz, die einer bestimmten Typsignatur entsprechen kann, denselben Hashcode zurückgeben. Diese Methode wird in Verbindung mit Typsignaturen verwendet, um Typsignaturen mit Typinstanzen abzugleichen.
IDebugHostType2/IDebugHostType Systeminterne Methoden
Die folgenden IDebugHostType-Methoden sind spezifisch für systeminterne Typen (oder Typen, die systeminterne Daten enthalten, z. B. Enumerationen):
STDMETHOD(GetIntrinsicType)(_Out_opt_ IntrinsicKind *intrinsicKind, _Out_opt_ VARTYPE *carrierType) PURE;
Die GetIntrinsicType-Methode gibt Informationen darüber zurück, welche Art systemintern der Typ ist. Aus dieser Methode werden zwei Werte zurückgegeben:
- Die systeminterne Art gibt den Gesamttyp an (z. B. ganze Zahl, nicht signiert, Gleitkomma), aber nicht die Größe des Typs (z. B. 8 Bit, 16 Bit, 32 Bit, 64 Bit)
- Der Trägertyp gibt an, wie die systeminternen Typen in eine VARIANT-Struktur packen. Dies ist eine VT_*-Konstante.
Die Kombination der beiden Werte stellt den vollständigen Satz von Informationen über das systeminterne System bereit.
IDebugHostType2/IDebugHostType Bitfield-Methoden
Die folgenden IDebugHostType-Methoden sind spezifisch für Typen, die Daten in Bitfeldern speichern. Informationen zur Bitfeldplatzierung in einem systeminternen Element werden als Teil des Typsymbols im Datenmodell gespeichert, anstatt ein Attribut des Speicherorts zu sein.
STDMETHOD(GetBitField)(_Out_ ULONG* lsbOfField, _Out_ ULONG* lengthOfField) PURE;
Wenn ein bestimmtes Element einer Datenstruktur ein Bitfeld ist (z. B. ULONG MyBits:8), enthält die Typinformationen für das Feld Informationen zur Bitfeldplatzierung. Die GetBitField-Methode kann verwendet werden, um diese Informationen abzurufen. Diese Methode schlägt für jeden Typ fehl, der kein Bitfeld ist. Dies ist der einzige Grund, warum die Methode fehlschlägt. Das Einfache Aufrufen dieser Methode und das Betrachten von Erfolg/Fehler reicht aus, um ein Bitfeld von einem Nicht-Bit-Feld zu unterscheiden. Wenn ein bestimmter Typ ein Bitfeld ist, werden die Feldpositionen durch den halb geöffneten Satz definiert (lsbOfField + lengthOfField : lsbOfField]
IDebugHostType2/IDebugHostType Pointer Related Methods
Die folgenden IDebugHostType-Methoden sind spezifisch für Zeigertypen. Dies sind Typen, bei denen GetTypeKind TypePointer oder TypeMemberPointer zurückgibt:
STDMETHOD(GetPointerKind)(_Out_ PointerKind* pointerKind) PURE;
STDMETHOD(GetMemberType)(_Out_ IDebugHostType** memberType) PURE;
Bei Zeigertypen gibt die GetPointerKind-Methode die Art des Zeigers zurück. Dies wird durch die PointerKind-Aufzählung definiert.
Bei Typen, die Zeiger-zu-Member sind (wie durch eine Typart von TypeMemberPointer angegeben), gibt die GetMemberType-Methode die Klasse zurück, der der Zeiger ein Zeiger-zu-Member ist.
IDebugHostType2/IDebugHostType Array Related Methods
Arrays sind Typen, bei denen GetTypeKind TypeArray zurückgibt. Beachten Sie, dass Arrays, die vom Typsystem des Debughosts definiert sind, nicht mit dem eindimensionalen, nullindexbasierten, linearen eindimensionalen Arrays identisch sind, die C verwendet. C-Stilarrays passen in die Definition, aber der Gesamtumfang eines Arrays ist in IDebugHostType breiter. Ein Array im Debughost kann mehrdimensional sein, und jede Dimension innerhalb des Arrays wird durch einen Deskriptor definiert, der als ArrayDimensionThis-Deskriptor bezeichnet wird, die folgenden Felder aufweist:
| Feld | Bedeutung |
|---|---|
| Untergrenze | Der Basisindex des Arrays als signierter 64-Bit-Wert. Bei einem C-Stilarray ist dies immer null. Es muss nicht sein. Eine einzelne Dimension eines Arrays kann als Start bei einem beliebigen 64-Bit-Index betrachtet werden, sogar als negative. |
| Länge | Die Länge der Arraydimension als nicht signierter 64-Bit-Wert. Die Indicies des Arrays umfassen den halb geöffneten Satz [LowerBound, LowerBound + Length). |
| Schritt | Definiert den Schritt der Arraydimension. Für eine Erhöhung eines (von N auf N + 1) im Index dieser Dimension gibt dies an, wie viele Bytes im Arbeitsspeicher vorwärts verschoben werden sollen. Bei einem C-Formatarray wäre dies die Größe jedes Elements des Arrays. Es muss nicht sein. Der Abstand zwischen Elementen kann als Schritt größer als die Größe jedes einzelnen Elements ausgedrückt werden. Bei mehrdimensionalen Arrays würde dieser Wert angeben, wie eine gesamte Dimension vorwärts verschoben werden soll. Betrachten Sie eine M x N-Matrix. Dies kann in Zeilen-Hauptform als zwei Dimensionen beschrieben werden: |
{ [LowerBound: 0, Length: M, Stride: N \* sizeof(element)], [LowerBound: 0, Length: N, Stride: sizeof(element)]}
oder es kann alternativ in Spalten-Hauptform als zwei Dimensionen beschrieben werden:
{ [LowerBound: 0, Length: M, Stride: sizeof(element)], [LowerBound: 0, Length: N, Stride: M \* sizeof(element)]}
Das ArrayDimension-Konzept ermöglicht dieses Maß an Flexibilität.
Die folgenden IDebugHostType-Methoden sind spezifisch für Arraytypen.
STDMETHOD(GetArrayDimensionality)(\_Out_ ULONG64\* arrayDimensionality) PURE;
STDMETHOD(GetArrayDimensions)(\_In_ ULONG64 dimensions, \_Out_writes_(dimensions) ArrayDimension \*pDimensions) PURE;
Die GetArrayDimensionality-Methode gibt die Anzahl der Dimensionen zurück, in denen das Array indiziert ist. Bei C-Stilarrays ist der hier zurückgegebene Wert immer 1.
Die GetArrayDimensions-Methode gibt einen Satz von Deskriptoren zurück, eine für jede Dimension des Arrays, wie durch die GetArrayDimensionality-Methode angegeben. Jeder Deskriptor ist eine ArrayDimension-Struktur, die den Anfangsindex, die Länge und den Vorwärtsschritt jeder Arraydimension beschreibt. Dies ermöglicht Beschreibungen deutlich leistungsstärkerer Arraykonstrukte als im C-Typsystem zulässig sind.
Bei Arrays im C-Stil wird hier eine einzelne Arraydimension mit Werten zurückgegeben, die immer sind:
- LowerBound = 0
- Length = ARRAYSIZE(array)
- Stride = sizeof(elementType)
IDebugHostType2/IDebugHostType Function Related Methods
Typen, die angeben, dass sie Funktionstypen über eine Art von TypeFunction sind, unterstützen die folgenden Methoden in IDebugHostType und IDebugHostType2.
//
// IDebugHostType:
//
STDMETHOD(GetFunctionCallingConvention)(_Out_ CallingConventionKind* conventionKind) PURE;
STDMETHOD(GetFunctionReturnType)(_COM_Outptr_ IDebugHostType** returnType) PURE;
STDMETHOD(GetFunctionParameterTypeCount)(_Out_ ULONG64* count) PURE;
STDMETHOD(GetFunctionParameterTypeAt)(_In_ ULONG64 i, _Out_ IDebugHostType** parameterType) PURE;
//
// IDebugHostType2:
//
STDMETHOD(GetFunctionVarArgsKind)(_Out_ VarArgsKind* varArgsKind) PURE;
Die GetFunctionCallingConvention-Methode gibt die aufrufende Konvention der Funktion zurück. Diese wird als Mitglied der CallingConventionKind-Aufzählung zurückgegeben.
Die GetFunctionReturnType-Methode gibt den Rückgabetyp der Funktion zurück.
GetFunctionParameterTypeCount-
Die GetFunctionParameterTypeCount-Methode gibt die Anzahl der Argumente zurück, die die Funktion verwendet. Beachten Sie, dass die C/C++-ellipsenbasierte Variablenargumentmarkierung in dieser Anzahl nicht berücksichtigt wird. Das Vorhandensein einer solchen muss über die GetFunctionVarArgsKind-Methode erkannt werden. Dies schließt nur Argumente vor den Auslassungspunkten ein.
Die GetFunctionParameterTypeAt-Methode gibt den Typ des i-th-Arguments an die Funktion zurück.
Die GetFunctionVarArgsKind-Methode gibt zurück, ob eine bestimmte Funktion eine Variablenargumentliste verwendet, und wenn ja, welche Art von Variablenargumenten sie verwendet. Dies wird durch ein Element der VarArgsKind-Aufzählung definiert wie folgt:
| Aufzählung | Bedeutung |
|---|---|
| VarArgsNone | Die Funktion verwendet keine variablen Argumente. |
| VarArgsCStyle | Die Funktion ist eine Varargs-Funktion im C-Stil (returnType(arg1, arg2, ...)). Die Anzahl der argumente, die von der Funktion gemeldet werden, enthält nicht das Auslassungszeichen-Argument. Jedes variable Argument, das übergeben wird, tritt nach der Anzahl der Argumente auf, die von der GetFunctionParameterTypeCount-Methode zurückgegeben werden. |
IDebugHostType2 GetFunctionVarArgsKind
Die GetFunctionVarArgsKind-Methode gibt zurück, ob eine bestimmte Funktion eine Variablenargumentliste verwendet, und wenn ja, welche Art von Variablenargumenten sie verwendet. Dies wird durch ein Element der VarArgsKind-Aufzählung definiert wie folgt:
IDebugHostType2/IDebugHostType Typedef Related Methods
Jeder Typ, bei dem es sich um einen Typedef handelt, verhält sich so, als ob es sich bei dem Typ um den endgültigen Typ handelt, der dem Typedef zugrunde liegt. Dies bedeutet, dass Methoden wie GetTypeKind nicht angeben, dass der Typ ein Typedef ist. Ebenso gibt GetBaseType nicht den Typ zurück, auf den sich die Definition bezieht. Sie geben stattdessen das Verhalten an, als ob sie für die endgültige Definition aufgerufen wurden, die dem Typedef zugrunde liegt. Beispiel:
typedef MYSTRUCT *PMYSTRUCT;
typedef PMYSTRUCT PTRMYSTRUCT;
Ein IDebugHostType für "PMYSTRUCT" oder "PTRMYSTRUCT" meldet die folgenden Informationen:
- Die GetTypeKind-Methode gibt TypePointer zurück. Der letzte zugrunde liegende Typ MYSTRUCT * ist tatsächlich ein Zeiger.
- Die 'GetBaseType-Methode gibt einen Typ für MYSTRUCT zurück. Der zugrunde liegende Typ von MYSTRUCT * ist MYSTRUCT.
Der einzige Unterschied hier ist, wie sich die typedef-spezifischen Methoden für IDebugHostType2 verhalten. Diese Methoden sind:
STDMETHOD(IsTypedef)(_Out_ bool* isTypedef) PURE;
STDMETHOD(GetTypedefBaseType)(_Out_ IDebugHostType2** baseType) PURE;
STDMETHOD(GetTypedefFinalBaseType)(_Out_ IDebugHostType2** finalBaseType) PURE;
In diesem Beispiel:
- Die IsTypedef-Methode gibt true für PMYSTRUCT und PTRMYSTRUCT zurück.
- Die GetTypedefBaseType-Methode gibt MYSTRUCT * für PMYSTRUCT und PMYSTRUCT für PTRMYSTRUCT zurück.
- Die GetTypedefFinalBaseType-Methode gibt MYSTRUCT * für beide Typen zurück.
Die IsTypedef-Methode ist die einzige Methode, die erkennen kann, ob ein Typ ein Typedef ist. Die GetTypeKind-Methode verhält sich so, als ob sie für den zugrunde liegenden Typ aufgerufen wird.
Die GetTypedefBaseType-Methode gibt die unmittelbare Definition des Typedef zurück. In den in der Dokumentation beschriebenen Beispielen:
typedef MYSTRUCT *PMYSTRUCT;
typedef PMYSTRUCT PTRMYSTRUCT;
diese Methode gibt MYSTRUCT * für PMYSTRUCT und PMYSTRUCT für PTRMYSTRUCT zurück.
Die GetTypedefFinalBaseType-Methode gibt den endgültigen Typ zurück, für den der Typedef eine Definition ist. Wenn der Typedef eine Definition eines anderen Typedef ist, folgt dies weiterhin der Definitionskette, bis er einen Typ erreicht, der kein Typedef ist und dieser Typ zurückgegeben wird. In den in der Dokumentation beschriebenen Beispielen:
typedef MYSTRUCT *PMYSTRUCT;
typedef PMYSTRUCT PTRMYSTRUCT;
diese Methode gibt MYSTRUCT * zurück, wenn entweder PMYSTRUCT oder PTRMYSTRUCT aufgerufen wird.
IDebugHostType2/IDebugHostType-Typerstellungsmethoden
STDMETHOD(CreatePointerTo)(_In_ PointerKind kind, _COM_Outptr_ IDebugHostType** newType) PURE;
STDMETHOD(CreateArrayOf)(_In_ ULONG64 dimensions, _In_reads_(dimensions) ArrayDimension *pDimensions, _COM_Outptr_ IDebugHostType** newType) PURE;
Konstantensymbolwerte: IDebugHostConstant
Für Orte, an denen Konstantenwerte in symbolischen Informationen vorhanden sind (wobei ein bestimmter Wert ein Symbol ist, das möglicherweise ein konstanter Wert sein kann, gibt die IDebugHostConstant-Schnittstelle den Begriff einer solchen Konstante aus. Dies wird in der Regel an Stellen wie Vorlagenargumenten verwendet, bei denen ein angegebenes Argument in der Regel ein Typ ist, aber stattdessen ein Argument ohne Typvorlage sein kann (z. B. eine Konstante).
Die IDebugHostConstant-Schnittstelle wird wie folgt definiert (ignoriert generische Methoden, die von IDebugHostSymbol implementiert werden):
DECLARE_INTERFACE_(IDebugHostConstant, IDebugHostSymbol)
{
STDMETHOD(GetValue)(_Out_ VARIANT* value) PURE;
}
Die GetValue-Methode gibt den Wert der Konstanten zurück, die in einen VARIANT-Wert verpackt ist. Beachten Sie, dass die GetType-Methode für IDebugHostSymbol möglicherweise ein bestimmtes Typsymbol für die Konstante zurückgibt. In solchen Fällen besteht keine Garantie dafür, dass die Verpackung des konstanten Werts, wie durch das Typsymbol definiert, mit der Verpackung identisch ist wie die Verpackung, die hier von der GetValue-Methode zurückgegeben wird.
Data Member Access: IDebugHostField
Die IDebugHostField-Klasse stellt ein Symbol dar, bei dem es sich um ein Datenelement einer Klasse, einer Struktur, einer Union oder eines anderen Typkonstrukts handelt. Sie stellt keine freien Daten dar (z. B. globale Daten). Die Schnittstelle wird wie folgt definiert (methoden generic to IDebugHostSymbol ignorieren):
DECLARE_INTERFACE_(IDebugHostField, IDebugHostSymbol)
{
STDMETHOD(GetLocationKind)(_Out_ LocationKind *locationKind) PURE;
STDMETHOD(GetOffset)(_Out_ ULONG64* offset) PURE;
STDMETHOD(GetLocation)(_Out_ Location* location) PURE;
STDMETHOD(GetValue)(_Out_ VARIANT* value) PURE;
}
Die GetLocationKind-Methode gibt die Art der Position zurück, an der sich das Symbol gemäß der LocationKind-Aufzählung befindet. Eine solche Aufzählung kann einer der folgenden Werte sein:
| Aufzählung | Bedeutung |
|---|---|
| LocationMember | Das Feld ist ein reguläres Datenelement einer Klasse, Struktur, Vereinigung oder eines anderen Typkonstrukts. Er weist einen Offset auf, der relativ zur Basisadresse des enthaltenden Typkonstrukts ist. Diese Basisadresse wird in der Regel durch diesen Zeiger dargestellt. Der Offset des Felds kann über die GetOffset-Methode abgerufen werden. Die Methoden "GetLocation" und "GetValue" schlagen für ein Feld fehl, das "LocationMember" ist. |
| LocationStatic | Das Feld ist statisch und hat eine eigene Adresse. Die GetLocation-Methode gibt die abstrakte Position (z. B. Adresse) des statischen Felds zurück. Die Methoden "GetOffset" und "GetValue" schlagen für ein Feld fehl, das "LocationStatic" ist. |
| LocationConstant | Das Feld ist eine Konstante und hat einen Wert. Die GetValue-Methode gibt den Wert der Konstante zurück. Die Methoden "GetOffset" und "GetLocation" schlagen für ein Feld fehl, das "LocationConstant" ist. |
| LocationNone | Das Feld hat keine Position. Möglicherweise wurde sie vom Compiler optimiert, oder es handelt sich um ein statisches Feld, das deklariert, aber nie definiert wird. Unabhängig davon, wie ein solches Feld zu sein kam, hat es keine physische Präsenz oder keinen Wert. Sie befindet sich nur in den Symbolen. Alle Kaufmethoden (GetOffset, GetLocation und GetValue) schlagen für ein Feld fehl, das LocationNone ist. |
Bei Feldern, die einen Offset aufweisen (z. B. Felder, deren Positionstyp LocationMember angibt), gibt die GetOffset-Methode den Offset von der Basisadresse des enthaltenden Typs (dem folgenden Zeiger) an die Daten für das Feld selbst zurück. Solche Offsets werden immer als nicht signierte 64-Bit-Werte ausgedrückt. Wenn das angegebene Feld keine Position aufweist, die ein Offset von der Basisadresse des enthaltenden Typs ist, schlägt die GetOffset-Methode fehl.
Bei Feldern, die unabhängig von der jeweiligen Typinstanz eine Adresse haben (z. B. Felder, deren Standorttyp "LocationStatic" angibt), gibt die GetLocation-Methode den abstrakten Speicherort (Adresse) des Felds zurück. Wenn das angegebene Feld keine statische Position hat, schlägt die GetLocation-Methode fehl.
Bei Feldern mit einem konstanten Wert, der innerhalb der symbolischen Informationen definiert ist (z. B. Felder, deren Standorttyp LocationConstant angibt), gibt die GetValue-Methode den Konstantenwert des Felds zurück. Wenn das angegebene Feld keinen Konstantenwert aufweist, schlägt die GetValue-Methode fehl.
Kostenloser Datenzugriff: IDebugHostData
Daten in Modulen, die kein Mitglied eines anderen Typs sind, werden durch die IDebugHostData-Schnittstelle dargestellt. Diese Schnittstelle wird wie folgt definiert (methoden generic to IDebugHostSymbol ignorieren):
DECLARE_INTERFACE_(IDebugHostData, IDebugHostSymbol)
{
STDMETHOD(GetLocationKind)(_Out_ LocationKind *locationKind) PURE;
STDMETHOD(GetLocation)(_Out_ Location* location) PURE;
STDMETHOD(GetValue)(_Out_ VARIANT* value) PURE;
}
Alle diese Methoden entsprechen semantisch ihren Gegenstücken in IDebugHostField. Der einzige Unterschied besteht darin, dass die GetLocationKind-Methode niemals LocationMember für kostenlose Daten zurückgibt.
Die GetLocationKind-Methode gibt die Art der Position zurück, an der sich das Symbol gemäß der LocationKind-Aufzählung befindet. Die Beschreibung dieser Aufzählung finden Sie in der Dokumentation für IDebugHostField.
Für Daten mit einer Adresse gibt die GetLocation-Methode den abstrakten Speicherort (Adresse) des Felds zurück. Wenn die angegebenen Daten keinen statischen Speicherort haben, schlägt die GetLocation-Methode fehl.
Für Daten, für die ein konstanter Wert innerhalb der symbolischen Informationen definiert ist (z. B. Daten, deren Standorttyp LocationConstant angibt), gibt die GetValue-Methode den Konstantenwert des Felds zurück. Wenn die angegebenen Daten keinen Konstantenwert aufweisen, schlägt die GetValue-Methode fehl.
Basisklassen: IDebugHostBaseClass
Die Vererbungshierarchie eines bestimmten Typs wird durch untergeordnete Elemente eines Typsymbols ausgedrückt. Wenn ein bestimmter Typ von einem oder mehreren Typen abgeleitet ist (vererbungsweisen), gibt es mindestens ein untergeordnetes Symbol der Symboltypklasse für den Typ. Jedes dieser SymbolBaseClass-Symbole stellt die sofortige Vererbung von einem bestimmten Typ dar. Der Name der Basisklasse ist sowohl der Name des SymbolBaseClass-Symbols als auch des Typsymbols für die Basisklasse. Die GetType-Methode für das Symbol "SymbolBaseClass" kann verwendet werden, um das Typsymbol für die Basisklasse selbst abzurufen. Die vollständige Vererbungshierarchie kann durchlaufen werden, indem symbolBaseClass untergeordnete Symbole rekursiv untersucht werden. Jede dieser Basisklassensymbole wird durch die IDebugHostBaseClass-Schnittstelle ausgedrückt, die wie folgt definiert ist (ignoring methods generic to IDebugHostSymbol):
DECLARE_INTERFACE_(IDebugHostBaseClass, IDebugHostSymbol)
{
STDMETHOD(GetOffset)(_Out_ ULONG64* offset) PURE;
}
Die GetOffset-Methode gibt den Offset der Basisklasse aus der Basisadresse der abgeleiteten Klasse zurück. Dieser Offset kann null oder ein positiver nicht signierter 64-Bit-Wert sein.
öffentliche Symbole: IDebugHostPublic
Öffentliche Symbole stellen Elemente in der öffentlichen Tabelle in einer Symboldatei dar. Sie sind tatsächlich Exportadressen. Es gibt keine Typinformationen, die einem öffentlichen Symbol zugeordnet sind – nur eine Adresse. Wenn kein öffentliches Symbol explizit vom Aufrufer angefordert wird, bevorzugt der Debughost private Symbole für jede Anfrage zurückzugeben. Ein öffentliches Symbol wird durch die IDebugHostPublic-Schnittstelle ausgedrückt, die wie folgt definiert ist (methoden ignorieren, die generisch für IDebugHostSymbol sind):
DECLARE_INTERFACE_(IDebugHostPublic, IDebugHostSymbol)
{
STDMETHOD(GetLocationKind)(_Out_ LocationKind *locationKind) PURE;
STDMETHOD(GetLocation)(_Out_ Location* location) PURE;
}
Alle diese Methoden entsprechen semantisch ihren Gegenstücken in IDebugHostField. Der einzige Unterschied besteht darin, dass die GetLocationKind-Methode niemals LocationMember oder LocationConstant für solche Symbole zurückgibt.
Die GetLocationKind-Methode gibt die Art der Position zurück, an der sich das Symbol gemäß der LocationKind-Aufzählung befindet. Die Beschreibung dieser Aufzählung finden Sie in der Dokumentation für IDebugHostField.
Für Daten mit einer Adresse gibt die GetLocation-Methode den abstrakten Speicherort (Adresse) des Felds zurück. Wenn die angegebene Öffentliche keinen statischen Speicherort hat, schlägt die GetLocation-Methode fehl.
Modulsignaturen und Versionsabgleich: IDebugHostModuleSignature
Modulsignaturen stellen eine Möglichkeit dar, zu überprüfen, ob ein bestimmtes Modul eine Reihe von Kriterien hinsichtlich Benennung und Versionsverwaltung erfüllt. Eine Modulsignatur wird über die CreateModuleSignature-Methode auf IDebugHostSymbols erstellt. Er kann mit dem Modulnamen und einem optionalen Bereich von Versionsnummern für das Modul übereinstimmen. Sobald eine solche Signatur erstellt wurde, empfängt der Client eine IDebugHostModuleSignature-Schnittstelle, die wie folgt definiert ist:
DECLARE_INTERFACE_(IDebugHostModuleSignature, IUnknown)
{
STDMETHOD(IsMatch)(_In_ IDebugHostModule* pModule, _Out_ bool* isMatch) PURE;
}
Die IsMatch-Methode vergleicht ein bestimmtes Modul (wie durch ein IDebugHostModule-Symbol angegeben) mit einer Signatur, wobei der Modulname und die Version mit dem namen und dem Versionsbereich verglichen werden, der in der Signatur angegeben ist. Ein Hinweis darauf, ob das angegebene Modulsymbol mit der Signatur übereinstimmt, wird zurückgegeben.
Typsignatur und Typabgleich: IDebugHostTypeSignature
Typsignaturen stellen eine Möglichkeit dar, zu überprüfen, ob eine bestimmte Typinstanz eine Reihe von Kriterien zum Namen des Typs, die generischen Argumente für den Typ und das Modul erfüllt, in dem sich der Typ befindet. Eine Typsignatur wird über die CreateTypeSignature-Methode auf IDebugHostSymbols erstellt. Sobald eine solche Signatur erstellt wurde, empfängt der Client eine IDebugHostTypeSignature-Schnittstelle, die wie folgt definiert ist:
DECLARE_INTERFACE_(IDebugHostTypeSignature, IUnknown)
{
STDMETHOD(GetHashCode)(_Out_ ULONG* hashCode) PURE;
STDMETHOD(IsMatch)(_In_ IDebugHostType* type, _Out_ bool* isMatch, _COM_Outptr_opt_ IDebugHostSymbolEnumerator** wildcardMatches) PURE;
STDMETHOD(CompareAgainst)(_In_ IDebugHostTypeSignature* typeSignature, _Out_ SignatureComparison* result) PURE;
}
Die GetHashCode-Methode gibt einen 32-Bit-Hashcode für die Typsignatur zurück. Der Debughost garantiert, dass zwischen dem für Typinstanzen zurückgegebenen Hashcode und dem für Typsignaturen zurückgegebenen Hashcode eine Synchronisierung vorhanden ist. Wenn eine Typinstanz eine Typsignatur abgleichen kann, haben beide mit ausnahme einer globalen Übereinstimmung den gleichen 32-Bit-Hashcode. Dies ermöglicht einen anfänglichen schnellen Vergleich und eine Übereinstimmung zwischen einer Typinstanz und einer Vielzahl von Typsignaturen, die beim Datenmodell-Manager registriert sind.
Die IsMatch-Methode gibt einen Hinweis darauf zurück, ob eine bestimmte Typinstanz den in der Typsignatur angegebenen Kriterien entspricht. Wenn dies der Fall ist, wird ein Hinweis darauf sowie ein Enumerator zurückgegeben, der alle spezifischen Teile der Typinstanz (als Symbole) angibt, die mit Wildcards in der Typsignatur übereinstimmen.
Die CompareAgainst-Methode vergleicht die Typsignatur mit einer anderen Typsignatur und gibt zurück, wie die beiden Signaturen verglichen werden. Das zurückgegebene Vergleichsergebnis ist ein Element der SignatureComparison-Aufzählung, die wie folgt definiert ist:
| Aufzählung | Bedeutung |
|---|---|
| Unverwandt | Es gibt keine Beziehung zwischen den beiden Signaturen oder Typen, die verglichen werden. |
| Zweideutig | Eine Signatur oder ein Typ vergleicht mehrdeutig mit der anderen. Bei zwei Typsignaturen bedeutet dies, dass es potenzielle Typinstanzen gibt, die beide Signaturen gleichermaßen gut abgleichen können. Als Beispiel sind die beiden unten gezeigten Signaturen mehrdeutig. Signatur 1: std::pair<*, int> Signatur 2: std::pair<int,*>, da die Typinstanz std::pair<int, int> beide gleichermaßen übereinstimmen (beide weisen eine konkrete und eine Wildcard-Übereinstimmung auf). |
| LessSpecific | Eine Signatur oder ein Typ ist weniger spezifisch als die andere. Dies bedeutet häufig, dass die weniger spezifische Signatur über einen Wildcard verfügt, bei dem der spezifischere Typ einen konkreten Typ aufweist. Als Beispiel ist die erste Signatur unten weniger spezifisch als die zweite. Signatur 1: std::pair<*, int> Signatur 2: std::pair<int, int>, da sie einen Platzhalter (die *) aufweist, wobei die zweite einen konkreten Typ (Int) aufweist. |
| MoreSpecific | Eine Signatur oder ein Typ ist spezifischer als die andere. Dies bedeutet häufig, dass die spezifischere Signatur einen konkreten Typ aufweist, bei dem die weniger spezifische Signatur einen Wildcard hat. Als Beispiel ist die erste Signatur unten spezifischer als die zweite. Signatur 1: std::pair<int, int> Signatur 2: std::pair<*, int>, da sie einen konkreten Typ (int) aufweist, wobei die zweite einen Platzhalter (die *) aufweist. |
| Identisch | Die beiden Signaturen oder Typen sind identisch. |
Siehe auch
Dieses Thema ist Teil einer Reihe, in der die von C++ zugänglichen Schnittstellen beschrieben werden, wie sie zum Erstellen einer C++-basierten Debuggererweiterung und zur Verwendung anderer Datenmodellkonstrukte (z. B. JavaScript oder NatVis) aus einer C++-Datenmodellerweiterung verwendet werden.
Debuggerdatenmodell C++-Übersicht
Debugger-Datenmodell-C++-Objekte
Debuggerdatenmodell C++ zusätzliche Schnittstellen