KAWA - COFF

COFF
Rozszerzenie nazwy pliku
none, .o , .obj , .lib
magiczny numer 4C 01 dla 386 64 86 dla AMD64 00 02 dla Itanium
Opracowany przez AT&T Corporation
Rodzaj formatu Biblioteki binarne , wykonywalne , obiektowe , współdzielone
Rozszerzony do XCOFF , ECOFF , przenośny plik wykonywalny , plik wykonywalny i możliwy do połączenia

Common Object File Format ( COFF ) jest w formacie do pliku wykonywalnego , kodu wynikowego , a Biblioteka współdzielona pliki komputerowe stosowane w uniksowych systemach. Został wprowadzony w Unix System V , zastąpił poprzednio używany format a.out i stworzył podstawę dla rozszerzonych specyfikacji, takich jak XCOFF i ECOFF , zanim został w dużej mierze zastąpiony przez ELF , wprowadzony z SVR4 . COFF i jego warianty są nadal używane w niektórych systemach typu Unix , w systemie Microsoft Windows ( Portable Executable ), w środowiskach UEFI oraz w niektórych wbudowanych systemach programistycznych.

Historia

Oryginalny format pliku obiektowego Unix a.out nie jest w stanie odpowiednio obsługiwać bibliotek współdzielonych , identyfikacji formatu obcego ani jawnego łączenia adresów. Wraz z rozwojem systemów uniksopodobnych zarówno wewnątrz, jak i na zewnątrz AT&T, pojawiły się różne rozwiązania tych i innych problemów.

COFF został wprowadzony w 1983 roku w systemie UNIX System V firmy AT&T dla 32-bitowych platform innych niż VAX, takich jak 3B20 . Ulepszenia w stosunku do istniejącego formatu AT&T a.out obejmowały dowolne sekcje, jawne deklaracje procesora i jawne powiązanie adresów.

Jednak projekt COFF był zarówno zbyt ograniczony, jak i niecałkowicie określony: istniał limit maksymalnej liczby sekcji, ograniczenie długości nazw sekcji, w tym plików źródłowych, a symboliczne informacje debugowania nie były w stanie obsługiwać języków świata rzeczywistego, takich jak jak C , znacznie mniej nowsze języki, takie jak C ++ , lub nowe procesory. W rezultacie wszystkie implementacje COFF w świecie rzeczywistym z konieczności stanowiły naruszenie normy. Doprowadziło to do wielu rozszerzeń COFF. IBM używał formatu XCOFF w systemie AIX ; DEC , SGI i inni używali ECOFF ; a liczne porty SysV i łańcuchy narzędzi ukierunkowane na rozwój oprogramowania wbudowanego stworzyły własne, niekompatybilne odmiany.

Wraz z wydaniem SVR4, AT&T zastąpiło COFF ELF .

Natomiast rozszerzone wersje COFF być nadal używane dla niektórych platform uniksowych, przede wszystkim w systemach wbudowanych, chyba najbardziej powszechnym użyciu formatu COFF jest dziś w Microsoft „s Portable Executable formacie (PE). Opracowany dla systemu Windows NT format PE (czasami zapisywany jako PE / COFF) wykorzystuje nagłówek COFF dla plików obiektowych oraz jako składnik nagłówka PE dla plików wykonywalnych.

funkcje

Głównym ulepszeniem COFF w stosunku do a.out było wprowadzenie wielu nazwanych sekcji w pliku obiektowym. Różne pliki obiektowe mogą mieć różne numery i typy sekcji.

Symboliczne informacje debugowania

Symboliczne informacje debugowania COFF składają się z symbolicznych (ciągów) nazw funkcji i zmiennych programu oraz informacji o numerze linii, używanej do ustawiania punktów przerwania i wykonywania śledzenia.

Nazwy symboliczne są przechowywane w tabeli symboli COFF. Każda pozycja tablicy symboli zawiera nazwę, klasę pamięci, typ, wartość i numer sekcji. Krótkie nazwy (do 8 znaków) są przechowywane bezpośrednio w tablicy symboli; dłuższe nazwy są przechowywane jako przesunięcie w tablicy ciągów na końcu obiektu COFF.

Klasy pamięci opisują jednostkę typu, którą reprezentuje symbol, i mogą zawierać zmienne zewnętrzne (C_EXT), zmienne automatyczne (stosowe) (C_AUTO), zmienne rejestru (C_REG), funkcje (C_FCN) i wiele innych. Typ symbolu opisuje interpretację wartości jednostki symbolu i zawiera wartości dla wszystkich typów danych C.

Po skompilowaniu z odpowiednimi opcjami plik obiektu COFF będzie zawierał informacje o numerze linii dla każdego możliwego punktu przerwania w sekcji tekstowej pliku obiektowego. Informacja o numerze linii ma dwie formy: w pierwszej, dla każdego możliwego punktu przerwania w kodzie, pozycja tablicy numerów linii rejestruje adres i odpowiadający mu numer linii. W drugiej postaci wpis identyfikuje wpis tablicy symboli reprezentujący początek funkcji, umożliwiając ustawienie punktu przerwania przy użyciu nazwy funkcji.

Zwróć uwagę, że COFF nie był w stanie przedstawić numerów linii ani symboli debugowania dla dołączonego źródła, tak jak w przypadku plików nagłówkowych, które powodują, że informacje debugowania COFF są praktycznie bezużyteczne bez niekompatybilnych rozszerzeń.

Względny adres wirtualny

Kiedy generowany jest plik COFF, zwykle nie wiadomo, gdzie w pamięci zostanie załadowany. Adres wirtualny , gdzie pierwszy bajt pliku zostanie załadowany obraz nazywa adres bazowy . Reszta pliku niekoniecznie jest ładowana w ciągłym bloku, ale w różnych sekcjach .

Względnych adresów wirtualnych (RVA) nie należy mylić ze standardowymi adresami wirtualnymi. Względem adres wirtualny jest adresem wirtualnym obiektu z plikiem, gdy jest on załadowany do pamięci, bez adres bazowy obrazie pliku. Gdyby plik miał być mapowany dosłownie z dysku do pamięci, RVA byłaby taka sama, jak przesunięcie w pliku, ale jest to w rzeczywistości dość niezwykłe.

Zwróć uwagę, że termin RVA jest używany tylko z obiektami w pliku obrazu. Po załadowaniu do pamięci adres bazowy obrazu jest dodawany i używane są zwykłe urządzenia wirtualne.

Problemy

Nagłówek pliku COFF przechowuje datę i godzinę utworzenia pliku obiektowego jako 32-bitową binarną liczbę całkowitą, reprezentującą liczbę sekund, które upłynęły od epoki systemu Unix , 1 stycznia 1970 r. O godzinie 00:00:00 UTC. Daty po 19 stycznia 2038 r. Nie mogą być przechowywane w tym formacie.

Zobacz też

Uwagi

  1. ^ „LIB Reference (Embedded Visual C ++ Programmers Guide)” . msdn.microsoft.com . Zarchiwizowane od oryginału w dniu 2003-08-25 . Źródło 2021-02-04 . CS1 maint: zniechęcony parametr ( link )
  2. ^ "IMAGE_FILE_HEADER (winnt.h) - aplikacje Win32" . 2018-05-12 . Źródło 2021-02-06 .
  3. ^ Microsoft Corporation 2006b

Bibliografia

Linki zewnętrzne