XCOFF-Objektdateiformat

Zweck

Das erweiterte allgemeine Objektdateiformat (XCOFF) ist das Objektdateiformat für das Betriebssystem. XCOFF verbindet das allgemeine Standardobjektdateiformat (COFF) mit dem Formatkonzept des TOC-Moduls, das dynamisches Binden und das Ersetzen von Bereichen innerhalb einer Objektdatei ermöglicht. Eine Variante von XCOFF wird für 64-Bit-Objektdateien und ausführbare Dateien verwendet.

XCOFF ist die formale Definition von Maschinenimageobjekten und ausführbaren Dateien. Diese Objektdateien werden von Sprachprozessoren (Assembler und Compiler) und dem Binder (oder Linkeditor) erstellt und hauptsächlich vom Binder und dem Systemladeprogramm verwendet.

Der Standardname für eine ausführbare XCOFF-Datei lautet a.out.

Lesen Sie die folgenden Informationen, um mehr über XCOFF-Objektdateien zu erfahren:

• Header für Verbunddatei (Composite File Header)
• Abschnitte und Abschnittsüberschriften
• Verlagerungsinformationen für XCOFF-Datei (reloc.h)
• Zeilennummerninformationen für XCOFF-Datei (linenum.h)
• Informationen zur Symboltabelle
• dbx-Stabstrings

Anwendungen schreiben, die XCOFF-Deklarationen verwenden

XCOFF32 -Deklarationen auswählen

Um die XCOFF32 -Definition auszuwählen, muss eine Anwendung lediglich die entsprechenden Headerdateien einschließen. Nur XCOFF32 -Strukturen, -Felder und -Vorprozessordefinitionen werden eingeschlossen.

Auswählen von XCOFF64 -Deklarationen

Um die XCOFF64 -Definitionen auszuwählen, muss eine Anwendung das Vorprozessormakro __XCOFF64__definieren. Wenn XCOFF-Headerdateien eingeschlossen werden, werden die Strukturen, Felder und Vorprozessoren eingeschlossen, die für XCOFF64 definiert sind. Wenn möglich, sind die Struktur-und Feldnamen identisch mit den XCOFF32 -Namen, aber die Feldgrößen und Offsets können abweichen.

XCOFF32 und XCOFF64 -Deklarationen auswählen

Zur Auswahl von Strukturdefinitionen für XCOFF32 und XCOFF64sollte eine Anwendung sowohl die Vorprozessormakros __XCOFF32__ als auch __XCOFF64__definieren. Dadurch werden Strukturen für beide Arten von XCOFF-Dateien definiert. Strukturen und Typdefinitionsnamen für XCOFF64 -Dateien erhalten das Suffix "_64". (Details finden Sie in den Headerdateien.)

XCOFF-Hybriddeklarationen auswählen

Eine Anwendung kann einzelne Strukturen auswählen, die Felddefinitionen für XCOFF32 -und XCOFF64 -Dateien enthalten. Für Felder, die in XCOFF32 -und XCOFF64 -Definitionen dieselbe Größe und denselben Offset haben, werden die Feldnamen beibehalten. Für Felder, deren Größe oder Offset zwischen XCOFF32 -und XCOFF64 -Definitionen unterschiedlich ist, haben die XCOFF32 -Felder das Suffix "32", die XCOFF64 -Felder das Suffix "64". Zur Auswahl von Hybridstrukturdefinitionen muss eine Anwendung das Vorprozessormakro __XCOFF_HYBRID__definieren. Beispiel: Die Symboltabellendefinition (in /usr/include/syms.h) hat den Namenn_offset32für das Feld n_offset für XCOFF32und den Namenn_offset64für das Feld n_offset für XCOFF64verwendet.

Informationen zu XCOFF

Assemblers und Compiler erzeugen XCOFF-Objektdateien als Ausgabe. Der Binder kombiniert einzelne Objektdateien zu einer ausführbaren XCOFF-Datei. Das Systemladeprogramm liest eine ausführbare XCOFF-Datei, um ein ausführbares Speicherimage eines Programms zu erstellen. Der symbolische Debugger liest eine ausführbare XCOFF-Datei, um symbolischen Zugriff auf Funktionen und Variablen eines ausführbaren Speicherimages bereitzustellen.

Eine XCOFF-Datei enthält die folgenden Teile:

• Ein zusammengesetzter Header, der aus folgenden Elementen besteht:
  • Ein Dateiheader
  • Ein optionaler Zusatzheader
  • Abschnittsüberschriften, eine für jeden Abschnitt der Rohdaten der Datei
• Rohdatenabschnitte, höchstens einer pro Abschnittsüberschrift
• Optionale Verlagerungsinformationen für einzelne Rohdatenabschnitte
• Optionale Zeilennummerninformationen für einzelne Rohdatenabschnitte
• Eine optionale Symboltabelle
• Eine optionale Zeichenfolgetabelle, die für alle Symbolnamen in XCOFF64 und für Symbolnamen mit mehr als 8 Byte in XCOFF32verwendet wird.

Nicht jede XCOFF-Datei enthält alle Teile. Eine minimale XCOFF-Datei enthält nur den Dateiheader.

Objekt und ausführbare Dateien

Die Struktur von XCOFF-Objektdateien und ausführbaren Dateien ist ähnlich. Eine ausführbare XCOFF-Datei (oder "Modul") muss einen zusätzlichen Header, einen Ladeprogrammabschnittsheader und einen Ladeprogrammabschnitt enthalten.

Der Abschnitt mit den Rohdaten des Ladeprogramms enthält Informationen, die erforderlich sind, um ein Modul dynamisch zur Ausführung in den Speicher zu laden. Beim Laden einer ausführbaren XCOFF-Datei in den Speicher werden die folgenden logischen Segmente erstellt:

• Ein Textsegment (initialisiert über die.textAbschnitt der XCOFF-Datei).
• Ein Datensegment, das aus initialisierten Daten besteht (initialisiert über die.dataAbschnitt der XCOFF-Datei) gefolgt von nicht initialisierten Daten (mit 0 initialisiert). Die Länge der nicht initialisierten Daten wird in der.bssAbschnittsüberschrift der XCOFF-Datei.

Die XCOFF-Dateiorganisation veranschaulicht die Struktur der XCOFF-Objektdatei.

XCOFF-Headerdateien

Die Datei xcoff.h definiert die Struktur der XCOFF-Datei. Die Datei xcoff.h enthält die folgenden Dateien:

Die Datei a.out.h enthält die Datei xcoff.h . Alle XCOFF-Include-Dateien enthalten die Datei xcoff32_64.h .

Weitere Informationen zu Abschnitten der XCOFF-Objektdatei finden Sie unter Abschnitte und Abschnittsüberschriften . Weitere Informationen zur Symboltabelle finden Sie unter "Symboltabelleninformationen" . Weitere Informationen zur Zeichenfolgetabelle finden Sie unter "Zeichenfolgetabelle" . Weitere Informationen zum Abschnitt 'Debug' finden Sie unter Abschnitt 'Debug' .

Verbunddateiheader

In den folgenden Abschnitten werden die Headerkomponenten der zusammengesetzten XCOFF-Datei beschrieben:

• Dateiheader (filehdr.h)
• Zusatzheader (aouthdr.h)
• Abschnittsüberschriften (scnhdr.h)

Dateiheader (filehdr.h)

Die Datei filehdr.h definiert den Dateiheader einer XCOFF-Datei. Der Dateiheader ist 20 Byte lang in XCOFF32 und 24 Byte lang in XCOFF64. Die Struktur enthält die in der folgenden Tabelle aufgeführten Felder.

Felddefinitionen

Zusatzheader (aouthdr.h)

Der Zusatzheader enthält systemabhängige und implementierungsabhängige Informationen, die zum Laden und Ausführen eines Moduls verwendet werden. Die Informationen im Zusatzheader minimieren, wie viel der Datei vom Systemladeprogramm zur Ausführungszeit verarbeitet werden muss.

Der Binder generiert einen Zusatzheader für die Verwendung durch das Systemladeprogramm. Für eine Objektdatei, die nicht geladen wird, sind keine zusätzlichen Header erforderlich. Wenn zusätzliche Header von Compilern und Assemblern generiert werden, werden die Header vom Binder ignoriert.

Die C-Sprachstruktur für den Zusatzheader ist in der Datei aouthdr.h definiert. Der Zusatzheader enthält die in der folgenden Tabelle aufgeführten Felder.

Felddefinitionen

Die folgenden Informationen definieren die zusätzlichen Headerfelder. Bei Einträgen mit zwei Beschriftungen ist die Beschriftung in runden Klammern der Name des alternativen ursprünglichen COFF-Dateiformats a.out .

Section_offset_value=o_entry-s_paddr[o_snentry - 1],

