fbpx
Wikipedia

COFF

The Common Object File Format (COFF) is a format for executable, object code, and shared library computer files used on Unix systems. It was introduced in Unix System V, replaced the previously used a.out format, and formed the basis for extended specifications such as XCOFF and ECOFF, before being largely replaced by ELF, introduced with SVR4. COFF and its variants continue to be used on some Unix-like systems, on Microsoft Windows (Portable Executable), in UEFI environments and in some embedded development systems.

COFF
Filename extension
none, .o, .obj, .lib[1]
Internet media typeapplication/x-coff, application/x-coffexec
Magic number
Developed byAT&T Corporation
Type of formatBinary, executable, object, shared libraries
Extended toXCOFF, ECOFF, Portable Executable, Executable and Linkable Format

History edit

The original Unix object file format a.out is unable to adequately support shared libraries, foreign format identification,[citation needed] or explicit address linkage.[citation needed] As development of Unix-like systems continued both inside and outside AT&T, different solutions to these and other issues emerged.

COFF was introduced in 1983, in AT&T's UNIX System V for non-VAX 32-bit platforms such as the 3B20.[citation needed] Improvements over the existing AT&T a.out format included arbitrary sections, explicit processor declarations, and explicit address linkage.

However, the COFF design was both too limited and incompletely specified: there was a limit on the maximum number of sections, a limit on the length of section names, included source files, and the symbolic debugging information was incapable of supporting real world languages such as C, much less newer languages like C++, or new processors. All real world implementations of COFF were necessarily violations of the standard as a result. This led to numerous COFF extensions. IBM used the XCOFF format in AIX; DEC, SGI and others used ECOFF; and numerous SysV ports and tool chains targeting embedded development each created their own, incompatible, variations.

With the release of SVR4, AT&T replaced COFF with ELF.

While extended versions of COFF continue to be used for some Unix and Unix-like platforms, primarily in embedded systems, perhaps the most widespread use of the COFF format today is in Microsoft's Portable Executable (PE) format. Developed for Windows NT, the PE format (sometimes written as PE/COFF) uses a COFF header for object files, and as a component of the PE header for executable files.[3]

Features edit

COFF's main improvement over a.out was the introduction of multiple named sections in the object file. Different object files could have different numbers and types of sections.

Symbolic debugging information edit

The COFF symbolic debugging information consists of symbolic (string) names for program functions and variables, and line number information, used for setting breakpoints and tracing execution.

Symbolic names are stored in the COFF symbol table. Each symbol table entry includes a name, storage class, type, value and section number. Short names (8 characters or fewer) are stored directly in the symbol table; longer names are stored as an offset into the string table at the end of the COFF object.

Storage classes describe the type entity the symbol represents, and may include external variables (C_EXT), automatic (stack) variables (C_AUTO), register variables (C_REG), functions (C_FCN), and many others. The symbol type describes the interpretation of the symbol entity's value and includes values for all the C data types.

When compiled with appropriate options, a COFF object file will contain line number information for each possible break point in the text section of the object file. Line number information takes two forms: in the first, for each possible break point in the code, the line number table entry records the address and its matching line number. In the second form, the entry identifies a symbol table entry representing the start of a function, enabling a breakpoint to be set using the function's name.

Note that COFF was not capable of representing line numbers or debugging symbols for included source as with header files rendering the COFF debugging information virtually useless without incompatible extensions.

Relative virtual address edit

When a COFF file is generated, it is not usually known where in memory it will be loaded. The virtual address where the first byte of the file will be loaded is called image base address. The rest of the file is not necessarily loaded in a contiguous block, but in different sections.

Relative virtual addresses (RVAs) are not to be confused with standard virtual addresses. A relative virtual address is the virtual address of an object from the file once it is loaded into memory, minus the base address of the file image. If the file were to be mapped literally from disk to memory, the RVA would be the same as that of the offset into the file, but this is actually quite unusual.

Note that the RVA term is only used with objects in the image file. Once loaded into memory, the image base address is added, and ordinary VAs are used.

Problems edit

The COFF file header stores the date and time that the object file was created as a 32-bit binary integer, representing the number of seconds since the Unix epoch, 1 January 1970 00:00:00 UTC. Dates occurring after 19 January 2038 cannot be stored in this format, resulting in an instance of the year 2038 problem.[4]: 11–4 

See also edit

References edit

  1. ^ . msdn.microsoft.com. Archived from the original on 2003-08-25. Retrieved 2021-02-04.
  2. ^ "IMAGE_FILE_HEADER structure (winnt.h)". 2018-05-12. Retrieved 2023-12-22.
  3. ^ Microsoft Corporation 2006b
  4. ^ "11 Common Object File Format (COFF)". UNIX System V/386 Release 3.2 Programmer's Guide, Volume II (PDF). Prentice-Hall. 1989. ISBN 0-13-944885-3.

Further reading edit

  • Gircys, Gintaras (1988), Understanding and Using COFF, O'Reilly and Associates, ISBN 0-937175-31-5
  • Microsoft Corporation (2006b), (Revision 4.1 ed.), archived from the original on 2006-12-16, retrieved 2007-06-02
  • "A Brief History of TI Object File Formats". from the original on 2023-11-26.
  • "Common Object File Format" (PDF). Texas Instruments.

External links edit

  • An In-Depth Look into the Win32 Portable Executable File Format and PE format documentation at Microsoft

