Debuggerdatenmodell-C++-Schnittstellen
Dieses Thema enthält eine Übersicht über die Verwendung von Debuggerdatenmodell-C++-Schnittstellen zum Erweitern und Anpassen der Funktionen des Debuggers.
Debuggerdatenmodell C++-Hostschnittstellen
Der Debuggerdatenmodellhost
Das Debuggerdatenmodell ist als komponentenbezogenes System konzipiert, das in einer Vielzahl verschiedener Kontexte 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 kerne Aspekte des Debuggers verfügbar zu machen: seine Zielrichtung, seine Speicherräume, seine Auswertung, sein symbolisches und Typsystem usw. Obwohl 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 Kernschnittstellen sind:
| Schnittstellenname | BESCHREIBUNG |
|---|---|
| IDebugHost | Die Kernschnittstelle zum Debughost. |
| IDebugHostStatus | Eine Schnittstelle, die es einem Client ermöglicht, die status des Hosts abzufragen. |
| 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 Aufrufenden implementiert wird, um Fehler aus bestimmten Teilen des Host- und Datenmodells zu empfangen. |
| IDebugHostEvaluator/IDebugHostEvaluator2 | Die Ausdrucksauswertung des Debughosts. |
| IDebugHostExtensibility | Eine Schnittstelle zum Erweitern der Funktionen des Hosts oder von Teilen davon (z. B. der Ausdrucksauswertung). |
Das Typsystem und die symbolischen Schnittstellen sind:
| InterfaceName | Beschreibung |
|---|---|
| IDebugHostSymbols | Kernschnittstelle, die den Zugriff auf und die Auflösung von Symbolen ermöglicht |
| IDebugHostSymbol/IDebugHostSymbol2 | Stellt ein einzelnes Symbol beliebiger Art dar. Das jeweilige Symbol ist eine Ableitung dieser Schnittstelle. |
| IDebugHostModule | Stellt ein Modul dar, das innerhalb eines Prozesses geladen wird. Dies ist eine Art Symbol. |
| IDebugHostType/IDebugHostType2 | Stellt einen nativen/Sprachtyp dar. |
| IDebugHostConstant | Stellt eine Konstante innerhalb symbolischer Informationen dar (z. B. ein Nicht-Typ-Vorlagenargument in C++). |
| IDebugHostField | Represents a field within a structure or class. |
| 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 publics-Tabelle eines PDB dar. Diesem sind keine Typinformationen zugeordnet. Es handelt sich um einen Namen und eine Adresse. |
| IDebugHostModuleSignature | Stellt eine Modulsignatur dar– eine Definition, die einer Gruppe von Modulen nach Name und/oder Version entspricht. |
| IDebugHostTypeSignature | Stellt eine Typsignatur dar– eine Definition, die nach Modul und/oder Name mit einer Gruppe von Typen übereinstimmt. |
Die Kernhostschnittstelle: IDebugHost
Die IDebugHost-Schnittstelle ist die Kernschnittstelle jedes Datenmodellhosts. Nachfolgend ist diese Definition gezeigt:
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 Standard privaten Schnittstelle des Hosts zurück, wenn eine solche für den angegebenen Host vorhanden ist. Für Debugtools für Windows wird hier ein IDebugClient (in IUnknown umgewandelt) zurückgegeben.
Die GetCurrentContext-Methode gibt eine Schnittstelle zurück, die den aktuellen Zustand des Debuggerhosts darstellt. Die genaue Bedeutung bleibt dem Host überlassen, umfasst aber in der Regel Dinge wie die Sitzung, den Prozess und den Adressraum, der auf der Benutzeroberfläche des Debughosts aktiv ist. Das zurückgegebene Kontextobjekt ist für den Aufrufer weitgehend undurchsichtig, aber es ist ein wichtiges Objekt, das zwischen Aufrufen an den Debughost übergeben werden muss. Wenn ein Aufrufer instance Arbeitsspeicher liest, ist es wichtig zu wissen, aus welchem Prozess und Adressraum der Arbeitsspeicher gelesen wird. Dieser Begriff wird im Konzept 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. Dies ermöglicht es dem Debughost, die Art und Weise zu steuern, wie einige Daten dargestellt werden. Die Standardmetadaten können beispielsweise einen PreferredRadix-Schlüssel enthalten, sodass der Host angeben kann, ob Ordnungszahlen im Dezimal- oder Hexadezimalwert angezeigt werden sollen, wenn 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.
Die Statusschnittstelle: IDebugHostStatus
Mit der IDebugHostStatus-Schnittstelle kann ein Client des Datenmodells oder der Debughost bestimmte Aspekte der status des Debughosts abfragen. Die Schnittstelle wird wie folgt definiert:
DECLARE_INTERFACE_(IDebugHostStatus, IUnknown)
{
STDMETHOD(PollUserInterrupt)(_Out_ bool* interruptRequested) PURE;
}
Mit der PollUserInterrupt-Methode wird abgefragt, ob der Benutzer des Debughosts eine Unterbrechung des aktuellen Vorgangs angefordert hat. Ein Eigenschaftenaccessor im Datenmodell kann für instance beliebigen Code aufrufen (z. B. eine JavaScript-Methode). Dieser Code kann einen beliebigen Zeitraum in Anspruch nehmen. Um die Reaktionsfähigkeit des Debughosts aufrechtzuerhalten, sollte jeder code, der einen beliebigen Zeitraum in Anspruch nehmen kann, über den Aufruf dieser Methode nach einer Interruptanforderung suchen. Wenn der interruptRequested-Wert als true zurückgegeben wird, sollte der Aufrufer sofort abbrechen und ein Ergebnis von E_ABORT zurückgeben.
Die Kontextschnittstelle: IDebugHostContext
Kontext ist einer der wichtigsten Aspekte des Datenmodells und des zugrunde liegenden Debughosts. Wenn Sie ein Objekt halten, ist es wichtig, dass Sie wissen können, woher ein Objekt stammt – in welchem Prozess es sich befindet, welchem 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 abgerufen 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 eine besondere Bedeutung im Kontext einer IDebugHostContext-Schnittstelle haben, die entweder von einem Datenmodell oder einer Debughostmethode zurückgegeben oder an diese übergeben wird:
nullptr: Ein Hinweis darauf, dass kein Kontext vorhanden ist. Es ist vollkommen gültig, wenn einige Objekte keinen Kontext haben. Das Debuggerobjekt im Stammnamespace des Datenmodells verweist nicht auf etwas innerhalb eines bestimmten Prozesses oder Adressraums. Es 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 eine Eingabe IDebugHostContext verwendet, anstatt explizit die GetCurrentContext-Methode von IDebugHost aufzurufen. Beachten Sie, dass das explizite Übergeben von USE_CURRENT_HOST_CONTEXT häufig eine größere Leistung als das explizite Abrufen des aktuellen Kontexts ist.
Die Kontexte eines Hostkontexts sind für den Aufrufer weitgehend undurchsichtig. 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 Schnittstellenäquivalenz ist. Dadurch werden die zugrunde liegenden undurchsichtigen Inhalte des Kontexts selbst verglichen.
Die Fehlersenke: IDebugHostErrorsink
Der IDebugHostErrorSink ist ein Mittel, mit dem ein Client Benachrichtigungen über Fehler empfangen kann, die während bestimmter Vorgänge auftreten, und diese Fehler bei Bedarf weiterleiten kann. Die Schnittstelle wird 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 für die Fehlersenke, um sie zu benachrichtigen, dass ein Fehler aufgetreten ist, und der Senke das Weiterleiten des Fehlers an eine beliebige Benutzeroberfläche oder einen geeigneten Mechanismus ermöglicht.
Hostauswertung: IDebugHostEvaluator/IDebugHostEvaluator2
Einer der wichtigsten Funktionen, die der Debughost clients bereitstellt, ist der Zugriff auf die sprachbasierte Ausdrucksauswertung. Die Schnittstellen IDebugHostEvaluator und IDebugHostEvaluator2 sind die Möglichkeit, über den Debughost auf diese Funktionalität zuzugreifen.
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;
}
Die EvaluateExpression-Methode ermöglicht es dem Debughost, einen Sprachausdruck (z. B. C++) auszuwerten und den resultierenden Wert dieser Ausdrucksauswertung als IModelObject zurückzugeben. Diese spezielle Variante der -Methode lässt nur Sprachkonstrukte zu. Alle zusätzlichen Funktionen, die in der Ausdrucksauswertung des Debughosts angezeigt werden, der in der Sprache nicht vorhanden ist (z. B. LINQ-Abfragemethoden), werden für die Auswertung deaktiviert.
Die EvaluateExtendedExpression-Methode ähnelt der EvaluateExpression-Methode, mit der Ausnahme, dass sie zusätzliche nichtsprachliche Funktionen zurückgibt, die ein bestimmter Debughost seinem Ausdrucksauswertungs-Evaluator hinzufügen möchte. Für Debugtools für Windows ermöglicht dies beispielsweise anonyme Typen, LINQ-Abfragen, Modulqualifizierer, Formatbezeichner und andere Nicht-C/C++-Funktionen.
IDebugHostEvaluator2
Die AssignTo-Methode führt die Zuweisung entsprechend der Semantik der zu debuggenden Sprache aus.
Die Hosterweiterbarkeitsschnittstelle: IDebugHostExtensibility
Bestimmte Funktionen des Debughosts unterliegen optional der Erweiterbarkeit. Dies kann für instance die Ausdrucksauswertung umfassen. Die IDebugHostExtensibility-Schnittstelle ist das Mittel, mit dem auf diese Erweiterbarkeitspunkte zugegriffen wird. Die Schnittstelle wird 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 Methode, die in einer Erweiterung implementiert ist. Die Bedeutung dieses Alias ist hostspezifisch. Es kann die Ausdrucksauswertung des Hosts um die -Funktion erweitern oder etwas ganz anderes ausführen.
Die DestroyFunctionAlias-Methode hebt einen vorherigen Aufruf der CreateFunctionAlias-Methode auf. Die Funktion ist unter dem Schnellaliasnamen nicht mehr verfügbar.
Zugreifen auf das Datenmodell
In erster Linie sind die Datenmodellerweiterungs-APIs so konzipiert, dass sie für die Anwendung (in der Regel ein Debugger) neutral sind, die als Host des Datenmodells fungiert. Theoretisch kann jede Anwendung das Datenmodell hosten, indem sie eine Reihe von Host-APIs bereitstellt, die das Typsystem der Debugziele der Anwendung und eine Reihe von projizierten Objekten im Namespace des Datenmodells verfügbar machen, welche Ziele, Prozesse, Threads usw. befinden sich in diesen Debugzielen.
Die Datenmodell-APIs , die mit IDataModel, IDebugHost und den Ablegern von IModelObject beginnen, sind zwar so konzipiert, dass sie portierbar sind, aber sie definieren nicht, was eine "Debuggererweiterung" ist. Heute muss eine Komponente, die die Debugtools für Windows und die bereitgestellte Engine erweitern möchte, eine Engine-Erweiterung schreiben, um Zugriff auf das Datenmodell zu erhalten. Diese Engine-Erweiterung muss nur eine Engine-Erweiterung in so viel sein, wie dies der Lade- und Bootstrappingmechanismus 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 Objektmodellbearbeitungen einzurichten.
- DebugExtensionUninitialize: Eine Methode, mit der die In DebugExtensionInitialize ausgeführten Objektmodellbearbeitungen rückgängig gemacht werden.
- DebugExtensionCanUnload: Eine Methode, die zurückgibt, ob die Erweiterung entladen werden kann. Wenn die Erweiterung noch aktive COM-Objekte enthält, muss dies angegeben werden. Dies ist die Entsprechung des Debuggers mit dllCanUnloadNow von COM. Wenn dies den S_FALSE Hinweis zurückgibt, dass das Entladen nicht möglich ist, kann der Debugger dies später abfragen, um festzustellen, ob ein Entladen sicher ist, oder er kann die Erweiterung erneut initialisieren, indem DebugExtensionInitialize erneut aufgerufen wird. Die Erweiterung muss für die Verarbeitung beider Pfade vorbereitet sein.
- DebugExtensionUnload: Eine Methode, die alle abschließenden Bereinigungen vor dem Entladen der DLL durchführt.
Die Bridge-Schnittstelle: IHostDataModelAccess
Wie bereits erwähnt, wird beim Aufruf von DebugExtensionInitialize ein Debugclient erstellt und Zugriff auf das Datenmodell abgerufen. Dieser Zugriff wird über eine Brückenschnittstelle zwischen den IDebug*-Legacyschnittstellen der Debugtools für Windows und dem Datenmodell bereitgestellt. Diese Bridgeschnittstelle ist "IHostDataModelAccess" und ist 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 Bridge-Schnittstelle, die Zugriff auf beide Seiten des Datenmodells ermöglicht: Der Debughost (der untere Rand des Debuggers) wird durch die zurückgegebene IDebugHost-Schnittstelle ausgedrückt. Die Standard Komponente des Datenmodells – der Datenmodell-Manager wird durch die zurückgegebene IDataModelManager-Schnittstelle ausgedrückt.
Debugger-Datenmodellsystemschnittstellen
Der Datenmodellhost
Das Debuggerdatenmodell ist als komponentenbezogenes System konzipiert, das in einer Vielzahl verschiedener Kontexte 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 kerne Aspekte des Debuggers verfügbar zu machen: seine Zielrichtung, seine Speicherräume, seine Auswertung, sein symbolisches und Typsystem usw. Obwohl 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 den Zugriff auf und die Auflösung von Symbolen ermöglicht |
| IDebugHostSymbol/IDebugHostSymbol2 | Stellt ein einzelnes Symbol beliebiger Art dar. Das jeweilige Symbol ist eine Ableitung dieser Schnittstelle. |
| IDebugHostModule | Stellt ein Modul dar, das innerhalb eines Prozesses geladen wird. Dies ist eine Art Symbol. |
| IDebugHostType/IDebugHostType2 | Stellt einen nativen/Sprachtyp dar. |
| IDebugHostConstant | Stellt eine Konstante innerhalb symbolischer Informationen dar (z. B. ein Nicht-Typ-Vorlagenargument in C++). |
| IDebugHostField | Represents a field within a structure or class. |
| 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 publics-Tabelle eines PDB dar. Diesem sind keine Typinformationen zugeordnet. Es handelt sich um einen Namen und eine Adresse. |
| IDebugHostModuleSignature | Stellt eine Modulsignatur dar– eine Definition, die einer Gruppe von Modulen nach Name und/oder Version entspricht. |
| IDebugHostTypeSignature | Stellt eine Typsignatur dar– eine Definition, die nach Modul und/oder Name mit einer Gruppe von Typen übereinstimmt. |
Die anderen Kernschnittstellen sind:
| Schnittstellenname | BESCHREIBUNG |
|---|---|
| IDebugHost | Die Kernschnittstelle zum Debughost. |
| IDebugHostStatus | Eine Schnittstelle, die es einem Client ermöglicht, die status des Hosts abzufragen. |
| IDebugHostContext | Eine Abstraktion eines Kontexts innerhalb des Hosts (z. B. ein bestimmtes Ziel, ein bestimmter Prozess, ein bestimmter Adressraum usw.) |
| IDebugHostErrorSink | Eine von Aufrufern implementierte Schnittstelle zum Empfangen von Fehlern aus bestimmten Teilen des Host- und Datenmodells |
| IDebugHostEvaluator/IDebugHostEvaluator2 | Der Ausdrucksauswerter des Debughosts. |
| IDebugHostExtensibility | Eine Schnittstelle zum Erweitern der Funktionen des Hosts oder von Teilen davon (z. B. der Ausdrucksauswertung). |
Die symbolische Hauptschnittstelle: IDebugHostSymbols
Die IDebugHostSymbols-Schnittstelle ist der Standard Ausgangspunkt für den Zugriff auf Symbole im Debugziel. Diese Schnittstelle kann von einem instance von IDebugHost abgefragt werden und ist 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 einen Satz bestimmter Module nach Name und optional nach Version abzugleichen. Es gibt drei Komponenten für eine Modulsignatur:
- Ein Name: Ein übereinstimmende Modul muss einen Namen haben, bei dem die Groß-/Kleinschreibung nicht mit dem Namen in der Signatur übereinstimmt.
- Mindestversion: Wenn angegeben, muss ein übereinstimmende Modul 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 ist als der vorherige. Nur das erste Segment ist obligatorisch.
- 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 ist als der vorherige. Nur das erste Segment ist obligatorisch.
Die CreateTypeSignature-Methode erstellt eine Signatur, die verwendet werden kann, um eine Reihe von konkreten Typen abzugleichen, indem sie Modul und Typname enthält. Das Format der Typnamensignaturzeichenfolge ist spezifisch für die Zu debuggende Sprache (und den Debughost). Für C/C++ entspricht die Signaturzeichenfolge einer NatVis-Typspezifikation. Das heißt, die Signaturzeichenfolge ist ein Typname, bei dem Platzhalter (als *angegeben) für Vorlagenargumente zulässig sind.
CreateTypeSignatureForModuleRange
Die CreateTypeSignatureForModuleRange-Methode erstellt eine Signatur, die verwendet werden kann, um eine Reihe von konkreten Typen nach Modulsignatur und Typname abzugleichen. Dies ähnelt der CreateTypeSignature-Methode, mit dem Unterschied, 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 alle module aufzählt, die in einem bestimmten Hostkontext verfügbar sind. Dieser Hostkontext kapselt möglicherweise einen Prozesskontext oder kapselt etwas wie den Windows-Kernel.
Die FindModuleByName-Methode durchsieht den angegebenen Hostkontext, sucht ein Modul mit dem angegebenen Namen und gibt eine Schnittstelle zurück. Es ist legal, nach dem Namen des Moduls mit oder ohne Dateierweiterung zu suchen.
Die FindModuleByLocation-Methode durchsieht den angegebenen Hostkontext und bestimmt, welches Modul die adresse enthält, die vom angegebenen Speicherort angegeben wird. Anschließend wird eine Schnittstelle für dieses Modul zurückgegeben.
GetMostDerivedObject verwendet das Typsystem des Debuggers, um den Laufzeittyp eines Objekts anhand des statischen Typs zu bestimmen. Diese Methode verwendet nur symbolische Informationen und Heuristiken, die auf der Typsystemebene verfügbar sind, um diese Analyse durchzuführen. Diese Informationen können C++-RTTI (Laufzeittypinformationen) oder die Analyse der Form der virtuellen Funktionstabellen des Objekts umfassen. Es enthält keine Dinge wie das bevorzugte Laufzeittypkonzept für ein IModelObject. Wenn die Analyse keinen Laufzeittyp oder keinen anderen Laufzeittyp als den statischen Typ finden kann, der an die Methode übergeben wird, werden der Eingabespeicherort und -typ möglicherweise übergeben. Die Methode schlägt aus diesen Gründen nicht fehl.
Die zentrale Schnittstelle für einzelne Symbole: IDebugHostSymbol
Jedes Symbol, das vom Datenmodellhost zurückgegeben werden kann, wird in irgendeiner Weise von IDebugHostSymbol abgeleitet. Dies ist die Kernschnittstelle, die jedes Symbol unabhängig von der Art des Symbols implementiert. Abhängig von der Art des Symbols kann ein bestimmtes Symbol einen Satz anderer Schnittstellen implementieren, die Attribute zurückgeben, die für die bestimmte Art von Symbol, die von dieser Schnittstelle dargestellt wird, eindeutiger sind. Die IDebugHostSymbol2/IDebugHostSymbol-Schnittstelle ist 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 - die durch die SymbolKind-Enumeration mit folgenden Werten abgegrenzt werden:
| Enumarant | Bedeutung |
|---|---|
| Symbol | Nicht angegebener Symboltyp |
| SymbolModule | Das Symbol ist ein Modul und kann nach IDebugHostModule abgefragt werden. |
| SymbolType | Das Symbol ist ein Typ und kann nach IDebugHostType abgefragt werden. |
| SymbolField | Das Symbol ist ein Feld (ein Datenmember innerhalb einer Struktur oder Klasse) und kann nach IDebugHostField abgefragt werden. |
| SymbolConstant | Das Symbol ist ein konstanter Wert und kann nach IDebugHostConstant abgefragt werden. |
| SymbolData | Das Symbol sind Daten, die kein Element einer Struktur oder Klasse sind und für IDebugHostData abfragbar sind. |
| SymbolBaseClass | Das Symbol ist eine Basisklasse und für IDebugHostBaseClass abfragbar. |
| SymbolPublic | Das Symbol ist ein Eintrag in der publics-Tabelle eines Moduls (ohne Typinformationen) und kann für IDebugHostPublic abfragt werden. |
| SymbolFunction | Das Symbol ist eine Funktion und für IDebugHostData abfragbar. |
Die GetContext-Methode gibt den Kontext zurück, in dem das Symbol gültig ist. Dies stellt zwar Dinge wie das Debugziel und den Prozess-/Adressraum dar, in dem das Symbol vorhanden ist, ist jedoch möglicherweise nicht so spezifisch wie ein Kontext, der von anderen Mitteln (z. B. von einem IModelObject) abgerufen wird.
Die EnumerateChildren-Methode gibt einen Enumerator zurück, der alle untergeordneten Elemente eines bestimmten Symbols aufzählt. Für einen C++-Typ gelten beispielsweise die Basisklassen, Felder, Memberfunktionen und dergleichen als untergeordnete Elemente des Typsymbols.
Die Modulschnittstelle: IDebugHostModule
Die Vorstellung eines Moduls des Debuggers, das innerhalb eines Adressraums geladen wird, wird im Datenmodell auf zwei verschiedene Arten dargestellt: Auf Typsystemebene über die IDebugHostModule-Schnittstelle. Hierbei ist ein Modul ein Symbol, und kernattribute des Moduls sind Schnittstellenmethodenaufrufe Projected auf Datenmodellebene über das Debugger.Models.Module-Datenmodell. Dies ist eine erweiterbare Kapselung der IDebugHostModule-Typdarstellung eines Moduls.
Die IDebugHostModule-Schnittstelle ist wie folgt definiert (methoden ignoriert, die für IDebugHostSymbol generisch 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 Imagenamen des Moduls zurück. Abhängig vom Wert des arguments allowPath kann der zurückgegebene Imagename den vollständigen Pfad zum Image enthalten oder nicht.
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 diese 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 gibt möglicherweise einen gültigen IDebugHostType zurück, der niemals durch explizite Rekursion untergeordneter Elemente des Moduls zurückgegeben wird. Der Debughost kann die Erstellung von abgeleiteten Typen ermöglichen– Typen, die nicht innerhalb des Moduls selbst verwendet werden, sondern von typen abgeleitet sind. Wenn beispielsweise die Struktur MyStruct in den Symbolen des Moduls definiert ist, der Typ MyStruct ** jedoch nie verwendet wird, kann die FindTypeByName-Methode legitimerweise ein Typsymbol für MyStruct ** zurückgeben, 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 einziges Symbol vorhanden ist (z. B. mehrere Übereinstimmungen), wird von dieser Methode ein Fehler zurückgegeben. Beachten Sie, dass diese Methode ein privates Symbol vor einem Symbol in der publics-Tabelle zurückgibt.
Die FindSymbolByName-Methode sucht ein einzelnes globales Symbol des angegebenen Namens innerhalb des Moduls. Wenn kein einziges Symbol mit dem angegebenen Namen übereinstimmt, wird von dieser Methode ein Fehler zurückgegeben. Beachten Sie, dass diese Methode ein privates Symbol vor einem Symbol in der publics-Tabelle zurückgibt.
Zugriff auf das Typsystem: IDebugHostType2 / IDebugHostType
Ein bestimmter Sprach-/nativer Typ wird durch die Schnittstellen IDebugHostType2 oder IDebugHostType 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-Enumeration beschrieben:
| Typtyp | Beschreibung |
|---|---|
| TypeUDT | Ein benutzerdefinierter Typ (Struktur, Klasse, Union usw.). Ein Modellobjekt, das über einen systemeigenen Typ verfügt, dessen Art TypeUDT ist, verfügt über eine kanonische Darstellung von ObjectTargetObject, wobei der Typ immer im entsprechenden IModelObject enthalten ist. |
| TypePointer | Ein Zeiger. Ein Modellobjekt mit einem systemeigenen Typ, dessen Art TypePointer ist, verfügt über eine kanonische Darstellung von ObjectIntrinsic, wobei der Wert des Zeigers null auf VT_UI8 erweitert und als intrinsische Daten in dieser 64-Bit-Form beibehalten wird. Jedes Typsymbol von TypePointer verfügt über einen Basistyp (wie von der GetBaseType-Methode zurückgegeben) des Typs, auf den der Zeiger zeigt. |
| TypeMemberPointer | Ein Zeiger auf den Klassenmember. Ein Modellobjekt, das über einen systemeigenen Typ verfügt, dessen Art TypeMemberPointer ist, verfügt über eine kanonische Darstellung, die intrinsisch ist (der Wert ist mit dem Zeigerwert identisch). Die genaue Bedeutung dieses Werts ist compiler-/debughostspezifisch. |
| TypeArray | Ein -Array. Ein Modellobjekt, das über einen systemeigenen Typ verfügt, dessen Art TypeArray ist, verfügt über eine kanonische Darstellung von ObjectTargetObject. Die Basisadresse des Arrays ist der Speicherort des Objekts (abgerufen über die GetLocation-Methode), und der Typ des Arrays wird immer beibehalten. Jedes Typsymbol von TypeArray hat einen Basistyp (wie von der GetBaseType-Methode zurückgegeben) des Typs, von dem das Array ein Array ist. |
| TypeFunction | Eine Funktion. |
| TypeTypedef | Eine Typdefinition. Ein Modellobjekt, das über einen systemeigenen Typ verfügt, dessen Art andernfalls TypeTypedef lautet, verfügt über eine kanonische Darstellung, die mit der kanonischen Darstellung des endgültigen Typs identisch ist, der der Typedef zugrunde liegt. Dies scheint für den Endbenutzer des Objekts und die Typinformationen völlig transparent zu sein, es sei denn, die expliziten typedef-Methoden von IDebugHostType2 werden zum Abfragen von Typedef-Informationen verwendet oder es ist ein explizites Datenmodell für die Typedef registriert. Beachten Sie, dass die GetTypeKind-Methode nie TypeTypedef zurückgibt. Jede Methode gibt den letzten Typ zurück, der der Typdefinition zugrunde liegt. Es gibt typedef-spezifische Methoden für IDebugHostType2, die verwendet werden können, um die typspezifischen Informationen abzurufen. |
| TypeEnum | Eine Enumeration. Ein Modellobjekt, das über einen systemeigenen Typ verfügt, dessen Art TypeEnum ist, verfügt über eine kanonische Darstellung von ObjectIntrinsic, wobei der Wert und der Typ des systeminternen Werts mit dem Enumerationswert identisch sind. |
| TypeIntrinsic | Ein systeminterner (Basistyp). Ein Modellobjekt, das über einen systemeigenen Typ verfügt, dessen Art TypeIntrinsic ist, verfügt über eine kanonische Darstellung von ObjectIntrinsic. Die Typinformationen können beibehalten werden oder nicht - insbesondere, wenn der zugrunde liegende Typ vollständig durch den Variantendatentyp (VT_*) der im IModelObject gespeicherten intrinsischen Daten beschrieben wird. |
Die gesamte IDebugHostType2/IDebugHostType-Schnittstelle ist wie folgt definiert (mit Ausnahme von 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 – Allgemeine Methoden
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 zurück, auf welche Art von Typ (Zeiger, Array, systemintern usw.) das Symbol verweist.
Die GetSize-Methode gibt die Größe des Typs zurück (als hätte man sizeof(type) in C++ ausgeführt).
Wenn der Typ eine Ableitung eines anderen einzelnen Typs ist (z. B.: da MyStruct * von MyStruct abgeleitet ist), gibt die GetBaseType-Methode den Basistyp der Ableitung zurück. Bei Zeigern gibt dies den Typ zurück, auf den verwiesen wird. Für Arrays gibt dies zurück, was das Array ist. Wenn es sich beim Typ nicht um einen solchen abgeleiteten Typ handelt, 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 alles entspricht, wenn dies vom Host zulässig ist) muss jeder Typ instance, der mit einer bestimmten Typsignatur übereinstimmen kann, denselben Hashcode zurückgeben. Diese Methode wird in Verbindung mit Typsignaturen verwendet, um Typsignaturen mit Typinstanzen abzugleichen.
Intrinsische IDebugHostType2/IDebugHostType-Methoden
Die folgenden IDebugHostType-Methoden sind spezifisch für systeminterne Typen (oder Typen, die intrinsische Daten wie Enumerationen enthalten):
STDMETHOD(GetIntrinsicType)(_Out_opt_ IntrinsicKind *intrinsicKind, _Out_opt_ VARTYPE *carrierType) PURE;
Die GetIntrinsicType-Methode gibt Informationen darüber zurück, welcher Typ intrinsisch ist. Aus dieser Methode werden zwei Werte zurückgegeben:
- Die intrinsische Art gibt den Gesamttyp an (z. B. ganzzahlig, ohne Vorzeichen, Gleitkomma), aber nicht die Größe des Typs (z. B. 8 Bit, 16 Bit, 32 Bit, 64 Bit).
- Der Carriertyp gibt an, wie die intrinsische Art in eine VARIANT-Struktur verpackt wird. Dies ist eine VT_*-Konstante.
Die Kombination der beiden Werte liefert den vollständigen Satz von Informationen über das systeminterne.
IDebugHostType2/IDebugHostType Bitfield-Methoden
Die folgenden IDebugHostType-Methoden sind spezifisch für Typen, die Daten in Bitfeldern speichern. Informationen zur Bitfeldplatzierung innerhalb eines systeminternen Elements 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 Bitfeldplatzplatzierung. Die GetBitField-Methode kann verwendet werden, um diese Informationen abzurufen. Diese Methode schlägt bei jedem Typ fehl, der kein Bitfeld ist. Dies ist der einzige Grund, warum die Methode fehlschlägt. Das einfache Aufrufen dieser Methode und die Betrachtung von Erfolg/Misserfolg reicht aus, um ein Bitfeld von einem Nicht-Bitfeld zu unterscheiden. Wenn ein bestimmter Typ ein Bitfeld ist, werden die Feldpositionen durch den halb geöffneten Satz (lsbOfField + lengthOfField : lsbOfField) definiert.
IDebugHostType2/IDebugHostType-Zeiger bezogene Methoden
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;
Für Typen, die Zeiger sind, gibt die GetPointerKind-Methode die Art des Zeigers zurück. Dies wird durch die PointerKind-Enumeration definiert.
Für Typen, bei denen es sich um Zeiger auf Member handelt (wie durch eine Typart von TypeMemberPointer angegeben), gibt die GetMemberType-Methode die Klasse zurück, für die der Zeiger ein Zeiger auf Member ist.
IDebugHostType2/IDebugHostType Array verwandte Methoden
Arrays sind Typen, bei denen GetTypeKind TypeArray zurückgibt. Beachten Sie, dass Arrays, die vom Typsystem des Debughosts definiert sind, nicht mit den von C verwendeten eindimensionalen, indexbasierten, gepackten linearen eindimensionalen Arrays identisch sind. Arrays im C-Stil 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 ArrayDimensionDieser Deskriptor verfügt über die folgenden Felder:
| Feld | Bedeutung |
|---|---|
| Lowerbound | Der Basisindex des Arrays als signierter 64-Bit-Wert. Bei einem Array im C-Format ist dies immer 0. Das muss nicht sein. Eine einzelne Dimension eines Arrays kann davon ausgegangen werden, dass sie bei einem beliebigen 64-Bit-Index beginnt, auch wenn es negativ ist. |
| Länge | Die Länge der Arraydimension als 64-Bit-Wert ohne Vorzeichen. Die Zeichenfolgen des Arrays umfassen den halb geöffneten Satz [LowerBound, LowerBound + Length). |
| Stride | Definiert den Schritt der Arraydimension. Bei einer Erhöhung um eins (von N auf N + 1) im Index dieser Dimension gibt dies an, wie viele Bytes im Arbeitsspeicher vorwärts verschoben werden sollen. Bei einem Array im C-Format wäre dies die Größe jedes Elements des Arrays. Das muss nicht sein. Der Abstand zwischen Elementen kann als Schritt ausgedrückt werden, der größer als die Größe jedes einzelnen Elements ist. 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 diesen Grad 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. Für Arrays im C-Format wird hier immer 1 zurückgegeben.
Die GetArrayDimensions-Methode gibt einen Satz von Deskriptoren zurück, einen 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 von wesentlich leistungsfähigeren Arraykonstrukten, als im C-Typsystem zulässig sind.
Für 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-Funktion bezogene Methoden
Typen, die angeben, dass es sich um Funktionstypen über eine Art von TypeFunction handelt, unterstützen die folgenden Methoden sowohl in IDebugHostType als auch in 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 Aufrufkonvention der Funktion zurück. Diese wird als Member der CallingConventionKind-Enumeration zurückgegeben.
Die GetFunctionReturnType-Methode gibt den Rückgabetyp der Funktion zurück.
Die GetFunctionParameterTypeCount-Methode gibt die Anzahl der Argumente zurück, die die Funktion annimmt. Beachten Sie, dass der Argumentmarker mit den Auslassungspunkten auf C/C++-Basis in dieser Anzahl nicht berücksichtigt wird. Das Vorhandensein solcher muss über die GetFunctionVarArgsKind-Methode erkannt werden. Dies schließt nur Argumente vor den Auslassungspunkten ein.
Die GetFunctionParameterTypeAt-Methode gibt den Typ des i-ten 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 verwendet wird. Dies wird durch ein Element der VarArgsKind-Enumeration definiert, die wie folgt definiert ist:
| Enumerant | Bedeutung |
|---|---|
| VarArgsNone | Die Funktion akzeptiert keine Variablenargumente. |
| VarArgsCStyle | Die Funktion ist eine varargs-Funktion im C-Stil (returnType(arg1, arg2, ...)). Die Anzahl von Argumenten, die von der Funktion gemeldet werden, enthält nicht das Argument mit den Auslassungspunkten. Alle Variablenargumentübergaben treten nach der Anzahl von Argumenten 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 verwendet wird. Dies wird durch ein Element der VarArgsKind-Enumeration definiert, die wie folgt definiert ist:
IDebugHostType2/IDebugHostType Typedef Related Methods
Jeder Typ, der eine Typedef ist, verhält sich so, als ob der Typ der letzte Typ ist, der dem Typedef zugrunde liegt. Dies bedeutet, dass Methoden wie GetTypeKind nicht angeben, dass der Typ eine Typedef ist. Ebenso gibt GetBaseType nicht den Typ zurück, auf den sich die Definition bezieht. Sie geben stattdessen an, dass sie sich so verhalten, als ob sie in der endgültigen Definition aufgerufen würden, die der Typedef zugrunde liegt. Beispiel:
typedef MYSTRUCT *PMYSTRUCT;
typedef PMYSTRUCT PTRMYSTRUCT;
Ein IDebugHostType für "entweder PMYSTRUCT oder PTRMYSTRUCT meldet die folgenden Informationen:
- Die GetTypeKind-Methode gibt TypePointer zurück. Der endgültige zugrunde liegende Typ MYSTRUCT * ist in der Tat ein Zeiger.
- Die GetBaseType-Methode gibt einen Typ für MYSTRUCT zurück. Der zugrunde liegende Typ von MYSTRUCT * ist MYSTRUCT.
Der einzige Unterschied besteht hier darin, wie sich die typedef-spezifischen Methoden auf 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 sowohl für PMYSTRUCT als auch für PTRMYSTRUCT true 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 eine 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 der 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 die typedef eine Definition ist. Wenn die Typedef eine Definition eines anderen Typs ist, folgt diese weiterhin der Definitionskette, bis sie einen Typ erreicht, der keine 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 sie entweder für PMYSTRUCT oder PTRMYSTRUCT aufgerufen wird.
IDebugHostType2/IDebugHostType Type Creation-Methoden
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;
Konstante Symbolwerte: IDebugHostConstant
Für Orte, an denen konstante Werte in symbolischen Informationen vorhanden sind (wenn ein bestimmter Wert ein Symbol ist, das ein konstanter Wert sein kann oder nicht), drückt 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 Vorlagenargument ohne Typ sein kann (z. B. eine Konstante).
Die IDebugHostConstant-Schnittstelle ist wie folgt definiert (wobei generische Methoden ignoriert werden, 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 gepackt 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 gibt es keine Garantie dafür, dass die Verpackung des konstanten Werts, wie durch das Typsymbol definiert, mit der Verpackung identisch ist, die von der GetValue-Methode hier zurückgegeben wird.
Datenmemberzugriff: IDebugHostField
Die IDebugHostField-Klasse stellt ein Symbol dar, das ein Datenmember eines Klassen-, Struktur-, Union- oder anderen Typkonstrukts ist. Sie stellt keine freien Daten (z. B. globale Daten) dar. Die -Schnittstelle ist wie folgt definiert (die generischen Methoden für IDebugHostSymbol werden ignoriert):
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 zurück, an welcher Position sich das Symbol gemäß der LocationKind-Enumeration befindet. Eine solche Enumeration kann einer der folgenden Werte sein:
| Enumerant | Bedeutung |
|---|---|
| LocationMember | Das Feld ist ein regulärer Datenmember eines Klassen-, Struktur-, Union- oder anderen Typkonstrukts. Es verfügt über einen Offset, der relativ zur Basisadresse des enthaltenden Typkonstrukts ist. Eine solche Basisadresse wird in der Regel durch den folgenden 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 verfügt über eine eigene Adresse. Die GetLocation-Methode gibt den abstrakten Speicherort (z. B. Adresse) des statischen Felds zurück. Bei den Methoden GetOffset und GetValue treten für ein Feld locationStatic ein Fehler auf. |
| LocationConstant | Das Feld ist eine Konstante und verfügt über einen Wert. Die GetValue-Methode gibt den Wert der Konstanten zurück. Die GetOffset- und GetLocation-Methoden schlagen für ein Feld fehl, das LocationConstant ist. |
| LocationNone | Das Feld hat keinen Speicherort. Es kann vom Compiler optimiert worden sein, oder es kann ein statisches Feld sein, das deklariert, aber nie definiert ist. Unabhängig davon, wie ein solches Feld entstanden ist, hat es keinen physischen Vorhandensein oder Wert. Sie befindet sich nur in den Symbolen. Alle Erfassungsmethoden (GetOffset, GetLocation und GetValue) schlagen für ein Feld mit locationNone fehl. |
Für Felder mit einem Offset (z. B. Felder, deren Standortart LocationMember angibt), gibt die GetOffset-Methode den Offset von der Basisadresse des enthaltenden Typs (diesem Zeiger) auf die Daten für das Feld selbst zurück. Solche Offsets werden immer als unsignierte 64-Bit-Werte ausgedrückt. Wenn das angegebene Feld keinen Speicherort aufweist, der ein Offset von der Basisadresse des enthaltenden Typs ist, schlägt die GetOffset-Methode fehl.
Für Felder, die unabhängig vom jeweiligen Typ instance eine Adresse aufweisen (z. B. Felder, deren Standortart LocationStatic angibt), gibt die GetLocation-Methode den abstrakten Speicherort (Adresse) des Felds zurück. Wenn das angegebene Feld keinen statischen Speicherort aufweist, schlägt die GetLocation-Methode fehl.
Bei Feldern mit einem konstanten Wert, der in den symbolischen Informationen definiert ist (z. B. Felder, deren Standortart LocationConstant angibt), gibt die GetValue-Methode den konstanten Wert des Felds zurück. Wenn das angegebene Feld keinen konstanten Wert aufweist, schlägt die GetValue-Methode fehl.
Kostenloser Datenzugriff: IDebugHostData
Daten in Modulen, die kein Element eines anderen Typs sind, werden durch die IDebugHostData-Schnittstelle dargestellt. Diese Schnittstelle wird wie folgt definiert (die generischen Methoden für 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 sind semantisch äquivalent zu ihren Entsprechungen in IDebugHostField. Der einzige Unterschied besteht darin, dass die GetLocationKind-Methode niemals LocationMember für kostenlose Daten zurückgibt.
Die GetLocationKind-Methode gibt den Standort zurück, an dem sich das Symbol gemäß der LocationKind-Enumeration befindet. Die Beschreibung dieser Enumeration finden Sie in der Dokumentation zu 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 aufweisen, schlägt die GetLocation-Methode fehl.
Für Daten, für die ein konstanter Wert in den symbolischen Informationen definiert ist (z. B. Daten, deren Standortart LocationConstant angibt), gibt die GetValue-Methode den konstanten Wert des Felds zurück. Wenn die angegebenen Daten keinen konstanten Wert 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 (vererbungsmäßig) von einem oder mehreren Typen abgeleitet wird, gibt es mindestens eine untergeordnete SymbolBaseClass des Typsymbols für den Typ. Jedes dieser SymbolBaseClass-Symbole stellt die sofortige Vererbung eines bestimmten Typs dar. Der Name der Basisklasse ist sowohl der Name des SymbolBaseClass-Symbols als auch der des Typsymbols für die Basisklasse. Die GetType-Methode für das SymbolBaseClass-Symbol kann verwendet werden, um das Typsymbol für die Basisklasse selbst abzurufen. Die vollständige Vererbungshierarchie kann durch die rekursive Untersuchung untergeordneter SymbolBaseClass-Symbole durchlaufen werden. Jedes dieser Basisklassensymbole wird durch die IDebugHostBaseClass-Schnittstelle ausgedrückt, die wie folgt definiert ist (ignorieren von generischen Methoden zu 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. Ein solcher 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. Dabei handelt es sich tatsächlich um Exportadressen. Einem öffentlichen Symbol sind keine Typinformationen zugeordnet, nur eine Adresse. Sofern vom Aufrufer nicht explizit ein öffentliches Symbol angefordert wird, gibt der Debughost lieber private Symbole für jede Anfrage zurück. Ein öffentliches Symbol wird durch die IDebugHostPublic-Schnittstelle ausgedrückt, die wie folgt definiert ist (methoden ignoriert, die für IDebugHostSymbol generisch sind):
DECLARE_INTERFACE_(IDebugHostPublic, IDebugHostSymbol)
{
STDMETHOD(GetLocationKind)(_Out_ LocationKind *locationKind) PURE;
STDMETHOD(GetLocation)(_Out_ Location* location) PURE;
}
Alle diese Methoden sind semantisch äquivalent zu ihren Entsprechungen 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 den Standort zurück, an dem sich das Symbol gemäß der LocationKind-Enumeration befindet. Die Beschreibung dieser Enumeration finden Sie in der Dokumentation zu IDebugHostField.
Für Daten mit einer Adresse gibt die GetLocation-Methode den abstrakten Speicherort (Adresse) des Felds zurück. Wenn die angegebene öffentliche Datei keinen statischen Speicherort aufweist, schlägt die GetLocation-Methode fehl.
Modulsignaturen und Versionsabgleich: IDebugHostModuleSignature
Modulsignaturen stellen ein Mittel dar, um zu überprüfen, ob ein bestimmtes Modul eine Reihe von Kriterien in Bezug auf Benennung und Versionsverwaltung erfüllt. Eine Modulsignatur wird über die CreateModuleSignature-Methode auf IDebugHostSymbols erstellt. Es kann mit dem Modulnamen und einem optionalen Bereich von Versionsnummern für das Modul übereinstimmen. Sobald eine solche Signatur erstellt wurde, erhält 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 in der Signatur angegebenen Namen und Versionsbereich verglichen werden. Ein Hinweis darauf, ob das angegebene Modulsymbol mit der Signatur übereinstimmt, wird zurückgegeben.
Typsignaturen und Typabgleich: IDebugHostTypeSignature
Typsignaturen stellen ein Mittel dar, um zu überprüfen, ob ein bestimmter Typ instance eine Reihe von Kriterien für den 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, erhält 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 in der Implementierung eine Synchronisierung erfolgt. Mit Ausnahme einer globalen Übereinstimmung verfügen beide über denselben 32-Bit-Hashcode, wenn ein Typ instance mit einer Typsignatur übereinstimmen kann. Dies ermöglicht einen ersten schnellen Vergleich und Eine Übereinstimmung zwischen einem Typ instance und einer Vielzahl von Typsignaturen, die beim Datenmodell-Manager registriert sind.
Die IsMatch-Methode gibt einen Hinweis zurück, ob ein bestimmter Typ instance 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 des Typs instance (als Symbole) angibt, die mit Denkplatzhaltern in der Typsignatur übereinstimmen.
Die CompareAgainst-Methode vergleicht die Typsignatur mit einer anderen Typsignatur und gibt den Vergleich der beiden Signaturen zurück. Das zurückgegebene Vergleichsergebnis ist ein Member der SignatureComparison-Enumeration, die wie folgt definiert ist:
| Enumerant | Bedeutung |
|---|---|
| Unrelated | Es besteht keine Beziehung zwischen den beiden Signaturen oder Typen, die verglichen werden. |
| Nicht eindeutig | Eine Signatur oder ein Typ vergleicht mehrdeutig mit der anderen. Für zwei Typsignaturen bedeutet dies, dass es potenzielle Typinstanzen gibt, die mit beiden Signaturen gleich gut übereinstimmen könnten. Als Beispiel sind die beiden unten gezeigten Typsignaturen mehrdeutig. Signatur 1: std::pair<*, int> Signatur 2: std::pair<int,*> Da der Typ instance std::pair<int, int> mit einem gleich gut übereinstimmt (beide haben eine Konkrete und eine Wildcard-Übereinstimmung). |
| Wenigerspezifisch | Eine Signatur oder ein Typ ist weniger spezifisch als die andere. Häufig bedeutet dies, dass die weniger spezifische Signatur über einen Feldhalter verfügt, wobei die spezifischere signatur 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 (das *) hat, wobei die zweite einen konkreten Typ (int) hat. |
| MehrSpecific | Eine Signatur oder ein Typ ist spezifischer als die andere. Häufig bedeutet dies, dass die spezifischere Signatur einen konkreten Typ hat, wobei 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 es einen konkreten Typ (int) hat, wobei der zweite einen Platzhalter (das *) hat. |
| Identisch | Die beiden Signaturen oder Typen sind identisch. |
Siehe auch
Dieses Thema ist Teil einer Reihe, in der die Schnittstellen beschrieben werden, auf die über C++ zugegriffen werden kann, wie sie zum Erstellen einer C++-basierten Debuggererweiterung verwendet werden und wie andere Datenmodellkonstrukte (z. B. JavaScript oder NatVis) aus einer C++-Datenmodellerweiterung verwendet werden.
Debuggerdatenmodell C++-Übersicht
Debuggerdatenmodell-C++-Schnittstellen
Debuggerdatenmodell C++-Objekte
Debuggerdatenmodell C++-Zusätzliche Schnittstellen
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für