Im Allgemeinen kann eine Objektdatei mehrere Abschnitte eines bestimmten Typs enthalten, aber in einem ladbaren Modul muss genau ein Abschnitt vorhanden sein.text,.data,.bssund.loaderein. Ein ladbares Objekt kann auch ein.tdataAbschnitt und eine.tbssein.

Abschnittsüberschriften (scnhdr.h)

Jeder Abschnitt einer XCOFF-Datei hat einen entsprechenden Abschnittsheader, obwohl einige Abschnittsheader möglicherweise keinen entsprechenden Rohdatenabschnitt haben. Ein Abschnittsüberschrift stellt Identifikations-und Dateizugriffsinformationen für jeden Abschnitt bereit, der in einer XCOFF-Datei enthalten ist. Jeder Abschnittsheader in einer XCOFF32 -Datei ist 40 Byte lang, während XCOFF64 Abschnittsheader 72 Byte lang sind. Die Struktur der Programmiersprache C für eine Abschnittsüberschrift finden Sie in der Datei scnhdr.h . Eine Abschnittsüberschrift enthält die in der folgenden Tabelle aufgeführten Felder.

Felddefinitionen

Die folgenden Informationen definieren die Headerfelder des Abschnitts:

Abschnitte und Abschnittsüberschriften

Abschnittsüberschriften werden definiert, um eine Vielzahl von Informationen zum Inhalt einer XCOFF-Datei bereitzustellen. Programme, die XCOFF-Dateien verarbeiten, erkennen nur einige der gültigen Abschnitte.

Die folgenden Informationen enthalten weitere Informationen zu XCOFF-Dateiabschnitten:

• Abschnitt für Ladeprogramm (loader.h)
• Abschnitt 'Debug'
• Abschnitt für Typüberprüfung
• Abschnitt 'Exception'
• Abschnitt 'Kommentar'

Aktuelle Anwendungen verwenden nicht dies_nameum den Abschnittstyp zu bestimmen. Dennoch werden konventionelle Namen von Systemtools verwendet, wie in der folgenden Tabelle dargestellt.

Einige Felder einer Abschnittsüberschrift werden möglicherweise nicht immer verwendet oder haben eine besondere Verwendung. Dies betrifft die folgenden Felder:

Eine XCOFF-Datei bietet in den folgenden Abschnitten eine besondere Bedeutung:

• Der.text,.dataund.bssAbschnitte und die optionalen.tdataund.tbssAbschnitte, definieren das Speicherabbild des Programms. Die Verlagerungsteile, die dem zugeordnet sind..textund.dataAbschnitte enthalten die vollständigen Informationen zur Binderverlagerung, damit sie für die Ersatzlinkbearbeitung verwendet werden können. Nur die.textist einem Zeilennummernteil zugeordnet. Die dem ausführbaren Code zugeordneten Teile werden von den Compilern und Assemblern erzeugt.
• Der.padDer Abschnitt ist als ein mit Nullen ausgefüllter Abschnitt mit Rohdaten definiert, der verwendet wird, um einen nachfolgenden Abschnitt in der Datei an einer definierten Begrenzung, wie z. B. einer Dateiblockbegrenzung oder einer Systemseitenbegrenzung, auszurichten. Das Auffüllen ist in einer XCOFF-Datei ohne entsprechende Abschnittsüberschrift zulässig, sodass der Binder keine Auffüllabschnittsüberschriften generiert.
• Der.loaderAbschnitt ist ein Abschnitt für Rohdaten, der die dynamischen Ladeprogramminformationen enthält. Dieser Abschnitt wird vom Binder generiert und verfügt über eine eigene eigenständige Symboltabelle und Verlagerungstabelle. Die XCOFF-Symboltabelle enthält keinen Verweis auf diesen Abschnitt.
• Der.debugAbschnitt ist ein Abschnitt für Rohdaten, der so definiert ist, dass er die für den symbolischen Debugger erforderlichen Tabellen-(Symboltabelle) oder Wörterverzeichnisinformationen enthält.
• Der.dwinfo,.dwline,.dwpbnms,.dwpbtyp,.dwarnge,.dwabrev,.dwstr,und.dwrngesAbschnitte sind Abschnitte mit Rohdaten, die so definiert sind, dass sie Symboltabellen-und Quellendateiinformationen für den symbolischen Debugger enthalten.
• Der.typchksection ist ein Rohdatenabschnitt, der so definiert ist, dass er Parameter-und Argumenttypprüfzeichenfolgen enthält.
• Der.exceptAbschnitt ist ein Rohdatenabschnitt, der so definiert ist, dass er die Ausnahmetabellen enthält, die verwendet werden, um die Ursachen für eine Ausnahmebedingung bei der Programmausführung zu identifizieren.
• Der.infoKommentarabschnitt ist ein Rohdatenabschnitt, der so definiert ist, dass er Kommentare oder Daten enthält, die für spezielle Verarbeitungsdienstprogramme von Bedeutung sind.
• Der.debug,.except,.infound.typchkAbschnitte werden von Compilern und Assembler erzeugt. Verweise auf diese Abschnitte oder auf Elemente in diesen Abschnitten stammen aus der XCOFF-Symboltabelle.

Weitere Informationen zu XCOFF-Dateiabschnitten finden Sie unter "Loader Section (loader.h)," "Debug Section," "Type-Check Section," "Exception Section," and "Comment Section."

Laderbereich ( loader.h )

Der Ladeprogrammabschnitt enthält Informationen, die das Systemladeprogramm benötigt, um ein ausführbares XCOFF-Objekt zu laden und zu verlagern. Der Ladeprogrammabschnitt wird vom Binder generiert. Der Ladeprogrammabschnitt hat einens_flagsAbschnittstypflag STYP_LOADER im XCOFF-Abschnittsheader. Nach Konvention.loaderDer Name des Ladeprogrammabschnitts. Die Daten in diesem Abschnitt werden nicht von Einträgen in der XCOFF-Symboltabelle referenziert.

Der Ladeprogrammabschnitt besteht aus den folgenden Teilen:

• Headerfelder
• Symboltabelle
• Verlagerungstabelle
• Dateien-ID-Zeichenfolgen importieren
• Zeichenfolgentabelle für Symbolnamen

Die C-Sprachstruktur für den Ladeprogrammabschnitt finden Sie in der Datei loader.h .

Felddefinitionen für Ladeprogrammheader

In der folgenden Tabelle werden die Headerfelddefinitionen des Ladeprogrammabschnitts beschrieben.

Die folgenden Informationen definieren die Headerfelder des Ladeprogrammabschnitts:

Felddefinitionen für Ladeprogrammsymboltabellen

Die Symboltabelle des Ladeprogrammabschnitts enthält die Symboltabelleneinträge, die das Systemladeprogramm für die Import-und Exportsymbolverarbeitung und die dynamische Verlagerungsverarbeitung benötigt.

Die Datei loader.h definiert die Symboltabellenfelder. Jeder Eintrag ist 24 Byte lang.

Es gibt fünf implizite externe Symbole, jeweils eines für die.text,.data,.bss,.tdataund.tbssAbschnitte. Diese Symbole werden von den Einträgen in der Umzugstabelle mit den Symboltabellen-Indexwerten 0, 1, 2, -1 bzw. -2 referenziert.

Die Symboltabellenfelder sind:

Bit 0     0x80  Reserved.
Bit 1     0x40  Specifies an imported symbol.
Bit 2     0x20  Specifies an entry point descriptor symbol.
Bit 3     0x10  Specifies an exported symbol.
Bit 4     0x08  Specifies a weak symbol.
Bits 5-7  0x07 Symbol type--see below.

l_smclas

l_ifile

l_parm

Felddefinitionen der Verlagerungstabelle für Ladeprogramm

Die Loader Section Relocation Table Structure enthält alle Verlagerungsinformationen, die das Systemladeprogramm benötigt, um eine ausführbare XCOFF-Datei ordnungsgemäß zu verlagern, wenn sie geladen wird. Die Datei loader.h definiert die Felder der Verlagerungstabelle. Jeder Eintrag in der Verlagerungstabelle für den Ladeprogrammabschnitt ist 12 Byte lang in XCOFF32und 16 Byte lang in XCOFF64. Die Felder l_vaddr, l_symndxundl_rtype haben dieselbe Bedeutung wie die entsprechenden Felder der regulären Verlagerungseinträge, die in der Datei reloc.h definiert sind. Weitere Informationen zu Verlagerungseinträgen finden Sie unter Verlagerungsinformationen für XCOFF-Datei (reloc.h).

Die Datei loader.h definiert die folgenden Felder:

Loader Import Datei ID Name Tabelle Definition

Die Zeichenfolgen für die ID der Importdatei im Ladeprogrammabschnitt eines Moduls enthalten eine Liste abhängiger Module, die das Systemladeprogramm laden muss, damit das Modul erfolgreich geladen werden kann. Diese Liste enthält jedoch nicht die Namen der Module, von denen die benannten Module abhängen.

