Annotation of GNUtools/cctools/include/mach-o/reloc.h, revision 1.1

1.1     ! root        1: /*
        !             2:  * Copyright (c) 1980 Regents of the University of California.
        !             3:  * All rights reserved.  The Berkeley software License Agreement
        !             4:  * specifies the terms and conditions for redistribution.
        !             5:  *
        !             6:  *     @(#)a.out.h     5.1 (Berkeley) 5/30/85
        !             7:  *
        !             8:  * The structure this file describes was originally taken from the above file
        !             9:  * and the above copyright has been carried over to this file.
        !            10:  */
        !            11: 
        !            12: #ifndef _MACHO_RELOC_H_
        !            13: #define _MACHO_RELOC_H_
        !            14: 
        !            15: /*
        !            16:  * Format of a relocation entry of a Mach-O file.  Modified from the 4.3BSD
        !            17:  * format.  The modifications from the original format were changing the value
        !            18:  * of the r_symbolnum field for "local" (r_extern == 0) relocation entries.
        !            19:  * This modification is required to support symbols in an arbitrary number of
        !            20:  * sections not just the three sections (text, data and bss) in a 4.3BSD file.
        !            21:  * Also the last 4 bits have had the r_type tag added to them.
        !            22:  */
        !            23: struct relocation_info {
        !            24:    long                r_address;      /* offset in the section to what is being
        !            25:                                   relocated */
        !            26:    unsigned int r_symbolnum:24,        /* symbol index if r_extern == 1 or section
        !            27:                                   ordinal if r_extern == 0 */
        !            28:                r_pcrel:1,      /* was relocated pc relative already */
        !            29:                r_length:2,     /* 0=byte, 1=word, 2=long */
        !            30:                r_extern:1,     /* does not include value of sym referenced */
        !            31:                r_type:4;       /* if not 0, machine specific relocation type */
        !            32: };
        !            33: #define        R_ABS   0               /* absolute relocation type for Mach-O files */
        !            34: 
        !            35: /*
        !            36:  * The r_address is not really the address as it's name indicates but an offset.
        !            37:  * In 4.3BSD a.out objects this offset is from the start of the "segment" for
        !            38:  * which relocation entry is for (text or data).  For Mach-O object files it is
        !            39:  * also an offset but from the start of the "section" for which the relocation
        !            40:  * entry is for.
        !            41:  * 
        !            42:  * In 4.3BSD a.out objects if r_extern is zero then r_symbolnum is an ordinal
        !            43:  * for the segment the symbol being relocated is in.  These ordinals are the
        !            44:  * symbol types N_TEXT, N_DATA, N_BSS or N_ABS.  In Mach-O object files these
        !            45:  * ordinals refer to the sections in the object file in the order their section
        !            46:  * structures appear in the headers of the object file they are in.  The first
        !            47:  * section has the ordinal 1, the second 2, and so on.  This means that the
        !            48:  * same ordinal in two different object files could refer to two different
        !            49:  * sections.  And further could have still different ordinals when combined
        !            50:  * by the link-editor.  The value R_ABS is used for relocation entries for
        !            51:  * absolute symbols which need no further relocation.
        !            52:  */
        !            53: 
        !            54: /*
        !            55:  * For RISC machines some of the references are split across two instructions
        !            56:  * and the instruction does not contain the complete value of the reference.
        !            57:  * In these cases a second, or paired relocation entry, follows each of these
        !            58:  * relocation entries, using a PAIR r_type, which contains the other part of the
        !            59:  * reference not contained in the instruction.  This other part is stored in the
        !            60:  * pair's r_address field.  The exact number of bits of the other part of the
        !            61:  * reference store in the r_address field is dependent on the particular
        !            62:  * relocation type for the particular architecture.
        !            63:  */
        !            64: 
        !            65: /*
        !            66:  * To make scattered loading by the link editor work correctly "local"
        !            67:  * relocation entries can't be used when the item to be relocated is the value
        !            68:  * of a symbol plus an offset (where the resulting expresion is outside the
        !            69:  * block the link editor is moving, a blocks are divided at symbol addresses).
        !            70:  * In this case. where the item is a symbol value plus offset, the link editor
        !            71:  * needs to know more than just the section the symbol was defined.  What is
        !            72:  * needed is the actual value of the symbol without the offset so it can do the
        !            73:  * relocation correctly based on where the value of the symbol got relocated to
        !            74:  * not the value of the expression (with the offset added to the symbol value).
        !            75:  * So for the NeXT 2.0 release no "local" relocation entries are ever used when
        !            76:  * there is a non-zero offset added to a symbol.  The "external" and "local"
        !            77:  * relocation entries remain unchanged.
        !            78:  *
        !            79:  * The implemention is quite messy given the compatibility with the existing
        !            80:  * relocation entry format.  The ASSUMPTION is that a section will never be
        !            81:  * bigger than 2**24 - 1 (0x00ffffff or 16,777,215) bytes.  This assumption
        !            82:  * allows the r_address (which is really an offset) to fit in 24 bits and high
        !            83:  * bit of the r_address field in the relocation_info structure to indicate
        !            84:  * it is really a scattered_relocation_info structure.  Since these are only
        !            85:  * used in places where "local" relocation entries are used and not where
        !            86:  * "external" relocation entries are used the r_extern field has been removed.
        !            87:  *
        !            88:  * For scattered loading to work on a RISC machine where some of the references
        !            89:  * are split across two instructions the link editor needs to be assured that
        !            90:  * each reference has a unique 32 bit reference (that more than one reference is
        !            91:  * NOT sharing the same high 16 bits for example) so it move each referenced
        !            92:  * item independent of each other.  Some compilers guarantees this but the
        !            93:  * compilers don't so scattered loading can be done on those that do guarantee
        !            94:  * this.
        !            95:  */
        !            96: #if defined(__BIG_ENDIAN__) || defined(__LITTLE_ENDIAN__)
        !            97: /*
        !            98:  * The reason for the ifdef's of __BIG_ENDIAN__ and __LITTLE_ENDIAN__ are that
        !            99:  * when stattered relocation entries were added the mistake of using a mask
        !           100:  * against a structure that is made up of bit fields was used.  To make this
        !           101:  * design work this structure must be laid out in memory the same way so the
        !           102:  * mask can be applied can check the same bit each time (r_scattered).
        !           103:  */
        !           104: #endif /* defined(__BIG_ENDIAN__) || defined(__LITTLE_ENDIAN__) */
        !           105: #define R_SCATTERED 0x80000000 /* mask to be applied to the r_address field 
        !           106:                                   of a relocation_info structure to tell that
        !           107:                                   is is really a scattered_relocation_info
        !           108:                                   stucture */
        !           109: struct scattered_relocation_info {
        !           110: #ifdef __BIG_ENDIAN__
        !           111:    unsigned int r_scattered:1, /* 1=scattered, 0=non-scattered (see above) */
        !           112:                r_pcrel:1,      /* was relocated pc relative already */
        !           113:                r_length:2,     /* 0=byte, 1=word, 2=long */
        !           114:                r_type:4,       /* if not 0, machine specific relocation type */
        !           115:                r_address:24;   /* offset in the section to what is being
        !           116:                                   relocated */
        !           117:    long                r_value;        /* the value the item to be relocated is
        !           118:                                   refering to (without any offset added) */
        !           119: #endif /* __BIG_ENDIAN__ */
        !           120: #ifdef __LITTLE_ENDIAN__
        !           121:    unsigned int
        !           122:                r_address:24,   /* offset in the section to what is being
        !           123:                                   relocated */
        !           124:                r_type:4,       /* if not 0, machine specific relocation type */
        !           125:                r_length:2,     /* 0=byte, 1=word, 2=long */
        !           126:                r_pcrel:1,      /* was relocated pc relative already */
        !           127:                r_scattered:1;  /* 1=scattered, 0=non-scattered (see above) */
        !           128:    long                r_value;        /* the value the item to be relocated is
        !           129:                                   refering to (without any offset added) */
        !           130: #endif /* __LITTLE_ENDIAN__ */
        !           131: };
        !           132: 
        !           133: /*
        !           134:  * Relocation types used in a generic implementation.  Relocation entries for
        !           135:  * nornal things use the generic relocation as discribed above and their r_type
        !           136:  * is GENERIC_RELOC_VANILLA (a value of zero).
        !           137:  *
        !           138:  * The other type of generic relocation, GENERIC_RELOC_SECTDIFF, is to support
        !           139:  * the difference of two symbols defined in different sections.  That is the
        !           140:  * expression "symbol1 - symbol2 + constant" is a relocatable expression when
        !           141:  * both symbols are defined in some section.  For this type of relocation the
        !           142:  * both relocations entries are scattered relocation entries.  The value of
        !           143:  * symbol1 is stored in the first relocation entry's r_value field and the
        !           144:  * value of symbol2 is stored in the pair's r_value field.
        !           145:  */
        !           146: enum reloc_type_generic
        !           147: {
        !           148:     GENERIC_RELOC_VANILLA,     /* generic relocation as discribed above */
        !           149:     GENERIC_RELOC_PAIR,                /* Only follows a GENRIC_RELOC_SECTDIFF */
        !           150:     GENERIC_RELOC_SECTDIFF
        !           151: };
        !           152: 
        !           153: #endif /* _MACHO_RELOC_H_ */

unix.superglobalmegacorp.com

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.