coff, this, article, needs, additional, citations, verification, please, help, improve, this, article, adding, citations, reliable, sources, unsourced, material, challenged, removed, find, sources, news, newspapers, books, scholar, jstor, march, 2010, learn, w. This article needs additional citations for verification Please help improve this article by adding citations to reliable sources Unsourced material may be challenged and removed Find sources COFF news newspapers books scholar JSTOR March 2010 Learn how and when to remove this template message The Common Object File Format COFF is a format for executable object code and shared library computer files used on Unix systems It was introduced in Unix System V replaced the previously used a out format and formed the basis for extended specifications such as XCOFF and ECOFF before being largely replaced by ELF introduced with SVR4 COFF and its variants continue to be used on some Unix like systems on Microsoft Windows Portable Executable in UEFI environments and in some embedded development systems COFFFilename extensionnone o obj lib 1 Internet media typeapplication x coff application x coffexecMagic number4C 01 for i386 64 86 for AMD64 00 02 for Itanium 2 Developed byAT amp T CorporationType of formatBinary executable object shared librariesExtended toXCOFF ECOFF Portable Executable Executable and Linkable Format Contents 1 History 2 Features 2 1 Symbolic debugging information 2 2 Relative virtual address 3 Problems 4 See also 5 References 6 Further reading 7 External linksHistory editThe original Unix object file format a out is unable to adequately support shared libraries foreign format identification citation needed or explicit address linkage citation needed As development of Unix like systems continued both inside and outside AT amp T different solutions to these and other issues emerged COFF was introduced in 1983 in AT amp T s UNIX System V for non VAX 32 bit platforms such as the 3B20 citation needed Improvements over the existing AT amp T a out format included arbitrary sections explicit processor declarations and explicit address linkage However the COFF design was both too limited and incompletely specified there was a limit on the maximum number of sections a limit on the length of section names included source files and the symbolic debugging information was incapable of supporting real world languages such as C much less newer languages like C or new processors All real world implementations of COFF were necessarily violations of the standard as a result This led to numerous COFF extensions IBM used the XCOFF format in AIX DEC SGI and others used ECOFF and numerous SysV ports and tool chains targeting embedded development each created their own incompatible variations With the release of SVR4 AT amp T replaced COFF with ELF While extended versions of COFF continue to be used for some Unix and Unix like platforms primarily in embedded systems perhaps the most widespread use of the COFF format today is in Microsoft s Portable Executable PE format Developed for Windows NT the PE format sometimes written as PE COFF uses a COFF header for object files and as a component of the PE header for executable files 3 Features editCOFF s main improvement over a out was the introduction of multiple named sections in the object file Different object files could have different numbers and types of sections Symbolic debugging information edit The COFF symbolic debugging information consists of symbolic string names for program functions and variables and line number information used for setting breakpoints and tracing execution Symbolic names are stored in the COFF symbol table Each symbol table entry includes a name storage class type value and section number Short names 8 characters or fewer are stored directly in the symbol table longer names are stored as an offset into the string table at the end of the COFF object Storage classes describe the type entity the symbol represents and may include external variables C EXT automatic stack variables C AUTO register variables C REG functions C FCN and many others The symbol type describes the interpretation of the symbol entity s value and includes values for all the C data types When compiled with appropriate options a COFF object file will contain line number information for each possible break point in the text section of the object file Line number information takes two forms in the first for each possible break point in the code the line number table entry records the address and its matching line number In the second form the entry identifies a symbol table entry representing the start of a function enabling a breakpoint to be set using the function s name Note that COFF was not capable of representing line numbers or debugging symbols for included source as with header files rendering the COFF debugging information virtually useless without incompatible extensions Relative virtual address edit When a COFF file is generated it is not usually known where in memory it will be loaded The virtual address where the first byte of the file will be loaded is called image base address The rest of the file is not necessarily loaded in a contiguous block but in different sections Relative virtual addresses RVAs are not to be confused with standard virtual addresses A relative virtual address is the virtual address of an object from the file once it is loaded into memory minus the base address of the file image If the file were to be mapped literally from disk to memory the RVA would be the same as that of the offset into the file but this is actually quite unusual Note that the RVA term is only used with objects in the image file Once loaded into memory the image base address is added and ordinary VAs are used Problems editThe COFF file header stores the date and time that the object file was created as a 32 bit binary integer representing the number of seconds since the Unix epoch 1 January 1970 00 00 00 UTC Dates occurring after 19 January 2038 cannot be stored in this format resulting in an instance of the year 2038 problem 4 11 4 See also editComparison of executable file formatsReferences edit LIB Reference Embedded Visual C Programmers Guide msdn microsoft com Archived from the original on 2003 08 25 Retrieved 2021 02 04 IMAGE FILE HEADER structure winnt h 2018 05 12 Retrieved 2023 12 22 Microsoft Corporation 2006b 11 Common Object File Format COFF UNIX System V 386 Release 3 2 Programmer s Guide Volume II PDF Prentice Hall 1989 ISBN 0 13 944885 3 Further reading editMIPS COFF Spec Gircys Gintaras 1988 Understanding and Using COFF O Reilly and Associates ISBN 0 937175 31 5 Microsoft Corporation 2006b Common Object File Format COFF Revision 4 1 ed archived from the original on 2006 12 16 retrieved 2007 06 02 A Brief History of TI Object File Formats Archived from the original on 2023 11 26 Common Object File Format PDF Texas Instruments External links editAn In Depth Look into the Win32 Portable Executable File Format and PE format documentation at Microsoft Retrieved from https en wikipedia org w index php title COFF amp oldid 1191972396, wikipedia, wiki, book, books, library,

article

, read, download, free, free download, mp3, video, mp4, 3gp, jpg, jpeg, gif, png, picture, music, song, movie, book, game, games.