Jeder Name einer Importdatei-ID besteht aus drei durch null begrenzten Zeichenfolgen.

Die erste Importdatei-ID ist ein Standardwert für LIBPATH , der vom Systemladeprogramm verwendet werden soll. Die LIBPATH -Informationen bestehen aus durch Doppelpunkte getrennten Dateipfaden. Es gibt keinen Basis-oder Archiveleintragungsnamen, daher folgen auf den Dateipfad drei Nullbytes.

Jeder Eintrag in der Tabelle mit den Namen der Importdatei-IDs besteht aus:

• Pfadname der Importdatei-ID
• Nullbegrenzer (ASCII-Nullzeichen)
• Basisname der Importdatei-ID
• Nullbegrenzer
• Name des Archivdateimembers für die Importdatei-ID
• Nullbegrenzer

Beispiel:

/usr/lib\0mylib.a\0shr.o\0

Zeichenfolgetabellendefinition für Ladeprogramm

Die Zeichenfolgetabelle des Ladeprogrammabschnitts enthält die Zeichenfolgen für die Parametertypprüfung, alle Symbolnamen für eine XCOFF64 -Datei und die Namen von Symbolen, die länger als 8 Byte sind, für eine XCOFF32 -Datei. Jede Zeichenfolge besteht aus einem 2-Byte-Längenfeld gefolgt von der Zeichenfolge.

Symbolnamen enden auf null. Der Wert im Längenfeld enthält die Länge der Zeichenfolge plus die Länge des Nullabschlusszeichens, aber nicht die Länge des Längenfelds selbst.

Die Zeichenfolgen für die Parametertypüberprüfung enthalten Binärwerte und sind nicht auf null endend. Der Wert im Längenfeld enthält nur die Länge der Zeichenfolge, aber nicht die Länge des Längenfelds selbst.

Die Symboltabelleneinträge des Ladeprogrammabschnitts enthalten einen Byteoffsetwert, der auf das erste Byte der Zeichenfolge und nicht auf das Längenfeld verweist.

Inhalt der Abschnittsüberschrift für Ladeprogramm

Der Inhalt der Abschnittsheaderfelder für den Ladeprogrammabschnitt lautet wie folgt:

Allgemeine Informationen zum XCOFF-Dateiformat finden Sie unter "XCOFF-Objektdateiformat" .

Weitere Informationen zu XCOFF-Dateiabschnitten finden Sie unter "Abschnitte und Abschnittsüberschriften", "Abschnitt" Debug ", " Abschnitt "Typüberprüfung", " " Abschnitt "Ausnahme" und "Abschnitt" Kommentar ".

Debugabschnitt

Der Debugabschnitt enthält den symbolischen Debugger stabstrings (Symboltabellenzeichenfolgen). Sie wird von den Compilern und Assemblern generiert. Es stellt Symbolattributinformationen für die Verwendung durch den symbolischen Debugger bereit. Der Debugabschnitt hat das Abschnittstypflag STYP_DEBUG im XCOFF-Abschnittsheader. Nach Konvention.debugDer Name des Debugabschnitts. Die Daten in diesem Abschnitt werden von Einträgen in der XCOFF-Symboltabelle referenziert. Eine stabstring ist eine auf null endende Zeichenfolge. Jeder Zeichenfolge wird ein 2-Byte-Längenfeld in XCOFF32 oder ein 4-Byte-Längenfeld in XCOFF64vorangestellt.

Felddefinitionen

Die folgenden beiden Felder werden für jede symbolische Debuggerzeichenfolge wiederholt:

• Ein Feld mit einer Länge von 2 Byte (XCOFF32) oder 4 Byte (XCOFF64), das die Länge der Zeichenfolge enthält. Der Wert im Längenfeld enthält die Länge des abschließenden Nullzeichens, aber nicht die Länge des Längenfelds selbst.
• Die symbolische Debuggerzeichenfolge.

Informationen zum spezifischen Format der stabstrings finden Sie in den Erläuterungen zur Grammatik des symbolischen Debuggers stabstring .

Inhalt der Kopfzeile des Debugabschnitts

Der Inhalt der Abschnittsheaderfelder für den Debugabschnitt lautet wie folgt:

Allgemeine Informationen zum XCOFF -Dateiformat finden Sie unter "XCOFF Object File Format" .

Weitere Informationen zu XCOFF -Dateiabschnitten finden Sie unter "Abschnitte und Abschnittsüberschriften", "Debugabschnitt", "Typüberprüfungsabschnitt",, "Ausnahmeabschnitt" und "Kommentarabschnitt" .

DWARF-Abschnitte

Die DWARF-Abschnitte enthalten Debuginformationen für den symbolischen Debugger. DWARF ist ein alternatives Debugformat, das anstelle von Debuggerstabstrings verwendet wird. Der Inhalt der verschiedenen DWARF-Abschnitte wird im "DWARF Debugging Information Format" beschrieben, das von www.dwarfstd.orgabgerufen werden kann.

Alle DWARF-Abschnitte haben das primäre Abschnittstypflag STYP_DWARF in der XCOFF-Abschnittsüberschrift. Die Namen konventioneller Abschnitte sind unter "Konventionelle Headernamen"aufgeführt.

Inhalt der Abschnittsüberschrift für DWARF

Der Inhalt der Abschnittsheaderfelder für den Debugabschnitt lautet wie folgt:

Abschnitt "Typüberprüfung"

Der Abschnitt 'type-check' enthält die Hashzeichenfolgen für die Typüberprüfung und wird von Compilern und Assemblern erzeugt. Sie wird vom Binder verwendet, um Variablenabweichungen und Argumentschnittstellenfehler zu erkennen, wenn separat kompilierte Objektdateien verknüpft werden. (Die Hashzeichenfolgen für die Typüberprüfung im Ladeprogrammabschnitt werden verwendet, um diese Fehler vor der Ausführung eines Programms zu erkennen.) Der Abschnitt "type-check" hat das Abschnittstypflag STYP_TYPCHK in der Abschnittsüberschrift XCOFF . Nach Konvention.typchkDer Name des Typprüfungsabschnitts. Die Zeichenfolgen in diesem Abschnitt werden von Einträgen in der Symboltabelle XCOFF referenziert.

Felddefinitionen

Die folgenden beiden Felder werden für jede Parametertypprüfzeichenfolge wiederholt:

• Ein 2-Byte-Längenfeld, das die Länge der Typprüfzeichenfolge enthält. Der im Längenfeld enthaltene Wert enthält nicht die Länge des Längenfelds selbst.
• Die Hashzeichenfolge für die Parametertypprüfung.

Typcodierung und -prüfung für Datenformat

Die Hashzeichenfolgen für die Typüberprüfung werden verwendet, um Fehler vor der Ausführung eines Programms zu erkennen. Informationen zu allen externen Symbolen (Daten und Funktionen) werden von den Compilern codiert und anschließend zur Bindezeit und Ladezeit auf Konsistenz überprüft. Die Zeichenfolgen für die Typüberprüfung sind so konzipiert, dass sie die maximale Überprüfung, die für die Semantik jeder einzelnen unterstützten Sprache erforderlich ist, erzwingen und Anwendungen schützen, die in mehreren Sprachen geschrieben sind.

Der Typcodierungs-und Prüfmechanismus verfügt über eine vierteilige Hashcodierung, die eine gewisse Flexibilität bei der Prüfung bietet. Der Mechanismus verwendet auch einen eindeutigen Wert, UNIVERSAL, der einem beliebigen Code entspricht. Der UNIVERSAL-Hashwert kann als Escapemechanismus für Assemblierprogramme oder für Programme verwendet werden, in denen Typinformationen oder Subroutinenschnittstellen möglicherweise nicht bekannt sind. Der UNIVERSAL-Hash besteht aus vier leeren ASCII-Zeichen (0x20202020) oder vier Nullzeichen (0x00000000).

Die folgenden Felder sind dem Typcodierungs-und Prüfmechanismus zugeordnet:

Inhalt der Abschnittsüberschrift

Der Inhalt der Abschnittsheaderfelder für den Typprüfungsabschnitt lautet wie folgt:

Allgemeine Informationen zum XCOFF -Dateiformat finden Sie unter "XCOFF Object File Format" .

Weitere Informationen zu XCOFF -Dateiabschnitten finden Sie unter "Abschnitte und Abschnittsüberschriften", "Abschnitt für Debugging", "Abschnitt für Typüberprüfung", "Abschnitt für Ausnahmen" und "Abschnitt für Kommentare" .

Ausnahmeabschnitt

