Go to the first, previous, next, last section, table of contents.


BFD

The linker accesses object and archive files using the BFD libraries. These libraries allow the linker to use the same routines to operate on object files whatever the object file format. A different object file format can be supported simply by creating a new BFD back end and adding it to the library. To conserve runtime memory, however, the linker and associated tools are usually configured to support only a subset of the object file formats available. You can use objdump -i (see section `objdump' in The GNU Binary Utilities) to list all the formats available for your configuration.

¸µÄ¿´Â BFD ¶óÀ̺귯¸®¸¦ »ç¿ëÇÏ¿© ¿ÀºêÁ§Æ®¿Í ¾ÆÄ«À̺ê ÆÄÀÏ¿¡ Á¢±ÙÇÑ´Ù. ÀÌ ¶óÀ̺귯¸®´Â ¸µÄ¿°¡ °°Àº ÇÔ¼ö¸¦ »ç¿ëÇÏ¿© ¾î¶² ¿ÀºêÁ§Æ® ÆÄÀÏ Çü½Äµµ ´Ù·ê ¼ö ÀÖ°ÔÇÑ´Ù. ´Ù¸¥ ¿ÀºêÁ§Æ® ÆÄÀÏ Çü½ÄÀº »õ·Î¿î BFD ¹é¿£µå¸¦ ¸¸µé°í ¶óÀ̺귯¸®¿¡ Ãß°¡ÇÏ¿© Áö¿øÇÒ ¼ö ÀÖ´Ù. ±×·¯³ª ½ÇÇà Áß ¸Þ¸ð¸®¸¦ Àý¾àÇϱâ À§Çؼ­ ¸µÄ¿ µîÀÇ µµ±¸µéÀº °¡´ÉÇÑ ¿ÀºêÁ§Æ® ÆÄÀÏ Çü½ÄÀÇ ÀϺθ¸À» Áö¿øÇÏ°Ô ¼³Á¤µÈ´Ù. ÇöÀç ¼³Á¤¿¡¼­ »ç¿ë°¡´ÉÇÑ Çü½ÄÀº objdump -iÀ¸·Î (The GNU Binary UtilitiesÀÇ `objdump'À» Âü°í) È®ÀÎÇÒ ¼ö ÀÖ´Ù.

As with most implementations, BFD is a compromise between several conflicting requirements. The major factor influencing BFD design was efficiency: any time used converting between formats is time which would not have been spent had BFD not been involved. This is partly offset by abstraction payback; since BFD simplifies applications and back ends, more time and care may be spent optimizing algorithms for a greater speed.

´ëºÎºÐ ±¸Çö¿¡¼­ BFD´Â ¿©·¯ »óÃæÇÏ´Â Á¶°ÇÀÇ Å¸ÇùÁ¡ÀÌ´Ù. BFD ¼³°è¿¡ ¿µÇâÀ» ÁØ ÁÖµÈ ¿äÀÎÀº È¿À²¼ºÀÌ´Ù. Çü½Ä °£¿¡ º¯È¯ÇÏ´Â ½Ã°£Àº BFD¸¦ »ç¿ëÇÏÁö ¾ÊÀ¸¸é ÇÊ¿äÇÏÁö ¾Ê´Â ½Ã°£ÀÌ´Ù. ÀÌ´Â ºÎºÐÀûÀ¸·Î Ãß»óÈ­ÀÇ ºñ¿ëÀÌ´Ù. ±× ´ë½Å BFD°¡ ÇÁ·Î±×·¥°ú ¹é¿£µå¸¦ °£´ÜÇÏ°Ô ÇÏ¿©, ºü¸¥ ¼Óµµ¸¦ À§ÇØ ¾Ë°í¸®ÁòÀ» ÃÖÀûÈ­Çϴµ¥ ´õ ¸¹Àº ½Ã°£°ú ³ë·ÂÀÌ µéÀÏ ¼ö ÀÖ´Ù.

One minor artifact of the BFD solution which you should bear in mind is the potential for information loss. There are two places where useful information can be lost using the BFD mechanism: during conversion and during output. See section Information Loss.
BFD¸¦ »ç¿ëÇÒ ¶§ ¿°µÎÇÒ Á¡Àº Á¤º¸ ¼Õ½ÇÀÇ °¡´É¼ºÀÌ´Ù. BFD¸¦ »ç¿ëÇÏ¸é º¯È¯°ú Ãâ·Â µÎ ºÎºÐ¿¡¼­ À¯¿ëÇÑ Á¤º¸°¡ ¼Õ½ÇµÉ ¼ö ÀÖ´Ù. Information Loss¸¦ Âü°íÇ϶ó.

¾î¶»°Ô ÀÛµ¿Çϳª, BFD °³°ü

When an object file is opened, BFD subroutines automatically determine the format of the input object file. They then build a descriptor in memory with pointers to routines that will be used to access elements of the object file's data structures.
¿ÀºêÁ§Æ® ÆÄÀÏÀ» ¿­¸é BFD´Â ÀÚµ¿À¸·Î ÆÄÀÏÀÇ Çü½ÄÀ» ÆÇ´ÜÇÑ´Ù. ±×¸®°í ¿ÀºêÁ§Æ® ÆÄÀÏ ÀڷᱸÁ¶¿¡ Á¢±ÙÇÏ´Â ÇÔ¼öÀÇ Æ÷ÀÎÅ͸¦ ¸¸µç´Ù.

As different information from the the object files is required, BFD reads from different sections of the file and processes them. For example, a very common operation for the linker is processing symbol tables. Each BFD back end provides a routine for converting between the object file's representation of symbols and an internal canonical format. When the linker asks for the symbol table of an object file, it calls through a memory pointer to the routine from the relevant BFD back end which reads and converts the table into a canonical form. The linker then operates upon the canonical form. When the link is finished and the linker writes the output file's symbol table, another BFD back end routine is called to take the newly created symbol table and convert it into the chosen output format.

¿ÀºêÁ§Æ® ÆÄÀÏ¿¡¼­ ´Ù¸¥ Á¤º¸°¡ ÇÊ¿äÇϸé BFD´Â ÆÄÀÏÀÇ ´Ù¸¥ ¼½¼Ç¿¡¼­ Àаí ó¸®ÇÑ´Ù. ¿¹¸¦ µé¾î ¸µÄ¿ÀÇ ÁÖµÈ ±â´ÉÀº ½Éº¼Ç¥¸¦ ó¸®ÀÌ´Ù. °¢ BFD ¹é¿£µå´Â ¿ÀºêÁ§Æ® ÆÄÀÏÀÇ ½Éº¼ Ç¥ÇöÀ» ³»ºÎ Ç¥ÁØ Çü½ÄÀ¸·Î º¯È¯ÇÏ´Â ÇÔ¼ö¸¦ °¡Áö°í ÀÖ´Ù. ¸µÄ¿°¡ ¿ÀºêÁ§Æ® ÆÄÀÏÀÇ ½Éº¼Ç¥¸¦ ¿ä±¸Çϸé, °ü·Ã BFD ¹é¿£µåÀÇ ÇÔ¼ö Æ÷ÀÎÅ͸¦ »ç¿ëÇÏ¿© ½Éº¼À» Àо Ç¥ÁØ Çü½ÄÀ¸·Î º¯È¯ÇÑ´Ù. ±× ÈÄ ¸µÄ¿´Â Ç¥ÁØ Çü½ÄÀ» °¡Áö°í ÀÛ¾÷À» ÇÑ´Ù. ¸µÅ©°¡ ³¡³ª¸é ¸µÄ¿´Â »õ·Î ¸¸µç ½Éº¼Ç¥¸¦ Ãâ·Â Çü½ÄÀ¸·Î º¯È¯ÇÏ´Â BFD ¹é¿£µå ÇÔ¼ö¸¦ »ç¿ëÇÏ¿© Ãâ·ÂÆÄÀÏ¿¡ ½Éº¼Ç¥¸¦ ÀÛ¼ºÇÑ´Ù.

Á¤º¸ ¼Õ½Ç

Information can be lost during output. The output formats supported by BFD do not provide identical facilities, and information which can be described in one form has nowhere to go in another format. One example of this is alignment information in b.out. There is nowhere in an a.out format file to store alignment information on the contained data, so when a file is linked from b.out and an a.out image is produced, alignment information will not propagate to the output file. (The linker will still use the alignment information internally, so the link is performed correctly).

Á¤º¸´Â Ãâ·Â Áß¿¡ ¼Õ½ÇµÉ ¼ö ÀÖ´Ù. BFD°¡ Áö¿øÇÏ´Â Ãâ·Â Çü½ÄµéÀÌ °°Àº ±â´ÉÀ» Á¦°øÇÏÁö ¾Ê±â ¶§¹®¿¡ ÇÑ Çü½Ä¿¡ ÀúÀåµÈ Á¤º¸°¡ ´Ù¸¥ Çü½Ä¿¡¼­´Â ÇØ´ç Ç׸ñÀÌ ¾øÀ» ¼ö ÀÖ´Ù. ÀÌ ¿¹´Â b.out¿¡ ÀúÀåµÈ Á¤·Ä Á¤º¸ÀÌ´Ù. ÀÌ Á¤º¸´Â Á¤·Ä Á¤º¸¸¦ ÀÚ·á¿¡ ÀúÀåÇÏ´Â a.out¿¡´Â ÇØ´çÀÌ ¾ø´Ù. ±×·¡¼­ b.out°ú a.out Çü½ÄÀÇ ÆÄÀÏÀ» °°ÀÌ ¸µÅ©Çϸé Á¤·Ä Á¤º¸¸¦ Ãâ·ÂÆÄÀÏ¿¡ ÀúÀåµÇÁö ¾Ê´Â´Ù. (±×·¡µµ ¸µÄ¿´Â ³»ºÎÀûÀ¸·Î Á¤·Ä Á¤º¸¸¦ »ç¿ëÇÏ¿© ¸µÅ©´Â ¿Ã¹Ù¸£°Ô ¼öÇàÇÑ´Ù.)

Another example is COFF section names. COFF files may contain an unlimited number of sections, each one with a textual section name. If the target of the link is a format which does not have many sections (e.g., a.out) or has sections without names (e.g., the Oasys format), the link cannot be done simply. You can circumvent this problem by describing the desired input-to-output section mapping with the linker command language.

´Ù¸¥ ¿¹´Â COFF ¼½¼Ç À̸§ÀÌ´Ù. COFF ÆÄÀÏÀº À̸§À» °¡Áö´Â ¼½¼ÇÀ» ¹«Á¦ÇÑ °¡Áú ¼ö ÀÖ´Ù. ¸µÅ©ÀÇ ´ë»óÀÌ (a.out °°ÀÌ) ¸¹Àº ¼½¼ÇÀ» °¡ÁöÁö ¸øÇÏ´Â Çü½ÄÀ̰ųª (Oasys °°ÀÌ) Çü½ÄÀÌ ¼½¼Ç À̸§À» °¡ÁöÁö ¸øÇÑ´Ù¸é ¸µÅ©´Â °£´ÜÈ÷ ¼öÇàµÉ ¼ö ¾ø´Ù. ÀÌ ¹®Á¦¸¦ ÇØ°áÇϱâ À§Çؼ­ Á÷Á¢ ÀÔ·Â ¼½¼ÇÀ» Ãâ·Â ¼½¼ÇÀ¸·Î ´ëÀÀ½ÃÅ°´Â ¸µÄ¿ ¸í·É¾î ¾ð¾î¸¦ »ç¿ëÇØ¾ß ÇÑ´Ù.

Information can be lost during canonicalization. The BFD internal canonical form of the external formats is not exhaustive; there are structures in input formats for which there is no direct representation internally. This means that the BFD back ends cannot maintain all possible data richness through the transformation between external to internal and back to external formats.

Á¤º¸´Â Ç¥ÁØÈ­ °úÁ¤¿¡¼­ ¼Õ½ÇµÉ ¼ö ÀÖ´Ù. ¿ÜºÎ Çü½Ä¿¡ ´ëÇÑ BFD ³»ºÎ Ç¥ÁØ Çü½ÄÀº ¸ðµç °æ¿ì¸¦ ó¸®ÇÏÁö ¸øÇϱ⠶§¹®¿¡ ÀÔ·Â ¼½¼ÇÀÇ ±¸Á¶¿Í Á÷Á¢ ¿¬°üµÈ ³»ºÎ ±¸Á¶°¡ ¾øÀ» ¼ö ÀÖ´Ù. ±×·¡¼­ BFD ¹é¿£µå´Â À§ºÎ¿Í ³»ºÎ, ´Ù½Ã ¿ÜºÎ·Î º¯È¯ÇÏ´Â °úÁ¤¿¡¼­ °¡´ÉÇÑ Á¤º¸¸¦ À¯Áö¸øÇÒ ¼ö ÀÖ´Ù.

This limitation is only a problem when an application reads one format and writes another. Each BFD back end is responsible for maintaining as much data as possible, and the internal BFD canonical form has structures which are opaque to the BFD core, and exported only to the back ends. When a file is read in one format, the canonical form is generated for BFD and the application. At the same time, the back end saves away any information which may otherwise be lost. If the data is then written back in the same format, the back end routine will be able to use the canonical form provided by the BFD core as well as the information it prepared earlier. Since there is a great deal of commonality between back ends, there is no information lost when linking or copying big endian COFF to little endian COFF, or a.out to b.out. When a mixture of formats is linked, the information is only lost from the files whose format differs from the destination.

ÀÌ Á¦ÇÑÀº ÇÁ·Î±×·¥ÀÌ ÇÑ Çü½ÄÀ¸·Î Àо ´Ù¸¥ Çü½ÄÀ¸·Î ¾µ ¶§¸¸ ¹®Á¦°¡ µÈ´Ù. °¢ BFD º¤¿£µå´Â °¡´ÉÇÑ ¸¹Àº Á¤º¸¸¦ À¯ÁöÇÏ°í, BFD ³»ºÎ Ç¥ÁØ Çü½ÄÀº BFD Çٽɰú º°µµ·Î ¹é¿£µå¿¡¸¸ ÀͽºÆ÷Æ®µÇ´Â ±¸Á¶¸¦ °¡Áö°í ÀÖ´Ù. ÇÑ Çü½ÄÀ¸·Î ÀÐÀ¸¸é BFD¿Í ÇÁ·Î±×·¥À» À§ÇØ Ç¥ÁØ Çü½ÄÀÌ »ý¼ºµÈ´Ù. µ¿½Ã¿¡ ¹é¿£µå´Â ±×·¸Áö ¾ÊÀ¸¸é ¼Õ½ÇµÇ´Â Á¤º¸¸¦ ÀúÀåÇÑ´Ù. ÀÚ·á°¡ ´Ù½Ã °°Àº Çü½ÄÀ¸·Î ¾²¿©Áø´Ù¸é ¹é¿£µå´Â BFD Çٽɿ¡¼­ Á¦°øµÇ´Â Ç¥ÁØ Çü½Ä°ú ÀÌ¹Ì ÀúÀåµÈ Á¤º¸¸¦ ¸ðµÎ ÀÌ¿ëÇÑ´Ù. ¹é¿£µå °£¿¡ À¯»çÁ¡ÀÌ ¸¹ÀÌ ¶§¹®¿¡ big endian COFF¸¦ little endian COFF·Î ȤÀº a.outÀ» b.out·Î º¹»çÇϰųª ¸µÅ©ÇÒ ¶§ ¼Õ½ÇµÇ´Â Á¤º¸´Â ¾ø´Ù. ¿©·¯ Çü½ÄÀ» °°ÀÌ ¸µÅ©ÇÒ ¶§ °á°ú¿Í ´Ù¸¥ Çü½ÄÀÇ ÆÄÀÏ¿¡¼­¸¸ Á¤º¸ ¼Õ½ÇÀÌ ÀÖ´Ù.

BFD Ç¥ÁØ ¿ÀºêÁ§Æ® ÆÄÀÏ Çü½Ä

The greatest potential for loss of information occurs when there is the least overlap between the information provided by the source format, that stored by the canonical format, and that needed by the destination format. A brief description of the canonical form may help you understand which kinds of data you can count on preserving across conversions.

Ç¥ÁØ Çü½ÄÀ¸·Î ÀúÀåµÇ°í °á°ú¸¦ À§ÇØ »ç¿ëµÇ´Â, ÀÔ·Â Çü½ÄÀÇ Á¤º¸µé »çÀÌ¿¡ °øÅëÁ¡ÀÌ ÀûÀ» ¶§ Á¤º¸ ¼Õ½Ç °¡´É¼ºÀÌ Å©´Ù. Ç¥ÁØ Çü½ÄÀÇ ¼³¸íÀÌ º¯È¯°£¿¡ À¯ÁöµÇ´Â Á¤º¸¸¦ ÀÌÇØÇϴµ¥ µµ¿òÀÌ µÉ °ÍÀÌ´Ù.

files
Information stored on a per-file basis includes target machine architecture, particular implementation format type, a demand pageable bit, and a write protected bit. Information like Unix magic numbers is not stored here--only the magic numbers' meaning, so a ZMAGIC file would have both the demand pageable bit and the write protected text bit set. The byte order of the target is stored on a per-file basis, so that big- and little-endian object files may be used with one another.
ÆÄÀÏ ´ÜÀ§·Î ÀúÀåµÇ´Â Á¤º¸¿¡´Â ´ë»ó ¾ÆÅ°ÅØó, ƯÁ¤ ±¸Çö Çü½Ä, ÆäÀÌÁö ¿ä±¸ ºñÆ®, ¾²±â º¸È£ ºñÆ®°¡ ÀÖ´Ù. À¯´Ð½º ¸ÞÁ÷³Ñ¹ö¿Í °°Àº Á¤º¸´Â ¿©±â¿¡ Æ÷ÇÔµÇÁö ¾Ê´Â´Ù. ´Ü ÆäÀÌÁö ¿ä±¸ ºñÆ®¿Í ¾²±â º¸È£ ºñÆ®¸¦ ¼³Á¤ÇÏ´Â ZMAGIC°ú °°ÀÌ ¸ÞÁ÷³Ñ¹öÀÇ Àǹ̴ Æ÷ÇÔÀÌ µÈ´Ù. ´ë»óÀÇ ¹ÙÀÌÆ® ¼ø¼­´Â ÆÄÀÏ ´ÜÀ§·Î ÀúÀåµÇ±â ¶§¹®¿¡ big endian°ú little endian ÆÄÀÏÀ» °°ÀÌ »ç¿ëÇÒ ¼ö ÀÖ´Ù.
sections
Each section in the input file contains the name of the section, the section's original address in the object file, size and alignment information, various flags, and pointers into other BFD data structures.
ÀÔ·ÂÆÄÀÏÀÇ °¢ ¼½¼ÇÀº ¼½¼Ç À̸§, ¿ÀºêÁ§Æ® ÆÄÀÏ¿¡¼­ ¼½¼ÇÀÇ ÁÖ¼Ò, Å©±â, Á¤·Ä Á¤º¸, ¸¹Àº Ç÷¡±×, ´Ù¸¥ BFD ÀڷᱸÁ¶¿¡ Æ÷ÀÎÅ͸¦ Æ÷ÇÔÇÑ´Ù.
symbols
Each symbol contains a pointer to the information for the object file which originally defined it, its name, its value, and various flag bits. When a BFD back end reads in a symbol table, it relocates all symbols to make them relative to the base of the section where they were defined. Doing this ensures that each symbol points to its containing section. Each symbol also has a varying amount of hidden private data for the BFD back end. Since the symbol points to the original file, the private data format for that symbol is accessible. ld can operate on a collection of symbols of wildly different formats without problems. Normal global and simple local symbols are maintained on output, so an output file (no matter its format) will retain symbols pointing to functions and to global, static, and common variables. Some symbol information is not worth retaining; in a.out, type information is stored in the symbol table as long symbol names. This information would be useless to most COFF debuggers; the linker has command line switches to allow users to throw it away. There is one word of type information within the symbol, so if the format supports symbol type information within symbols (for example, COFF, IEEE, Oasys) and the type is simple enough to fit within one word (nearly everything but aggregates), the information will be preserved.
°¢ ½Éº¼Àº ½Éº¼À» Á¤ÀÇÇÑ ¿ÀºêÁ§Æ® ÆÄÀÏ Á¤º¸ÀÇ Æ÷ÀÎÅÍ, À̸§, °ª, ¸¹Àº Ç÷¡±× ºñÆ®¸¦ Æ÷ÇÔÇÑ´Ù. BFD ¹é¿£µå°¡ ½Éº¼Ç¥¸¦ ÀÐÀ¸¸é ¸ðµç ½Éº¼À» Á¤ÀÇµÈ ¼½¼Ç¿¡ »ó´ëÀûÀ¸·Î ¸¸µç´Ù. ÀÌ´Â °¢ ½Éº¼ÀÌ ½Éº¼À» Æ÷ÇÔÇÏ´Â ¼½¼ÇÀ» °¡¸®Å°°Ô ÇÑ´Ù. ¶Ç °¢ ½Éº¼Àº BFD ¹é¿£µå¿¡ ¸¹Àº ¼û°ÜÁø Á¤º¸¸¦ °¡Áø´Ù. ½Éº¼ÀÌ ¿ø·¡ ÆÄÀÏÀ» °¡¸®Å°±â ¶§¹®¿¡ ½Éº¼¿¡ ´ëÇÑ »çÀûÀÎ ÀڷḦ ÀÌ¿ëÇÒ ¼ö ÀÖ´Ù. ±×·¡¼­ ¸µÄ¿´Â ¹®Á¦¾øÀÌ ´Ù¸¥ Çü½ÄÀÇ ½Éº¼µéÀ» ´Ù·ê ¼ö ÀÖ´Ù. º¸Åë Àü¿ª ½Éº¼°ú Áö¿ª ½Éº¼Àº Ãâ·Â¿¡ À¯ÁöµÇ±â ¶§¹®¿¡ Ãâ·ÂÆÄÀÏÀº (Çü½Ä°ú °ü°è¾øÀÌ) ÇÔ¼ö¿Í Àü¿ª, Á¤Àû, °øÅë º¯¼öÀÇ ½Éº¼À» À¯ÁöÇÑ´Ù. a.out¿¡¼­ ±ä ½Éº¼¸íÀ¸·Î ½Éº¼Ç¥¿¡ ÀúÀåµÇ´Â ŸÀÔ Á¤º¸¿Í °°Àº Á¤º¸´Â À¯ÁöÇÒ ÇÊ¿ä°¡ ¾ø´Ù. ÀÌ Á¤º¸´Â ´ëºÎºÐ COFF µð¹ö°Å¿¡°Ô ÇÊ¿ä°¡ ¾ø´Ù. ¿É¼ÇÀ¸·Î ¸µÄ¿°¡ ÀÌ Á¤º¸¸¦ ¹ö¸®°Ô ÇÑ´Ù. ½Éº¼ ¾È¿¡ ŸÀÔ Á¤º¸ ¿öµå°¡ ÀÖ´Ù. ±×·¡¼­ (COFF, IEEE, Oasys¿Í °°ÀÌ) Çü½ÄÀÌ ½Éº¼ ¾È¿¡ ½Éº¼ ŸÀÔ Á¤º¸¸¦ Áö¿øÇϸé Á¤º¸´Â À¯ÁöµÈ´Ù.
relocation level
Each canonical BFD relocation record contains a pointer to the symbol to relocate to, the offset of the data to relocate, the section the data is in, and a pointer to a relocation type descriptor. Relocation is performed by passing messages through the relocation type descriptor and the symbol pointer. Therefore, relocations can be performed on output data using a relocation method that is only available in one of the input formats. For instance, Oasys provides a byte relocation format. A relocation record requesting this relocation type would point indirectly to a routine to perform this, so the relocation may be performed on a byte being written to a 68k COFF file, even though 68k COFF has no such relocation type.
°¢ BFD Ç¥ÁØ Àç¹èÄ¡ ±â·ÏÀº Àç¹èÄ¡ÇÒ ½Éº¼ÀÇ ÂüÁ¶, Àç¹èÄ¡ÇÒ ÀÚ·áÀÇ ¿É¼Ë, ÀڷḦ Æ÷ÇÔÇÏ´Â ¼½¼Ç, Àç¹èÄ¡ ŸÀÔ ±â¼úÀÇ Æ÷ÀÎÅ͸¦ ÀúÀåÇÑ´Ù. Àç¹èÄ¡´Â Àç¹èÄ¡ ŸÀÔ ±â¼ú°ú ½Éº¼ Æ÷ÀÎÅ͸¦ »ç¿ëÇÏ¿© ¼öÇàµÈ´Ù. ±×·¡¼­ ÀÔ·Â Çü½Ä¿¡ ÀÖ´Â Àç¹èÄ¡ ¹æ¹ýÀ» »ç¿ëÇÏ¿© Ãâ·Â ÀڷḦ Àç¹èÄ¡ÇÑ´Ù. ¿¹¸¦ µé¾î Oasys´Â ¹ÙÀÌÆ® Àç¹èÄ¡ Çü½ÄÀ» Á¦°øÇÑ´Ù. ÀÌ Á¾·ùÀÇ Àç¹èÄ¡ ±â·ÏÀº ¼öÇàÇÒ ÇÔ¼ö¸¦ °£Á¢ÀûÀ¸·Î Áö½ÃÇÏ¿© 68k COFF°¡ ÀÌ Á¾·ùÀÇ Àç¹èÄ¡°¡ ¾ø´ÙÇÏ´õ¶óµµ 68k COFF ÆÄÀÏ·Î Ãâ·ÂµÇ´Â ¹ÙÀÌÆ®¿¡ Àç¹èÄ¡¸¦ ¼öÇàÇÑ´Ù.
line numbers
Object formats can contain, for debugging purposes, some form of mapping between symbols, source line numbers, and addresses in the output file. These addresses have to be relocated along with the symbol information. Each symbol with an associated list of line number records points to the first record of the list. The head of a line number list consists of a pointer to the symbol, which allows finding out the address of the function whose line number is being described. The rest of the list is made up of pairs: offsets into the section and line numbers. Any format which can simply derive this information can pass it successfully between formats (COFF, IEEE and Oasys).
¿ÀºêÁ§Æ® Çü½ÄÀº µð¹ö±ëÀ» À§ÇØ ½Éº¼°ú ¼Ò½º ÁÙ¹øÈ£, Ãâ·Â ÆÄÀÏ°ú ÁÖ¼Ò °£ÀÇ ´ëÀÀÀ» ÀúÀåÇÑ´Ù. ÀÌ ÁÖ¼Ò´Â ½Éº¼ Á¤º¸¿Í °°ÀÌ Àç¹èÄ¡µÇ¾ß ÇÑ´Ù. ÁÙ¹øÈ£ ¸ñ·ÏÀÇ °¢ ½Éº¼Àº ¸ñ·ÏÀÇ Ã³À½À» °¡¸®Å²´Ù. ÁÙ¹øÈ£ ¸ñ·ÏÀÇ ¾ÕÀº ÁÙ¹øÈ£°¡ ³ªÅ¸³»´Â ÇÔ¼ö ÁÖ¼Ò¸¦ ã´Âµ¥ »ç¿ëÇÏ´Â ½Éº¼ÀÇ Æ÷ÀÎÅ͸¦ Æ÷ÇÔÇÑ´Ù. ¸ñ·ÏÀÇ ³ª¸ÓÁö´Â ¼½¼Ç¿¡¼­ÀÇ ¿É¼Â°ú ÁÙ¹øÈ£ ½ÖÀ¸·Î ÀÌ·ç¾îÁ®ÀÖ´Ù. ÀÌ Á¤º¸¸¦ ½±°Ô ¾òÀ» ¼ö ÀÖ´Â (COFF, IEEE, Oasys) Çü½ÄÀº ÀÌ Á¤º¸¸¦ Çü½Äµé °£¿¡ Àü´ÞÇÒ ¼ö ÀÖ´Ù.


Go to the first, previous, next, last section, table of contents.