Der Ausnahmeabschnitt enthält Adressen von Trapinstruktionen, Quellensprachenkennungscodes und Trapursachencodes. Dieser Abschnitt wird von Compilern und Assemblern erstellt und während oder nach der Laufzeit verwendet, um die Ursache für das Auftreten eines bestimmten Traps oder einer Ausnahmebedingung zu ermitteln. Der Ausnahmeabschnitt hat das Abschnittstypflag STYP_EXCEPT im XCOFF-Abschnittsheader. Nach Konvention.exceptist der Name des Ausnahmeabschnitts. Daten im Ausnahmeabschnitt werden von Einträgen in der XCOFF-Symboltabelle referenziert.

Ein Ausnahmetabelleneintrag mit dem Wert 0 in dere_reasonFeld enthält den Symboltabellenindex für den Symboltabelleneintrag C_EXT, C_WEAKEXT oder C_HIDEXT einer Funktion. Der Verweis von der Symboltabelle auf einen Eintrag in der Ausnahmetabelle erfolgt über den Eintrag der Zusatzsymboltabelle der Funktion. Weitere Informationen zu diesem Eintrag finden Sie unter "csect Auxiliary Entry for C_EXT, C_WEAKEXT and C_HIDEXT Symbols".

Die C-Sprachstruktur für die Ausnahmeabschnitteinträge finden Sie in der Datei exceptab.h .

Die Einträge im Ausnahmeabschnitt enthalten die Felder, die in den folgenden Tabellen aufgeführt sind.

Felddefinitionen

Im Folgenden werden die Felder definiert, die im Ausnahmeabschnitt aufgelistet sind:

Inhalt der Abschnittsüberschrift

Die folgenden Felder sind der Inhalt der Abschnittsheaderfelder für den Ausnahmeabschnitt.

Allgemeine Informationen zum XCOFF -Dateiformat finden Sie unter "XCOFF Object File Format" .

Weitere Informationen zu XCOFF -Dateiabschnitten finden Sie unter "Abschnitte und Abschnittsüberschriften", "Abschnitt für Debugging", "Abschnitt für Typüberprüfung", "Abschnitt für Ausnahmen" und "Abschnitt für Kommentare" .

Kommentarabschnitt

Der Kommentarabschnitt enthält Informationen mit besonderer Verarbeitungsbedeutung für eine Anwendung. Dieser Abschnitt kann von Compilern und Assemblern erstellt und während oder nach der Laufzeit verwendet werden, um einen besonderen Verarbeitungsbedarf einer Anwendung zu erfüllen. Der Kommentarabschnitt hat das Abschnittstypflag STYP_INFO in der Abschnittsüberschrift XCOFF . Nach Konvention.infoist der Name des Kommentarabschnitts. Daten im Kommentarabschnitt werden aus C_INFO -Einträgen in der Symboltabelle XCOFF referenziert.

Der Inhalt eines Kommentarabschnitts besteht aus wiederholten Instanzen eines 4-Byte-lengthgefolgt von einer Bytefolge (die einen beliebigen Binärwert enthält). Die Länge der einzelnen Zeichenfolgen wird in den vorhergehenden 4 Byte gespeichert.lengtherlaubt. Die Bytefolge muss nicht durch ein Nullzeichen oder ein anderes Sonderzeichen beendet werden. Die angegebene Länge enthält nicht die Länge derlengthFeld selbst. Die Länge 0 ist zulässig. Das Format der Bytefolge ist nicht angegeben.

Auf eine Kommentarabschnittszeichenfolge wird von einem Eintrag in der Symboltabelle XCOFF verwiesen. Die Speicherklasse des Symbols, das einen Verweis erstellt, ist C_INFO. Weitere Informationen finden Sie unter "Symboltabellenfeldinhalte nach Speicherklasse" .

Ein Symbol C_INFO ist dem nächsten vorangestellten Symbol C_FILE, C_EXT, C_WEAKEXToder C_HIDEXT zugeordnet.

Inhalt der Abschnittsüberschrift

Die folgenden Felder sind der Inhalt der Abschnittsüberschriftenfelder für den Kommentarabschnitt.

Allgemeine Informationen zum XCOFF -Dateiformat finden Sie unter "XCOFF Object File Format" .

Weitere Informationen zu XCOFF-Dateiabschnitten finden Sie unter "Abschnitte und Abschnittsüberschriften", "Abschnitt" Debug ", " Abschnitt "Typüberprüfung", " " Abschnitt "Ausnahme" und "Abschnitt" Kommentar ".

Verlagerungsinformationen für XCOFF-Datei (reloc.h)

Einige Abschnitte enthalten Informationen zur Verlagerung. Ders_relptrFeld in der Abschnittsüberschrift gibt den Dateioffset zu den Verlagerungseinträgen für den Abschnitt an. Der Binder verwendet die Verlagerungsinformationen zum Ändern von Adresskonstanten und anderen verschiebbaren Werten, wenn einzelne XCOFF-Objektdateien verknüpft werden, um eine ausführbare XCOFF-Datei zu erstellen.

Compiler und Assembler generieren die Verlagerungseinträge für die Informationen für Abschnitte. Der Binder generiert Verlagerungsinformationen, die in der.loaderAbschnitt, wie vom Systemladeprogramm benötigt.

Jeder Verlagerungseintrag ist 10 Byte lang (14 für XCOFF64). (Ein Verlagerungseintrag in der.loaderDer Abschnitt ist 12 Byte lang (16 für XCOFF64) und wird in der Beschreibung des Ladeprogrammabschnitts in diesem Dokument erläutert. Weitere Informationen finden Sie unter Felddefinitionen für Verlagerungstabelle . Sie finden die Struktur der Programmiersprache C für einen Verlagerungseintrag in der Datei reloc.h . Ein Verlagerungseintrag enthält die in der folgenden Tabelle aufgeführten Felder.

Die Verlagerungseinträge für einen Abschnitt müssen in aufsteigender Adressreihenfolge angegeben werden.

(Der Ladeprogrammabschnitt enthält eine einzelne Gruppe von Verlagerungseinträgen, die vom Systemladeprogramm verwendet werden. Daher ist in jedem Verlagerungseintrag eine Abschnittsnummer erforderlich, um den Abschnitt zu identifizieren, der geändert werden muss.)

Felddefinitionen

Zusätzliche Verlagerungsfunktionen

Standardverfahren ist es, Verlagerungsinformationen nur für nicht aufgelöste Referenzen oder Referenzen zwischen unterschiedlichen Abschnitten aufzubewahren. Sobald eine Referenz aufgelöst ist, werden die Verlagerungsinformationen gelöscht. Dies ist für eine inkrementelle Bindung und ein festes Adressraummodell ausreichend. Um die Funktionalität zum erneuten Binden und zum Verarbeiten eines verschiebbaren Adressraummodells bereitzustellen, werden die Verlagerungsinformationen nicht aus einer XCOFF -Datei gelöscht.

Allgemeine Informationen zum XCOFF -Dateiformat finden Sie unter "XCOFF Object File Format" .

Weitere Informationen zu Definitionen von Verlagerungsfeldtabellen finden Sie unter "Verlagerungstabellenfelddefinitionen" im Abschnitt zum Ladeprogramm.

Zeilennummer-Informationen für XCOFF-Datei (linenum.h)

Zeilennummerneinträge werden vom symbolischen Debugger verwendet, um Code auf Quellenebene zu debuggen. Wenn vorhanden, gibt es einen einzelnen Zeilennummerneintrag für jede Quellenzeile, die einen symbolischen Debugger-Unterbrechungspunkt haben kann. Die Zeilennummern werden nach Funktion gruppiert. Der Anfang jeder Funktion wird durch diel_lnnoFeld mit dem Wert 0. Das erste Feld,l_symndxist der Symboltabellenindex für den Symboltabelleneintrag C_EXT, C_WEAKEXToder C_HIDEXT für die Funktion.

Jeder Zeilennummerneintrag ist sechs Byte lang. Die C-Sprachstruktur für einen Zeilennummerneintrag finden Sie in der Datei linenum.h . Ein Zeilennummerneintrag enthält die in den folgenden Tabellen gezeigten Felder.

Felddefinitionen

Die folgende Liste definiert die Zeilennummerneinträge:

Allgemeine Informationen zum XCOFF -Dateiformat finden Sie unter "XCOFF Object File Format" .

Informationen zum Debugging finden Sie im Abschnitt 'Debug' .

Informationen zur Symboltabelle

Für eine XCOFF -Datei ist eine zusammengesetzte Symboltabelle definiert. Die Symboltabelle enthält Informationen, die sowohl vom Binder (externe Symbole) als auch vom symbolischen Debugger (Funktionsdefinitionen und interne und externe Symbole) benötigt werden.

Die Symboltabelle besteht aus einer Liste von 18-Byte-Einträgen mit fester Länge. Jedes Symbol, das in der Symboltabelle dargestellt wird, besteht aus mindestens einem Eintrag mit fester Länge, auf den einige Hilfseinträge gleicher Größe folgen.

Weitere Informationen zur Symboltabelle finden Sie in den folgenden Abschnitten:

• Zusatzinformationen zur Symboltabelle
• Symboltabellenfeldinhalte nach Speicherklasse
• Zeichenfolgetabelle

Für jedes externe Symbol ist mindestens ein Hilfseintrag erforderlich, der zusätzliche Informationen zum externen Symbol enthält. Es gibt drei Haupttypen externer Symbole, die für den Binder von Interesse sind und die folgenden Funktionen ausführen:

• Definieren Sie austauschbare Einheiten oder csects.
• Definieren Sie die externen Namen für Funktionen oder Eingangspunkte in csects.
• Verweisen Sie auf die Namen externer Funktionen in einem anderen XCOFF -Objekt.

Für Symbole, die eine austauschbare Einheit (csect) definieren, definiert ein csect-Zusatzeintrag die Länge und die Speicherzuordnungsklasse des csect. Für Symbole, die externe Namen für Funktionen in einem csect definieren, zeigt der csect-Zusatzeintrag auf den übergeordneten csect, die Informationen zur Parametertypprüfung und die symbolischen Debuggerinformationen für die Funktion. Bei Symbolen, die auf den Namen einer externen Funktion verweisen, identifiziert ein csect-Hilfseintrag das Symbol als externe Referenz und verweist auf Informationen zur Parametertypprüfung.

Symboltabelleninhalt

Eine XCOFF-Symboltabelle hat den folgenden allgemeinen Inhalt und die folgende Reihenfolge:

• Die Symboltabelleneinträge C_FILE , die zum Einklammern aller Symboltabelleneinträge verwendet werden, die einer bestimmten Quellendatei zugeordnet sind.
• Die Symboltabelleneinträge des Kommentarabschnitts C_INFO , die den Geltungsbereich der Quellendatei haben. Diese folgen dem Eintrag C_FILE , aber vor dem ersten Eintrag in der Symboltabelle der csect-Definition.
• Die symbolischen Debuggersymboltabelleneinträge, die sich im Dateibereich befinden. Diese folgen dem Eintrag C_FILE , aber vor dem ersten csect-Eintrag.
• Die C_DWARF -Symbole für DWARF -Debuginformationen. Diese folgen dem Eintrag C_FILE und zwischen dem Eintrag C_FILE und den zugehörigen C_DWARF -Symbolen sollten keine csect-Symbole angezeigt werden.
• Einträge in der Symboltabelle für die csect-Definition, die zum Definieren und Einklammern aller Symbole verwendet werden, die in einem csect enthalten sind.
• C_INFO Symboltabelleneinträge im Kommentarabschnitt, die auf einen Symboltabelleneintrag in der Csect-Definition folgen, werden diesem Csect zugeordnet.
• Alle symbolischen Debugger-Symboltabelleneinträge, die auf einen Eintrag in der Symboltabelle für die csect-Definition oder einen Bezeichnungssymboltabelleneintrag folgen, werden diesem csect oder dieser Bezeichnung zugeordnet.

Die Reihenfolge der Symboltabelle muss von den Compilern und Assemblern so angeordnet werden, dass sie sowohl die Anforderungen des symbolischen Debuggers erfüllen als auch eine effektive Verwaltung der verschiedenen Abschnitte der Objektdatei durch den Binder als Ergebnis solcher Binderaktionen wie Garbage-Collection, inkrementelles Binden und erneutes Binden ermöglichen. Diese Reihenfolge ist für den Binder erforderlich, damit beim Löschen oder Ersetzen eines csect alle Symboltabelleninformationen, die dem csect zugeordnet sind, ebenfalls gelöscht oder ersetzt werden können. Wenn alle csects, die einer Quellendatei zugeordnet sind, gelöscht oder ersetzt werden, können alle Symboltabellen und zugehörigen Informationen, die der Datei zugeordnet sind, ebenfalls gelöscht oder ersetzt werden.

Symboltabellenlayout

Das folgende Beispiel zeigt die allgemeine Reihenfolge der Symboltabelle.

un_external      Undefined global symbols

.file                Prolog --defines stabstring compaction level
.file                Source file 1
  .info              Comment section reference symbol with file scope
  stab               Global Debug symbols of a file
  dwarf	             DWARF Information of a file
  csect              Replaceable unit definition (code)
     .info           Comment section reference symbol with csect scope
     function        Local/External function
         stab        Debug and local symbols of function
     function        Local/External function
         stab        Debug and local symbols of function
  ..............
  csect              Replaceable unit definition (local statics)
         stab        Debug and local statics of file
  ..............
  csect              Relocatable unit definition (global data)
         external    Defined global symbol
         stab        Debug info for global symbol
  ..............
.file                Source file 2
  stab               Global Debug symbols of a file
  dwarf	             DWARF Information of a file
  csect              Replaceable unit definition (code)
         function    Local/External function
             stab    Debug and local symbols of function
  ..............
  csect              Replaceable unit definition (local statics)
      stab           Debug and Local statics of file
  ..............
  csect              Replaceable unit definition (global data)
      external       Defined global symbol
          stab       Debug info for global symbol
.file                Source file
  ..............

Symboltabelleneintrag (syms.h)

Jedes Symbol hat unabhängig von Speicherklasse und -typ einen Eintrag im festen Format in der Symboltabelle. Außerdem können einige Symboltypen zusätzliche (zusätzliche) Symboltabelleneinträge enthalten, die unmittelbar auf den Eintrag im festen Format folgen. Jeder Eintrag in der Symboltabelle ist 18 Byte lang. Die C-Sprachstruktur für einen Symboltabelleneintrag befindet sich in der Datei syms.h . Der Index für den ersten Eintrag in der Symboltabelle ist 0. Die folgende Tabelle zeigt die Struktur des Teils mit festem Format jedes Symbols in der Symboltabelle.

Felddefinitionen

Im Folgenden werden die Eingabefelder der Symboltabelle definiert:

Allgemeine Informationen zum XCOFF-Dateiformat finden Sie unter "XCOFF-Objektdateiformat" .

Zusätzliche Informationen zur Symboltabelle

Die Symboltabelle enthält zusätzliche Einträge, die ergänzende Informationen zu einem Symbol bereitstellen. Die Zusatzeinträge für ein Symbol folgen dem zugehörigen Symboltabelleneintrag. Die Länge jedes Zusatzeintrags entspricht der eines Symboltabelleneintrags (18 Byte). Das Format und die Menge der Zusatzeinträge hängen von der Speicherklasse ab (n_sclass) und Typ (n_type) des Symboltabelleneintrags.

In XCOFF32müssen Symbole mit der Speicherklasse C_EXT, C_WEAKEXT oder C_HIDEXT und mehreren Zusatzeinträgen den Zusatzeintrag csect als letzten Zusatzeintrag haben. In XCOFF64x_auxtypeFeld jedes Hilfssymboltabelleneintrags unterscheidet die Symbole, aber die Konvention besteht darin, den csect-Hilfssymboltabelleneintrag zuletzt zu generieren.

Dateihilfseintrag für C_FILE-Symbole

Der Eintrag für die Zusatzsymboltabelle der Datei ist so definiert, dass er den Namen der Quellendatei und die compilerbezogenen Zeichenfolgen enthält. Ein Dateihilfseintrag ist optional und wird zusammen mit einem Symboltabelleneintrag mit dem Speicherklassenwert C_FILEverwendet. Die C-Sprachstruktur für einen Dateihilfseintrag befindet sich in der Struktur x_file in der Datei syms.h .

Das Symbol C_FILE stellt Informationen zum Quellendateinamen, zur Quellensprachen-ID und zur CPU-Versions-ID sowie optional zur Compilerversion und zur Zeitmarke bereit.

Dern_typeFeld des Symboltabelleneintrags gibt die Quellensprache der Quellendatei und die CPU-Versions-ID der kompilierten Objektdatei an. Die Feldinformationen lauten wie folgt:

Felddefinitionen

Im Folgenden werden die oben aufgeführten Felder definiert:

Wird der Dateizusatzeintrag nicht verwendet, ist der Symbolname der Name der Quellendatei. Wird der Zusatzeintrag für die Datei verwendet, muss der Symbolname.file, und der erste zusätzliche Dateieintrag (nach Konvention) enthält den Namen der Quellendatei. Für einen bestimmten Symboltabelleneintrag sind mehrere zusätzliche Dateieinträge zulässig. Dern_numauxenthält die Anzahl der zusätzlichen Dateieinträge.

csect-Zusatzeintrag für die Symbole C_EXT, C_WEAKEXT und C_HIDEXT

Der Zusatzeintrag csect gibt csects (Abschnittsdefinitionen), Eingangspunkte (Beschriftungsdefinitionen) und externe Referenzen (Beschriftungsdeklarationen) an. Für jeden Symboltabelleneintrag mit dem Speicherklassenwert C_EXT, C_WEAKEXToder C_HIDEXTist ein csect-Zusatzeintrag erforderlich. Weitere Informationen finden Sie unter "Symboltabelleneintrag (syms.h)" Gemäß Konvention muss der csect-Zusatzeintrag in einer XCOFF32 -Datei der letzte Zusatzeintrag für jedes externe Symbol sein, das mehrere Zusatzeinträge enthält. Die C-Sprachstruktur für einen csect-Hilfseintrag finden Sie in der Struktur x_csect in der Datei syms.h .

Felddefinitionen

Zusatzeinträge für die Symbole C_EXT, C_WEAKEXT und C_HIDEXT

Einträge in der Zusatzsymboltabelle werden in XCOFF definiert und enthalten Referenz-und Größeninformationen, die einer definierten Funktion zugeordnet sind. Diese Zusatzeinträge werden durch Compiler und Assembler zur Verwendung durch die symbolischen Debugger erzeugt. In XCOFF32enthält ein Symboltabelleneintrag für Hilfsfunktionen die erforderlichen Informationen. In XCOFF64kann sowohl ein externer Funktionseintrag als auch ein externer Zusatzeintrag erforderlich sein. Wenn beide Hilfseinträge für ein einzelnes Symbol C_EXT, C_WEAKEXToder C_HIDEXT generiert werden,x_sizeundx_endndxFelder müssen dieselben Werte haben.

Der Eintrag für die Funktionszusatzsymboltabelle ist in der folgenden Tabelle definiert.

Felddefinitionen

Im Folgenden werden die Felder definiert, die in der Tabelle "Format des zusätzlichen Funktionseintrags" aufgelistet sind:

Der Eintrag für die Zusatzsymboltabelle für Ausnahmebedingungen, der nur in XCOFF64 definiert ist, wird in der folgenden Tabelle gezeigt.

Felddefinitionen

Im Folgenden werden die Felder definiert, die in der Tabelle "Exception Auxiliary Entry Format" aufgelistet sind:

Zusätzliche Einträge für die Symbole C_BLOCK und C_FCN blockieren

Der Symboleintrag für die Zusatzsymboltabelle wird in XCOFF definiert, um Informationen zu den Anfangs-und Endblöcken von Funktionen bereitzustellen. Der Symbolhilfssymboltabelleneintrag wird von Compilern zur Verwendung durch die symbolischen Debugger erzeugt.

Felddefinitionen

Im Folgenden werden die obigen Felder definiert:

Zusatzeintrag im Abschnitt für das Symbol C_STAT

Die ID des Eintrags für die Zusatzsymboltabelle für Abschnitte wird in XCOFF32 definiert, um Informationen in der Symboltabelle über die Größe von Abschnitten bereitzustellen, die von einem Compiler oder Assembler erzeugt wurden. Die Generierung dieser Informationen durch einen Compiler ist optional und wird vom Binder ignoriert und entfernt.

Felddefinitionen

Die folgende Liste definiert die Felder:

Allgemeine Informationen zum XCOFF-Dateiformat finden Sie unter "XCOFF-Objektdateiformat" . Weitere Informationen zur Symboltabelle finden Sie unter "Symboltabelleninformationen" .

Informationen zum Debugging finden Sie im Abschnitt 'Debug' .

SECT-Zusatzeintrag für das Symbol C_DWARF

Der Eintrag für die SECT-Zusatzsymboltabelle wird definiert, um in der Symboltabelle Informationen zur Größe des Abschnitts bereitzustellen, der durch das Symbol C_DWARF dargestellt wird.

Felddefinitionen

Die folgende Liste definiert die Felder:

Symboltabellenfeldinhalt nach Speicherklasse

Dieser Abschnitt definiert den Inhalt der Symboltabellenfelder für jede der definierten Speicherklassen (n_sclass) die in XCOFF verwendet werden. In der folgenden Tabelle sind Speicherklasseneinträge in alphabetischer Reihenfolge aufgelistet. Weitere Informationen finden Sie unter "Symboltabelleneintrag (syms.h)"

Speicherklassen nach Verwendung und Symbolwertklassifizierung

Im Folgenden sind die Speicherklassen aufgeführt, die vom Binder verwendet und verlagert wurden. Die Symbolwerte (n_value) sind Adressen.

Nachfolgend sind Speicherklassen aufgeführt, die vom Binder und symbolischen Debugger oder von anderen Dienstprogrammen für den Dateigeltungsbereich und den Dateizugriff verwendet werden:

Im Folgenden sind die Speicherklassen aufgeführt, die nur für das symbolische Debugging vorhanden sind:

Allgemeine Informationen zum XCOFF-Dateiformat finden Sie unter "XCOFF-Objektdateiformat" . Weitere Informationen zur Symboltabelle finden Sie unter "Symboltabelleninformationen" .

Informationen zum Debugging finden Sie im Abschnitt 'Debug' .

Zeichenfolgetabelle

In XCOFF32enthält die Zeichenfolgetabelle die Namen von Symbolen, die länger als 8 Byte sind. In XCOFF64enthält die Zeichenfolgetabelle die Namen aller Symbole. Wenn die Zeichenfolgetabelle vorhanden ist, enthalten die ersten 4 Byte die Länge (in Byte) der Zeichenfolgetabelle einschließlich der Länge dieses Längenfelds. Der Rest der Tabelle ist eine Folge von auf null endenden ASCII-Zeichenfolgen. Wenn dasn_zeroesFeld im Symboltabelleneintrag ist 0, dann wird dien_offsetgibt die relative Byteadresse in der Zeichenfolgetabelle des Namens des Symbols an.

Wenn eine Zeichenfolgetabelle nicht verwendet wird, kann sie vollständig weggelassen werden oder es kann eine Zeichenfolgetabelle verwendet werden, die nur aus dem Längenfeld (mit dem Wert 0 oder 4) besteht. Der Wert 4 ist vorzuziehen. Die folgende Tabelle zeigt die Organisation der Zeichenfolgetabelle.

Allgemeine Informationen zum XCOFF -Dateiformat finden Sie unter "XCOFF Object File Format" .

dbx-Stabstrings

Der Debugabschnitt enthält den symbolischen Debugger stabstrings (Symboltabellenzeichenfolgen). Sie wird von den Compilern und Assemblern generiert. Es stellt Symbolattributinformationen für die Verwendung durch den symbolischen Debugger bereit.

Eine allgemeine Beschreibung finden Sie im Abschnitt "Debug" .

Stabstring-Terminalsymbole

Stabstring-Grammatik

REALs können Leerzeichen vorangestellt werden und STRINGs können beliebige Zeichen enthalten, einschließlich Null und Leerzeichen. Andernfalls enthält eine stabstring-Zeichenfolge keine Null-oder Leerzeichen.

Lange Tabellenzeichenfolgen können zur einfacheren Handhabung auf mehrere Symboltabelleneinträge aufgeteilt werden. In der stabstring-Grammatik gibt ein # (Nummernzeichen) einen Punkt an, an dem eine stabstring fortgesetzt werden kann. Eine Fortsetzung wird durch die Verwendung des? (Fragezeichen) oder \ als letztes Zeichen in der Zeichenfolge. Der nächste Teil der Tabellenzeichenfolge ist der Name des nächsten Symboltabelleneintrags. Wenn eine Alternative für eine Produktion leer ist, zeigt die Grammatik das Schlüsselwort/*EMPTY*/.

Die folgende Liste enthält die stabstring-Grammatik:

Stabstring:

Basisstruktur von stabstring:

NAME: Klasse

Name des Objekts gefolgt von Objektklassifikation

:Klasse

Nicht benannte Objektklassifikation.

Klasse:

Objektklassifikationen:

c = Konstante ;

Konstantenobjekt

NamedType

Benutzerdefinierte Typen und Tags

Parameter

Argument für Unterprogramm

Prozedur

Unterprogrammdeklaration

Variable

Variable im Programm

Kennsatz

Objekt beschriften.

Konstante:

Konstantendeklarationen

b OrdValue

Boolesche Konstante

OrdValue

Zeichenkonstante

e TypeID, OrdValue

Aufzählungskonstante

i GANZZAHL

Ganzzahlige Konstante

REAL

Dezimale oder binäre Gleitkommakonstante

s ZEICHENFOLGE

Zeichenfolgekonstante

C REAL, REAL

Komplexe Konstante

S TypeID, NumElements, NumBits, BitPattern

Konstante festlegen.

OrdValue:

Zugeordneter numerischer Wert: INTEGER

NumElements:

Anzahl der Elemente in der Gruppe: INTEGER

NumBits:

Anzahl der Bits im Element: INTEGER

NumBytes:

Anzahl Byte im Element: INTEGER

BitPattern:

Hexadezimale Darstellung, bis zu 32 Byte: HEXINTEGER

NamedType:

Benutzerdefinierte Typen und Tags:

TypeID

Benutzerdefinierter Typ (TYPE oder typedef), mit Ausnahme derjenigen, die für T TypeID gültig sind

T TypeID

Struct-, union-, class-oder enumeration-Tag

Parameter:

Argument für Prozedur oder Funktion:

TypeID

Nach Referenz im allgemeinen Register übergeben

p TypeID

Übergeben nach Wert im Stack

v TypeID

Nach Referenz im Stack übergeben

C TypeID

Konstante, nach Wert im Stack übergeben

D TypeID

Nach Wert im Gleitkommaregister übergeben

R TypeID

Nach Wert im allgemeinen Register übergeben

X TypeID

Nach Wert im Vektorregister übergeben

Vorgehensweise:

Prozedur-oder Funktionsdeklaration:

Proz

Prozedur auf aktueller Scoping-Stufe

Proc , NAME: NAME

Prozedur mit dem Namen 1. NAME, lokal für 2. NAME, wobei 2. NAME sich vom aktuellen Geltungsbereich unterscheidet.

Variable:

Variable im Programm:

TypeID

Lokale (automatische) Variable des Typs TypeID

d TypeID

Variable Registervariable vom Typ TypeID

hTypeID

Statische threadlokale Variable des Typs TypeID

r TypeID

Registriervariable des Typs TypeID

x TypeID

Vektorregistervariable des Typs TypeID

G TypeID

Globale (externe) Variable des Typs TypeID

H TypeID

Globale (externe) Threadlokale Variable des Typs TypeID

S TypeID

Modulvariable des Typs TypeID (C statisch global)

Version TypeID

Eigene Variable des Typs TypeID (C statisch lokal)

Y

Zeigervariable FORTRAN

Z TypeID NAME

FORTRAN, Pointee-Variable

Bezeichnung:

Bezeichnung:

L

Bezeichnungsname.

Prozedur:

Verschiedene Arten von Funktionen und Prozeduren:

f TypeID

Private Funktion des Typs TypeID

g TypeID

Generische Funktion (FORTRAN)

m TypeID

Modul (Modula-2, ext. Pascal)

J TypeID

Interne Funktion des Typs TypeID

F TypeID

Externe Funktion des Typs TypeID

I

(Kapital i) Internes Verfahren

P

Externe Prozedur

Q

Privates Verfahren

TypeID:

Typdeklarationen und Kennungen:

INTEGER

Typennummer des zuvor definierten Typs

INTEGER = TypeDef

Neue Typennummer, beschrieben von TypeDef

INTEGER = TypeAttrs TypeDef

Neuer Typ mit speziellen Typattributen

TypeAttrs:

@ TypeAttrList ;

Hinweis: Typattribute (TypeAttrs) sind zusätzliche Informationen, die einem Typ zugeordnet sind, wie z. B. Ausrichtungseinschränkungen oder Zeigerprüfungssemantik. Das Programm dbx erkennt nur das Attribut size und das Attribut packed . Das Attribut size gibt die Gesamtgröße eines aufgefüllte Elements in einem Array an. Das Attribut packed gibt an, dass ein Typ ein gepackter Typ ist. Alle anderen Attribute werden von dbxignoriert.

TypeAttrList:

Liste der Attribute des Sondertyps:

TypeAttrList ;

@ TypeAttr TypeAttr

TypeAttr:

Spezielle Typattribute:

INTEGER

Begrenzung ausrichten

s INTEGER

Größe in Bit

p GANZZAHL

Zeigerklasse (zur Überprüfung)

P

Gepackter Typ

Sonstige

Alles, was nicht abgedeckt ist, wird vollständig übersprungen

TypeDef:

Basisbeschreibungen von Objekten

INTEGER

Typennummer eines zuvor definierten Typs

b TypeID; # NumBytes

Pascal-Space-Typ

TypeID ; # NumBits

Komplexer Typ TypeID

d TypeID

Datei des Typs TypeID

e EnumSpec;

Aufzählungstyp (Standardgröße, 32 Bit)

g TypeID; # NumBits

Gleitkommatyp der Größe NumBits

D TypeID; # NumBits

Dezimaler Gleitkommatyp der Größe NumBits

Bei i -Typen bezieht sich ModuleName auf das Modul Modula-2 , aus dem es importiert wird.

i NAME: NAME;

Importierter Typ Modulname:Name

i NAME: NAME, TypeID ;

Importierter Typ ModuleName:Name des Typs TypeID

k TypeID

C + + -Konstantentyp

l; #

Verwendung-ist-Index; spezifisch für COBOL

m OptVBaseSpec OptMultiBaseSpec TypeID: TypeID: TypeID;

C + + -Zeiger auf Mitgliedstyp; die erste TypeID ist der Mitgliedstyp; die zweite ist der Typ der Klasse

n TypeID; # NumBytes

Zeichenfolgedatentyp, wobei die maximale Zeichenfolgelänge durch NumBytes angegeben wird

o NAME;

Nicht transparenter Typ

o NAME, TypeID

Nicht transparenter Typ mit Definition von TypeID

w TypeID

Breitzeichen

z TypeID; # NumBytes

Pascal-gstring-Typ

Nutzung

COBOL Bild

I NumBytes # PicSize

(Großbuchstabe i) Index ist Typ; spezifisch für COBOL

K CobolFileDesc;

COBOL Dateideskriptor

M TypeID ; # Gebunden

Typ mit mehreren Instanzen von ' TypeID ' mit einer durch 'Gebunden' angegebenen Länge

N

Pascal Zeichenfolgezeiger

S TypeID

Typgruppe TypeID

* TypeID

Zeiger des Typs TypeID

& TypeID

C + + -Referenztyp

Version TypeID

Flüchtiger C + + -Typ

Z

C + + -Parametertyp mit Auslassungspunkten

Array-Teilbereich ProcedureType

Für Funktionstypen anstelle von Deklarationen

Datensatz

Datensatz-, Struktur-, Union-oder Gruppentypen

EnumSpec:

Liste der aufgezählten Skalare:

EnumList

Aufzählungstyp (C und andere Sprachen)

TypeID : EnumList

C + + -Aufzählungstyp mit sich wiederholendem ganzzahligen Typ

EnumList: Aufzählung

EnumList Aufzählung

Aufzählung:

Beschreibung des skalaren Aufzählungswerts: NAME : OrdValue , #

Array:

Array-Beschreibungen:

TypeID # TypeID

Array; FirstTypeID ist der Index-Typ

Eine TypeID

Array von TypeID öffnen

D INTEGER,TypeID

N-dimensionale dynamische Feldgruppe von TypeID

E INTEGER, TypeID

N-dimensionale dynamische Subarray von TypeID

O INTEGER, TypeID

Neues geöffnetes Array

P TypeID; # TypeID

Gepacktes Array

Unterbereich:

Unterbereichsbeschreibungen:

r TypeID ; # Gebunden ; # Gebunden

Unterbereichstyp (z. B. char, int, \,), Unter-und Obergrenze

Gebunden

Beschreibung der Ober-und Untergrenze

INTEGER

Konstante gebunden

Boundtyp INTEGER

Variable oder dynamische Bindung; Wert ist Adresse oder Offset zur Bindung

J

Grenze ist unbestimmbar (keine Grenzen)

Grenztyp:

Anpassbare Unterbereichsbeschreibungen:

A

Gebunden durch Referenz im Stack übergeben

S

Gebunden nach Wert im statischen Speicher

T

Gebunden durch Wert im Stack übergeben

a

Gebunden durch Referenz im Register übergeben

t

Gebunden durch Wert im Register übergeben

ProcedureType:

Funktionsvariablen (nur 1. Typ C; andere Modula-2 & Pascal)

f TypeID;

Funktionsrückgabetyp TypeID

f TypeID, NumParams; TParamList;

Funktion von N Parametern, die Typ TypeID zurückgeben

p NumParams; TParamList;

Prozedur für N Parameter

R NumParams; NamedTParamList

Pascal, Subroutinenparameter

F TypeID, NumParams; NamedTParamList;

Pascal, Funktionsparameter

NumParams:

Anzahl Parameter in Routine:

GANZE ZAHL.

TParamList:

Typen von Parametern in der Funktionsvariablen Modula-2 :

Parameter

Typ des Parameters und übergehende Methode

Parameter:

Typ und Methode übergeben

TypeID , PassBy ; #

NamedTParamList:

Typen von Parametern in Pascal-Routinenvariable:/*EMPTY*/ NamedTPList

NamedTPList:

NamedTParam NamedTPList NamedTParam

NamedTParam:

Benannter Typ und übergebene Methode: Name : TypeID , PassBy InitBody ; # : TypeID , PassBy InitBody ; # Nicht benannter Parameter

Datensatz:

Typen von Strukturdeklarationen:

• s NumBytes # FieldList ;
• Struktur-oder Datensatzdefinition
• u NumBytes # FieldList ;
• Union
• v NumBytes # FieldListVariantPart ;
• Variantendatensatz
• Y NumBytes ClassKey OptPBV OptBaseSpecList ( ExtendedFieldListOptNameResolutionList;
• C++-Klasse
• G Neudefinition, n NumBits # FieldList ;
• COBOL Gruppe ohne Bedingungen

Gn NumBitsFieldList ;

• G Neudefinition, c NumBits # CondFieldList;
• COBOL Gruppe mit Bedingungen

Gc NumBits CondFieldList;

OptVBaseSpec:

v

ptr-to-mem-Klasse hat virtuelle Basen.

/*LEER*/

Klasse hat keine virtuellen Basen.

OptMultiBaseSpec:

m

Die Klasse ist mehrfachbasiert.

/*LEER*/

Die Klasse ist nicht multibasiert.

OptPBV:

V

Klasse wird immer nach Wert übergeben.

/*LEER*/

Klasse wird nie nach Wert übergeben.

ClassKey:

s

Struct

u

Datentypvariable

c

Klasse

OptBaseSpecList:

/*LEER*/ BaseSpecList

BaseSpecList:

BaseSpec BaseSpecList , BaseSpec

BaseSpec:

VirtualAccessSpec BaseClassOffset : ClassTypeID

BaseClassOffset:

INTEGER

Basisdatensatz-Offset in Byte

ClassTypeID:

TypeID

ID des Basisklassentyps

VirtualAccessSpec:

v AccessSpec

Virtuell

v

Virtuell

AccessSpec

/*LEER*/

GenSpec:

c

Vom Compiler generiert

/*LEER*/

AccessSpec:

i #

Nicht öffentlich

o #

Protected

u #

Öffentliche

AnonSpec:

a

Anonymes Gewerkschaftsmitglied

/*LEER*/

VirtualSpec:

v p

Rein virtuell

v

Virtuell

/*LEER*/

ExtendedFieldList:

ExtendedFieldExtendedFieldList /*LEER*/

ExtendedField:

GenSpec AccessSpec AnonSpec DataMember GenSpec VirtualSpec AccessSpec OptVirtualFuncIndex MemberFunction AccessSpec AnonSpec NestedClass AnonSpec FriendClass AnonSpec FriendFunction

DataMember:

MemberAttrs : Feld ;

MemberAttrs:

IsStatic IsVtblPtr IsVBasePtr

IsStatic:

/*LEER*/

s

Das Member ist statisch.

IsVtblPtr:

/*LEER*/

p INTEGER NAME

Mitglied ist vtbl-Zeiger; NAME ist der externe Name der v-Tabelle.

IsVBasePtr:

/*LEER*/

b

Mitglied ist vbase-Zeiger.

r

Mitglied ist vbase-Selbstzeiger.

Memberfunktion:

[ FuncType MemberFuncAttrs: NAME : TypeID; #

MemberFuncAttrs:

IsStatic IsInline IsConst IsVolatile

IsInline:

/*LEER*/

i

Inline-Funktion

IsConst:

/*LEER*/

k

const (Memberfunktion)

IsVolatile:

/*LEER*/

V

Funktion für flüchtige Member

NestedClass:

N TypeID ; #

FriendClass:

( TypeID ; #

FriendFunction:

] NAME : TypeID ; #

OptVirtualFuncIndex:

/*EMPTY*/GANZZAHL

FuncType:

f

Member-Funktion

c

Konstruktor

d

Destruktor

InitBody:

STRING/*EMPTY*/

OptNameResolutionList:

/*LEER*/ ) NameResolutionList

NameResolutionList: NameResolution

NameResolution , NameResolutionList

NameResolution: MemberName : ClassTypeID

Der Name wird vom Compiler aufgelöst.

Mitgliedsname:

Der Name ist mehrdeutig.

MemberName:

Name

FieldList:

Strukturinhaltsbeschreibungen:

Feld

/*LEER*/

FeldFieldList

Mitglied des Datensatzes oder der Union.

Feld:

Beschreibung des Strukturteildateityps:

NAME : TypeID , BitOffset , NumBits ; #

VariantPart:

Variantenabschnitt des Variantendatensatzes:

[ VTag VFieldList ]

Beschreibung der Variante

VTag:

Datensatzvariantentag:

( Feld

Element des Variantendatensatzes

(NAME:; #

Name des Variantenschlüssels

VFieldList:

Beschreibung des Inhalts von Variantendatensätzen:

VList VFieldList VList

Element des Variantendatensatzes

VList:

Felder für Variantendatensätze:

VField VField VariantPart

Element des Variantendatensatzes

VFeld:

Beschreibung des Elementtyps des Variantendatensatzes:

( VRangeList : FieldList

Variante mit Feldliste

VRangeList:

Liste der Variantenfeldbeschriftungen:

VRange VRangeList, VRange

Element des Variantendatensatzes

VRange:

Beschreibung der Variantenfelder

b OrdValue

Boolesche Variante

OrdValue

Zeichenvariante

e TypeID, OrdValue

Aufzählungsvariante

i GANZZAHL

Ganzzahlige Variante

r TypeID ; Gebunden : Gebunden

Unterbereichsvariante

CondFieldList:

Conditions,#FieldList FeldListe#;

Bedingungen:

/*Empty*/ Bedingung

BitOffset:

Offset in Bit vom Anfang der Struktur: INTEGER

Syntax:

Cobol-Verwendungsbeschreibung: PICStorageType NumBits , EditDescription , PicSize ; Redefinition , PICStorageType NumBits , EditDescription , PicSize ; PICStorageType NumBits , EditDescription , PicSize , # Condition ; Redefinition , PICStorageType NumBits , EditDescription , PicSize , # Bedingung ;

Neudefinition:

COBOL-Neudefinition: r NAME

PICStorageType:

Cobol PICTURE-Typen:

a

Alphabetisch

b

Alphabetisch, bearbeitet

c

Alphanumerisch

d

Alphanumerisch, bearbeitet

e

Numerisch, mit Vorzeichen, nachgestellt, eingeschlossen

f

Numerisch, signiert, abschließend, getrennt

g

Numerisch, mit Vorzeichen, führend, eingeschlossen

h

Numerisch, mit Vorzeichen, führend, getrennt

i

Numerisch, mit Vorzeichen, Standardwert, Firma

j

Numerisch, ohne Vorzeichen, Standardwert, comp

k

Numerisch, gepackt, dezimal, mit Vorzeichen

l

Numerisch, gepackt, dezimal, ohne Vorzeichen

m

Numerisch, ohne Vorzeichen, comp-x

n

Numerisch, ohne Vorzeichen, comp-5

o

Numerisch, signiert, comp-5

p

Numerisch, editiert

q

Numerisch, ohne Vorzeichen

s

Indexiertes Element

t

Zeiger

EditDescription:

COBOL-Editierbeschreibung:

ZEICHENFOLGE

Zeichen in einem Alpha-PIC bearbeiten

INTEGER

Position des Dezimalzeichens in einer numerischen PIC

PicSize:

Länge der COBOL-Beschreibung:

INTEGER

Anzahl wiederholter '9' in numerischer Klausel oder Länge des Editierformats für editierte numerische Zeichen

Bedingung:

Beschreibungen bedingter Variablen:

NAME : INTEGER = q ConditionType, ValueList; #

ConditionType:

Bedingungsbeschreibungen:

ConditionPrimitive , KanjiChar

ConditionPrimitive:

Primitiver Typ der Bedingung:

n Zeichen DecimalSite

Numerisch bedingt

a

Alphanumerisch bedingt

f

Figurativ bedingt

Vorzeichen:

Für Typen mit explizitem Vorzeichen:

+

Positiv

-

Negativ

[^+-]

Nicht angegeben

DecimalSite:

Anzahl der linken Stellen für impliziertes Dezimalzeichen:

INTEGER

KanjiChar:

0 nur, wenn Kanji-Zeichen im Wert: INTEGER

ValueList

Werte, die Bedingungsnamen zugeordnet sind

Wert ValueList Wert

Wert

Den Bedingungsnamen zugeordnete Werte:

INTEGER: ArbitraryCharacters #

Ganze Zahl gibt Länge der Zeichenfolge an

CobolFileDesc:

COBOL Dateibeschreibung: Organisation AccessMethod NumBytes

Unternehmen:

COBOL Dateibeschreibung Organisation:

i

Indiziert

l

Zeile sequenziell

r

Relativ

s

Sequenziell

AccessMethod:

COBOL Dateibeschreibung Zugriffsmethode:

d

Dynamisch

o

Sortieren

r

Zufall

s

Sequenziell

PassBy:

Parameterübergabe:

INTEGER

0 = nach Referenz übergeben; 1 = nach Wert übergeben